From nobody Sun Nov 1 16:57:20 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0403A0B58; Sun, 1 Nov 2020 16:57:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160427863467.23607.17022367772306047140@ietfa.amsl.com> Date: Sun, 01 Nov 2020 16:57:14 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 00:57:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-09.txt Pages : 37 Date : 2020-11-01 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 17:02:36 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB03A082F for ; Sun, 1 Nov 2020 17:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=eTuXZV1M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C40KKuGh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cvwQiP8Ju_I for ; Sun, 1 Nov 2020 17:02:32 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E0F3A07F9 for ; Sun, 1 Nov 2020 17:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3080; q=dns/txt; s=iport; t=1604278952; x=1605488552; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BQQjr9I0joHTBNwgXsJm9nmLcS7RcguGUjBtMDoLswo=; b=eTuXZV1MV1vhyCXsMgdKJgiUrFQkQEOizCebW9KS+pUULjG2RWpPSADo 953w85flWep2gSuTEqTbBd/97vi3Sm44jP8aDSa99Rq0q9nSTdtXUXAy0 dRy+cXBpgCKqQsqCoH7grgNzP+1I2gb0mIHtpcM9vf6ith6t/yZxvzsuv 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AMjfA7RKwOTY0NUwEKdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpHwArWp9f/5NdJa1hHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQEVgU8CgVBRB3BZLy4Kh3wDjUyYf4JTA1QLAQEBDQEBGA0IAgQ?= =?us-ascii?q?BAYQGRAKCBwIlNwYOAgMBAQsBAQUBAQECAQYEcYVhAQuFcgEBAQQBARAoBgE?= =?us-ascii?q?BLAwLBAIBCBEBAwEBHxAnCxcGCAIEEwgagwWCSwMtAQEOowcCgTuIaHSBNIM?= =?us-ascii?q?EAQEFgTMBAwIOQYMXGIIQCYE4AYJxgmFOhxkbgUE/gVSCTz6CXQEBAgEBFYF?= =?us-ascii?q?Ig0iCLJAqp3gKgmyJCJIggxiBKohnlEGTSoF+iHqRFoQxAgQCBAUCDgEBBYF?= =?us-ascii?q?qJIFXcBUaIYI1AQEyCUcXAg2OKxeDToUUhUR0OAIGCgEBAwl8jDsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,443,1596499200"; d="scan'208";a="745924920" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Nov 2020 01:02:31 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A212Sfr020160 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Nov 2020 01:02:31 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 19:02:30 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 19:02:27 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 1 Nov 2020 19:02:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QMBfcJ74aq2fubiUomkf4y9Nk1VHtOfB43yF4nfmHcw679WdDP4U+mzUI+BYK9achCQ/Wa+JKnL5lriEHHImfnsFp5KWIskLQPjkQ1D/UqTHazsXuFgO187754PedEKief4Qp7S8B5oSOlmlV63e6ig0HtUDhhl2DB1DHEyB89tEMx5dyPbpehdFxzPMN7TdcmdnDj/ZVupdK1xssFk6kJ6g3yi0qoZo4UryqBhEm/oD27rLsrNj6hG6I2YCXl+Yt/FG39DrA8UwPJw2mfIGAVYpK1pzrCgwKF61gzNJR0hiB+/FPuNDwa5P10GU6gbv/3NS6tsOUtV2p7TfHBqoGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XNrb/h6iRyVqAbBVg/M1DURJQmZViDhIIaw/7DLJbQs=; b=I1uBmauD1fm+bByxfHXj1vf147dlBN7ngMLFG6UxTz3FtzvZmCWeECwV/VrWBKfm+E4/g1/zQVQ/rTbUyKk1OnobOAXPA/lDmmdAfr303SS7+RU+KWhmhMSgMuJ3ytcNgDuhknZWt3HWFdGXm7vEnqWtNUSw8Lg8001/bWHl1fhYDsFFIFuhGkYpRA+AhD72NnC1mnA0DCjAeoOK6SK0oYeKOUgi8ZeR3/r2th5Gdl4uoRE/bbwv9LsfEU0C7XMZWUE3ijDDe+b74F4uyPsBLrLNsljuP4XQC02cxbH97qAK7Xw+zRvRrxCWqBJZiN82lVIHtEVceva+jtraAO5+8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XNrb/h6iRyVqAbBVg/M1DURJQmZViDhIIaw/7DLJbQs=; b=C40KKuGhLOpff/W5s+x3GOlxZ74V/FTQx/NYLE2FFBPZA+7d9nnSLVEq4CLgWWlLZudvNdo1Ht0ya4awZfFxxEh0eW/up+vx5GZWXLIW9/RsYBDHLMWqRLMjMEuqIK4wRpFTyAFu0gmHCXiUgMr08eXjK+VQW4vN6xD2ismM1fY= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2336.namprd11.prod.outlook.com (2603:10b6:300:75::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Mon, 2 Nov 2020 01:02:26 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 01:02:26 +0000 From: "Ketan Talaulikar (ketant)" To: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfg Date: Mon, 2 Nov 2020 01:02:26 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: <160427863467.23607.17022367772306047140@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.36.43.203] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a02688ea-851c-41bc-de53-08d87ecaf6f8 x-ms-traffictypediagnostic: MWHPR1101MB2336: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 241AJ+jmWanNb0JRcgySK511O8OzWwS2rtuqjLtXI2kb/+IPB2+xWu34Yu4c7HQe3knL0mW+JZPas0hI6JJVn9w1TYmMQazXjSklBL5F0UKUrqm2mLsXsYwpr2nKxtkpl1uGg1QDgVSFj1Co9e3g+5V2sljd7Bt2TDyB9XA7aO+DRdpQCK52dHRRuxFD4j6IsVU4rMWbV4asEIZuMkfTniKBg4hrErBdpMsXMKyiW6VNgEikLrnJHyROFtCgLobeXqzOtVdQ3dLs2r/T+WJz+VoNjzBJpIoi3B7q73RTC556DA6doPbkcP1II1hk6wHpuGR2w+VquaeoeE0fH05TJCplTvq927hjzd7Xt+aoJy1pyk35P0udnI8lf1t0Ey+ECEyp7rKz772ndx91C4Gggg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(376002)(346002)(39860400002)(186003)(8936002)(71200400001)(5660300002)(83380400001)(66574015)(8676002)(2906002)(7696005)(26005)(966005)(86362001)(478600001)(52536014)(316002)(66446008)(64756008)(66556008)(53546011)(9686003)(6916009)(55016002)(66946007)(33656002)(66476007)(76116006)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: f49xYOsdOEodqSw16MuW5gVnl8G9p0rxTShqXbKQM4tG3ENbSjjPNCopQ81ijp33Ij99KjcWZwlC0b42ZVt2vTw9lgP8nsHBU31maAL35VYFlV2vBaFCR0tD+CSd9YPwH8biPF9prEPo/50nHKtNAhdxFEWS8I3Lf+hLYs9N4TFUL4G5YdsaUvOBZ3VBSpAaF6tT7SsDDQlt0GZSDrG1vAeXIUvRP4NNJehfceJTbAlrS1awfEMcbi+3hXnmzqbl54N/UoGUvTgwh70ojyHXTGzRyTBgMtgJgu6rNBg2vvD40S4y1T8SPEyCUcsNgJ9mnzw3Pq/54Opml8dt5kvk9UHpSsr5uSwon0F170hJ6+z2ldslFFtxUTt7XYvW8BA4WV+31sVMIIs8dN3mwRZ7JdfOV4dn67wiipOi/5yqscwq41CG4ILU0zdopY36KnJxyTxHIXPJs1IEYGdnW0HyzAsLJryj0Q+tJ8rS2sK/A9lN0sBQ+Ln5zZzu5T65ixggwtlJnhMv6GTXGimN/P1LgvgQ9UQN1yXYOMdoQRi+Mk5cl14zFq5aBZ7dNXe9IP5/SgS3kT+on63t2b3lXD7ve7UkHRDld8cPh22g6vydBt354i5cU4wwnvv/tzagVaoaMqsqvPTbJtQlAeOZ/kJ/BQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a02688ea-851c-41bc-de53-08d87ecaf6f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 01:02:26.3967 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i7BQLawoN9IOIKqgdxnAEM3UXotnwGqr+3uEKosARfWmElW4EM7dYGeIK8LL97rB/enmnxOOa5cGvZjwdW9cxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2336 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 01:02:34 -0000 Hello All, We have just posted an update for the draft and following is the summary of= changes: 1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring= /fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spr= ing/d9oSSbgp0jCExRx0SXyBY0CyqXU/) 2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08. 3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received. 4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHD= N0IvFhw9id40/) Please let know your comments/feedback. Thanks, Ketan (on behalf of co-authors) -----Original Message----- From: spring On Behalf Of internet-drafts@ietf.or= g Sent: 02 November 2020 06:27 To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking WG of = the IETF. Title : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-09.txt Pages : 37 Date : 2020-11-01 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-polic= y-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Sun Nov 1 20:02:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A013A0CE4 for ; Sun, 1 Nov 2020 20:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 ho8SUOGUO_C2 for ; Sun, 1 Nov 2020 20:01:52 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255028.outbound.protection.outlook.com [40.92.255.28]) (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 544603A0CEF for ; Sun, 1 Nov 2020 20:01:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OX1WEkbqn88uVFSSf5sffRISHrOO2iS8Eko3kDFFwoxVjEbCyYr6xdEUd9oaLVjkyDrNQv1Yi2V1ROvX3bmFj4iYsrln/+zl6VwyfhJqcRxgostpj75I645CcjFi5EGPPVyzKSo9TrVAjytkk74/r56KLeg9qkp/ZONPCMp/r/98ZXKQFtZSG1PrPmDuuYoVO9aIm/RiHwmlRr6nRN2YpsY6t7FjLkAEY/wT1gtr0t+k2U+XqXlEGzuhynSiRmH32ExiyN4Dv5j1PjBf1w5s6y1rYNTM2v69L3KxXZjXfIgfvMUocvVcpiCkWuqMI224dTAL5TmhA2oIO2H6A9DfDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CVOdIVKXYufTrySbOXFbKktG3DSGyWvZrQPOotQcF6c=; b=a+Wthv1bPAycQNCLfb7qC5yTSUrD3r7MnlnrcdicN7w2cKBwZxdYDX6dNkt9pwm0DcLyDSNNgjINtXCBODzwwU3mjOq9cTIHDjmioVY+FjabCqcZgdgsaWnV49Fkern1rI1hrJnYte+jv1GpDlg6rfDV1scF4KRdj1/BG3DjKXrWzz8ISXXgLeGOCp5r0Tz4oPOp01etS0bWzr44RI2HAQIBv2myN1GaaibOnO4iDG4ZxOWiyyvF0mMdzeFk1dGmOEZHtmnjqSWgtFNQcO9CCR7nXAlgfsjEhETmZedyI6r0k0piH+IKFBO6xsxXRTWZhy/sS7C4G/vjxPzk7X3liA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CVOdIVKXYufTrySbOXFbKktG3DSGyWvZrQPOotQcF6c=; b=lbqNPfAZFn6FLbeFHn/sXC4DNZNJPvK8hZsY3/d7NfO+XtsLggKDUuIO1ugSi1ABPZ36djx0b1P9WYL/xcD1ROee46zxzqgkvX+TZaiqpXS3XTUZUiC5brXSd1WfE55frJSK983mI9SjYdXcxIPI/1VqAEWB9cVg6MiZ1IkfstqC+LKsfO9b6uBW5PtxU0YtqhHgk23TSDx4TU5V9j3m6LT5O1cDPoQStFIhKgIwZxqRI6J27CByr7fcFlTsmqEnL6L5kGVhsDNhqTFVfFX4+/WAoDFYB+5e48ejVKga0W72APwHBLXXxnHmjWIN2uzX1/KVfxoa2yD+V3lH2NvhJQ== Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::52) by PU1APC01HT070.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::331) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15; Mon, 2 Nov 2020 04:01:49 +0000 Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15 via Frontend Transport; Mon, 2 Nov 2020 04:01:48 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:2010E99771BA9182417B8CA501C37C51FE8A7AFDC98B09B3ECA83F862A08344A; UpperCasedChecksum:986D33177FA18FEF8E7F63E1605207436CD82CBBC297B8747E21BF89F1E0511E; SizeAsReceived:8520; Count:44 Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8]) by MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 04:01:48 +0000 Date: Mon, 2 Nov 2020 12:02:27 +0800 From: "li_zhenqiang@hotmail.com" To: "spring@ietf.org" X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart633780482172_=----" X-TMN: [WK77BK5HEK+dj1OKGxuTyyOSSOCnurhN] X-ClientProxiedBy: HKAPR03CA0027.apcprd03.prod.outlook.com (2603:1096:203:c9::14) To MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:b4::7) X-Microsoft-Original-Message-ID: <2020110212022428068317@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from cmcc-PC (183.243.252.119) by HKAPR03CA0027.apcprd03.prod.outlook.com (2603:1096:203:c9::14) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3541.10 via Frontend Transport; Mon, 2 Nov 2020 04:01:47 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 44 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 64d9ea1f-e278-47da-2830-08d87ee40566 X-MS-TrafficTypeDiagnostic: PU1APC01HT070: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BTBKu2ZxF37O1QKVxNR2bnWGM0E4hwOxh67ArmPtmTsIltQpuvv/Cgf47KyMBsYOW+4yfjQ4oybCCpkxEtZ/3dvs0/aJ5bKUT7jUljlTD2l5PGSz/p/qQPKKdjIJTVFPIHs1MTGg69XYeyd6Ldaz5JczPCdbMnjQ40fXzTmpiJpwbG8u43icrB0NwNGgA2sdlI2dbjtBFs2muHBZ4p10f64K32jjnad9RZYwDFqHtkEk8Y539EzPRC5AS2bcMzvP X-MS-Exchange-AntiSpam-MessageData: YLE79/LOAu24uNNGrc9IFtcutq24AThsvAA4jscsQTVAxHZXUGtMAI7t7kXMTteZIAKnAN9bGYfR9S/4q9UEXHbPLrb+R8w9V+x+vcIsklalsI8fLpi466pZsUGTUWHsDRuRGgrKFN3+uC0LBK7wng== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64d9ea1f-e278-47da-2830-08d87ee40566 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2020 04:01:48.7551 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT052.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT070 Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 04:02:02 -0000 ------=_001_NextPart633780482172_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8gQWxso6wNCg0KSSd2ZSByZWFkIHRoZSBkb2MgYW5kIHN1cHBvcnQgdGhlIGFkb3B0aW9u IHdpdGggdGhlIGZvbGxvd2luZyBjb21tZW50Lg0KDQpGb3IgdHdvIHdheSBsb3NzIG1lYXN1cmVt ZW50IGZvciBTUnY2IHBvbGljeSwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21lIHRleHRzIHRvIGRl c2NyaWJlIHRoZSB3YXkgdG8gZ2V0IHRoZSByZXZlcnNlIHBhdGggZm9yIHRoZSBzcGVjaWZpYyBT UnY2IHBvbGljeS4NCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExpIA0KDQoNCmxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbQ0K ------=_001_NextPart633780482172_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <= style>body { line-height: 1.5; }body { font-size: 10.5pt; font-family: =CE= =A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5; }=0A=
Hello All=A3=AC

I've read the do= c and support the adoption with the following comment.
=0A=

For two way loss measurement for SRv6 policy, it is bet= ter to add some texts to describe the way to get the reverse path for the s= pecific SRv6 policy.

Best Regards,
Zhenq= iang Li 
=0A=
li_zhenqiang@hotmail.com
=0A= = ------=_001_NextPart633780482172_=------ From nobody Sun Nov 1 20:03:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E881A3A0CEA for ; Sun, 1 Nov 2020 20:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 SgpM_f10sjYE for ; Sun, 1 Nov 2020 20:03:08 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254076.outbound.protection.outlook.com [40.92.254.76]) (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 936573A0CE6 for ; Sun, 1 Nov 2020 20:03:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X0WTTfuwACLocAAyM4ru6IqXr1773vr7SEHgI8jrnAvriTXyRcQWIEVifmNOmH4ax+Pifuf4VqMvwR4+J8fiUaFFm1+v9/hs3hlpw06zvTbNJ/fJwDYbLCFhmJRsLkxTp/TOPwbduANEEnY360UwI7ZDhb6VkynCTTjhNlB4kaCiVbOqb+TmIgnVPEeLmhv8Il1rS5CPIQatT99n9fFrmgwUDVd5g9J0UKXOS4NanFdlbczm1VsC7l62Fw9wzbGiclKyAg4btpkl/s7xtYpUrgIbwannFiOOJPyGlzge7/PHuRVDauORTIXC1ecTUM1GHXmb82yuP10resu5NTvQaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JJpNNt+KrIqBhar3KPOSgklGEnfmZU1IFck8Kl5Ks2Y=; b=XJ/mFI4zF5mJnYQ9xG5YyxuJ2byU/sNpBtzD9Z8qmpe6RadkGFsK9O529itzmOnePj0i9/l9kQ2hZzc7EUXiXsTafvtSGEhLDaaj83wWHWRupBN8KyVC+IPgC4M/UhZngMleBjyLGyC/+QnUrM+CS1Q4sOpi9GID5clOgTvRoKnvq7BOLwtvpSFQb3k9i+VbGRkLOY93tIICHZEZDO9s76p5yMufp0oKOmMGtuIevR9Rwnpl5q4xVjcsidZ3TnPSdo0ZGQHrnPolFPkI9YyLS4284pdoF083pyITAMxmMKL1oxfWwbxbupfkW5pvgT3IUHl+KTa3Fz91iE+Sa+6UAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JJpNNt+KrIqBhar3KPOSgklGEnfmZU1IFck8Kl5Ks2Y=; b=cZgWh/Tabfl4qEAd54QA0wHWrBqUpVJpI07dYPBwVNcfl4lt0vakSEQYGRY/RRzoQ2+vSM70uREZOSMA4tTL3T9DrVTJ+K2pXJ7SLGXAwQtAXhyXva7/5MUUiiJ8kEJuwhgFry0IyI0tRcAwt6yebZ56smuE+BETgz8xRDlZv+ogJ8hIO0g+3FH/kdQ05Z/qUNFaHvE6M5ASJWo9IKBCf34Lr8dI7oywQJmwtCBjXjMgcmL2baQDJab7UVYtMgKr4jGXJeJkOTi5dfA4JJV/ZKSBv4yhivf64Vz7A5gn3a+Vy0zEda8ThFtBYE7quB6KfvGeaNnVtN9qefWz2lxklw== Received: from PU1APC01FT052.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::40) by PU1APC01HT176.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::438) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15; Mon, 2 Nov 2020 04:03:04 +0000 Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT052.mail.protection.outlook.com (10.152.253.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15 via Frontend Transport; Mon, 2 Nov 2020 04:03:04 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:7F78D102168FD32D4F25C7203F83EED7F4DF9CC67A7FB6445FD7DFF0ABDAD379; UpperCasedChecksum:C35FD30357681972A079CDBCAFACDA079081AB565A20EE4FD5250375C624DE7A; SizeAsReceived:8532; Count:44 Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8]) by MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 04:03:04 +0000 Date: Mon, 2 Nov 2020 12:03:43 +0800 From: "li_zhenqiang@hotmail.com" To: "spring@ietf.org" X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart332256221481_=----" X-TMN: [dNqnCsesM/S9uFz9hyb0JrPEFTrpcxFJd96H/dsFbtw=] X-ClientProxiedBy: HKAPR03CA0023.apcprd03.prod.outlook.com (2603:1096:203:c9::10) To MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:b4::7) X-Microsoft-Original-Message-ID: <2020110212034017287319@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from cmcc-PC (183.243.252.119) by HKAPR03CA0023.apcprd03.prod.outlook.com (2603:1096:203:c9::10) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3541.10 via Frontend Transport; Mon, 2 Nov 2020 04:03:03 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 44 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 7007f8a5-7781-431f-d8a3-08d87ee43288 X-MS-TrafficTypeDiagnostic: PU1APC01HT176: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sLhz3o7vDwXSqVki37Fug+d2RK76Hha6bzBu868aRY6cm8wJw/l2nq9/PSWauyChLGfctE1Ts0a4vflzodICBVWU30rvkKAhyVjAIqYqt4gnNYqEtLTLIzGxcaLByHmFjBLTwK6ZJ+Fea2s6HZRpRkQYT20kBvjU3pmlSK+ZrRi5vQcqc5J48ROJW9kaPOVGyLOnZ2tfVN7X0JKb+18mV4UneYLWB6iwoq/mbIhH53MXQATcjNx5Pp3cmGzzYnLc X-MS-Exchange-AntiSpam-MessageData: 0RhEdFhBRffSBHg52c1dTzQS41tBvOdU8y+clKCTuXl3JDjkQP8Zuz303eOX2iDP3a0ms/lj5x9ib1JrwvZ4ygz/Q8saeZpv27e3JbocrbsxQgUPzxNX4QH7CnKwzp/3mi5PZmbPXbLcRNJjqIg7uw== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7007f8a5-7781-431f-d8a3-08d87ee43288 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2020 04:03:04.2579 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT052.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT176 Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 04:03:10 -0000 ------=_001_NextPart332256221481_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8gQWxso6wNCg0KSSd2ZSByZWFkIHRoZSBkb2MgYW5kIHN1cHBvcnQgdGhlIGFkb3B0aW9u IHdpdGggdGhlIGZvbGxvd2luZyBjb21tZW50Lg0KDQpGb3IgdHdvIHdheSBsb3NzIG1lYXN1cmVt ZW50IGZvciBTUnY2IHBvbGljeSwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21lIHRleHRzIHRvIGRl c2NyaWJlIHRoZSB3YXkgdG8gZ2V0IHRoZSByZXZlcnNlIHBhdGguDQoNCkJlc3QgUmVnYXJkcywN ClpoZW5xaWFuZyBMaSANCg0KDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCg== ------=_001_NextPart332256221481_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <= style>body { line-height: 1.5; }body { font-size: 10.5pt; font-family: =CE= =A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5; }body { font-= size: 10.5pt; font-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); l= ine-height: 1.5; }=0A=
Hello All=A3=AC

I've read the do= c and support the adoption with the following comment.
=0A=

For two way loss measurement for SRv6 policy, it is bet= ter to add some texts to describe the way to get the reverse path.

Best Regards,
Zhenqiang Li 
=0A=
li_zhenqiang@hotmail.com
=0A= = ------=_001_NextPart332256221481_=------ From nobody Sun Nov 1 20:15:01 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF03A0D17; Sun, 1 Nov 2020 20:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=RJf96A6k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s7Bg2sf+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSC-YsAYBAkI; Sun, 1 Nov 2020 20:14:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC33C3A0D8A; Sun, 1 Nov 2020 20:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19906; q=dns/txt; s=iport; t=1604290496; x=1605500096; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xj8potbv61qFXxqujjLAA+XRl+xUXAJ594AZ8BaRQNc=; b=RJf96A6kimp2+mVVmrhGyI111A/WoPaCEVxoR3vD9h6NAxAZfH3+MeYE AgVL+uHqrPBfAmSqt4ILF/8QIQ0dkQwLABGOhVGVxo5h9O0ei7vsfpaKa kHnQfl7kUO5SUxxkkIaWuCZ1qXW3LVsDF9WnCaLRAd0S445fwx43vDVlh I=; IronPort-PHdr: =?us-ascii?q?9a23=3AGgM8EhA5pj+jHvY0jJHgUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw31g3HQJnG8f9bhuuQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFPPvmCo4CEfG1?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQCQCohp9f/40NJK1iHgEBCxIMQIJ?= =?us-ascii?q?yL1EHcFkvLgqHfAONS5h/gUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIHAiU4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBHGFYQyFcgEBAQQSCxATAQEsCwEPAgEIEQQBASEOMh0?= =?us-ascii?q?IAQEEAQ0FCBqDBYF+TQMtAQEOowMCgTuIaHSBNIMEAQEFgTcCg2sYghADBoE?= =?us-ascii?q?4gnKCYU6HGRuBQT+BEUOCTz6CXQEBA4EiIBwrgx2CLJp8i1Y1kRsKgmyJCJI?= =?us-ascii?q?gggaBEooRiFqLZ4YbjS+KeJEWhDECBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2?= =?us-ascii?q?OHzcYgyKFFIVEdDgCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,443,1596499200"; d="scan'208,217";a="826731301" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Nov 2020 04:14:55 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A24EsBY002942 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2020 04:14:55 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 22:14:55 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 22:14:50 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 1 Nov 2020 22:14:51 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QH+LURjJKLWSJ+cGmoDgTObqgbsy5mnCpO18D92orL/Kknb2qyas4647KSOFwSXdV95Ko5hZXXVC5HwKcC66A/7Oudx/PODLHdfbgdnilYz3Ra4MXCkdECkjSBOGVzACUsbcTQlqtUi1OZV70iQRXDGO3XMFs+kPgaoHWunm5whuBQ9Bt/+KCe8GvOhRHDqeW27iLVD7hobONzpDgmKg9mJEY1H2Xwc17INBPi3bLUJsrhEEGaFW5AkD549BA7106qyotx+fr5rtNBfC3jqYRzl5m/y8XzDQHqvSxaRXRwE+ZbQQvZ11/JMCP0QyQ/TvsNtHZdI9gkwWFqYPT/XMKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X6NhwoEEG17J7BayI0cs+j3TSiQy4eLlaBZnbHkPt8E=; b=ZOC4OwIv6qWh2l1kREHYInmhO1dhQgB9dp2dH55RUthzJjxKW4G5d2F5WtAMxAx6wmeVu8ITl+f2wlPUxlGpWnX9CxhPFER2Izgz4s0N7RbebivmyTQn56aIn25mJR10hT/kj1yxlECuUo7ZTgsuczCFrrVbx/3daEC3Ap/jR3sKe/NOhqHW5q3/pUAPODx3z/gsiIY9vp3DdvtEbvrsslIb25FtN9zZJMM/q6UIWZm+/J7miLoOJbgZcZ0cULCmGnRr5GFQ4kba+hZ53vspefDdHVc3JXewAjiGN20FP5prz0kKftVjYMm5Qr20JSJvQnMdn2kkO7A7bshkW2sgDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X6NhwoEEG17J7BayI0cs+j3TSiQy4eLlaBZnbHkPt8E=; b=s7Bg2sf+gKgWEVf4QXiUrYTHmqbhdh8BBBdXzjkBgdS65nCYofNG+PUNswipgifFrR8+cnROJ3B/tfs45ISPXBe6EB9fCHApcbjs1ZQFAt0gacSHf+xVby3flRvG8EAzHn23uEPV10mwfEPJbXYPGMzuA40TWC/6SDfiYBtkaRI= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5140.namprd11.prod.outlook.com (2603:10b6:303:95::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Mon, 2 Nov 2020 04:14:48 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 04:14:48 +0000 From: "Ketan Talaulikar (ketant)" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQIX0q+w Date: Mon, 2 Nov 2020 04:14:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.36.43.203] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8237a110-d633-4851-1c61-08d87ee5d669 x-ms-traffictypediagnostic: CO1PR11MB5140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O5L5fvdAnzekDKnUeHdErO1r9Rx+ep5xUgNc/HjXwjT6/YRq+MnGgOpwMXlSBFmcnaCz7Sn0JIJlaQEcvmUQoL1Oz+Neke5m54jRH8dHRL1WRiuLlQYHP5dQgSjiAHTWmR0ciQIPXrzVHnhRf0ezck/hynXDr3ZdtzdeEBuhoDuw/nI3dcqHvweKFIa3DlKmmeCsFk51tzBhn5rRG2C4iPjcYLoxgALFABFGsyBYrWJpkR1AiRQF4Nbtqq8Zd8//jzQWOoSqfY5muoFQfl1Cu8I2oFFi0fb+WrLWk6n+HEgNz5bT5sIowFMtDWuLtfVZlDKj550UTaKjkIT10ybS9zkFgzed7NHq7zJj/oO8e7CTfdkxTUxxS9+xXfVxhiyfsnQ83oOgExVGAsbZ/XEnyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(366004)(396003)(136003)(8676002)(2906002)(8936002)(71200400001)(53546011)(186003)(26005)(7696005)(6506007)(4326008)(86362001)(9326002)(54906003)(110136005)(478600001)(316002)(966005)(55016002)(66556008)(9686003)(66446008)(66476007)(64756008)(76116006)(66946007)(83380400001)(166002)(52536014)(5660300002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: BgyK7ISQ99Kicd8kEkE9X9tWZTmCwPTQMqWHbePTsUw6fppxRZBktL0WzTiNatQuGoXX7ou+OcBYEBS27eHN+vFKUh+xAZmEza8eEZaLLSHlfY4tvEpOMZp46lejmddxYGsBAxbr9tnY8v75M3gxCXRrlGS1jerIisEqUAU6tEaP6ScOaVlQSdBrkeMSbkX0ldHyyoD2Su8nFQG+dypI0nk31Ijr2ofurqnSab2qB7JWLs3CdhaTgyR278InrxwDBHCej3d7bEG/FpYdhCkyj9S7RmySiZOMDgxY/mynsXfJgxM/hSRCPtCAnn6jyskNpGPVCHYrSnlXwWEaQhMffuQBrYVZ3xBbkuA1Z+2frvgn1+TrY3tHmUmjbrJ2Hc7c25HaTA42DPqDpFKLxoGBI5BrhKjC+T8dx1dYV5BB20rVWaeODhC4ixPJjvFUietzbQTLiOGuWguxBAvjGK/2eP0dhm+WuIC9vcVoqwQ9il79bTISqpZmdlQhKOvYIoAh5ei1+jfoRv41idWpUZbXDl9PNFX0q/Y0koOproCJtjx3S/L6qca5RUp6LNCCNohdCb1zhgvAMVUw1l4plMb/1b79SEwyUlH5YUqdu5Jlvlrak4VFex4Dafp1zPDaWSmWtCRjUzB3oqdnvecRqmNUog== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45708859C6D449923F43A337C1100MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8237a110-d633-4851-1c61-08d87ee5d669 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 04:14:48.0120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zcdPit6+PnqsfgsqAVtYApsNs9moi/UlGivtf3cPjw8F71QfpWeDsMfrV5BpggTU1bpNnTIrOeLohhguRsOZZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5140 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 04:15:00 -0000 --_000_MW3PR11MB45708859C6D449923F43A337C1100MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I support the adoption of this work for performance monitoring in SR networ= ks that leverages TWAMP. Thanks, Ketan From: spring On Behalf Of James Guichard Sent: 22 October 2020 18:22 To: spring@ietf.org Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-11 Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_MW3PR11MB45708859C6D449923F43A337C1100MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All= ,

&nbs= p;

I support= the adoption of this work for performance monitoring in SR networks that l= everages TWAMP.

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: 22 October 2020 18:22
To: spring@ietf.org
Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/d= raft-gandhi-spring-twamp-srpm-11

 

Dear WG:

 

This message starts a 3 week WG= adoption call for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending Nov= ember 12th 2020. Please note that this document has several chan= ges from v-10 that were requested by the SPRING and IPPM chairs. For this reason, the chairs have extended t= he adoption call for an additional week to allow the WG enough time to revi= ew these changes before deciding on WG adoption.

 

Some background:  

 

Several review comments were re= ceived previously for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those com= ments, and upon review of this version of the document, determined the foll= owing:

 

  • The SPRING document should describe only the pro= cedures relevant to SPRING with pointers to non-SPRING document/s that defi= ne any extensions. Several extensions including Control Code Field Extension fo= r TWAMP Light Messages, Loss Measurement Query Message Extensions, and Loss Measurement Res= ponse Message Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and shou= ld be removed from the SPRING document.
  • The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-= twamp-srpm-10 should be described in a new document published= in the IPPM WG.  

 

These conclusions were discusse= d with the authors of  https://tools.ietf.o= rg/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:

 

 

After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please als= o provide comments/reasons for that support (or lack thereof) as silence wi= ll not be considered as consent.

 

Finally, the chairs would like to thank the authors for their efforts= in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

 

 

 

 

 

--_000_MW3PR11MB45708859C6D449923F43A337C1100MW3PR11MB4570namp_-- From nobody Sun Nov 1 20:18:40 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5143A0D21; Sun, 1 Nov 2020 20:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=IsBGc2l9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=unpjpIdI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXETHaZRi7lK; Sun, 1 Nov 2020 20:18:36 -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 8A9543A0D20; Sun, 1 Nov 2020 20:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19568; q=dns/txt; s=iport; t=1604290716; x=1605500316; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kJKLj35XN2iUsiYyveWZlW1vG9l98Hyoo/5gy3qEUJs=; b=IsBGc2l9tL0ViimPlQeMAtEmQzMZ0J3DyffuK4CyQzvrcQ8hXHcZY0K+ yUP3zYrjlcIALjnebphp25IONi2X5aAFUf34HeMsAN2TjHJ3iJmuND8Jn YCHg5OlvGd0wfdgMdCTVuMkfUaWc3BjRCMnK6DbFfm08KUTlCudfyZh4c 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AfxDYPhaKYY34Z1eLfF0XHSD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWTD4vG9+9ehvXbsubrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrGCu8CQfBR?= =?us-ascii?q?j+cwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVCABPiJ9f/4wNJK1iHgEBCxIMQIF?= =?us-ascii?q?EC4EjL1EHcFkvLgqHfAONS5h/gUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIHAiU?= =?us-ascii?q?3Bg4CAwEBCwEBBQEBAQIBBgRxhWEMhXIBAQEEEgsQEwEBLAsBDwIBCBEEAQE?= =?us-ascii?q?hDjIdCAEBBAENBQgagwWBfk0DLQEBDqMAAoE7iGh0gTSDBAEBBYE3AoNrGII?= =?us-ascii?q?QAwaBOIJygmFOhxkbgUE/gRFDgk8+gl0BAQOBIiAcK4MdgiyafItWNZEbCoJ?= =?us-ascii?q?siQiSIIIGgRKKEYhai2eGG40viniRFoQxAgQCBAUCDgEBBYFqJIFXcBU7gml?= =?us-ascii?q?QFwINjh83GIMihRSFRHQ4AgYKAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,443,1596499200"; d="scan'208,217";a="578091125" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Nov 2020 04:18:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A24IYbM021484 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2020 04:18:35 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 22:18:35 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Nov 2020 22:18:33 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 1 Nov 2020 22:18:33 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B3MWYMfT7iT1OMlNUY5/eGyRf3Axmxoclyp/2g2i9UCBb/UK6u8YFOnT+ucDTi8y3xveWzAS/qiBVX3c1k76XwK9vMM1Q0OwVvCYqEa5tVbNsjkIuYtIDnYj/YCN0gPWh07q2WqkJZ0vv4NzgLh5EHMy2f4kSnmlmZMb7IyFaKYdTHFi0bcL8JeY9unuv/kNRbhsxiaa50bL5VsjWK+vtMpDeH3GS+KZ6xy+Vzduf6fjmd2Egm1PydidvXIzBR42d+rguSRMOrD+Y29rb8wRLYKs9JXvOPR4ZSqlsMauAwIQy5Slhf1/gGrN0bTsJD9vJ/n8cbALdtIGB1m7uWy5JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0E2IAhe7pdvli1MACrRY1Omqaj7cIKc9L1gmujOsNc4=; b=e6pdJr3tJNJX3sdRsA+8YM+HQvA4ng8cxbveZqrOKkITPR3BEoCKRehC0poh61yUnYHjUJ7xk4h2ut4dCDz1u3G3I0sny4yXDoXtOfn3dWhkryN6+NurI0WqK1F19QaH7N1FOjokYRqcyqO7hq1Xmx7BebH3H64F2S5U7gYpHC2qRcLb1VyvY0drATiA5Ag3E1E/NHYNKnWaDTVkADdOjFomR+MR8oq1D1vs1U1SPu0ITjNbCTx8akaA3VbWhGgF4gDOH+4KMLtFDDB1upupuvFK4K1Z862ZFBqlHVC1210vp3vVjCrtVLnUbOviiDL6xRa6mizFpfCEdN0+ZZHRiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0E2IAhe7pdvli1MACrRY1Omqaj7cIKc9L1gmujOsNc4=; b=unpjpIdIXgKkWgud8lV3Cx9pQLWYxhV0bKNixlkveiedJl6UWeYl70x/NSd2elQ46ot56PiIMwagfnyUI5+X8FUIq3fTOdvvjI6oX6kKjOpj5LM2MiCBH+39im7qgIPT1Gwytmp3TSh8n+uYYyzYY9HaCeLoEfrb+FwBmTA6n0o= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5140.namprd11.prod.outlook.com (2603:10b6:303:95::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Mon, 2 Nov 2020 04:18:32 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 04:18:32 +0000 From: "Ketan Talaulikar (ketant)" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: Adaoaxv73543NQYjR7aQ9fY490xJIQIY5omg Date: Mon, 2 Nov 2020 04:18:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.36.43.203] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c23976f8-5e0a-4a52-ca87-08d87ee65c45 x-ms-traffictypediagnostic: CO1PR11MB5140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dlRRUK31/JJFgkC0WSS1b/0M2oxWzio4JqBblIvP5ADBNLqSfHQUquH5nuHS3Pwftya7srynwsEpYy5AHzhnFG8rGmFTpH9fucxO7GbCbDWmsa9EteDMZResg6rwqdd8gnE7S+24PEj/0R/grD2swAbE+sm/E6okW5uT77giR6KlTERIqgdLymjgZVURmAbdKxm9AhInLcwGM5OCSZ38608h3luXV/GcFN7TG7IumfJq7AitII9zu2BTgkMHLXGyoxquL1Mgos+IeOkO3wByODhscpjysHvRzO6HLMP7qZfPxdjqMX6ONAG1ZTsqQfRGn/f1SSRWtzUdtp4mQRS2Ji1qAEpiRnfqZV1EMGzU8b6gvHdr2pkTn89qUk5A4kvf48tUazghjrPpuaUXQW7cZQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(366004)(396003)(136003)(8676002)(2906002)(8936002)(71200400001)(53546011)(186003)(26005)(7696005)(6506007)(4326008)(86362001)(9326002)(54906003)(110136005)(478600001)(316002)(966005)(55016002)(66556008)(9686003)(66446008)(66476007)(64756008)(76116006)(66946007)(83380400001)(166002)(52536014)(5660300002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0+MJAhW+1/7HQ6IoAJtoe1d/JjIw6Fx3pfHfKJ5Fv+mWxBGzsuvWMZDxhL2K6cUywDRB6VPKH5RmNESvxiMiSI8Vyls44TNg9heak7lumN1tb9tFpnhfLbuSLlPZZNEMuJ6o24t9eTn0dF6BmoEusgYuy4OUENxKnvaKsIX0M/ZDn8iUzG0v4E19qzGVUbb73VxMy8zFQ7vXme8wWrXoArYX9g2JEs8fk5tl8yPF7MES6YqzDllmaMhlgdXHBf1FgHYabyvBP/AJxjX4PwoNpiqa/UheCpRlSmYss+kX6r6PV4yqJU6IIfiNAcLwVTGVP/9A4llePozgnjXw2xVTXyfpsVm3wYmGFdYiTaP60zZvWhKWOEKyXHHeGFotvHw2n2e3Cof8SoQgrQrJU36mO4kQK3/aLkag3vGJLtgoV/BeencY05bYcKzbeXeXAT3DXBZAHBHoxaLlZ9OZja5WUFLIHtwfcjvW9qIE7cOCPGfMp8jU4zdtxsKPIiGE0lA3mPQOXA3qTXY6EnDlxZ6hfkAz3vqFmBxjdnlfJ6oFM345cXSu/e4cK/bOedw4+uFjDn+Ckek6jSCAc4Zd7wLfqLUGfHGsi78MABMQv/J67KHMZuji5PFkVgMLqYRmUK5y4QI7/64dSkcn1iHpc8yyMw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570A0CCD995BDBC145283B7C1100MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c23976f8-5e0a-4a52-ca87-08d87ee65c45 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 04:18:32.6828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R/RpSV1mZWSOsCaAy9+vOfNhqTxJwlUpp1VFOikOenMrK7vR90AGbBO54WYF72w8IhftLjG66w/ONvDGiL4D+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5140 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 04:18:39 -0000 --_000_MW3PR11MB4570A0CCD995BDBC145283B7C1100MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I support the adoption of this work for performance monitoring in SR networ= ks that leverages STAMP encoding. Thanks, Ketan From: spring On Behalf Of James Guichard Sent: 22 October 2020 18:22 To: spring@ietf.org Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-03 Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-stamp-srpm-03, ending November 12th 2020. Please not= e that this document has several changes from v-02 that were requested by t= he SPRING and IPPM chairs. For this reason, the chairs have extended the ad= option call for an additional week to allow the WG enough time to review th= ese changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for STAMP Messages,= Loss Measurement Query Message Extensions, Loss Measurement Response Messa= ge Extensions, Node Address TLV Extensions, and Return Path TLV Extensions = were included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02 and should be removed from the SPRING document. * The STAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-02 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.org= /html/draft-gandhi-spring-stamp-srpm-02 the result of which is the publicat= ion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_MW3PR11MB4570A0CCD995BDBC145283B7C1100MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All= ,

&nbs= p;

I support= the adoption of this work for performance monitoring in SR networks that l= everages STAMP encoding.

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: 22 October 2020 18:22
To: spring@ietf.org
Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/d= raft-gandhi-spring-stamp-srpm-03

 

Dear WG:

 

This message starts a 3 week WG= adoption call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending No= vember 12th 2020. Please note that this document has several cha= nges from v-02 that were requested by the SPRING and IPPM chairs. For this reason, the chairs have extended t= he adoption call for an additional week to allow the WG enough time to revi= ew these changes before deciding on WG adoption.

 

Some background:  

 

Several review comments were re= ceived previously for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chairs considered those com= ments, and upon review of this version of the document, determined the foll= owing:

 

  • The SPRING document should describe only the pro= cedures relevant to SPRING with pointers to non-SPRING document/s that defi= ne any extensions. Several extensions including Control Code Field Extension fo= r STAMP Messages, Loss Measurement Query Message Extensions, Loss Measurement Respons= e Message Extensions, Node Address TLV Extensions, and = ;Return Path TLV Extensions were include= d in https://tools.ietf.org/html/draft-gandhi-spring-= stamp-srpm-02 and should be removed from the SPRING document.
  • The STA= MP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-= stamp-srpm-02 should be described in a new document published= in the IPPM WG.  

 

These conclusions were discusse= d with the authors of https://tools.ietf.org/html/draft-gandhi-spring-= stamp-srpm-02 the result of which is the publication of the following t= wo documents:

 

 

After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please als= o provide comments/reasons for that support (or lack thereof) as silence wi= ll not be considered as consent.

 

Finally, the chairs would like to thank the authors for their efforts= in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

--_000_MW3PR11MB4570A0CCD995BDBC145283B7C1100MW3PR11MB4570namp_-- From nobody Sun Nov 1 23:02:54 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED0E3A00D9; Sun, 1 Nov 2020 23:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YcGiR7w93kSE; Sun, 1 Nov 2020 23:02:50 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B37133A00C9; Sun, 1 Nov 2020 23:02:49 -0800 (PST) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 063EF7F3791F6536C700; Mon, 2 Nov 2020 07:02:48 +0000 (GMT) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 2 Nov 2020 07:02:47 +0000 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 2 Nov 2020 15:02:45 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 2 Nov 2020 15:02:45 +0800 From: "Xiejingrong (Jingrong)" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQIdDJrw Date: Mon, 2 Nov 2020 07:02:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.201.174] Content-Type: multipart/alternative; boundary="_000_fa009033516d46ea810e1a5573cc6ae2huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 07:02:52 -0000 --_000_fa009033516d46ea810e1a5573cc6ae2huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi working-group: I support the adoption, and I have the following questions: 1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word "as neede= d" for inner IP Header. Can authors please clarify in which case(s) it is = needed and in which it is not. 2. Section 4.3.1 "Destination ipv6 address from the ::FFFF:127/104 range", = and Section 4.1.4 "the loopback address ::1/128 for IPv6", are they differe= nt cases or same case ? Thanks Jingrong From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Thursday, October 22, 2020 8:52 PM To: spring@ietf.org Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-11 Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_fa009033516d46ea810e1a5573cc6ae2huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi working-group:

 

I support the adoption, and I have the following questions:<= /o:p>

 

1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word= “as needed” for inner IP Header.  Can authors please clar= ify in which case(s) it is needed and in which it is not.=

2. Section 4.3.1 “Destination ipv6 address from the ::FFFF:= 127/104 range”, and Section 4.1.4 “the loopback address ::1/128= for IPv6”, are they different cases or same case ?=

 

Thanks

Jingrong

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org
Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/d= raft-gandhi-spring-twamp-srpm-11

 

Dear WG:

 

This message starts a 3 week WG= adoption call for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending Nov= ember 12th 2020. Please note that this document has several chan= ges from v-10 that were requested by the SPRING and IPPM chairs. For this reason, the chairs have extended t= he adoption call for an additional week to allow the WG enough time to revi= ew these changes before deciding on WG adoption.

 

Some background:  

 

Several review comments were re= ceived previously for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those com= ments, and upon review of this version of the document, determined the foll= owing:

 

  • The SPRING document should describe only the procedures relevant to SPR= ING with pointers to non-SPRING document/s that define any extensions. Seve= ral extensions including Control Code Field Extension for TWAMP Light Messages, Loss Measurement Query Message Extensions, and&n= bsp;Loss Measurement Response Message Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and shou= ld be removed from the SPRING document.
  • The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-= twamp-srpm-10 should be described in a new document published= in the IPPM WG.  

 

These conclusions were discusse= d with the authors of  https://tools.ietf.o= rg/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:

 

 

After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that s= upport (or lack thereof) as silence will not be considered as consent.=

 

Finally, the chairs would like = to thank the authors for their efforts in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

 

 

 

 

 

--_000_fa009033516d46ea810e1a5573cc6ae2huaweicom_-- From nobody Mon Nov 2 01:25:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1825D3A0C94; Mon, 2 Nov 2020 01:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9bsWj3AoP-Mi; Mon, 2 Nov 2020 01:25:41 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 82FE93A0B9D; Mon, 2 Nov 2020 01:25:40 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5f9fd08946c-73935; Mon, 02 Nov 2020 17:25:29 +0800 (CST) X-RM-TRANSID: 2eea5f9fd08946c-73935 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.146]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5f9fd087486-18c30; Mon, 02 Nov 2020 17:25:29 +0800 (CST) X-RM-TRANSID: 2eea5f9fd087486-18c30 From: "Weiqiang Cheng" To: "'James Guichard'" , Cc: , References: In-Reply-To: Date: Mon, 2 Nov 2020 17:25:27 +0800 Message-ID: <086801d6b0fa$1a219790$4e64c6b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0869_01D6B13D.2844D790" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Adaoaxv73543NQYjR7aQ9fY490xJIQIjskOA Content-Language: zh-cn Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 09:25:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0869_01D6B13D.2844D790 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I support the adoption. =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C222=C8=D5 20:52 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: ippm-chairs@ietf.org; spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 =20 Dear WG: =20 This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending November 12th 2020. Please note that this document has several changes = from v-02 that were requested by the SPRING and IPPM chairs. For this reason, = the chairs have extended the adoption call for an additional week to allow = the WG enough time to review these changes before deciding on WG adoption. =20 Some background: =20 =20 Several review comments were received previously for document = https://tools. ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM = chairs considered those comments, and upon review of this version of the = document, determined the following: =20 * The SPRING document should describe only the procedures relevant to SPRING with pointers to non-SPRING document/s that define any = extensions. Several extensions including Control Code Field Extension for STAMP Messages, Loss Measurement Query Message Extensions, Loss Measurement Response Message Extensions, Node Address TLV Extensions, and Return = Path TLV Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and should = be removed from the SPRING document. * The STAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should be described in a new document published in the IPPM WG. =20 =20 These conclusions were discussed with the authors of https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result = of which is the publication of the following two documents: =20 * https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The subject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This document will be progressed (if determined by the WG) within the IPPM = WG. =20 After review of the SPRING document please indicate support (or not) for = WG adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as consent. =20 Finally, the chairs would like to thank the authors for their efforts in this matter. =20 Thanks! =20 Jim, Bruno, & Joel ------=_NextPart_000_0869_01D6B13D.2844D790 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I support the = adoption.

 

=B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C222=C8=D5 20:52
=CA=D5=BC=FE=C8=CB: = spring@ietf.org
=B3=AD=CB=CD: ippm-chairs@ietf.org; = spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption Call = for = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03<= /span>

 

Dear WG:

 

This message starts a 3 week WG adoption call for ht= tps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending = November 12th 2020. Please note that this document has = several changes from v-02 that were requested by the SPRING and IPPM = chairs. For this reason, the chairs have extended the adoption call for = an additional week to allow the WG enough time to review these changes = before deciding on WG adoption.

 

Some background: =  

 

Several review comments were received previously for = document ht= tps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. = The SPRING and IPPM chairs considered those = comments, and upon review of this version of the document, determined = the following:

 

  • The SPRING document should describe only the = procedures relevant to SPRING with pointers to non-SPRING document/s = that define any extensions. Several extensions including Control Code Field Extension for STAMP Messages, Loss Measurement Query Message = Extensions, Loss Measurement Response Message = Extensions, Node Address TLV Extensions, = and Return Path TLV Extensions = were included in ht= tps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and = should be removed from the SPRING document.
  • The STAMP = extensions included in ht= tps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 = should be described in a new document = published in the IPPM WG.  

 

These conclusions were discussed = with the authors of ht= tps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the = result of which is the publication of the following two = documents:

 

 

After review of the SPRING document please indicate support = (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or = lack thereof) as silence will not be considered as = consent.

 

Finally, the chairs would like to thank the authors for = their efforts in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

------=_NextPart_000_0869_01D6B13D.2844D790-- From nobody Mon Nov 2 01:25:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472AD3A0B9D; Mon, 2 Nov 2020 01:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iQ0FwxIHXm_G; Mon, 2 Nov 2020 01:25:42 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 63AA53A0C38; Mon, 2 Nov 2020 01:25:40 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee45f9fd0897e2-72ce2; Mon, 02 Nov 2020 17:25:30 +0800 (CST) X-RM-TRANSID: 2ee45f9fd0897e2-72ce2 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.146]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5f9fd087486-18c36; Mon, 02 Nov 2020 17:25:29 +0800 (CST) X-RM-TRANSID: 2eea5f9fd087486-18c36 From: "Weiqiang Cheng" To: "'James Guichard'" , Cc: , References: In-Reply-To: Date: Mon, 2 Nov 2020 17:25:27 +0800 Message-ID: <086d01d6b0fa$1ad07530$50715f90$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_086E_01D6B13D.28F3B530" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQIim+SA Content-Language: zh-cn Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 09:25:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_086E_01D6B13D.28F3B530 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The draft is useful, and I support the adoption. =20 B.R. Weiqiang Cheng =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C222=C8=D5 20:52 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: ippm-chairs@ietf.org; spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 =20 Dear WG: =20 This message starts a 3 week WG adoption call for document https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Please note that this document has several changes = from v-10 that were requested by the SPRING and IPPM chairs. For this reason, = the chairs have extended the adoption call for an additional week to allow = the WG enough time to review these changes before deciding on WG adoption. =20 Some background: =20 =20 Several review comments were received previously for document = https://tools. ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM = chairs considered those comments, and upon review of this version of the = document, determined the following: =20 * The SPRING document should describe only the procedures relevant to SPRING with pointers to non-SPRING document/s that define any = extensions. Several extensions including Control Code Field Extension for TWAMP = Light Messages, Loss Measurement Query Message Extensions, and Loss = Measurement Response Message Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should = be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should be described in a new document published in the IPPM WG. =20 =20 These conclusions were discussed with the authors of https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result = of which is the publication of the following two documents: =20 * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The subject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This document will be progressed (if determined by the WG) within the IPPM = WG. =20 After review of the SPRING document please indicate support (or not) for = WG adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as consent. =20 Finally, the chairs would like to thank the authors for their efforts in this matter. =20 Thanks! =20 Jim, Bruno, & Joel =20 =20 =20 =20 =20 ------=_NextPart_000_086E_01D6B13D.28F3B530 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The draft is useful, and I = support the adoption.

 

B.R.

Weiqiang = Cheng

 

=B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C222=C8=D5 20:52
=CA=D5=BC=FE=C8=CB: = spring@ietf.org
=B3=AD=CB=CD: ippm-chairs@ietf.org; = spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption Call = for = https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /span>

 

Dear WG:

 

This message starts a 3 week WG adoption call for document = ht= tps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending = November 12th 2020. Please note that this document has = several changes from v-10 that were requested by the SPRING and IPPM = chairs. For this reason, the chairs have extended the adoption call for = an additional week to allow the WG enough time to review these changes = before deciding on WG adoption.

 

Some background: =  

 

Several review comments were received previously for = document ht= tps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. = The SPRING and IPPM chairs considered those = comments, and upon review of this version of the document, determined = the following:

 

 

These conclusions were discussed = with the authors of  ht= tps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the = result of which is the publication of the following two = documents:

 

 

After review of the SPRING document please indicate support = (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or = lack thereof) as silence will not be considered as = consent.

 

Finally, the chairs would like to thank the authors for = their efforts in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

 

 

 

 

 

------=_NextPart_000_086E_01D6B13D.28F3B530-- From nobody Mon Nov 2 06:12:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F063A1056; Mon, 2 Nov 2020 06:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=VfJIHj2v; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cfr/Xaud Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woolfo-CJVpr; Mon, 2 Nov 2020 06:12:55 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690B13A1048; Mon, 2 Nov 2020 06:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18248; q=dns/txt; s=iport; t=1604326375; x=1605535975; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AhuwmudxPSgwQghNTpbwGQPNAySuWTzBSPAaZWIu8Pw=; b=VfJIHj2vxk5sBkn9TcoSw2l1d3cwytzoqyVvBvjfebmtUQIi5p5Ntczl m0fwez2ZCpieVM6jgZneXzR/mBG+jF1qnNhqKHc3s6Jf+EnfQAqiRPbx2 jxuNQkwBRe9lvy5vkqJTm5fWRFSoRPpDu1ar6zdYs6kYOIjuYEiOQRtBK I=; X-IPAS-Result: =?us-ascii?q?A0CKBwBUE6Bf/4ENJK1iHgEBCxIMQIFEC4EjL1EHcFkvL?= =?us-ascii?q?gqHfAONTph/gS4UgREDVAsBAQENAQEjCgIEAQGESgKCCAIlNQgOAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgRxhWEMhXIBAQEEEgsQEwEBLAsBDwIBCBEEAQEvMh0IA?= =?us-ascii?q?QEEAQ0FCBqDBYF+TQMuAQ6jdgKBO4hodIE0gwQBAQWBNwKDbRiCEAMGgTiCc?= =?us-ascii?q?opIG4FBP4ERQ4JPPoJdAQEDgSIgHCuDHYIsmnyLVjWRGwqCbIkIkiCCBoESi?= =?us-ascii?q?hGIWotnhhuNL4p4lUcCBAIEBQIOAQEFgVYDNYFXcBU7gmlQFwINjh83GIMih?= =?us-ascii?q?RSFRHQ4AgYKAQEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A5bNzJRURvchL6MyiCe+BigKgBgDV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+BufxZl/fMvr/tWCoL5pPS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4yMOBw?= =?us-ascii?q?/yKgd0YO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoE3Ru8AajJEkJLw2z0?= =?us-ascii?q?7Co2BDfKJdwmY7KA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,445,1596499200"; d="scan'208,217";a="569596027" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Nov 2020 14:12:54 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A2ECsKR018991 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2020 14:12:54 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Nov 2020 08:12:54 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Nov 2020 08:12:53 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 2 Nov 2020 09:12:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CwkJ8VBde2/miWSIH5lCGvwRMCp/u8jREyhGTyB0q+FK1YXFcEBRBCv4QI2Ak795bsrdjS5zH8o1DgO08JGbrbcJLLcFy36d2ED5vu2DwdBLnj5Ih5MXvXEhCSDgAhV28k7IGLfToaUmgQKHXd7sMc2lUQ3TCtYKb+WWMwuNF6yTnazsP11KoYrwMBRRMOC39Ic+LEigOlkbXhq1+ZWzekHEQuFr5z/rh+HJXMqwEp6QuYv0Bm6cwRtz4S9hDgDfAVy/8/uu6OpXQ1D0t4YpKCefgsx+agQlFKTnK7F60YAgsz1DaSKTq4xif6uiGi+RtJBM2QKthFaC7m0y7RQu9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a7081gSi3elPXPbXjO6OmqYdhZ1EcOAHB8jN6yrP5kw=; b=ebETVDr5wSMD6+1+Z2UP6AEnbavKSkMRT4uREjrcLpvacaYMuf7GLKCGkffVfEqe6R/z86dGTRtwkwZfPUb8ifH/SS1y8Eyxt1TVMphltn1JciosEaekAu68NOjen7NCZ5eq2ARl+b+ADO+IGb6tsXyj4VVVQ26mrF4DCaT2K9mhXbxkGQ5U4VRxeBxOBUUW0tHU4y+qPsOToGSDOKVWSwGMMp12ICq93LsBFmmkQjPzY9s20iECsjQR89WGw8NSxuH2nHt3GSJrb3BRASnlCu2SU4RQD916LozDg0GOm1j2sWa5f3RfVtx/LK8aD6SnDMcuO/qhERdhwU1DS7RLQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a7081gSi3elPXPbXjO6OmqYdhZ1EcOAHB8jN6yrP5kw=; b=Cfr/XaudisMGgMgKZmB+d/bavXHR7NTxQYGQMn0SRAr333oN+cWTGqctqhMa91lghLHsmCETCOqkfzr4FuUgM13HtdscXaYudXXX9J/xNAHtehoOQWyydNH4oIuV+XLkIQs/Sr48vgMYVzOya5PzpzP9+l0XYZf0mWAo4Tsi7N0= Received: from DM6PR11MB3802.namprd11.prod.outlook.com (2603:10b6:5:143::30) by DM5PR1101MB2106.namprd11.prod.outlook.com (2603:10b6:4:54::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Mon, 2 Nov 2020 14:12:52 +0000 Received: from DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::74ba:9dd3:1dcf:1de8]) by DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::74ba:9dd3:1dcf:1de8%6]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 14:12:52 +0000 From: "Mike Koldychev (mkoldych)" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: Adaoaxv73543NQYjR7aQ9fY490xJIQItxlqw Date: Mon, 2 Nov 2020 14:12:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b602a936-2a49-4a1a-d284-08d87f396337 x-ms-traffictypediagnostic: DM5PR1101MB2106: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 78YHvTfv0MHTFZav2Y7VYVFlMJWsSb7i6uFfEbpzN0Dp6D2EVB5iVVtKUndQKWWXPBL0lvBB336RH8+H3iJcSql9XYRQVm0q4ZrtB8xD5kcv7uOoQwpF5sRM9mbrlffx701xJjrD5W3t2l3iLVtzThcMysV0XmTWveVp1/PAH0Wwr7xQG3Eo6jQWEnlRXhjBYQ6VDDADlJy0c0QG2BeFp/w1YLQNXW5SFxqxhXBDXSHrQYBlvEI3eZi1n4FfSDja6/gEbDURChDb2D786LFqCQgOkoG7JQMw8nlWW2cfNhjScxFSKEh0ASliHwuK4yXU9soRUENLC/AkRYdcp1Juv2fPJcUQknBuntQWVBB3+oG3vwOO54fI2ltUZz88SHbuyXAYSOa7+ujlYERnGblyjQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3802.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(366004)(39860400002)(396003)(66476007)(4326008)(66446008)(76116006)(66946007)(66556008)(64756008)(2906002)(33656002)(86362001)(52536014)(71200400001)(7696005)(8936002)(9686003)(478600001)(166002)(6506007)(5660300002)(55016002)(8676002)(53546011)(966005)(316002)(110136005)(186003)(83380400001)(54906003)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WOAeJTfgMBM5/rmlq+ThMFUwExAZwEKqla/5Ox9zo8zWRTJ08ceDg0euEw4UjlpWdB8+S6TusCjX5Hy0V3aG/DkxuP1pa4SUDupJ0+YQqf8BeNP6zzcLxESEAlWFDAOfZkTENxJ3VS/lBZ1GLBLZCSPXsSyogPOXtQ3g9KExq5UIQw0i3kfLC1ux0ljCumMd0ToKifRRhFjBO31BDK3M1FiC2rLMocfd7hXBaVA1HCZP214QiohOR2zqlA4tFA94XLTdWr9ssV2GTVk38pOYDRfyNcAHDlIvqJ2fFCEBkqXGe+UvswCo/70bHEE7fmMPUTQnXH61bvNWBuB8HAi9drJYIdiLDXCsy9Tn5KzfIQU1oQbfZ+6k1N3N5spqc/HwVFBriHE4JvXUd9fitb6KPE/dmlrahRzPx/NpKidjpHQLYmb2tiH2ord/SLnRBmN2T2VqSUtCQ26lFRnJivB6VaKh/v+ycWtSBoEfcQHaJreqs/z/woTBZhwt9s4LngACjytn2Y5VhJkFhLKpr/sj7KOwumyav7LKsNWVJPhEzFOYDzcT5zJ+pgTlXh74pYKIHIIbf9IMcV9zIom/u8z71fS5y/c5gIKXn7StNQuQrglFAUGp/Oi/ORP+iDU4oXsNaRfQhv6O7vChhvWVRMFHJQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB380252ECD96D1EF08A909FA2D3100DM6PR11MB3802namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3802.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b602a936-2a49-4a1a-d284-08d87f396337 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 14:12:52.6531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wm2/uIkB2MCxVQF2g3aaz09t2Tz7M6bsuq8MdentqbAXs+YheGIwJCiSkA5DI7MOFQGbXmuEdYR2BUTiMjLVrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2106 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 14:12:58 -0000 --_000_DM6PR11MB380252ECD96D1EF08A909FA2D3100DM6PR11MB3802namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of this document. Thanks, Mike. From: spring On Behalf Of James Guichard Sent: Thursday, October 22, 2020 8:52 AM To: spring@ietf.org Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-03 Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-stamp-srpm-03, ending November 12th 2020. Please not= e that this document has several changes from v-02 that were requested by t= he SPRING and IPPM chairs. For this reason, the chairs have extended the ad= option call for an additional week to allow the WG enough time to review th= ese changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for STAMP Messages,= Loss Measurement Query Message Extensions, Loss Measurement Response Messa= ge Extensions, Node Address TLV Extensions, and Return Path TLV Extensions = were included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02 and should be removed from the SPRING document. * The STAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-02 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.org= /html/draft-gandhi-spring-stamp-srpm-02 the result of which is the publicat= ion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_DM6PR11MB380252ECD96D1EF08A909FA2D3100DM6PR11MB3802namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption of this document.<= /p>

 

Thanks,

Mike.

 

From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 AM
To: spring@ietf.org
Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/d= raft-gandhi-spring-stamp-srpm-03

 

Dear WG:

 

This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending N= ovember 12th 2020. Please note that this document has several ch= anges from v-02 that were requested by the SPRING and IPPM chairs. For this= reason, the chairs have extended the adoption call for an additional week to allow the WG enough time to re= view these changes before deciding on WG adoption.

 

Some background:  

 

Several review comments were received previously for= document h= ttps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chairs considered those comments, = and upon review of this version of the document, determined the following:<= o:p>

 

  • The SPRING document should describe only the pro= cedures relevant to SPRING with pointers to non-SPRING document/s that defi= ne any extensions. Several extensions including Control Code Field Extension fo= r STAMP Messages, Loss Measurement Query Message Extensions, Loss Measurement Respons= e Message Extensions, Node Address TLV Extensions, and = ;Return Path TLV Extensions were include= d in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and= should be removed from the SPRING document.
  • The STAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should be described in a new document published in the= IPPM WG.  

 

These conclusions were discusse= d with the authors of https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the= result of which is the publication of the following two documents:

 

 

After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please also provide comme= nts/reasons for that support (or lack thereof) as silence will not be consi= dered as consent.

&nbs= p;

Finally, = the chairs would like to thank the authors for their efforts in this matter= .

 

Thanks!

 

Jim, Bruno, & Joel

--_000_DM6PR11MB380252ECD96D1EF08A909FA2D3100DM6PR11MB3802namp_-- From nobody Mon Nov 2 07:13:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DACB3A13FD; Mon, 2 Nov 2020 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtgHbLHr-1rN; Mon, 2 Nov 2020 07:12:51 -0800 (PST) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 5D1293A14AB; Mon, 2 Nov 2020 07:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1604329921; x=1635865921; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QfTxLqCZYSAXKRTu3BYQiv4SUbryExZeuE1vFHj3Tfs=; b=U+HcOeBbkRB6lYUOhXWXkSuLeF+rJWGzvcEo6yB/rS0tw8Cgfhcfg+Np v6MwVAsiuyd5jofKA29D2FkC7fCktoUh9G5dyZmDnuws+mD2gaABIJ0Mm 6+r9NDASnMQDjQBMep5qsIpqTcSQfg7Ddr0tdlWCfJMwO2s+tzT+JMBy6 7WyIeHDxu7C3ODIxWmFwGhyk8OUuP5q8j/Bo0zMEJMOaedD09MEZX8ba3 NqftIbvDbrVtAEuW9r5wcJ3yepJ6k6vXODY7OtQY102W6mpIZ+EpcgkMT I0RQZIVwaA3Bbf3WERaIkrS19t6DiHdJbCoN2P3J1KO3hfpy+3v8Q+1N1 g==; IronPort-SDR: BxqM5ODdgkGtCjRz/QJiP01MtxFtPVPWUNMPIJMs/SyifYtgLAmVIfRsQ7zC/FtXAwnr33t0OB x9vf2YIY2k0g== Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 02 Nov 2020 16:11:57 +0100 IronPort-SDR: HJK4Zvtih59pNUIoCthSpKID8cZsbB5VJH6vfQaRcRVE/rYxt28bn7sCerXJnAbSghZd2Ay3Yv bLx/PQU6kI3hTrdsrhyx5HFMGo7GbvqGo= X-IronPort-AV: E=Sophos;i="5.77,445,1596492000"; d="scan'208,217";a="228147844" X-MGA-submission: =?us-ascii?q?MDHSmjfEVgnCZR1FOvrsP3lth2qW0YX8QKsM0l?= =?us-ascii?q?dcBreA+jG84tFM5CoCBEXdweV0W8hnloxuY07MdYv+hhOQdI4yhSvY/o?= =?us-ascii?q?7aAZHbVd6ja4fmbLFYkOdlhkFAHfW9CEJdrt/a+f320aoVEY+UHvamjz?= =?us-ascii?q?XqUGHri7/6THmXDSE6f4mX5g=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by qde0ps.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 02 Nov 2020 16:11:57 +0100 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Nov 2020 16:11:56 +0100 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 2 Nov 2020 16:11:56 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.24) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Nov 2020 16:11:57 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dbYw2J/LVKAhWKKf43tL6OT+v9QLuF1JltBqC9Ko6x8yjHREn2tEaHuSN5opgM+T2raOMUvpWD0QsDsIpuE81slKp1phxewxS1lvWhPcEUpmfRi5OTzTQ420D0CpnKqr/HACz/dWtPh6gKpClLxromMzpX/bQgTE/eHgZMr6mKRfhUPjwb2steN1f9cIl9yurhB9Y0cBKbovP25IyUFSYXv71G4hIFNhVauQZ1Gue3/2KD5ZJh6ysXrSoa/pD1QK/T8x2gjHq5B+UwtBJFswUzX9zfAFU4eILS6rhnWZ/nhRVQL3eujoacew5a9CqzRh4dlEh0+BXf3s/e5BwvRXnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QfTxLqCZYSAXKRTu3BYQiv4SUbryExZeuE1vFHj3Tfs=; b=CkLbH40aAFVka+X+aVtZJvYEXSNeVqApEyTojAa3G2aGWQV05DY2736WD09yXz4wlWKmDj32+RNwoE3ddeIUvjP0Gc7JqZIaiY8R3M4rAWfWMapLdl8JZ4DfZSg6UuWzOG7tSgmFM4nvI1Hb/T/N+QVvD3RiMJaz2mUKYSg7NYNJkmRb05JK0tf2XIntQ0Z9ZccM4ZvYWw+3EvmS6p/JjyKBICmCsGLhCNHz+vwnbsBg5m0sVsbOYjnuEjOGqiIwmlNqSodeAo6NYDQ4ECw2uX5tqT282dq77YrAS6uHqqfoCFdfniYnQjfRZOS7BiDny+EfTYNDwjqOWJDjJDpa+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:5::19) by LEJPR01MB1244.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Mon, 2 Nov 2020 15:11:56 +0000 Received: from LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE ([fe80::95a8:e1db:3c8e:f80b]) by LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE ([fe80::95a8:e1db:3c8e:f80b%7]) with mapi id 15.20.3499.030; Mon, 2 Nov 2020 15:11:56 +0000 From: To: CC: Thread-Topic: [ippm] Call for adoption: draft-geib-ippm-connectivity-monitoring Thread-Index: AQHWruzOQZ5KIE1gS0y4w+8Mp6uKoam058iAgAANcZA= Date: Mon, 2 Nov 2020 15:11:55 +0000 Message-ID: References: <63A1B18E-A7F6-4F91-8503-F1FCE3CF945A@apple.com> <6CAF4468-8AA6-43B7-A621-6116E473BFEC@apple.com> In-Reply-To: <6CAF4468-8AA6-43B7-A621-6116E473BFEC@apple.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telekom.de; x-originating-ip: [87.147.144.105] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4fc0e640-29c1-497d-6c13-08d87f41a33f x-ms-traffictypediagnostic: LEJPR01MB1244: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dlyl1j1hZlSHIpnpHmd9VIGR9AYcQD3FgyxHnbE4Bju9CeRO1IXV1kBaZgYhjf55j/MxGZ3Oh+VR5Xx3S9jg+HxmWmP2q/Sf3G6vd5pvpVY2OZhuxS6wzMSMr/XGrUbm681xQ9t6L0SCuSu3/PgfwIjAk2NBK0LxX9oitqZiZxSuBE1ZYRFZtKoUTZEn3hUm1i5OC9IsPIwR/ugx93SN9jxufGbZXYtVWRjCCZ67GHrFqyyCvPm24ZsiRDsxUhMvjVZdO7Sbf90LHgjuznRX9kkN+Jf6Dah/WO0XYevYERHqG8IjBk8fK93WTVlYgBs9osxFoQUyu2OUSGxy4SFO8qyNZCl0oQap/pOYdr+C7h+HwUwk17co3coztDw0hbnMBUzcuOV6zG0TTArRu0a4Jg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFS:(346002)(136003)(39860400002)(366004)(396003)(376002)(8936002)(8676002)(55016002)(2906002)(4326008)(66476007)(66556008)(64756008)(66446008)(33656002)(76116006)(66946007)(9686003)(450100002)(86362001)(166002)(5660300002)(478600001)(316002)(186003)(83380400001)(71200400001)(6916009)(7696005)(26005)(966005)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9k1ri0uez8x384irwPdN6nHey8AHi90juRbvr5+0jAV+nVeVmKYGQqSt9EIdNxtsSYTgCz9p+UM25C1tr0xKnGWGPmBO0keC0GHn6/SdDNzt1SIO7V0eA34CLVLI72ScXuLteEGJBcVJV/Vw+mLsJ4nJ5yEoXgASk9PqYpFLX85oYHi+NK9Kg2Omy6P8DyrC3+mRLU6jF3e8qpG+/tki0+8UoGEXeHqcE8/dK2RVWnyyl0KdBknVbvd8OWIEK/JCJtiFNXRMN8/4F9FvjO5sFK60euED/Deel2KJ3vBL7+srp94xrLBxmE+4Wf+cHQr6wiW1RBFRDX9Nc4txvajFsO2tldqQ8UMolSMNPoJXSa35HJIxXy0Nd7U6vPhyjVuhMGctLbz4nEkbPe1VZ1DHGK1fvNYA2CRAjGI+kqSzwGbgqmEnfM+X53KjCO9CYnJdrII7RgvPBVK7mHMS1yAGOSKDUUVlU0CcnhGLgybVRifYogjBPDReMvcOZjdm1Mb7MFVj6Twn3UA81Tz2XsfA61mitvjeoFDtUz3g5vqIGGZKjbhBtsJIKPjdQzujg93RRDf2N9DHgn2RMZhrx7G5zSQyvhqfBh/9RQrCqbuTH9U/E/p2hrDgLFwMXavuoV6YQrbqNREViyNxznQ60sjdfg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LEJPR01MB11161639FAC69671BD67FA869C100LEJPR01MB1116DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: 4fc0e640-29c1-497d-6c13-08d87f41a33f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 15:11:55.9310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZD9JZii04CDFER39GXSmv0Kb/19AUaQfyKxtF+5IfhiOVpCcQd5R+v1OCIn7ziNi/DPa2l7IIJbxSNf+8c3Et37hyp+wVx6UpcRTSdW+z24= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB1244 X-TM-SNTS-SMTP: 8E719CC07E54D08A4F547D143482E3E6911A95B6F15A5BDE9B3B593A044757462000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: [spring] WG: [ippm] Call for adoption: draft-geib-ippm-connectivity-monitoring X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:13:01 -0000 --_000_LEJPR01MB11161639FAC69671BD67FA869C100LEJPR01MB1116DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Spring WG, IPPM started a call for adoption of draft-geib-ippm-connectivity-monitoring= -03. The (tomographic) metric suggested by the draft can only be measured a= pplying SR, that's why I forward the call for adoption to the SR list. I ap= preciate your support on ippm@ietf.org, of course. Th= e metric localizes loss of connectivity and congestion. Regards, Ruediger Hello IPPM, This email starts a Working Group call for adoption for draft-geib-ippm-con= nectivity-monitoring. This document has been presented several times and di= scussed within the working group. The document can be found here: https://tools.ietf.org/html/draft-geib-ippm-connectivity-monitoring-03 Please provide your feedback on these document, and state whether or not yo= u believe the IPPM WG should adopt this work by replying to this email. Ple= ase provide your feedback by the start of the IETF 109 meeting week, on Mon= day, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_LEJPR01MB11161639FAC69671BD67FA869C100LEJPR01MB1116DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Spring WG,

 

IPPM started a call for adoption of draft-geib-ippm-= connectivity-monitoring-03. The (tomographic) metric suggested by the draft= can only be measured applying SR, that’s why I forward the call for = adoption to the SR list. I appreciate your support on ippm@ietf.org, of course. = The metric localizes loss of connectivity and congestion.

 

Regards,

 

Ruediger

 

Hello IPPM,


This email starts a Working Group call for adoption for draft-geib-ipp= m-connectivity-monitoring. This document has been presented several times a= nd discussed within the working group.

The document can be found here:

https://tools.= ietf.org/html/draft-geib-ippm-connectivity-monitoring-03


Please provide your feedback on these document, and state whether or not yo= u believe the IPPM WG should adopt this work by replying to this email. Ple= ase provide your feedback by the start of the IETF 109 meeting week, o= n Monday, November 16.

Best,
Tommy & Ian

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

 

--_000_LEJPR01MB11161639FAC69671BD67FA869C100LEJPR01MB1116DEUP_-- From nobody Mon Nov 2 07:26:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BACF3A12C8; Mon, 2 Nov 2020 07:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 mCLG6cSCHZ-B; Mon, 2 Nov 2020 07:26:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5697D3A1282; Mon, 2 Nov 2020 07:25:49 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4CPxZN0Qztzycq; Mon, 2 Nov 2020 16:25:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604330748; bh=YjyRVH9+YHuXbOC+gDiVb4+JqgHr9Hz0khgOk+mfYgc=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=j2fZVxRZdYbBHHrhidlO8/OWXu3UqJpOYf4HYDLkU8SqdrOBHfp6PDTU/loikcJ68 arwEIEQHqos2wr6baGnmzWgn8uOvoxDbca8nsZhbqkvzDL+f1Vsyap1zhpJ1FVnE1m nr9NJ2/zciq/u0it+gR3ZgAMPNbS3eohWWmKzOHBeW79egBkpBjybehFqbgqvpjId7 i+aYrxl4sE+QmdXByhCpIdPW/DmPjhAdi1f7AmWacY8kK3FB6qYFnEZSwm2M07c6+a dX6ddSf7T3tuHtKc351hFwwUYKFhy57aVwaAfH6uTbP306cZ68AecDcJUzAinPiRFD TYuPmnwXTJ9aw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4CPxZM6c3gzDq7V; Mon, 2 Nov 2020 16:25:47 +0100 (CET) From: To: "spring@ietf.org" , "draft-ietf-spring-nsh-sr@ietf.org" Thread-Topic: draft-ietf-spring-nsh-sr Thread-Index: AdaxATgOT2Tp67p4SFyEcOyZqcRmAw== Date: Mon, 2 Nov 2020 15:25:47 +0000 Message-ID: <5865_1604330748_5FA024FB_5865_230_1_53C29892C857584299CBF5D05346208A48FE27D5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48FE27D5OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ietf-spring-nsh-sr X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:26:14 -0000 --_000_53C29892C857584299CBF5D05346208A48FE27D5OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi authors, WG, Authors of draft-ietf-spring-nsh-sr have asked for WG last call. Before initiating it, I've done a review of the draft as document shepherd. Please find below some comments. --- It's not crystal clear to me what the scope and the goal of the document ar= e. - From the abstract, it's an informative description of two applic= ations scenarios - From section 5, it's a specification of how to integrate NSH and= SR. o Although it's only really specified for SRv6 and not SR-MPLS. Please clarify to update the document as needed. ---- IdNits reports for 2 errors. [1] ** Downref: Normative reference to an Informational RFC: RFC 7665 - Probably the only really normative reference is in the security = section. Do you think that a reference to RFC8300 could be used instead (83= 00 has a large security consideration section)? - I noticed that 8300 had the same issue. What was the feedback fr= om AD at the time? ** There are 4 instances of too long lines in the document, the longest o= ne being 82 characters in excess of 72. Could you please correct in the next version of the draft? [1] https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-iet= f-spring-nsh-sr-03.txt ----- Abstract The abstract feels like the document is informational (e.g., This document = describes two application scenarios") But the document asks for an IANA allocation requiring a STD track document= , so the draft needs to be std track. Do you think that you could add that the document defines the encapsulation= of NSH for SR-MPLS and SRv6? ---- The introduction section seems to be coming from the SFC WG. - May be adding some text about SPRING? - Although this is a personal opinion, I find some sentences a bit= marketing oriented. Could you please have a look? E.g. o "The SFC architecture has the merit to not make assumptions" What about "The SFC architecture does not make assumptions"? This seems mor= e neutral. o "Among all these approaches, the IETF endorsed a transport-independent - SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC encapsulation solution. =BB I'm not sure how much "is the most mature" is true or not. I'm not sure tha= t the SPRING WG needs to make such statement nor that it is best placed to = make such statement. I'm not sure about "the IETF endorsed a transport-independent SFC encapsul= ation scheme". Idem with regards to SPRING WG. I'm not sure that this is a = typical statement in RFC. If so, it feels like the IETF would have equally = endorsed transport-depending SFC encapsulation scheme. [RFC8595] https://to= ols.ietf.org/html/rfc8595 - "This design is pragmatic" Looks like an opinion. Plus I'm not sure that the SPRING WG needs to judge = the work of the SFC WG. ---- =A72 "The two SR flavors, namely SR-MPLS [RFC8660] and SRv6 [RFC8754]," May be :s/flavors/data plane "Further considerations such as simplifying classification at intermediate = SFs" I'm not sure that simplifying classification is the main point of adding NS= H. RFC8595 does not refers to this. A priori SR supports a single initial c= lassification. ---- =A72 "A classifier SHOULD assign an NSH Service Path Identifier (SPI) per SR policy so that different traffic flows that use the same NSH Service Function Path (SFP) but different SR policy can coexist on the same SFP without conflict during SFF processing." Is the above sentence applicable to both applications scenarios or only for= the second one (SR-based SFC with integrated NSH service plane)? In the current text, it's applicable to both while I'm not sure that it's a= pplicable to "NSH-based SFC with SR-based transport plane" where the transp= ort plane (hence the SR policy) is independent of the service plane. --- =AB hierarchical SFC [RFC8459] =BB Does this document specifically covers hierarchical SFC (hence hierarchical= SFC & SR)? Is this reference really pertinent? --- =A73 Section 3 barely speaks about SR. Is this really a SPRING document? When SR is refered to, there is nothing specific to SR. e.g. "After removing the outer transport encapsulation, that may or may not= be SR-MPLS or SRv6," If the document is related to the integration of SFC and SR, surely the enc= apsulation is either SR-MPLS or SRv6 (rather than may or may not be SR). May be indicating that in this scenario, there is a priori one SR-policy pe= r SF (while in the next scenario, there is a single SR-policy for the whole= service chain). That would talk about SR and may provide a key distinction= between both. " At the end of the SR-MPLS path it is necessary to provide an indication to the tail-end that NSH follows the SR-MPLS label stack. There are several ways to achieve this but its specification is outside the scope of this document." I agree that this is necessary. But why is the main text related to SR-MPLS in this scenario, not specifyi= ng the behaviour? I don't follow the logic of specifying it for SRv6 (and hence requiring th= is document to be standard track while otherwise it could be an information= al document describing two scenarios) and not specifying it for SR-MPLS. Note that this text is duplicated in =A75.1. And 5.1 is nearly defining one= proposition, so why not saying that this is a solution? (there is no need = to define the encoding for the control plane since this part would likely n= ot be in a spring document) (a specific prefix-SID be allocated at each node for use by the SFC application for this purpose.) --- =A74 The benefits of this scheme include: [...]. o It simplifies the SFF (i.e., the SR router) by nullifying the needs for re-classification and SR proxy. Regarding the need for reclassification, it seems to me that SR alone can n= ullify Regarding the need for SR proxy, the behaviour described seems very close t= o a SR proxy "The SFF strips the SR information of the packet, updates the SR information, and saves it to a cache indexed by the NSH SPI. This saved SR information is used to encapsulate and forward the packet(s) coming back from the SF. =BB o It provides a unique and standard way to pass metadata to SFs. Note that currently there is no solution for SR-MPLS to carry metadata and there is no solution to pass metadata to SR-unaware SFs. RFC8595 provides another standard way to pass meta data for SR-MPLS. https://tools.ietf.org/html/rfc8595#section-12 --- =A77.2 " Encapsulation of NSH following SRv6 may be indicated either by encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the Next Header field of the SRH, or by indicating an IP protocol number for NSH in the Next Header of the SRH. " Why is there a need for two solutions? If so, what are the applicability statement or pro&con of each? For interop purpose, which one is mandatory and which one is optional? Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A48FE27D5OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi authors, WG,

 

Authors of draft-ietf-spring= -nsh-sr have as= ked for WG last call.

Before initiating it, I’ve done a review of the draf= t as document shepherd.

Please find below some comments.

 

---

It’s not crystal clear to me what the scope and the = goal of the document are.

- =          From the abstract, it’s an informative descr= iption of two applications scenarios

- =          From section 5, it’s a specification of how = to integrate NSH and SR.

o   Although it’s only really specified for SRv6= and not SR-MPLS.

 

Please clarify to update the document as needed.

 

----

IdNits reports for 2 errors= . [1]

 &n= bsp;** Downref: Normative reference to an Informatio= nal RFC: RFC 7665

-          Probably the only really normative reference is in the security section. Do you think that a reference to RFC= 8300 could be used instead (8300 has a large security consideration section= )?

-          I noticed that 8300 had the same issue. What was the feedback from AD at the time?

 

  ** There are 4 instances of too long lines in the document, the long= est one

 &n= bsp;   being 82 characters in excess of 72.

Could you please correct in t= he next version of the draft?

 

[1] https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-nsh-sr-03.txt

-----

Abstract

 

The abstract feels like the document is informational (e.g=
., This document describes two application =
scenarios”)

But the document asks for an IANA allocation requiring a S= TD track document, so the draft needs to be std track.

Do you think that you could add that the document defines = the encapsulation of NSH for SR-MPLS and SRv6?

 

----

The introduction section seems to be coming from the SFC W= G.

- =          May be adding some text about SPRING?

-=    &n= bsp;      Although this is a personal opinion, I find some s= entences a bit marketing oriented. Could you please have a look? E.g.

o    “The SFC architecture has the merit to not make assumptions”
What about “The SFC architecture does n= ot make assumptions”? This seems more neutral.

o    “Among all these approaches, the IETF endorsed a transport-independent

-             SFC encap=
sulation scheme: NSH [RFC8300]; which is =
the most mature SFC encapsulation solution. =BB
I’m not sure how much “is the most mature” is =
true or not. I’m not sure that the SPRING WG needs to make such state=
ment nor that it is best placed to make such statement.
I’m not su=
re about “the IETF endorsed a transport-independent  SFC encapsulation scheme”. Idem with regards to SPRING WG. I’m not sure =
that this is a typical statement in RFC. If so, it feels like the IETF woul=
d have equally endorsed transport-depending SFC encapsulation scheme. [RFC8=
595] https://tools.ietf.org=
/html/rfc8595

-&nb= sp;         “This design is pragmatic= 221;
Looks like an opinion. Plus I’m not sure that the SPRING WG needs to= judge the work of the SFC WG.

----

=A72

“The two =
SR flavors, namely SR-MPLS [RFC8660] and SRv6 [RFC8754],”
M=
ay be :s/flavors/data plane

 

“Further =
considerations such as simplifying classification at intermediate SFs”=
;

I’m not sure that simplifying classification is the = main point of adding NSH. RFC8595 does not refers to this. A priori SR supp= orts a single initial classification.

&= nbsp;

----

=A72

“A classi=
fier SHOULD assign an NSH Service Path Identifier (SPI) per
   SR policy so that different traffic f=
lows that use the same NSH
   Service Function Path (SFP) but diffe=
rent SR policy can coexist on
   the same SFP without conflict during =
SFF processing.”
 
I=
s the above sentence applicable to both applications scenarios or only for =
the second one (SR-based SFC with integrated NSH service plane)?
I=
n the current text, it’s applicable to both while I’m not sure =
that it’s applicable to “NSH-based SFC with SR-based transport plane”<=
span style=3D"color:#1F497D"> where the transport plane (hence the SR polic=
y) is independent of the service plane.
-=
--
=AB hierarchical SFC [RFC8459] =BB 
D=
oes this document specifically covers hierarchical SFC (hence hierarchical =
SFC & SR)? Is this reference really pertinent?
 

---

=A73

Section 3 barely speaks about SR. Is this really a SPRING = document?

W=
hen SR is refered to, there is nothing specif=
ic to SR.
e=
.g. “Af=
ter removing the outer transport encapsulation, that may or may not be SR-M=
PLS or SRv6,”

If the document is related to the integration of SFC and S= R, surely the encapsulation is either SR-MPLS or SRv6 (rather than may or m= ay not be SR).

 

May be indicating that in this scenario, there is a priori= one SR-policy per SF (while in the next scenario, there is a single SR-pol= icy for the whole service chain). That would talk about SR and may provide a key distinction between both.

 
 
  “ At the end of the SR-MPLS path it i=
s necessary to provide an
   indication to the tail-end that NSH f=
ollows the SR-MPLS label stack.
   There are several ways to achieve thi=
s but its specification is
   outside the scope of this document.&#=
8221;
 

I agree that this is necessary.

But why is the main  text related to SR-MPLS in th= is scenario, not specifying the behaviour?

I  don’t follow the logic = of specifying it for SRv6 (and hence requiring this document to be standard= track while otherwise it could be an informational document describing two= scenarios) and not specifying it for SR-MPLS.

N=
ote that this text is duplicated in =A75.1. And 5.1 is nearly defining one =
proposition, so why not saying that this is a solution? (there is no need t=
o define the encoding for the control plane since this part would likely no=
t be in a spring document) (a
   specific prefix-SID be allocated at e=
ach node for use by the SFC
   application for this purpose.)

 


 


---


=A74


   The benefits of this scheme include:<=
o:p>


 


[…].=



 


   o&nb=
sp; It simplifies the SFF (i.e., the SR router) by nullifying the


      needs for re-classi=
fication and SR proxy.


 


Regarding the need for reclassification, it seems to me th=
at SR alone can nullify


R=
egarding the need for SR proxy, the behaviour described seems very close to=
 a SR proxy “The SFF strips


   the SR information of the packet, upd=
ates the SR information, and


   saves it to a cache indexed by the NS=
H SPI.  This saved SR


   information is used to encapsulate an=
d forward the packet(s) coming


   back fr=
om the SF. =BB


 


 


 


   o&nb=
sp; It provides a unique and standard way to pass metadata to SFs.


      Note that currently=
 there is no solution for SR-MPLS to carry


      metadata and there =
is no solution to pass metadata to SR-unaware


      SFs.


 


RFC8595 provides another standard way to pass meta data fo=
r SR-MPLS.


https://tools.ietf.org/html/rfc8595#section-12


 


---


=A77.2


“   Encapsulation of NSH following=
 SRv6 may be indicated either by


   encapsulating NSH in UDP (UDP port TB=
A1) and indicating UDP in the


   Next Header field of the SRH, or by i=
ndicating an IP protocol number


   for NSH in the Next Header of the SRH=
. “


 


Why is there a need for two solutions?



If so, what are the applicability statement or
pro&con of each?


For interop purpose, which one is mandatory and which one =
is optional?


 


Thanks,


Regards,


--Bruno


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A48FE27D5OPEXCAUBM43corp_-- From nobody Mon Nov 2 07:51:33 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82043A0D02; Mon, 2 Nov 2020 07:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2IwaCa2XItKZ; Mon, 2 Nov 2020 07:51:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D0A3A0CB9; Mon, 2 Nov 2020 07:51:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CPy815L3tz1nvlM; Mon, 2 Nov 2020 07:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604332289; bh=7NjUyJ+g5DAYAKFsQ/gADX8mbM6ssLQLBlyjsadCA/A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VZHq4chqScDRMFQOtZG29Hd7rPiVV+481MU4HzoTHhnSd8/W60MSdwE55ullMNEme fqCE43EwJEURV4SDc+mHZEF6VFI/7m5T74sEylJm9P7dQVFBDklc5n0+BEUi4K6mD0 WAdgqwzoI0rhoBK+nOCmS6rUhwm3+6ixxoBScEa4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (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 4CPy81131zz1nwCs; Mon, 2 Nov 2020 07:51:29 -0800 (PST) To: bruno.decraene@orange.com, "spring@ietf.org" , "draft-ietf-spring-nsh-sr@ietf.org" References: <5865_1604330748_5FA024FB_5865_230_1_53C29892C857584299CBF5D05346208A48FE27D5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Mon, 2 Nov 2020 10:51:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5865_1604330748_5FA024FB_5865_230_1_53C29892C857584299CBF5D05346208A48FE27D5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] draft-ietf-spring-nsh-sr X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:51:32 -0000 We will work on these comments. On the downref, when we did the IETF LC for what became RFC 8300, we explicitly included the downref to 7665. There is a standard IETF procedure for that case. In this case, we will look to see if 8300 would be a better reference. At first glance, it would. Yours, Joel On 11/2/2020 10:25 AM, bruno.decraene@orange.com wrote: > Hi authors, WG, > > Authors of draft-ietf-spring-nsh-sr have asked for WG last call. > > Before initiating it, I’ve done a review of the draft as document shepherd. > > Please find below some comments. > > --- > > It’s not crystal clear to me what the scope and the goal of the document > are. > > -From the abstract, it’s an informative description of two applications > scenarios > > -From section 5, it’s a specification of how to integrate NSH and SR. > > oAlthough it’s only really specified for SRv6 and not SR-MPLS. > > Please clarify to update the document as needed. > > ---- > > IdNitsreports for 2 errors. [1] > > ** Downref: Normative reference to an Informational RFC: RFC 7665 > > -Probably the only really normative reference is in the security > section. Do you think that a reference to RFC8300 could be used instead > (8300 has a large security consideration section)? > > -I noticed that 8300 had the same issue. What was the feedback from AD > at the time? > > ** There are 4 instances of too long lines in the document, the longest one > > being 82 characters in excess of 72. > > Could you please correct in the next version of the draft? > > [1] > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-03.txt > > ----- > > Abstract > > The abstract feels like the document is informational (e.g.,This > document describes two application scenarios”) > > But the document asks for an IANA allocation requiring a STD track > document, so the draft needs to be std track. > > Do you think that you could add that the document defines the > encapsulation of NSH for SR-MPLS and SRv6? > > ---- > > The introduction section seems to be coming from the SFC WG. > > -May be adding some text about SPRING? > > -Although this is a personal opinion, I find some sentences a bit > marketing oriented. Could you please have a look? E.g. > > o“The SFC architecture has the merit to not make assumptions” > What about “The SFC architecture does not make assumptions”? This seems > more neutral. > > o“Among all these approaches, the IETF endorsed a transport-independent > > -SFC encapsulation scheme: NSH [RFC8300 ]; which is the most mature SFC encapsulation solution. » > I’m not sure how much “is the most mature” is true or not. I’m not sure > that the SPRING WG needs to make such statement nor that it is best > placed to make such statement. > I’m not sure about “the IETF endorsed a transport-independentSFC > encapsulation scheme”. Idem with regards to SPRING WG. I’m not sure that > this is a typical statement in RFC. If so, it feels like the IETF would > have equally endorsed transport-depending SFC encapsulation scheme. > [RFC8595] https://tools.ietf.org/html/rfc8595 > > -“This design is pragmatic” > Looks like an opinion. Plus I’m not sure that the SPRING WG needs to > judge the work of the SFC WG. > > ---- > > §2 > > “The two SR flavors, namely SR-MPLS [RFC8660 ] and SRv6 [RFC8754 ],” > > May be :s/flavors/data plane > > “Further considerations such as simplifying classification at > intermediate SFs” > > I’m not sure that simplifying classification is the main point of adding > NSH. RFC8595 does not refers to this. A priori SR supports a single > initial classification. > > ---- > > §2 > > “A classifier SHOULD assign an NSH Service Path Identifier (SPI) per > > SR policy so that different traffic flows that use the same NSH > > Service Function Path (SFP) but different SR policy can coexist on > > the same SFP without conflict during SFF processing.” > > Is the above sentence applicable to both applications scenarios or only > for the second one (SR-based SFC with integrated NSH service plane)? > > In the current text, it’s applicable to both while I’m not sure that > it’s applicable to “NSH-based SFC with SR-based transport plane”where > the transport plane (hence the SR policy) is independent of the service > plane. > > --- > > «hierarchical SFC [RFC8459 ] » > > Does this document specifically covers hierarchical SFC (hence > hierarchical SFC & SR)? Is this reference really pertinent? > > --- > > §3 > > Section 3 barely speaks about SR. Is this really a SPRING document? > > When SR is refered to, there is nothing specific to SR. > > e.g. “After removing the outer transport encapsulation, that may or may > not be SR-MPLS or SRv6,” > > If the document is related to the integration of SFC and SR, surely the > encapsulation is either SR-MPLS or SRv6 (rather than may or may not be SR). > > May be indicating that in this scenario, there is a priori one SR-policy > per SF (while in the next scenario, there is a single SR-policy for the > whole service chain). That would talk about SR and may provide a key > distinction between both. > > “ At the end of the SR-MPLS path it is necessary to provide an > > indication to the tail-end that NSH follows the SR-MPLS label stack. > > There are several ways to achieve this but its specification is > > outside the scope of this document.” > > I agree that this is necessary. > > But why is the main text related to SR-MPLS in this scenario, not > specifying the behaviour? > > I don’t follow the logic of specifying it for SRv6 (and hence requiring > this document to be standard track while otherwise it could be an > informational document describing two scenarios) and not specifying it > for SR-MPLS. > > Note that this text is duplicated in §5.1. And 5.1 is nearly defining > one proposition, so why not saying that this is a solution? (there is no > need to define the encoding for the control plane since this part would > likely not be in a spring document) (a > > specific prefix-SID be allocated at each node for use by the SFC > > application forthis purpose.) > > --- > > §4 > > The benefits of this scheme include: > > […]. > > oIt simplifies the SFF (i.e., the SR router) by nullifying the > > needs for re-classification and SR proxy. > > Regarding the need for reclassification, it seems to me that SR alone > can nullify > > Regarding the need for SR proxy, the behaviour described seems very > close to a SR proxy “The SFF strips > > the SR information of the packet, updates the SR information, and > > saves it to a cache indexed by the NSH SPI.This saved SR > > information is used to encapsulate and forward the packet(s) coming > > backfrom the SF. » > > oIt provides a unique and standard way to pass metadata to SFs. > > Note that currently there is no solution for SR-MPLS to carry > > metadata and there is no solution to pass metadata to SR-unaware > > SFs. > > RFC8595 provides another standard way to pass meta data for SR-MPLS. > > https://tools.ietf.org/html/rfc8595#section-12 > > --- > > §7.2 > > “Encapsulation of NSH following SRv6 may be indicated either by > > encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the > > Next Header field of the SRH, or by indicating an IP protocol number > > for NSH in the Next Header of the SRH. “ > > Why is there a need for two solutions? > > If so, what are the applicability statement or pro&con of each? > > For interop purpose, which one is mandatory and which one is optional? > > Thanks, > > Regards, > > --Bruno > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Nov 2 19:48:07 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C164B3A13E8; Mon, 2 Nov 2020 19:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6J8jWLcXDPNt; Mon, 2 Nov 2020 19:48:02 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C80453A13EA; Mon, 2 Nov 2020 19:48:01 -0800 (PST) Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 231795467E2E73F67BFD; Tue, 3 Nov 2020 03:48:00 +0000 (GMT) Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 3 Nov 2020 03:47:59 +0000 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 3 Nov 2020 03:47:59 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.249]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 11:47:54 +0800 From: "Chengli (Cheng Li)" To: "bruno.decraene@orange.com" , "spring@ietf.org" , "draft-ietf-spring-nsh-sr@ietf.org" Thread-Topic: draft-ietf-spring-nsh-sr Thread-Index: AdaxATgOT2Tp67p4SFyEcOyZqcRmAwAkffaw Date: Tue, 3 Nov 2020 03:47:54 +0000 Message-ID: References: <5865_1604330748_5FA024FB_5865_230_1_53C29892C857584299CBF5D05346208A48FE27D5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <5865_1604330748_5FA024FB_5865_230_1_53C29892C857584299CBF5D05346208A48FE27D5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02C880FBdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] draft-ietf-spring-nsh-sr X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 03:48:06 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02C880FBdggeml529mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBCcnVub6GvcyBjb21tZW50cyBvbiBzZWN0aW9uIDQuDQoNCkkgdGhpbmsgdGhp cyBpcyBtb3JlIGxpa2UgYW4gUHJveHkgbWVjaGFuaXNtLiBBbHNvLCBJIG9ubHkgc2VlIE5TSCBv dmVyIFNSLU1QTFMgaXMgaWxsdXN0cmF0ZWQgaW4gdGhlIGZpZ3VyZS4gSG93IGFib3V0IFNSdjaj vw0KDQpXaGVuIGEgcGFja2V0IGhhcyB0byBiZSBmb3J3YXJkZWQgdG8gYW4gU0YgYXR0YWNoZWQg dG8gYW4gU0ZGLCB0aGUNCiAgIFNGRiBwZXJmb3JtcyBhIGxvb2t1cCBvbiB0aGUgcHJlZml4IFNJ RA0KDQpQcmVmaXggU0lEIGlzIG9ubHkgaW4gU1ItTVBMUy4gSW4gU1J2NiwgaXQgaXMgYSBBZGot U0lEPyBPciBhIHByb3h5IFNJRD8NCg0KDQogICBhc3NvY2lhdGVkIHdpdGggdGhlIFNGIHRvDQog ICByZXRyaWV2ZSB0aGUgbmV4dCBob3AgY29udGV4dCBiZXR3ZWVuIHRoZSBTRkYgYW5kIFNGIChl LmcuLCB0bw0KICAgcmV0cmlldmUgdGhlIGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIGluIGNhc2Ug bmF0aXZlIEV0aGVybmV0DQogICBlbmNhcHN1bGF0aW9uIGlzIHVzZWQgYmV0d2VlbiBTRkYgYW5k IFNGKS4gIEhvdyB0aGUgbmV4dCBob3AgY29udGV4dA0KICAgaXMgcG9wdWxhdGVkIGlzIG91dCBv ZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KVGhlIFNGRiBzdHJpcHMNCiAgIHRoZSBT UiBpbmZvcm1hdGlvbiBvZiB0aGUgcGFja2V0LCB1cGRhdGVzIHRoZSBTUiBpbmZvcm1hdGlvbiwg YW5kDQogICBzYXZlcyBpdCB0byBhIGNhY2hlIGluZGV4ZWQgYnkgdGhlIE5TSCBTUEkuDQoNCkl0 IGlzIHJlYWxseSBsaWtlIGFuIHByb3h5IG1lY2hhbmlzbS4gVG8gbWUsIGl0IGlzIGEgc3BlY2lh bCBwcm94eSBieSB1c2luZyBOU0ggYXMgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBiZXR3ZWVuIFNG RiBhbmQgU0YuDQpEbyB3ZSBuZWVkIHRvIGRlZmluZSBhbiBFTkQuTlNIIFNJRCBvciBzb21ldGhp bmcgbGlrZSB0aGlzIGZvciB0aGlzPw0KDQoNClRoaXMgc2F2ZWQgU1INCiAgIGluZm9ybWF0aW9u IGlzIHVzZWQgdG8gZW5jYXBzdWxhdGUgYW5kIGZvcndhcmQgdGhlIHBhY2tldChzKSBjb21pbmcN CiAgIGJhY2sgZnJvbSB0aGUgU0YuDQoNCiAgIFdoZW4gdGhlIFNGIHJlY2VpdmVzIHRoZSBwYWNr ZXQsIGl0IHByb2Nlc3NlcyBpdCBhcyB1c3VhbCBhbmQgc2VuZHMNCiAgIGl0IGJhY2sgdG8gdGhl IFNGRi4gIE9uY2UgdGhlIFNGRiByZWNlaXZlcyB0aGlzIHBhY2tldCwgaXQgZXh0cmFjdHMNCiAg IHRoZSBTUiBpbmZvcm1hdGlvbiB1c2luZyB0aGUgTlNIIFNQSSBhcyB0aGUgaW5kZXggaW50byB0 aGUgY2FjaGUuDQogICBUaGUgU0ZGIHRoZW4gcHVzaGVzIHRoZSBTUiBoZWFkZXIgb24gdG9wIG9m IHRoZSBOU0ggaGVhZGVyLCBhbmQNCiAgIGZvcndhcmRzIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQg c2VnbWVudCBpbiB0aGUgc2VnbWVudCBsaXN0Lg0KDQoNCkJlc3QsDQpDaGVuZw0KDQoNCg0KDQpG cm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMiwgMjAy MCAxMToyNiBQTQ0KVG86IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zcHJpbmctbnNoLXNy QGlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBkcmFmdC1pZXRmLXNwcmluZy1uc2gtc3INCg0K SGkgYXV0aG9ycywgV0csDQoNCkF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctbnNoLXNyIGhh dmUgYXNrZWQgZm9yIFdHIGxhc3QgY2FsbC4NCkJlZm9yZSBpbml0aWF0aW5nIGl0LCBJoa92ZSBk b25lIGEgcmV2aWV3IG9mIHRoZSBkcmFmdCBhcyBkb2N1bWVudCBzaGVwaGVyZC4NClBsZWFzZSBm aW5kIGJlbG93IHNvbWUgY29tbWVudHMuDQoNCi0tLQ0KSXShr3Mgbm90IGNyeXN0YWwgY2xlYXIg dG8gbWUgd2hhdCB0aGUgc2NvcGUgYW5kIHRoZSBnb2FsIG9mIHRoZSBkb2N1bWVudCBhcmUuDQoN Ci0gICAgICAgICAgRnJvbSB0aGUgYWJzdHJhY3QsIGl0oa9zIGFuIGluZm9ybWF0aXZlIGRlc2Ny aXB0aW9uIG9mIHR3byBhcHBsaWNhdGlvbnMgc2NlbmFyaW9zDQoNCi0gICAgICAgICAgRnJvbSBz ZWN0aW9uIDUsIGl0oa9zIGEgc3BlY2lmaWNhdGlvbiBvZiBob3cgdG8gaW50ZWdyYXRlIE5TSCBh bmQgU1IuDQoNCm8gICBBbHRob3VnaCBpdKGvcyBvbmx5IHJlYWxseSBzcGVjaWZpZWQgZm9yIFNS djYgYW5kIG5vdCBTUi1NUExTLg0KDQpQbGVhc2UgY2xhcmlmeSB0byB1cGRhdGUgdGhlIGRvY3Vt ZW50IGFzIG5lZWRlZC4NCg0KLS0tLQ0KSWROaXRzIHJlcG9ydHMgZm9yIDIgZXJyb3JzLiBbMV0N CiAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBJbmZvcm1hdGlvbmFsIFJG QzogUkZDIDc2NjUNCg0KLSAgICAgICAgICBQcm9iYWJseSB0aGUgb25seSByZWFsbHkgbm9ybWF0 aXZlIHJlZmVyZW5jZSBpcyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbi4gRG8geW91IHRoaW5rIHRo YXQgYSByZWZlcmVuY2UgdG8gUkZDODMwMCBjb3VsZCBiZSB1c2VkIGluc3RlYWQgKDgzMDAgaGFz IGEgbGFyZ2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uKT8NCg0KLSAgICAgICAgICBJ IG5vdGljZWQgdGhhdCA4MzAwIGhhZCB0aGUgc2FtZSBpc3N1ZS4gV2hhdCB3YXMgdGhlIGZlZWRi YWNrIGZyb20gQUQgYXQgdGhlIHRpbWU/DQoNCiAgKiogVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9m IHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qgb25lDQogICAgIGJl aW5nIDgyIGNoYXJhY3RlcnMgaW4gZXhjZXNzIG9mIDcyLg0KQ291bGQgeW91IHBsZWFzZSBjb3Jy ZWN0IGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Pw0KDQpbMV0gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0 Zi1zcHJpbmctbnNoLXNyLTAzLnR4dA0KLS0tLS0NCkFic3RyYWN0DQoNCg0KVGhlIGFic3RyYWN0 IGZlZWxzIGxpa2UgdGhlIGRvY3VtZW50IGlzIGluZm9ybWF0aW9uYWwgKGUuZy4sIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIHR3byBhcHBsaWNhdGlvbiBzY2VuYXJpb3OhsSkNCkJ1dCB0aGUgZG9j dW1lbnQgYXNrcyBmb3IgYW4gSUFOQSBhbGxvY2F0aW9uIHJlcXVpcmluZyBhIFNURCB0cmFjayBk b2N1bWVudCwgc28gdGhlIGRyYWZ0IG5lZWRzIHRvIGJlIHN0ZCB0cmFjay4NCkRvIHlvdSB0aGlu ayB0aGF0IHlvdSBjb3VsZCBhZGQgdGhhdCB0aGUgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZW5jYXBz dWxhdGlvbiBvZiBOU0ggZm9yIFNSLU1QTFMgYW5kIFNSdjY/DQoNCi0tLS0NClRoZSBpbnRyb2R1 Y3Rpb24gc2VjdGlvbiBzZWVtcyB0byBiZSBjb21pbmcgZnJvbSB0aGUgU0ZDIFdHLg0KDQotICAg ICAgICAgIE1heSBiZSBhZGRpbmcgc29tZSB0ZXh0IGFib3V0IFNQUklORz8NCg0KLSAgICAgICAg ICBBbHRob3VnaCB0aGlzIGlzIGEgcGVyc29uYWwgb3BpbmlvbiwgSSBmaW5kIHNvbWUgc2VudGVu Y2VzIGEgYml0IG1hcmtldGluZyBvcmllbnRlZC4gQ291bGQgeW91IHBsZWFzZSBoYXZlIGEgbG9v az8gRS5nLg0KDQpvICAgIKGwVGhlIFNGQyBhcmNoaXRlY3R1cmUgaGFzIHRoZSBtZXJpdCB0byBu b3QgbWFrZSBhc3N1bXB0aW9uc6GxDQpXaGF0IGFib3V0IKGwVGhlIFNGQyBhcmNoaXRlY3R1cmUg ZG9lcyBub3QgbWFrZSBhc3N1bXB0aW9uc6GxPyBUaGlzIHNlZW1zIG1vcmUgbmV1dHJhbC4NCg0K byAgICChsEFtb25nIGFsbCB0aGVzZSBhcHByb2FjaGVzLCB0aGUgSUVURiBlbmRvcnNlZCBhIHRy YW5zcG9ydC1pbmRlcGVuZGVudA0KDQotICAgICAgICAgICAgIFNGQyBlbmNhcHN1bGF0aW9uIHNj aGVtZTogTlNIIFtSRkM4MzAwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzAwPl07 IHdoaWNoIGlzIHRoZSBtb3N0IG1hdHVyZSBTRkMgZW5jYXBzdWxhdGlvbiBzb2x1dGlvbi4gPg0K SaGvbSBub3Qgc3VyZSBob3cgbXVjaCChsGlzIHRoZSBtb3N0IG1hdHVyZaGxIGlzIHRydWUgb3Ig bm90LiBJoa9tIG5vdCBzdXJlIHRoYXQgdGhlIFNQUklORyBXRyBuZWVkcyB0byBtYWtlIHN1Y2gg c3RhdGVtZW50IG5vciB0aGF0IGl0IGlzIGJlc3QgcGxhY2VkIHRvIG1ha2Ugc3VjaCBzdGF0ZW1l bnQuDQpJoa9tIG5vdCBzdXJlIGFib3V0IKGwdGhlIElFVEYgZW5kb3JzZWQgYSB0cmFuc3BvcnQt aW5kZXBlbmRlbnQgIFNGQyBlbmNhcHN1bGF0aW9uIHNjaGVtZaGxLiBJZGVtIHdpdGggcmVnYXJk cyB0byBTUFJJTkcgV0cuIEmhr20gbm90IHN1cmUgdGhhdCB0aGlzIGlzIGEgdHlwaWNhbCBzdGF0 ZW1lbnQgaW4gUkZDLiBJZiBzbywgaXQgZmVlbHMgbGlrZSB0aGUgSUVURiB3b3VsZCBoYXZlIGVx dWFsbHkgZW5kb3JzZWQgdHJhbnNwb3J0LWRlcGVuZGluZyBTRkMgZW5jYXBzdWxhdGlvbiBzY2hl bWUuIFtSRkM4NTk1XSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODU5NQ0KDQotICAg ICAgICAgIKGwVGhpcyBkZXNpZ24gaXMgcHJhZ21hdGljobENCkxvb2tzIGxpa2UgYW4gb3Bpbmlv bi4gUGx1cyBJoa9tIG5vdCBzdXJlIHRoYXQgdGhlIFNQUklORyBXRyBuZWVkcyB0byBqdWRnZSB0 aGUgd29yayBvZiB0aGUgU0ZDIFdHLg0KLS0tLQ0KoewyDQoNCqGwVGhlIHR3byBTUiBmbGF2b3Jz LCBuYW1lbHkgU1ItTVBMUyBbUkZDODY2MDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj ODY2MD5dIGFuZCBTUnY2IFtSRkM4NzU0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NzU0Pl0sobENCg0KTWF5IGJlIDpzL2ZsYXZvcnMvZGF0YSBwbGFuZQ0KDQoNCqGwRnVydGhlciBj b25zaWRlcmF0aW9ucyBzdWNoIGFzIHNpbXBsaWZ5aW5nIGNsYXNzaWZpY2F0aW9uIGF0IGludGVy bWVkaWF0ZSBTRnOhsQ0KSaGvbSBub3Qgc3VyZSB0aGF0IHNpbXBsaWZ5aW5nIGNsYXNzaWZpY2F0 aW9uIGlzIHRoZSBtYWluIHBvaW50IG9mIGFkZGluZyBOU0guIFJGQzg1OTUgZG9lcyBub3QgcmVm ZXJzIHRvIHRoaXMuIEEgcHJpb3JpIFNSIHN1cHBvcnRzIGEgc2luZ2xlIGluaXRpYWwgY2xhc3Np ZmljYXRpb24uDQoNCg0KLS0tLQ0KoewyDQoNCqGwQSBjbGFzc2lmaWVyIFNIT1VMRCBhc3NpZ24g YW4gTlNIIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkpIHBlcg0KDQogICBTUiBwb2xpY3kg c28gdGhhdCBkaWZmZXJlbnQgdHJhZmZpYyBmbG93cyB0aGF0IHVzZSB0aGUgc2FtZSBOU0gNCg0K ICAgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGJ1dCBkaWZmZXJlbnQgU1IgcG9saWN5IGNh biBjb2V4aXN0IG9uDQoNCiAgIHRoZSBzYW1lIFNGUCB3aXRob3V0IGNvbmZsaWN0IGR1cmluZyBT RkYgcHJvY2Vzc2luZy6hsQ0KDQoNCg0KSXMgdGhlIGFib3ZlIHNlbnRlbmNlIGFwcGxpY2FibGUg dG8gYm90aCBhcHBsaWNhdGlvbnMgc2NlbmFyaW9zIG9yIG9ubHkgZm9yIHRoZSBzZWNvbmQgb25l IChTUi1iYXNlZCBTRkMgd2l0aCBpbnRlZ3JhdGVkIE5TSCBzZXJ2aWNlIHBsYW5lKT8NCg0KSW4g dGhlIGN1cnJlbnQgdGV4dCwgaXShr3MgYXBwbGljYWJsZSB0byBib3RoIHdoaWxlIEmhr20gbm90 IHN1cmUgdGhhdCBpdKGvcyBhcHBsaWNhYmxlIHRvIKGwTlNILWJhc2VkIFNGQyB3aXRoIFNSLWJh c2VkIHRyYW5zcG9ydCBwbGFuZaGxIHdoZXJlIHRoZSB0cmFuc3BvcnQgcGxhbmUgKGhlbmNlIHRo ZSBTUiBwb2xpY3kpIGlzIGluZGVwZW5kZW50IG9mIHRoZSBzZXJ2aWNlIHBsYW5lLg0KDQotLS0N Cg0KPCBoaWVyYXJjaGljYWwgU0ZDIFtSRkM4NDU5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM4NDU5Pl0gPg0KDQpEb2VzIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWNhbGx5IGNvdmVycyBo aWVyYXJjaGljYWwgU0ZDIChoZW5jZSBoaWVyYXJjaGljYWwgU0ZDICYgU1IpPyBJcyB0aGlzIHJl ZmVyZW5jZSByZWFsbHkgcGVydGluZW50Pw0KDQoNCi0tLQ0KoewzDQpTZWN0aW9uIDMgYmFyZWx5 IHNwZWFrcyBhYm91dCBTUi4gSXMgdGhpcyByZWFsbHkgYSBTUFJJTkcgZG9jdW1lbnQ/DQoNCldo ZW4gU1IgaXMgcmVmZXJlZCB0bywgdGhlcmUgaXMgbm90aGluZyBzcGVjaWZpYyB0byBTUi4NCg0K ZS5nLiChsEFmdGVyIHJlbW92aW5nIHRoZSBvdXRlciB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbiwg dGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBTUi1NUExTIG9yIFNSdjYsobENCklmIHRoZSBkb2N1bWVu dCBpcyByZWxhdGVkIHRvIHRoZSBpbnRlZ3JhdGlvbiBvZiBTRkMgYW5kIFNSLCBzdXJlbHkgdGhl IGVuY2Fwc3VsYXRpb24gaXMgZWl0aGVyIFNSLU1QTFMgb3IgU1J2NiAocmF0aGVyIHRoYW4gbWF5 IG9yIG1heSBub3QgYmUgU1IpLg0KDQpNYXkgYmUgaW5kaWNhdGluZyB0aGF0IGluIHRoaXMgc2Nl bmFyaW8sIHRoZXJlIGlzIGEgcHJpb3JpIG9uZSBTUi1wb2xpY3kgcGVyIFNGICh3aGlsZSBpbiB0 aGUgbmV4dCBzY2VuYXJpbywgdGhlcmUgaXMgYSBzaW5nbGUgU1ItcG9saWN5IGZvciB0aGUgd2hv bGUgc2VydmljZSBjaGFpbikuIFRoYXQgd291bGQgdGFsayBhYm91dCBTUiBhbmQgbWF5IHByb3Zp ZGUgYSBrZXkgZGlzdGluY3Rpb24gYmV0d2VlbiBib3RoLg0KDQoNCg0KDQoNCiAgobAgQXQgdGhl IGVuZCBvZiB0aGUgU1ItTVBMUyBwYXRoIGl0IGlzIG5lY2Vzc2FyeSB0byBwcm92aWRlIGFuDQoN CiAgIGluZGljYXRpb24gdG8gdGhlIHRhaWwtZW5kIHRoYXQgTlNIIGZvbGxvd3MgdGhlIFNSLU1Q TFMgbGFiZWwgc3RhY2suDQoNCiAgIFRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8gYWNoaWV2ZSB0 aGlzIGJ1dCBpdHMgc3BlY2lmaWNhdGlvbiBpcw0KDQogICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LqGxDQoNCg0KSSBhZ3JlZSB0aGF0IHRoaXMgaXMgbmVjZXNzYXJ5Lg0KQnV0 IHdoeSBpcyB0aGUgbWFpbiAgdGV4dCByZWxhdGVkIHRvIFNSLU1QTFMgaW4gdGhpcyBzY2VuYXJp bywgbm90IHNwZWNpZnlpbmcgdGhlIGJlaGF2aW91cj8NCkkgIGRvbqGvdCBmb2xsb3cgdGhlIGxv Z2ljIG9mIHNwZWNpZnlpbmcgaXQgZm9yIFNSdjYgKGFuZCBoZW5jZSByZXF1aXJpbmcgdGhpcyBk b2N1bWVudCB0byBiZSBzdGFuZGFyZCB0cmFjayB3aGlsZSBvdGhlcndpc2UgaXQgY291bGQgYmUg YW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZXNjcmliaW5nIHR3byBzY2VuYXJpb3MpIGFuZCBu b3Qgc3BlY2lmeWluZyBpdCBmb3IgU1ItTVBMUy4NCg0KTm90ZSB0aGF0IHRoaXMgdGV4dCBpcyBk dXBsaWNhdGVkIGluIKHsNS4xLiBBbmQgNS4xIGlzIG5lYXJseSBkZWZpbmluZyBvbmUgcHJvcG9z aXRpb24sIHNvIHdoeSBub3Qgc2F5aW5nIHRoYXQgdGhpcyBpcyBhIHNvbHV0aW9uPyAodGhlcmUg aXMgbm8gbmVlZCB0byBkZWZpbmUgdGhlIGVuY29kaW5nIGZvciB0aGUgY29udHJvbCBwbGFuZSBz aW5jZSB0aGlzIHBhcnQgd291bGQgbGlrZWx5IG5vdCBiZSBpbiBhIHNwcmluZyBkb2N1bWVudCkg KGENCg0KICAgc3BlY2lmaWMgcHJlZml4LVNJRCBiZSBhbGxvY2F0ZWQgYXQgZWFjaCBub2RlIGZv ciB1c2UgYnkgdGhlIFNGQw0KDQogICBhcHBsaWNhdGlvbiBmb3IgdGhpcyBwdXJwb3NlLikNCg0K DQotLS0NCqHsNA0KDQogICBUaGUgYmVuZWZpdHMgb2YgdGhpcyBzY2hlbWUgaW5jbHVkZToNCg0K DQoNCluhrV0uDQoNCg0KDQogICBvICBJdCBzaW1wbGlmaWVzIHRoZSBTRkYgKGkuZS4sIHRoZSBT UiByb3V0ZXIpIGJ5IG51bGxpZnlpbmcgdGhlDQoNCiAgICAgIG5lZWRzIGZvciByZS1jbGFzc2lm aWNhdGlvbiBhbmQgU1IgcHJveHkuDQoNClJlZ2FyZGluZyB0aGUgbmVlZCBmb3IgcmVjbGFzc2lm aWNhdGlvbiwgaXQgc2VlbXMgdG8gbWUgdGhhdCBTUiBhbG9uZSBjYW4gbnVsbGlmeQ0KDQpSZWdh cmRpbmcgdGhlIG5lZWQgZm9yIFNSIHByb3h5LCB0aGUgYmVoYXZpb3VyIGRlc2NyaWJlZCBzZWVt cyB2ZXJ5IGNsb3NlIHRvIGEgU1IgcHJveHkgobBUaGUgU0ZGIHN0cmlwcw0KDQogICB0aGUgU1Ig aW5mb3JtYXRpb24gb2YgdGhlIHBhY2tldCwgdXBkYXRlcyB0aGUgU1IgaW5mb3JtYXRpb24sIGFu ZA0KDQogICBzYXZlcyBpdCB0byBhIGNhY2hlIGluZGV4ZWQgYnkgdGhlIE5TSCBTUEkuICBUaGlz IHNhdmVkIFNSDQoNCiAgIGluZm9ybWF0aW9uIGlzIHVzZWQgdG8gZW5jYXBzdWxhdGUgYW5kIGZv cndhcmQgdGhlIHBhY2tldChzKSBjb21pbmcNCg0KICAgYmFjayBmcm9tIHRoZSBTRi4gPg0KDQoN Cg0KDQoNCg0KICAgbyAgSXQgcHJvdmlkZXMgYSB1bmlxdWUgYW5kIHN0YW5kYXJkIHdheSB0byBw YXNzIG1ldGFkYXRhIHRvIFNGcy4NCg0KICAgICAgTm90ZSB0aGF0IGN1cnJlbnRseSB0aGVyZSBp cyBubyBzb2x1dGlvbiBmb3IgU1ItTVBMUyB0byBjYXJyeQ0KDQogICAgICBtZXRhZGF0YSBhbmQg dGhlcmUgaXMgbm8gc29sdXRpb24gdG8gcGFzcyBtZXRhZGF0YSB0byBTUi11bmF3YXJlDQoNCiAg ICAgIFNGcy4NCg0KUkZDODU5NSBwcm92aWRlcyBhbm90aGVyIHN0YW5kYXJkIHdheSB0byBwYXNz IG1ldGEgZGF0YSBmb3IgU1ItTVBMUy4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NTk1I3NlY3Rpb24tMTINCg0KLS0tDQqh7DcuMg0KDQqhsCAgIEVuY2Fwc3VsYXRpb24gb2YgTlNI IGZvbGxvd2luZyBTUnY2IG1heSBiZSBpbmRpY2F0ZWQgZWl0aGVyIGJ5DQoNCiAgIGVuY2Fwc3Vs YXRpbmcgTlNIIGluIFVEUCAoVURQIHBvcnQgVEJBMSkgYW5kIGluZGljYXRpbmcgVURQIGluIHRo ZQ0KDQogICBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgU1JILCBvciBieSBpbmRpY2F0aW5nIGFu IElQIHByb3RvY29sIG51bWJlcg0KDQogICBmb3IgTlNIIGluIHRoZSBOZXh0IEhlYWRlciBvZiB0 aGUgU1JILiChsA0KDQoNCldoeSBpcyB0aGVyZSBhIG5lZWQgZm9yIHR3byBzb2x1dGlvbnM/DQpJ ZiBzbywgd2hhdCBhcmUgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9yIHBybyZjb24gb2Yg ZWFjaD8NCkZvciBpbnRlcm9wIHB1cnBvc2UsIHdoaWNoIG9uZSBpcyBtYW5kYXRvcnkgYW5kIHdo aWNoIG9uZSBpcyBvcHRpb25hbD8NCg0KVGhhbmtzLA0KUmVnYXJkcywNCi0tQnJ1bm8NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB02C880FBdggeml529mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Agree with Bruno=A1=AFs comments on section 4.

 

I think this is more like an Proxy mechanism. Also, I only see NSH ove= r SR-MPLS is illustrated in the figure. How about SRv6=A3=BF

 

When a packet has t= o be forwarded to an SF attached to an SFF, the

   SFF pe= rforms a lookup on the prefix SID

 

Prefix SID is only in SR-MPLS. In SRv6, it is a Adj-SID? Or a proxy SI= D?

 

 

   associ= ated with the SF to

   retrie= ve the next hop context between the SFF and SF (e.g., to<= /p>

   retrie= ve the destination MAC address in case native Ethernet

   encaps= ulation is used between SFF and SF).  How the next hop context

   is pop= ulated is out of the scope of this document. 

 

The SFF strips=

   the SR= information of the packet, updates the SR information, and

   saves = it to a cache indexed by the NSH SPI.

 

It is really like an proxy mechanism. To me, it is a special proxy by = using NSH as the transport protocol between SFF and SF.

Do we need to define an END.NSH SID or something like this for this?

 

 

This saved SR<= /o:p>

   inform= ation is used to encapsulate and forward the packet(s) coming

   back f= rom the SF.

 

   When t= he SF receives the packet, it processes it as usual and sends

   it bac= k to the SFF.  Once the SFF receives this packet, it extracts

   the SR= information using the NSH SPI as the index into the cache.

   The SF= F then pushes the SR header on top of the NSH header, and=

   forwar= ds the packet to the next segment in the segment list.

 

 

Best,

Cheng

 

 

 

 

From:<= /span> spring [mailto:spring= -bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Monday, November 2, 2020 11:26 PM
To: spring@ietf.org; draft-ietf-spring-nsh-sr@ietf.org
Subject: [spring] draft-ietf-spring-nsh-sr

 

Hi auth= ors, WG,

&n= bsp;

Authors= of draft-ietf-spring-nsh-sr have asked for WG last call.=

Before = initiating it, I=A1=AFve done a review of the draft as document shepherd.

Please = find below some comments.

 

---

It=A1= =AFs not crystal clear to me what the scope and the goal of the document ar= e.

= -          From the abstract, it=A1=AFs an informative description of two application= s scenarios

= -          From section 5, it=A1=AFs a specification of how to integrate NSH and SR.<= o:p>

o   Although it=A1=AFs only really specified for SRv6 and not SR-MPLS.

&n= bsp;

Please = clarify to update the document as needed.

 

----

IdNits = reports for 2 errors. [1]

  ** Down= ref: Normative reference to an Informational RFC: RFC 7665

-      = ;    Probably the only really normative reference is= in the security section. Do you think that a reference to RFC8300 could be= used instead (8300 has a large security consideration section)?

-      = ;    I noticed that 8300 had the same issue. What wa= s the feedback from AD at the time?

&n= bsp;

  ** There are= 4 instances of too long lines in the document, the longest one<= /span>

   &= nbsp; being 82 characters in excess of 72.

Could you please correct in the next version of the d= raft?=

&n= bsp;

[1] https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-nsh-sr-03.txt

-----

Abstrac= t

&n= bsp;

The abstract =
feels like the document is informational (e.g., This document describes two=
 application scenarios=A1=B1)

But the= document asks for an IANA allocation requiring a STD track document, so th= e draft needs to be std track.

Do you = think that you could add that the document defines the encapsulation of NSH= for SR-MPLS and SRv6?

&n= bsp;

----

The int= roduction section seems to be coming from the SFC WG.

= -          May be adding some text about SPRING?

-  = ;        Although this is a personal opinion, I find some sentences a bit marketing= oriented. Could you please have a look? E.g.

o    =A1=B0The SFC architecture has the merit to no= t make assumptions=A1=B1
What about =A1=B0The SFC architecture does no= t make assumptions=A1=B1? This seems more neutral.

o    =A1=B0A= mong all these approaches, the IETF endorsed a transport-independent

-      &nb=
sp;    &=
nbsp; SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC encapsulation solution. &ra=
quo;
I=A1=AFm not sure how much =A1=B0is t=
he most mature=A1=B1 is true or not. I=A1=AFm not sure that the SPRING WG n=
eeds to make such statement nor that it is best placed to make such stateme=
nt.
I=A1=AFm not sure about =A1=B0the IETF endorsed a transport-i=
ndependent  SFC encapsulation scheme=A1=B1. Idem with regards to SPRING WG. I=A1=AFm not sure that this is a typica=
l statement in RFC. If so, it feels like the IETF would have equally endors=
ed transport-depending SFC encapsulation scheme. [RFC8595] https://tools.ietf.org/html/rfc8595

-          =A1=B0This design is pragmatic=A1= =B1
Looks like an opinion. = Plus I=A1=AFm not sure that the SPRING WG needs to judge the work of the SF= C WG.

----

=A1=EC2

=A1=B0The two SR flavors, namely SR-MPLS [=
=
RFC8660] and SRv6 [RFC8754],=A1=B1
May be :s/flavors/data pl=
ane

 

=A1=B0Further considerations such as simplifying =
classification at intermediate SFs=A1=B1

I=A1=AF= m not sure that simplifying classification is the main point of adding NSH.= RFC8595 does not refers to this. A priori SR supports a single initial cla= ssification.

&n= bsp;

----

=A1=EC2

=A1=B0A classifier SHOULD assign an NSH Service P=
ath Identifier (SPI) per
   SR policy so that different traffic =
flows that use the same NSH
   Service Function Path (SFP) but diff=
erent SR policy can coexist on
   the same SFP without conflict during=
 SFF processing.=A1=B1
 
Is the above sentence app=
licable to both applications scenarios or only for the second one (<=
span lang=3D"EN-GB">SR-based SFC with integrated NSH service plane)?
In the current text, it=
=A1=AFs applicable to both while I=A1=AFm not sure that it=A1=AFs applicabl=
e to =A1=B0NSH-based SFC with SR-based transpor=
t plane=A1=B1 where the transport plane (henc=
e the SR policy) is independent of the service plane.
---

« hierarchical SFC [RFC8459] » 


Does this document specif=
ically covers hierarchical SFC (hence hierarchical SFC & SR)? Is this r=
eference really pertinent?

 


---


=A1=EC3


Section=
 3 barely speaks about SR. Is this really a SPRING document?


When SR is refered to, th=
ere is nothing specific to SR.


e.g. =A1=B0After removing the outer transport encapsulation, that may or=
 may not be SR-MPLS or SRv6,=A1=B1


If the =
document is related to the integration of SFC and SR, surely the encapsulat=
ion is either SR-MPLS or SRv6 (rather than may or may not be SR).


 


May be =
indicating that in this scenario, there is a priori one SR-policy per SF (w=
hile in the next scenario, there is a single SR-policy for the whole servic=
e chain). That would talk about SR and
 may provide a key distinction between both.


 


 


  =A1=B0 At the end of the SR-MPLS path it i=
s necessary to provide an


   indication to the tail-end that NSH =
follows the SR-MPLS label stack.


   There are several ways to achieve th=
is but its specification is


   outside the scope of this document.=
=A1=B1


 


I agree=
 that this is necessary.


But why=
 is the main  text related to SR-MPLS in this scenario, not specifying=
 the behaviour?


I =
 don=A1=AFt follow the logic of specifying it for SRv6 (and hence requiring=
 this document to be standard track while otherwise it could be an informat=
ional document describing two scenarios) and not
 specifying it for SR-MPLS.


Note that this text is du=
plicated in =A1=EC5.1. And 5.1 is nearly defining one proposition, so why n=
ot saying that this is a solution? (there is no need to define the encoding=
 for the control plane since this part would likely not be in a spring docu=
ment) (a


   specific prefix-SID be allocated at =
each node for use by the SFC


   application=
 for this purpose.)


&n=
bsp;


&n=
bsp;


---


=A1=EC4=



   The benefits of this scheme include:=



 


[=A1=AD].


 


   o  It simplifies the SFF (i.e.,=
 the SR router) by nullifying the


      needs for re-class=
ification and SR proxy.


 


Regardi=
ng the need for reclassification, it seems to me that SR alone can nullify<=
o:p>


Regarding the need for SR=
 proxy, the behaviour described seems very close to a SR proxy =A1=B0The SFF strips


   the SR information of the packet, up=
dates the SR information, and


   saves it to a cache indexed by the N=
SH SPI.  This saved SR


   information is used to encapsulate a=
nd forward the packet(s) coming


   back from t=
he SF. »


&n=
bsp;


 


 


   o  It provides a unique and sta=
ndard way to pass metadata to SFs.


      Note that currentl=
y there is no solution for SR-MPLS to carry


      metadata and there=
 is no solution to pass metadata to SR-unaware


      SFs.


&n=
bsp;


RFC8595=
 provides another standard way to pass meta data for SR-MPLS.


https://tools.ietf.org/=
html/rfc8595#section-12


&n=
bsp;


---


=A1=EC7=
.2


=A1=B0   Encapsulation of NSH following=
 SRv6 may be indicated either by


   encapsulating NSH in UDP (UDP port T=
BA1) and indicating UDP in the


   Next Header field of the SRH, or by =
indicating an IP protocol number


   for NSH in the Next Header of the SR=
H. =A1=B0


 


Why is =
there a need for two solutions?



If so, =
what are the applicability statement or pro&con of each?


For int=
erop purpose, which one is mandatory and which one is optional?<=
/span>


&n=
bsp;


Thanks,=



Regards=
,


--Bruno=



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_C7C2E1C43D652C4E9E49FE7517C236CB02C880FBdggeml529mbxchi_-- From nobody Tue Nov 3 01:04:57 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDDA3A09E8; Tue, 3 Nov 2020 01:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 iD72pgr5UZ-I; Tue, 3 Nov 2020 01:04:55 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D7DBA3A097A; Tue, 3 Nov 2020 01:04:54 -0800 (PST) Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 31C0B7936ACA6E0F7649; Tue, 3 Nov 2020 09:04:53 +0000 (GMT) Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 3 Nov 2020 09:04:53 +0000 Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 3 Nov 2020 09:04:52 +0000 Received: from DGGEMM512-MBS.china.huawei.com ([169.254.4.215]) by dggemm422-hub.china.huawei.com ([169.254.138.104]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 17:04:50 +0800 From: Lizhenbin To: James Guichard , spring CC: IPPM Chairs , spring-chairs Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AdaxwGLX58vbu82jQ/ClUjOYTy5CmQ== Content-Class: urn:content-classes:message Date: Tue, 3 Nov 2020 09:04:50 +0000 Message-ID: 087AFEDF-20AC-4B29-99AC-C2EB478D9334 Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_087AFEDF20AC4B2999ACC2EB478D9334_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 09:04:57 -0000 --_000_087AFEDF20AC4B2999ACC2EB478D9334_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4NCg0KDQpCZXN0 IFJlZ2FyZHMsDQoNClpoZW5iaW4gKFJvYmluKQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQrmnY7mjK/mlowgTGkgWmhlbmJpbg0K TW9iaWxlOiArODYtMTM2NTEwMTc3NDU8dGVsOis4Ni0xMzY1MTAxNzc0NT4vKzk2OC05MTc5NzA2 OA0KRW1haWw6IGxpemhlbmJpbkBodWF3ZWkuY29tPG1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNv bT4NCg0K5Y+R5Lu25Lq677yaSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJl d2VpLmNvbT4NCuaUtuS7tuS6uu+8mnNwcmluZyA8c3ByaW5nQGlldGYub3JnPg0K5oqE4oCD6YCB 77yaSVBQTSBDaGFpcnMgPGlwcG0tY2hhaXJzQGlldGYub3JnPjtzcHJpbmctY2hhaXJzIDxzcHJp bmctY2hhaXJzQGlldGYub3JnPg0K5pe24oCD6Ze077yaMjAyMC0xMC0yMiAyMDo1Mjo0NQ0K5Li7 4oCD6aKY77yaW3NwcmluZ10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMQ0KDQpEZWFyIFdHOg0K VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBkb2N1bWVu dCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1z cnBtLTExIGVuZGluZyBOb3ZlbWJlciAxMnRoIDIwMjAuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBk b2N1bWVudCBoYXMgc2V2ZXJhbCBjaGFuZ2VzIGZyb20gdi0xMCB0aGF0IHdlcmUgcmVxdWVzdGVk IGJ5IHRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzLiBGb3IgdGhpcyByZWFzb24sIHRoZSBjaGFp cnMgaGF2ZSBleHRlbmRlZCB0aGUgYWRvcHRpb24gY2FsbCBmb3IgYW4gYWRkaXRpb25hbCB3ZWVr IHRvIGFsbG93IHRoZSBXRyBlbm91Z2ggdGltZSB0byByZXZpZXcgdGhlc2UgY2hhbmdlcyBiZWZv cmUgZGVjaWRpbmcgb24gV0cgYWRvcHRpb24uDQpTb21lIGJhY2tncm91bmQ6DQpTZXZlcmFsIHJl dmlldyBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAu IFRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzIGNvbnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFu ZCB1cG9uIHJldmlldyBvZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVk IHRoZSBmb2xsb3dpbmc6DQoNCiAgKiAgIFRoZSBTUFJJTkcgZG9jdW1lbnQgc2hvdWxkIGRlc2Ny aWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BSSU5HIHdpdGggcG9pbnRlcnMg dG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5lIGFueSBleHRlbnNpb25zLiBTZXZl cmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5nIENvbnRyb2wgQ29kZSBGaWVsZCBFeHRlbnNpb24gZm9y IFRXQU1QIExpZ2h0IE1lc3NhZ2VzLCBMb3NzIE1lYXN1cmVtZW50IFF1ZXJ5IE1lc3NhZ2UgRXh0 ZW5zaW9ucywgYW5kIExvc3MgTWVhc3VyZW1lbnQgUmVzcG9uc2UgTWVzc2FnZSBFeHRlbnNpb25z IHdlcmUgaW5jbHVkZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctdHdhbXAtc3JwbS0xMCBhbmQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgU1BS SU5HIGRvY3VtZW50Lg0KICAqICAgVGhlIFRXQU1QIGV4dGVuc2lvbnMgaW5jbHVkZWQgaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0x MCBzaG91bGQgYmUgZGVzY3JpYmVkIGluIGEgbmV3IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUg SVBQTSBXRy4NClRoZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhv cnMgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdh bXAtc3JwbS0xMCB0aGUgcmVzdWx0IG9mIHdoaWNoIGlzIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUg Zm9sbG93aW5nIHR3byBkb2N1bWVudHM6DQoNCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEuIFRoZSBzdWJqZWN0IG9mIHRo aXMgV0cgYWRvcHRpb24gY2FsbC4NCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwLiBUaGlzIGRvY3VtZW50IHdpbGwgYmUgcHJv Z3Jlc3NlZCAoaWYgZGV0ZXJtaW5lZCBieSB0aGUgV0cpIHdpdGhpbiB0aGUgSVBQTSBXRy4NCkFm dGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFzZSBpbmRpY2F0ZSBzdXBwb3J0 IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0LiBQbGVhc2UgYWxz byBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0aGVy ZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2VudC4NCkZpbmFs bHksIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgYXV0aG9ycyBmb3IgdGhlaXIg ZWZmb3J0cyBpbiB0aGlzIG1hdHRlci4NClRoYW5rcyENCkppbSwgQnJ1bm8sICYgSm9lbA0KDQo= --_000_087AFEDF20AC4B2999ACC2EB478D9334_ Content-Type: text/html; charset="utf-8" Content-ID: <228027316C4F644BB81B2F72CB70117C@huawei.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPC9tYXRhPjxzdHls ZSB0eXBlPSJ0ZXh0L2NzcyI+Cioge2JveC1zaXppbmc6Ym9yZGVyLWJveDt9CmJvZHkge2ZvbnQt ZmFtaWx5OiBDYWxpYnJpO30KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxwPjxm b250IHNpemU9IjMiPkhpIEFsbCw8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMyI+SSBzdXBw b3J0IHRoZSBhZG9wdGlvbiBvZiB0aGUgZHJhZnQuPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9 IjMiPjxicj4NCjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIzIj5CZXN0IFJlZ2FyZHMsPC9m b250PjwvcD4NCjxwPjxmb250IHNpemU9IjMiPlpoZW5iaW4gKFJvYmluKTxicj4NCjwvZm9udD48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3A+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0K PHAgZGlyPSJsdHIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0K5p2O5oyv5paMIExpIFpoZW5iaW48YnI+DQpNb2JpbGU6IDxhIGhyZWY9InRl bDomIzQzOzg2LTEzNjUxMDE3NzQ1Ij4mIzQzOzg2LTEzNjUxMDE3NzQ1PC9hPi8mIzQzOzk2OC05 MTc5NzA2ODxicj4NCkVtYWlsOiA8YSBocmVmPSJtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20i PmxpemhlbmJpbkBodWF3ZWkuY29tPC9hPjwvcD4NCjwvZGl2Pg0KPGRpdiBuYW1lPSJBbnlPZmZp Y2UtQmFja2dyb3VuZC1JbWFnZSIgc3R5bGU9ImJvcmRlci10b3A6MXB4IHNvbGlkICNCNUM0REY7 cGFkZGluZzo4cHg7IGJhY2tncm91bmQtaW1hZ2U6dXJsKGRhdGE6aW1hZ2UvcG5nO2Jhc2U2NCxp VkJPUncwS0dnb0FBQUFOU1VoRVVnQUFBQUVBQUFCQkNBWUFBQUFRVGM3bEFBQUFDWEJJV1hNQUFB c1RBQUFMRXdFQW1wd1lBQUFBQkdkQlRVRUFBTEdPZlB0Umt3QUFBQ0JqU0ZKTkFBQjZKUUFBZ0lN QUFQbi9BQUNBNlFBQWRUQUFBT3BnQUFBNm1BQUFGMiYjNDM7U1g4VkdBQUFBTjBsRVFWUjQybUo0 OHU3UGZ5WUdCb1ovY09Jdktnc2I4UWVWaFovNGpZWDdHd3NYcHhoJiM0MztnZ2hUY0xvRko0SG1T MndFVWxnQkJnQWpQa05SUWxHUGZBQUFBQUJKUlU1RXJrSmdnZz09KTsgYmFja2dyb3VuZC1yZXBl YXQ6IHJlcGVhdC14OyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbDsiPjxiPuWP keS7tuS6uu+8mjwvYj5KYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3 ZWkuY29tJmd0OzwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGw7Ij48Yj7m lLbku7bkurrvvJo8L2I+c3ByaW5nICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2 IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbDsiPjxiPuaKhOKAg+mAge+8mjwvYj5JUFBNIENo YWlycyAmbHQ7aXBwbS1jaGFpcnNAaWV0Zi5vcmcmZ3Q7O3NwcmluZy1jaGFpcnMgJmx0O3Nwcmlu Zy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFr LWFsbDsiPjxiPuaXtuKAg+mXtO+8mjwvYj4yMDIwLTEwLTIyIDIwOjUyOjQ1PC9kaXY+DQo8ZGl2 IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbDsiPjxiPuS4u+KAg+mimO+8mjwvYj5bc3ByaW5n XSBXRyBBZG9wdGlvbiBDYWxsIGZvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8c3R5bGU+DQo8IS0tDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nc30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VufQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIn0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaX0N CkBmb250LWZhY2UNCgl7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhc30NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmfQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmV9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmfQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dH0NCi5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmfQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe21hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbn0NCmRp di5Xb3JkU2VjdGlvbjENCgl7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW59DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbn0NCi0tPg0KPC9zdHlsZT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPmltZyB7 bWF4LXdpZHRoOjEwMCU7aGVpZ2h0OmF1dG87fSB0YWJsZSBpbWcge21heC13aWR0aDppbml0aWFs O30gdGFibGUgdGQge3Bvc2l0aW9uOnJlbGF0aXZlO30gYm9keSB7d29yZC13cmFwOmJyZWFrLXdv cmQ7fTwvc3R5bGU+PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPndpbmRvdy5vbmxvYWQ9 ZnVuY3Rpb24oKXtsZXQgdyA9IHNjcmVlbi53aWR0aCArICdweCc7IGRvY3VtZW50LmJvZHkuc3R5 bGUud2lkdGg9IjEwMCUiOyBkb2N1bWVudC5ib2R5LnN0eWxlLm1hcmdpbj0nYXV0byc7IGRvY3Vt ZW50LmJvZHkuc3R5bGUucGFkZGluZz0nMHB4Jzt9PC9zY3JpcHQ+DQo8ZGl2IG5hbWU9Im1haWxf aGlzdF9jb250ZW50Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EZWFyIFdHOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgbWVzc2FnZSBzdGFydHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2Fs bCBmb3IgZG9jdW1lbnQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMSIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMTwvYT4g ZW5kaW5nIE5vdmVtYmVyIDEyPHN1cD50aDwvc3VwPiAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRo aXMgZG9jdW1lbnQgaGFzIHNldmVyYWwgY2hhbmdlcyBmcm9tIHYtMTAgdGhhdCB3ZXJlIHJlcXVl c3RlZCBieSB0aGUgU1BSSU5HIGFuZCBJUFBNIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUg Y2hhaXJzIGhhdmUgZXh0ZW5kZWQNCiB0aGUgYWRvcHRpb24gY2FsbCBmb3IgYW4gYWRkaXRpb25h bCB3ZWVrIHRvIGFsbG93IHRoZSBXRyBlbm91Z2ggdGltZSB0byByZXZpZXcgdGhlc2UgY2hhbmdl cyBiZWZvcmUgZGVjaWRpbmcgb24gV0cgYWRvcHRpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBiYWNrZ3JvdW5kOiAmbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXZlcmFs IHJldmlldyBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50DQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10 d2FtcC1zcnBtLTEwIiB0YXJnZXQ9Il9CTEFOSyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwPC9hPi4gPHNwYW4gbGFuZz0iRU4t Q0EiPg0KVGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9zZSBjb21tZW50 cywgYW5kIHVwb24gcmV2aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGRldGVy bWluZWQgdGhlIGZvbGxvd2luZzo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdp bi10b3A6MGluIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbiI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBTUFJJTkcgZG9jdW1lbnQgc2hvdWxkIGRl c2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BSSU5HIHdpdGggcG9pbnRl cnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5lIGFueSBleHRlbnNpb25zLiBT ZXZlcmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5nPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6Q29uc29sYXM7IGNvbG9yOmJsYWNr OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTpDb25zb2xhczsgY29sb3I6YmxhY2s7 IGJhY2tncm91bmQ6d2hpdGUiPkNvbnRyb2wgQ29kZSBGaWVsZCBFeHRlbnNpb24gZm9yIFRXQU1Q IExpZ2h0IE1lc3NhZ2VzPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFzOyBjb2xvcjpibGFjazsgYmFja2dyb3Vu ZDp3aGl0ZSI+LA0KPGI+TG9zcyBNZWFzdXJlbWVudCBRdWVyeSBNZXNzYWdlIEV4dGVuc2lvbnM8 L2I+LCBhbmQgPGI+TG9zcyBNZWFzdXJlbWVudCBSZXNwb25zZSBNZXNzYWdlIEV4dGVuc2lvbnMN CjwvYj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPndlcmUgaW5jbHVkZWQgaW48L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMCIgdGFyZ2V0PSJfQkxBTksiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0t MTA8L2E+IGFuZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tDQogdGhlIFNQUklORyBkb2N1bWVudC48 c3BhbiBsYW5nPSJFTi1DQSI+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhlIFRXQU1QIGV4 dGVuc2lvbnMgaW5jbHVkZWQgaW4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwIiB0YXJnZXQ9Il9CTEFO SyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAt c3JwbS0xMDwvYT4NCjxzcGFuIGxhbmc9IkVOLUNBIj5zaG91bGQgYmUgZGVzY3JpYmVkIGluIGEg bmV3IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUgSVBQTSBXRy4gJm5ic3A7PC9zcGFuPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZXNlIGNvbmNsdXNp b25zIHdlcmUgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhvcnMgb2YNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAiIHRhcmdldD0iX0JMQU5LIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwPC9hPiB0 aGUgcmVzdWx0IG9mIHdoaWNoIGlzIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZm9sbG93aW5nIHR3 byBkb2N1bWVudHM6PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PC9wPg0KPHVsIHR5cGU9ImRp c2MiIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEiIHRhcmdldD0iX0JMQU5LIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBt LTExPC9hPi4gVGhlIHN1YmplY3Qgb2YgdGhpcyBXRyBhZG9wdGlvbiBjYWxsLjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0tdHdhbXAtc3JwbS0w MCIgdGFyZ2V0PSJfQkxBTksiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5k aGktaXBwbS10d2FtcC1zcnBtLTAwPC9hPi4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIHByb2dyZXNz ZWQgKGlmIGRldGVybWluZWQgYnkgdGhlDQogV0cpIHdpdGhpbiB0aGUgSVBQTSBXRy48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+QWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcgZG9jdW1lbnQgcGxlYXNl IGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWlsaW5n IGxpc3QuDQo8L3NwYW4+PHNwYW4gc3R5bGU9IiI+UGxlYXNlIGFsc28gcHJvdmlkZSBjb21tZW50 cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMgc2lsZW5jZSB3 aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iIj5GaW5hbGx5LCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gdGhhbmsg dGhlIGF1dGhvcnMgZm9yIHRoZWlyIGVmZm9ydHMgaW4gdGhpcyBtYXR0ZXIuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUNBIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+VGhhbmtzITwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj5KaW0sIEJydW5vLCAmYW1wOyBKb2VsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48L3NwYW4+PC9iPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PC9wPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_087AFEDF20AC4B2999ACC2EB478D9334_-- From nobody Tue Nov 3 01:22:34 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8B3A1550; Tue, 3 Nov 2020 01:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 n-BNQDjUXH3A; Tue, 3 Nov 2020 01:22:30 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8DA3A3A152C; Tue, 3 Nov 2020 01:22:30 -0800 (PST) Received: from lhreml720-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 41E0BABFD27A7787FEA1; Tue, 3 Nov 2020 09:22:29 +0000 (GMT) Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 3 Nov 2020 09:22:29 +0000 Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 3 Nov 2020 09:22:28 +0000 Received: from DGGEMM512-MBS.china.huawei.com ([169.254.4.215]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0487.000; Tue, 3 Nov 2020 17:22:23 +0800 From: Lizhenbin To: James Guichard , spring CC: ippm-chairs , spring-chairs Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AQHWscLWZvayuLIpG0WjojkmFXAILg== Date: Tue, 3 Nov 2020 09:22:23 +0000 Message-ID: EB740661-4474-4E61-BC4B-D695F7C151CE References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EB74066144744E61BC4BD695F7C151CE_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 09:22:33 -0000 --_000_EB74066144744E61BC4BD695F7C151CE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4NCg0KDQpCZXN0 IFJlZ2FyZHMsDQoNClpoZW5iaW4gKFJvYmluKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K5p2O5oyv5paMIExpIFpoZW5iaW4NCk1vYmlsZTog Kzg2LTEzNjUxMDE3NzQ1PHRlbDorODYtMTM2NTEwMTc3NDU+Lys5NjgtOTE3OTcwNjgNCkVtYWls OiBsaXpoZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+DQoNCuWP keS7tuS6uu+8mkphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+ DQrmlLbku7bkurrvvJpzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZz4NCuaKhOKAg+mAge+8mmlwcG0t Y2hhaXJzIDxpcHBtLWNoYWlyc0BpZXRmLm9yZz47c3ByaW5nLWNoYWlycyA8c3ByaW5nLWNoYWly c0BpZXRmLm9yZz4NCuaXtuKAg+mXtO+8mjIwMjAtMTAtMjIgMjA6NTM6MjUNCuS4u+KAg+mimO+8 mltzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMNCg0KRGVhciBXRzoNCg0KVGhpcyBt ZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzLCBlbmRpbmcg Tm92ZW1iZXIgMTJ0aCAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIHNl dmVyYWwgY2hhbmdlcyBmcm9tIHYtMDIgdGhhdCB3ZXJlIHJlcXVlc3RlZCBieSB0aGUgU1BSSU5H IGFuZCBJUFBNIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUgY2hhaXJzIGhhdmUgZXh0ZW5k ZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0aGUg V0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5nIG9u IFdHIGFkb3B0aW9uLg0KDQpTb21lIGJhY2tncm91bmQ6DQoNClNldmVyYWwgcmV2aWV3IGNvbW1l bnRzIHdlcmUgcmVjZWl2ZWQgcHJldmlvdXNseSBmb3IgZG9jdW1lbnQgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMi4gVGhlIFNQUklO RyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9zZSBjb21tZW50cywgYW5kIHVwb24gcmV2 aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGRldGVybWluZWQgdGhlIGZvbGxv d2luZzoNCg0KDQogICogICBUaGUgU1BSSU5HIGRvY3VtZW50IHNob3VsZCBkZXNjcmliZSBvbmx5 IHRoZSBwcm9jZWR1cmVzIHJlbGV2YW50IHRvIFNQUklORyB3aXRoIHBvaW50ZXJzIHRvIG5vbi1T UFJJTkcgZG9jdW1lbnQvcyB0aGF0IGRlZmluZSBhbnkgZXh0ZW5zaW9ucy4gU2V2ZXJhbCBleHRl bnNpb25zIGluY2x1ZGluZyBDb250cm9sIENvZGUgRmllbGQgRXh0ZW5zaW9uIGZvciBTVEFNUCBN ZXNzYWdlcywgTG9zcyBNZWFzdXJlbWVudCBRdWVyeSBNZXNzYWdlIEV4dGVuc2lvbnMsIExvc3Mg TWVhc3VyZW1lbnQgUmVzcG9uc2UgTWVzc2FnZSBFeHRlbnNpb25zLCBOb2RlIEFkZHJlc3MgVExW IEV4dGVuc2lvbnMsIGFuZCBSZXR1cm4gUGF0aCBUTFYgRXh0ZW5zaW9ucyB3ZXJlIGluY2x1ZGVk IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1w LXNycG0tMDIgYW5kIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFNQUklORyBkb2N1bWVudC4N CiAgKiAgIFRoZSBTVEFNUCBleHRlbnNpb25zIGluY2x1ZGVkIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDIgc2hvdWxkIGJlIGRl c2NyaWJlZCBpbiBhIG5ldyBkb2N1bWVudCBwdWJsaXNoZWQgaW4gdGhlIElQUE0gV0cuDQoNClRo ZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhvcnMgb2YgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiB0 aGUgcmVzdWx0IG9mIHdoaWNoIGlzIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZm9sbG93aW5nIHR3 byBkb2N1bWVudHM6DQoNCg0KICAqICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMy4gVGhlIHN1YmplY3Qgb2YgdGhpcyBXRyBhZG9w dGlvbiBjYWxsLg0KICAqICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1pcHBtLXN0YW1wLXNycG0tMDAuIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwcm9ncmVzc2VkIChp ZiBkZXRlcm1pbmVkIGJ5IHRoZSBXRykgd2l0aGluIHRoZSBJUFBNIFdHLg0KDQpBZnRlciByZXZp ZXcgb2YgdGhlIFNQUklORyBkb2N1bWVudCBwbGVhc2UgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90 KSBmb3IgV0cgYWRvcHRpb24gdG8gdGhlIG1haWxpbmcgbGlzdC4gUGxlYXNlIGFsc28gcHJvdmlk ZSBjb21tZW50cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMg c2lsZW5jZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuDQoNCkZpbmFsbHksIHRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgYXV0aG9ycyBmb3IgdGhlaXIgZWZmb3J0 cyBpbiB0aGlzIG1hdHRlci4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vLCAmIEpvZWwNCg== --_000_EB74066144744E61BC4BD695F7C151CE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzfQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIn0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q29uc29sYXN9DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZn0NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29s b3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lfQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttYXJnaW4t dG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdp bi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZn0NCnNwYW4uRW1haWxTdHlsZTE3DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHR9DQouTXNvQ2hwRGVmYXVsdA0KCXtmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZn0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW59DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCm9sDQoJe21h cmdpbi1ib3R0b206MGlufQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW59DQotLT4NCjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi Pg0KPCEtLQ0KKg0KCXt9DQpib2R5DQoJe2ZvbnQtZmFtaWx5OkNhbGlicml9DQotLT4NCjwvc3R5 bGU+DQo8ZGl2Pg0KPHA+PGZvbnQgc2l6ZT0iMyI+SGkgQWxsLDwvZm9udD48L3A+DQo8cD48Zm9u dCBzaXplPSIzIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC48L2ZvbnQ+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0iMyI+PGJyPg0KPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjMi PkJlc3QgUmVnYXJkcyw8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMyI+WmhlbmJpbiAoUm9i aW4pPC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+DQo8cCBkaXI9Imx0ciI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQrm nY7mjK/mlowgTGkgWmhlbmJpbjxicj4NCk1vYmlsZTogPGEgaHJlZj0idGVsOiYjNDM7ODYtMTM2 NTEwMTc3NDUiPiYjNDM7ODYtMTM2NTEwMTc3NDU8L2E+LyYjNDM7OTY4LTkxNzk3MDY4PGJyPg0K RW1haWw6IDxhIGhyZWY9Im1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbSI+bGl6aGVuYmluQGh1 YXdlaS5jb208L2E+PC9wPg0KPC9kaXY+DQo8ZGl2IG5hbWU9IkFueU9mZmljZS1CYWNrZ3JvdW5k LUltYWdlIiBzdHlsZT0iYm9yZGVyLXRvcDoxcHggc29saWQgI0I1QzRERjsgcGFkZGluZzo4cHgi Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuWPkeS7tuS6uu+8mjwvYj5K YW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0OzwvZGl2 Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuaUtuS7tuS6uu+8mjwvYj5z cHJpbmcgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJl YWs6YnJlYWstYWxsIj48Yj7mioTigIPpgIHvvJo8L2I+aXBwbS1jaGFpcnMgJmx0O2lwcG0tY2hh aXJzQGlldGYub3JnJmd0OztzcHJpbmctY2hhaXJzICZsdDtzcHJpbmctY2hhaXJzQGlldGYub3Jn Jmd0OzwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuaXtuKAg+mX tO+8mjwvYj4yMDIwLTEwLTIyIDIwOjUzOjI1PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFr OmJyZWFrLWFsbCI+PGI+5Li74oCD6aKY77yaPC9iPltzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwg Zm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1w LXNycG0tMDM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlz IG1lc3NhZ2Ugc3RhcnRzIGEgMyB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0t MDMiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3Rh bXAtc3JwbS0wMzwvYT4sIGVuZGluZyBOb3ZlbWJlciAxMjxzdXA+dGg8L3N1cD4gMjAyMC4gUGxl YXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIGNoYW5nZXMgZnJvbSB2LTAy IHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMuIEZvciB0 aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4dGVuZGVkDQogdGhlIGFkb3B0aW9uIGNhbGwg Zm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2 aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5nIG9uIFdHIGFkb3B0aW9uLjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUg YmFja2dyb3VuZDogJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2V2ZXJhbCByZXZpZXcgY29tbWVudHMgd2VyZSByZWNlaXZl ZCBwcmV2aW91c2x5IGZvciBkb2N1bWVudA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMjwvYT4uDQo8c3Bh biBsYW5nPSJFTi1DQSI+VGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9z ZSBjb21tZW50cywgYW5kIHVwb24gcmV2aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1l bnQsIGRldGVybWluZWQgdGhlIGZvbGxvd2luZzo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlz YyIgc3R5bGU9Im1hcmdpbi10b3A6MGluIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBTUFJJTkcgZG9j dW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BS SU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5lIGFu eSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5nPC9zcGFuPjxiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6Q29uc29s YXM7IGNvbG9yOmJsYWNrOyBiYWNrZ3JvdW5kOndoaXRlIj4NCiBDb250cm9sIENvZGUgRmllbGQg RXh0ZW5zaW9uIGZvciBTVEFNUCBNZXNzYWdlczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTpDb25zb2xhczsgY29sb3I6Ymxh Y2s7IGJhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8Yj5Mb3NzIE1lYXN1cmVtZW50IFF1ZXJ5IE1l c3NhZ2UgRXh0ZW5zaW9uczwvYj4sJm5ic3A7PGI+TG9zcyBNZWFzdXJlbWVudCBSZXNwb25zZSBN ZXNzYWdlIEV4dGVuc2lvbnM8L2I+LCZuYnNwOzxiPk5vZGUNCiBBZGRyZXNzIFRMViBFeHRlbnNp b25zPC9iPiwgYW5kJm5ic3A7PGI+UmV0dXJuIFBhdGggVExWIEV4dGVuc2lvbnM8L2I+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj4gd2VyZSBpbmNsdWRlZCBpbjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMjwvYT4gYW5kIHNob3VsZCBiZSByZW1v dmVkIGZyb20gdGhlIFNQUklORyBkb2N1bWVudC48c3BhbiBsYW5nPSJFTi1DQSI+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluIj48 c3BhbiBsYW5nPSJFTi1DQSI+VGhlIFNUQU1QIGV4dGVuc2lvbnMgaW5jbHVkZWQgaW4NCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmlu Zy1zdGFtcC1zcnBtLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhp LXNwcmluZy1zdGFtcC1zcnBtLTAyPC9hPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPnNob3VsZCBiZSBk ZXNjcmliZWQgaW4gYSBuZXcgZG9jdW1lbnQgcHVibGlzaGVkIGluIHRoZSBJUFBNIFdHLiAmbmJz cDs8L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+VGhlc2UgY29uY2x1c2lvbnMgd2VyZSBkaXNjdXNzZWQgd2l0aCB0aGUgYXV0aG9ycyBv Zg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5k aGktc3ByaW5nLXN0YW1wLXNycG0tMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDI8L2E+IHRoZSByZXN1bHQgb2Ygd2hpY2ggaXMg dGhlIHB1YmxpY2F0aW9uIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGRvY3VtZW50czo8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdp bi10b3A6MGluIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctc3RhbXAtc3JwbS0wMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMzwvYT4uIFRoZSBzdWJqZWN0IG9mIHRoaXMgV0cg YWRvcHRpb24gY2FsbC48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1pcHBtLXN0YW1wLXNycG0tMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtLTAwPC9hPi4gVGhpcyBkb2N1bWVudCB3aWxsIGJl IHByb2dyZXNzZWQgKGlmIGRldGVybWluZWQgYnkgdGhlIFdHKSB3aXRoaW4gdGhlDQogSVBQTSBX Ry48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcg ZG9jdW1lbnQgcGxlYXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9u IHRvIHRoZSBtYWlsaW5nIGxpc3QuDQo8L3NwYW4+PHNwYW4gc3R5bGU9IiI+UGxlYXNlIGFsc28g cHJvdmlkZSBjb21tZW50cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVv ZikgYXMgc2lsZW5jZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSIiPiZuYnNwOzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iIj5GaW5hbGx5LCB0aGUgY2hhaXJz IHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRoZWlyIGVmZm9ydHMgaW4gdGhp cyBtYXR0ZXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhhbmtzITwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5KaW0sIEJydW5vLCAmYW1wOyBK b2VsPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EB74066144744E61BC4BD695F7C151CE_-- From nobody Tue Nov 3 09:39:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724773A0E37; Tue, 3 Nov 2020 09:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 Y5cYgQ3GYEMM; Tue, 3 Nov 2020 09:39:14 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700130.outbound.protection.outlook.com [40.107.70.130]) (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 01C923A0E2E; Tue, 3 Nov 2020 09:39:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IQJZaQf+IWHIBiyeMPtnJIMAXfxLB3pyAq/QJPfn2o/jt6mBh3SMfsJwkSBrDPr32OBz9ANFrPfoJYlzpEgxpuOR8kTldFIvkevZx6DNbK82WMLxtcQRKNj7TzBXbBhBKKXw2Zsu+7RhjvubbXpd9Mj7Ejgck3mg7WRjNjIzl+bTsF77CWgssLr6nrQPxo6ygBwTk0FMTTS+AyDW4cflL/b6aGQXCNi7dMJE/HIZR35RbnZXngmhl58uHuXRejfBctpl2oI1A3IowlYSve4cZsV49/IR+THiNHDpt3f8/o6V1aIxjGP862O7LVGjaAu40a9UDtJYkjNB/Wl+wmmGkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LLiM4h13uZofimT3cTPsdPE2B0trtOR/AxMXVGBRRDU=; b=EgjcFNGrntCURZTcMpa6piLUjKM2s8EqfY+T+NDtjvPr9Mr7NERSqdUG8AGMP3VsGzSXXy/eOXUnmdc2qprTQhbko74zmLp4NB5rvOdfsxQbHWeX3KUqFvZ9379UWsySBEDPuCCh+CJogni75lpmXKKwHOwreqLcrZ9wRXcMhXiamVl9+fXZyvGTlL9qCqlq7l8zJFQ1Fqz6CD6tB2y1Gjnp8PNTJ2F9C1Vn9ELjRJtM9PHQqfLk8HtmW/O4mzqitGG0H6akZlzNMoaBS9TYTxgOmXvHG/Bxuer4IIfxMjNKTcqoKl4DP+lYlGTQGLEETBckaiOX0wwsr8imwiBk5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LLiM4h13uZofimT3cTPsdPE2B0trtOR/AxMXVGBRRDU=; b=S+ipmcmFtnGNby53mKN678XImiuu/uHyhj3BxFhUCnLBDFEl1FtH17Z7lEjE/n0YiDN/Cpl44BPnBMcS0tP0jiHqQ8JKarg/Nd0plWpdftwhryOzS1H2l1mkrU0mb8PJCyu4mIeW6vB+Tj6ZHKBdcPsIg2WjbSJAGK6kPhuiNm0= Received: from DM6PR13MB3066.namprd13.prod.outlook.com (2603:10b6:5:19d::18) by DM6PR13MB3193.namprd13.prod.outlook.com (2603:10b6:5:4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Tue, 3 Nov 2020 17:39:10 +0000 Received: from DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::b0e4:4885:8602:13f7]) by DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::b0e4:4885:8602:13f7%4]) with mapi id 15.20.3541.015; Tue, 3 Nov 2020 17:39:10 +0000 From: James Guichard To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJg== Date: Tue, 3 Nov 2020 17:39:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [47.14.47.233] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ae79a24-2181-4ba3-d140-08d8801f5f42 x-ms-traffictypediagnostic: DM6PR13MB3193: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hvE77BeRCsl5UVp1Djd7cgRiO0WrqGqYkMRAXdN4dDlv3FbwExG77tMr2NfmmKNFzvfkOOv9FFAQk7fCPmCCzdLQXEDqJfUVQWvRq1eCy6muk1bjBjvhw9ddl0K9JF7d+BLei4Y5tA1NsNkl2aivNLIXwkTMeW26Is8CWF5qqWfD+5c/z1MNnGrvr80JQh2P7WnCv5jIG2jPHF6xgHjXiHj0zCu9APL9bKvfzbRdouzVlmvBioqm9BZPG/VlF1UqCIHNEfAzWDlVELjw9DXzHg63lIWV8cDJ66FcXQOhfHOoY+ic9IIqrPoGQtaJKjlQOn8qUNCs0TCC1LJxOQKWYKJ48NlZTBY9iDZlYEaYourqBrmpyh0OO7GvT7APbU8B0avEvYr/SQYIuDuhy5M+QA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB3066.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(376002)(346002)(136003)(366004)(396003)(9686003)(66556008)(76116006)(66446008)(166002)(4326008)(316002)(6916009)(83380400001)(6506007)(186003)(2906002)(64756008)(66476007)(66946007)(478600001)(26005)(966005)(86362001)(71200400001)(8936002)(8676002)(5660300002)(55016002)(7696005)(52536014)(450100002)(33656002)(4744005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: vVaRASd8ewVrfkXMbKC8PBVab3sgoPyLcb0MBbO1IV2wcN9vvL4ozPXVGpMcyiCAEhIxVX16FOR8FjG0v+i7eQrxUU1Ue4zzA2soITKlc6iVlRXyxUGUhjlKCxXIKg2JTI+FVREZr/Irw9TTtGrhULLuykYR2bHtC1ZdSboGXMjCROZtnwL64w1xQN71wG7POEHIMAqvPZTl9PiVhtr9LjUczK7uIsLnoieULxNZkLF42C6+j3kOMByp95zW2mZb9/70cnrtjtQQ8zXs9DsncSGnh5ipkHJTzqM3VOWFi6qXonuvn3bamVKRw5crvjj6gEQUrv8Lo6QNy7ZDlyMg7C5OTwjsXQLkD+NBcg/9miONxy4vp69SIGhtgfj5t3kphQBtLnu1OIiWNVdQ6NfUsYT9Wh+VNckbVaUyVy8h9RuvfOrUNnei+oC+NOq6F785tT2J3a6h0F6PRwF9y3T3yOFASmIkbgy0MOmZFJPk7M1nLzdJS12GxxrMEbShb7rj6Zp6m0i0N3gesNUG5MGfYbPWLh8oHZdiCI7m6hM5Hk7HVIyj0BuwjZUciDac2iBX6zmX59Umnyps7uDn/SGTLvT1vsuaQHBkQ8N1DsfYAm/Y8el4sTgdLEWRUUeu3gDIkcZt5EYox13jYhmNVme3KQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB3066A62CF601F8B88B6B5DD9D2110DM6PR13MB3066namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB3066.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ae79a24-2181-4ba3-d140-08d8801f5f42 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 17:39:10.1772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lyX+Btw9qwpr//rqSxmtXFYb+TjZU9Comp6Uxokg5XNjoa5f5+gw57qFhXoYAOh51ibX6K1qaSG2Anr3tBlmFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3193 Archived-At: Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 17:39:15 -0000 --_000_DM6PR13MB3066A62CF601F8B88B6B5DD9D2110DM6PR13MB3066namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please = note that this document has several changes from v-06 that were requested b= y the SPRING chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption. After review of the document please indicate support (or not) for WG adopti= on to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel --_000_DM6PR13MB3066A62CF601F8B88B6B5DD9D2110DM6PR13MB3066namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, end= ing November 24th 2020. Please note that this document has sever= al changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.

 

After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please als= o provide comments/reasons for that support (or lack thereof) as silence wi= ll not be considered as consent.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

 

 

--_000_DM6PR13MB3066A62CF601F8B88B6B5DD9D2110DM6PR13MB3066namp_-- From nobody Tue Nov 3 09:41:54 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D93173A0E7D; Tue, 3 Nov 2020 09:41:52 -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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160442531287.20648.11140530244427364353@ietfa.amsl.com> Date: Tue, 03 Nov 2020 09:41:52 -0800 Archived-At: Subject: [spring] The SPRING WG has placed draft-li-spring-srv6-path-segment in state "Call For Adoption By WG Issued" X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 17:41:53 -0000 The SPRING WG has placed draft-li-spring-srv6-path-segment in state Call For Adoption By WG Issued (entered by Jim Guichard) The document is available at https://datatracker.ietf.org/doc/draft-li-spring-srv6-path-segment/ From nobody Tue Nov 3 17:08:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB81D3A0FAE; Tue, 3 Nov 2020 17:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vsPpciViwCgi; Tue, 3 Nov 2020 17:08:11 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3643A125B; Tue, 3 Nov 2020 17:08:11 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CQpQS2BCHz67H9J; Wed, 4 Nov 2020 09:06:56 +0800 (CST) Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 02:08:09 +0100 Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 02:08:08 +0100 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 4 Nov 2020 02:08:08 +0100 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.142]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0487.000; Wed, 4 Nov 2020 09:08:00 +0800 From: "Pengshuping (Peng Shuping)" To: "Pengshuping (Peng Shuping)" , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: Presentation slot request in SPRING WG - IETF109 Thread-Index: AdannfvjDlwGqFxyRYKGESI5E/pCcwKqFZIA Date: Wed, 4 Nov 2020 01:07:59 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE1953AA56@DGGEML532-MBX.china.huawei.com> References: <4278D47A901B3041A737953BAA078ADE194ADFC7@DGGEML532-MBX.china.huawei.com> In-Reply-To: <4278D47A901B3041A737953BAA078ADE194ADFC7@DGGEML532-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.30.26] Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE1953AA56DGGEML532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Presentation slot request in SPRING WG - IETF109 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 01:08:14 -0000 --_000_4278D47A901B3041A737953BAA078ADE1953AA56DGGEML532MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Just a kind reminder. If you would like to present, please send your reques= t if you have not done so. The cut-off date is 9th November. Best regards, Shuping From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Pen= g Shuping) Sent: Thursday, October 22, 2020 9:37 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] Presentation slot request in SPRING WG - IETF109 Dear all, We will continue to using the Google Form to collect presentation slot requ= ests in the SPRING WG for this IETF109. Please fill in your request in the = following Form. https://docs.google.com/forms/d/e/1FAIpQLSdEJ90WoDxTFGRXiNhFgKADPFdOTtSpetI= 9geRNw1FfzsSRqw/viewform If there is any issue for you to access this Form, please send your request= directly to spring-chairs@ietf.org. Thank you! Best regards, Shuping --_000_4278D47A901B3041A737953BAA078ADE1953AA56DGGEML532MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear al= l,

&n= bsp;

Just a = kind reminder. If you would like to present, please send your request if yo= u have not done so. The cut-off date is 9th November.

&n= bsp;

Best re= gards,

Shuping=

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, October 22, 2020 9:37 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] Presentation slot request in SPRING WG - IETF109

 

Dear all,

 

We will continue to using the G= oogle Form to collect presentation slot requests in the SPRING WG for this = IETF109. Please fill in your request in the following Form.

 

https://docs.google.com/forms/d/e/1FAIpQLSdEJ90WoDxTFGRXiNhFgKADPFdOT= tSpetI9geRNw1FfzsSRqw/viewform

 

If there is any issue for you t= o access this Form, please send your request directly to spring-chairs@ietf.org. =

 

Thank you!

 

Best regards,=

Shuping

--_000_4278D47A901B3041A737953BAA078ADE1953AA56DGGEML532MBXchi_-- From nobody Wed Nov 4 01:18:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86EB3A0DF9; Wed, 4 Nov 2020 01:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dK-lSS38ZaUg; Wed, 4 Nov 2020 01:17:59 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B63A0DF4; Wed, 4 Nov 2020 01:17:57 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5fa271bacee-9edee; Wed, 04 Nov 2020 17:17:46 +0800 (CST) X-RM-TRANSID: 2eec5fa271bacee-9edee X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.1.6.6]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35fa271b9998-70980; Wed, 04 Nov 2020 17:17:46 +0800 (CST) X-RM-TRANSID: 2ee35fa271b9998-70980 From: "Weiqiang Cheng" To: "'James Guichard'" , Cc: References: In-Reply-To: Date: Wed, 4 Nov 2020 17:17:45 +0800 Message-ID: <011e01d6b28b$5bcd0750$136715f0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01D6B2CE.69F04750" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgAhEKvg Content-Language: zh-cn Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 09:18:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_011F_01D6B2CE.69F04750 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Support as a co-author. =20 Weiqiang Cheng =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 01:39 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call for = draft-li-spring-srv6-path-segment =20 Dear WG: =20 This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please note that this document has several changes = from v-06 that were requested by the SPRING chairs. For this reason, the = chairs have extended the adoption call for an additional week to allow the WG enough time to review these changes before deciding on WG adoption.=20 =20 After review of the document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as consent. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 =20 =20 =20 ------=_NextPart_000_011F_01D6B2CE.69F04750 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as a = co-author.

 

Weiqiang = Cheng

 

=B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 01:39
=CA=D5=BC=FE=C8=CB: = spring@ietf.org
=B3=AD=CB=CD: = spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption Call = for = draft-li-spring-srv6-path-segment

 

Dear WG:

 

This message starts a 3 week WG = adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, = ending November 24th 2020. Please note that this document has = several changes from v-06 that were requested by the SPRING chairs. For = this reason, the chairs have extended the adoption call for an = additional week to allow the WG enough time to review these changes = before deciding on WG adoption.

 

After review of the document please = indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as = silence will not be considered as consent.

 

Thanks!

 

Jim, Bruno & = Joel

 

 

 

 

 

------=_NextPart_000_011F_01D6B2CE.69F04750-- From nobody Wed Nov 4 04:06:36 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44843A0779; Wed, 4 Nov 2020 04:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SfL3qCQ_Rv2p; Wed, 4 Nov 2020 04:06:32 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E8F3A0489; Wed, 4 Nov 2020 04:06:32 -0800 (PST) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CR5224NS2z67Hl8; Wed, 4 Nov 2020 20:05:14 +0800 (CST) Received: from fraeml738-chm.china.huawei.com (10.206.15.219) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 13:06:28 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 4 Nov 2020 13:06:27 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.249]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Wed, 4 Nov 2020 20:06:22 +0800 From: "Chengli (Cheng Li)" To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgAm8xoA Date: Wed, 4 Nov 2020 12:06:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02C8A3FBdggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 12:06:34 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02C8A3FBdggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SPRING, Support as a co-author. SRv6 Path Segment is useful to identify an SRv6 Pat= h, so that it can be used in use cases like PM, 1+1 Protection and OAM. I t= hink it can be a good basis for Path related services. Also, comments and = contributions are welcome! Many thanks, Cheng From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Wednesday, November 4, 2020 1:39 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please = note that this document has several changes from v-06 that were requested b= y the SPRING chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption. After review of the document please indicate support (or not) for WG adopti= on to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel --_000_C7C2E1C43D652C4E9E49FE7517C236CB02C8A3FBdggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SPRING, =

 

Support as a co-author= . SRv6 Path Segment is useful to identify an SRv6 Path, so that it can be u= sed in use cases like PM, 1+1 Protection and OAM. I think it can be a g= ood basis for Path related services.  Also, comments and contributions are welcome!

 

 

Many thanks,

Cheng

 

 

From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of James Guichard
Sent: Wednesday, November 4, 2020 1:39 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-seg= ment

 

Dear WG:

 

This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-s= rv6-path-segment-07, ending November 24th 2020. Please note that this document has several changes from v-06 that were requested by the SPRING c= hairs. For this reason, the chairs have extended the adoption call for an a= dditional week to allow the WG enough time to review these changes before d= eciding on WG adoption.

 

After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as silence= will not be considered as consent.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

 

 

--_000_C7C2E1C43D652C4E9E49FE7517C236CB02C8A3FBdggeml529mbxchi_-- From nobody Wed Nov 4 17:46:30 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02CC3A07C3; Wed, 4 Nov 2020 17:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KBrspVYOtxuz; Wed, 4 Nov 2020 17:46:26 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84A3A1256; Wed, 4 Nov 2020 17:46:25 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee15fa35963e3e-a5df3; Thu, 05 Nov 2020 09:46:13 +0800 (CST) X-RM-TRANSID: 2ee15fa35963e3e-a5df3 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.1.6.6]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee15fa35961b3f-04cf6; Thu, 05 Nov 2020 09:46:13 +0800 (CST) X-RM-TRANSID: 2ee15fa35961b3f-04cf6 From: "qinfengwei" To: "'James Guichard'" , Cc: References: In-Reply-To: Date: Thu, 5 Nov 2020 09:46:12 +0800 Message-ID: <00d801d6b315$714c76d0$53e56470$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D6B358.7F6FB6D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgBDpN9Q Content-Language: zh-cn Archived-At: Subject: [spring] =?gb2312?b?tPC4tDogIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0?= =?gb2312?b?LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudA==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 01:46:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01D6B358.7F6FB6D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Support=A1=A3 =20 =20 =20 Thanks=A3=AC Fengwei Qin =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 01:39 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call for = draft-li-spring-srv6-path-segment =20 Dear WG: =20 This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please note that this document has several changes = from v-06 that were requested by the SPRING chairs. For this reason, the = chairs have extended the adoption call for an additional week to allow the WG enough time to review these changes before deciding on WG adoption.=20 =20 After review of the document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as consent. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 =20 =20 =20 ------=_NextPart_000_00D9_01D6B358.7F6FB6D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support=A1=A3=

 

 

 

Thanks=A3=AC

Fengwei = Qin

 

=B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 01:39
=CA=D5=BC=FE=C8=CB: = spring@ietf.org
=B3=AD=CB=CD: = spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption Call = for = draft-li-spring-srv6-path-segment

 

Dear WG:

 

This message starts a 3 week WG = adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, = ending November 24th 2020. Please note that this document has = several changes from v-06 that were requested by the SPRING chairs. For = this reason, the chairs have extended the adoption call for an = additional week to allow the WG enough time to review these changes = before deciding on WG adoption.

 

After review of the document please = indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as = silence will not be considered as consent.

 

Thanks!

 

Jim, Bruno & = Joel

 

 

 

 

 

------=_NextPart_000_00D9_01D6B358.7F6FB6D0-- From nobody Thu Nov 5 01:13:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880D63A1186 for ; Thu, 5 Nov 2020 01:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.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 rNH8rExvJItg for ; Thu, 5 Nov 2020 01:13:00 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 C8F2E3A111A for ; Thu, 5 Nov 2020 01:12:59 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id za3so1553784ejb.5 for ; Thu, 05 Nov 2020 01:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XryXAabTJJ3CsOPsCoLl4WzxCeGvTBxPtDtduX+d2U8=; b=txy4HdM2aaMo/KH7B+/buZAtBUXgloq97ghyNBWQWRwRq3Z9Q5WHr/pW941BX5esrp iVbCZl2OOx2vyMXwvdaWBpFwOlfF/d+FZvp4iWrSpVbgNQ/0EDvB36GAjLoFPs8ll0yO +ojdUBjLVNA2XXV17d5p+u5s2k0nku/tHhhm9cOd28+CeGbzgaDpZdaMvHwIJLyaj1Zr 1HO1N2AR1CE04QmM5adyXQ35rwzdNAIUFp8ZzLOCRy/a5HoVkzXWZmyOLSLeP3mCI+nB kVj2g9AIYqy8dEzfofKGgderbT15vpxERlnVYPZ5WX7rAzHAaBubOwbUI2zzGnqi1NED b34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XryXAabTJJ3CsOPsCoLl4WzxCeGvTBxPtDtduX+d2U8=; b=np/nISZNnyPx8BUcm2n9i3tfYh3EiQGw94Fz+k6uuYlUbH1amfyO/rgkJjHXTeL/1H G6fJs0bRT5J51ZVuVxQou2keolv3VCWQF0XDVD3HP2LR1+ekJ3wzJYM5zZrWSrUJmGjL OoEhTtRSEj0VfYGRzItoOE7Hm8EilsNFPf12XRP4iDJGEZUSR8RQgQMhjsk4GvZrnQMs vNGxG9PumnOq9fznnbI5IVhg3sXayJ/FncI336ePgn8fPaKrbgPLFoefwmrI8OvBW8jG Z0PPGFeMHxpMiqw7xoDXyUc/0BYXpHTvjQCwMie2JJV3KPjuNxlv0NGet5zyYER3sixN LRBw== X-Gm-Message-State: AOAM533XoUNA6HgGW9TBRPnY7YsNMZoWHHUkyP6EQs7THbItiW0DcHzB YyY++RbjuSNiSmdUd74vdWht0g== X-Google-Smtp-Source: ABdhPJwYjtMLzJtsAfU70Xu2mQN7Q1t34KUC6m8fVlxlHuSIKSRJ1swX0vZ3hsVqpvp0pz4GnWr8fg== X-Received: by 2002:a17:906:22c7:: with SMTP id q7mr1394666eja.291.1604567577990; Thu, 05 Nov 2020 01:12:57 -0800 (PST) Received: from pc.home (host-79-47-210-53.retail.telecomitalia.it. [79.47.210.53]) by smtp.gmail.com with ESMTPSA id g25sm494400ejh.61.2020.11.05.01.12.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2020 01:12:57 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: Date: Thu, 5 Nov 2020 10:13:03 +0100 Cc: "spring@ietf.org" , "spring-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Guichard X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 09:13:02 -0000 Hi, I support the adoption of draft-li-spring-srv6-path-segment as it = describes a useful feature (identifying an SR path through a segment = identifier) which is already available in implementations. Thanks. s. > On Nov 3, 2020, at 6:39 PM, James Guichard = wrote: >=20 > Dear WG: > =20 > This message starts a 3 week WG adoption call for = https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending = November 24th 2020. Please note that this document has several changes = from v-06 that were requested by the SPRING chairs. For this reason, the = chairs have extended the adoption call for an additional week to allow = the WG enough time to review these changes before deciding on WG = adoption. > =20 > After review of the document please indicate support (or not) for WG = adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as = consent. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Nov 5 11:14:55 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082363A197C for ; Thu, 5 Nov 2020 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 dAanXifxd706 for ; Thu, 5 Nov 2020 11:14:51 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690124.outbound.protection.outlook.com [40.107.69.124]) (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 18B533A197B for ; Thu, 5 Nov 2020 11:14:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SoaknhhY3gpTQJSfZcIvtjA8K6GKjD87/S4qf6EBgGi7341nphLlYsLzGayYlyS/WN839FVErk+/nao6JH4ZskeRD7eul+QHHf5yo6L+qZC9C750I30cADsHVhTxZv9rjLFJNjSUHEd4GipW5uTNxePMvLrmxuykEsFcU7Q2PwBW8svqAhluaUcfT7HSFN8ubgk+gTDSuPf26nFS+9shejMZrDV54uqKqaJUrBcELhlaUJBaqxcAc3ZupczYl4+gG7fW326THGcx4ySsbkdXIWAGxNP0Q2phzBPFh2RLym+PeXKG69d4KCNjbyf1HbMRwCsgsPTvXLJQOAzio8rxhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tc42RguxoN0OJbIbKofR/+fJPLUSIu0SzE/PhMpfpDI=; b=Sc+W2XBF01YzU/0qNpRvs/zeOj+zH2ObubedUqjRGOUsOZE78vCgK06pD/eDx4fPit4zGzjbGE9+/a85pembC8uP1TApm3iSuEyQXbyD+h7Zm7gWF7Z8AtKovMKqJ9bN9+QORzzvW1c19/wu/l2DJxAypwwxBy/+UOwVg9v9kGP6shucY/GdXpTUjps9sJqlJ3MA7yqWQPmI0UWQi4FuDPSvk26oi/vIwywVStL2Pt8FKE91c9dCNjTtau/K50jnzdfywtZvt7f72wCfl6duH/o6VfeFWL3nG/RcgxkgxT2suq2eH7KVNH6x0Qt08ILexnZP9DnACY47KKfLPdeSpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tc42RguxoN0OJbIbKofR/+fJPLUSIu0SzE/PhMpfpDI=; b=Q1FNTILB+kVH16lryQFQibiLxDn6SQbxmsyqQvuQcHQgKGCBgz1bk2SnuuXhMTUJ0Dd4l+ftT16euDJHvxp85UbNzj4lPIaCSz3PDtfnR/WBr+RIm3WGDTRHglZAgkk//ONvcwM0aNjsDgCAcdl+Nm2WnC2hl/g9Lly9ZVCwkdY= Received: from DM6PR08MB4393.namprd08.prod.outlook.com (2603:10b6:5:a2::21) by DM5PR0801MB3751.namprd08.prod.outlook.com (2603:10b6:4:7e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Thu, 5 Nov 2020 19:14:47 +0000 Received: from DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424]) by DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424%6]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 19:14:47 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: "Ketan Talaulikar (ketant)" , "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLM70syLdU1bpku3yUTxttqV3Km0BkEAgAWUXwA= Date: Thu, 5 Nov 2020 19:14:47 +0000 Message-ID: <9C721BE5-F5FD-49DD-BC3E-4119E9105E7E@nokia.com> References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.26] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1a91ee28-760b-47be-420e-08d881bf0f99 x-ms-traffictypediagnostic: DM5PR0801MB3751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YGg9LpQKWod3EWflvZjkZScl1IziUE+dAXxDpr/erlpxtboBQehgbvy1LYGgOHS6FA/SYfJzDryCL1sxJgKJXS8KgFVxDEFJ7MMg3EgL+yYfqi+Z5XDdg543PCg9pEGm+kHp9mOmOdjcVwJbulNRSNadY7N9qFOq6VlEYcWH+lyTUW3m9KHIcogc+xLZNvB68BXHCrDcS6hTbAsRmCLeWhdbFFgsONIJgUUpGOJa/AUgneg6CDK+z3q3BuRVEFcdY2U1opqSqBgkhJxwK++MHmZ2byF5xMhuH9uK2svCv7VBz65Dzk5nuDH5NedVVV3wzr0xfyLfgH9G/Us5/BwpOyTW5iwnrilNVomQWI+bUFiw5v59YpQit69q9Mjg8nSsukulKvDKQ+ukT8RV0dtazg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4393.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(346002)(376002)(396003)(66476007)(8676002)(6486002)(2906002)(8936002)(6512007)(33656002)(86362001)(66556008)(6506007)(83380400001)(66574015)(53546011)(186003)(316002)(36756003)(110136005)(26005)(76116006)(91956017)(966005)(2616005)(64756008)(66446008)(478600001)(66946007)(71200400001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HBDEaNV+00msULryoQ2lYl/KfO379qrmHaBv1/Yma8hWQxZCvaqzFrqn3z8KBnuLPk3pPNuHmd0+nsn2kbWgiTs/PNMdaPBRZCHAHbogfOQiyWUrqY4xzz15jbGFtpaQUkrm8FSaiHXeJlF09TQ8RBz+2S8QIb+dQptpLzgiRGgCqO2Wk9qmIWYwvZ+W9jMfieiBp8Rky7gXNHCmnHk/wDfHUqi2P0HwoeSs3qVaP9LYUEtvJaBOwVvOGYqZbxNd6m6yHs9FhIuHJ/rF4HBVDuFw1tLdzP27PkgP/D0mMhbXUbjaGp4mM3ErH9T1kW6X3SNOPfemSZy7atLEQDsPaRjNzlBHGvjsHifU4EYPsmSoFW43FBLExCFJQCDEEgblaNHVT4SsHjYnDhc7WAIGppb/q+O4E+gU8+5k7to4S3anlwGxcq+lfsD9L7882sJ7vXAGMD3geH0pOULA2AqsGaYz6mhCXEqqMT7kUSiTlidWQlf1qp/P8P5d4L/uxjWGavDYTZ9DuPTeVr3j+jVAQzB95cLx+Rl59To/G/fchrVQMgQyi3RWXZRPRJj9rfQWTEgz0WrXKk8WMv73ADmLOHU/fVu1abupCJwZ8N8+Q7wPn+VupFdRlZ5zP+lMTEakAZT9MgjDGulSyd2mnnXyVA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB4393.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a91ee28-760b-47be-420e-08d881bf0f99 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 19:14:47.2714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: F4ckYbxn7fpFYsFey/ZBUPhU8KNbDe0fcDc7RBXcXYpuRgpQ4oSWEbpC6+kWx6RFraVpCd3+T9hRPuVUABdCJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0801MB3751 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 19:14:54 -0000 SGkgS2V0YW4sDQoNClRoYW5rcyBmb3IgdGhpcyB1cGRhdGUgLyByZWZlcmVuY2luZyB0aGUgeWFu ZyByZWxhdGVkIHF1ZXN0aW9uIEkgaGFkIGFib3V0IG11bHRpcGxlIG9iamVjdGl2ZS9jb25zdHJh aW50cyAoMSkuIFJlZ2FyZGluZyBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgsIHF1aWNrbHkgdGhp bmtpbmcgYWJvdXQgaXQgZnJvbSBhIGNvbnRyb2xsZXIvcGNlIHBvaW50IG9mIHZpZXcsIGl0IGRv ZXMgc2VlbSBsaWtlIGFuIGVsZWdhbnQgc29sdXRpb24gdG8gcmUtdXNlIHRoZSBlbnRpcmUgU1Ig UG9saWN5IGNvbnN0cnVjdCBpbiBhIG5lc3RlZCBtYW5uZXIgdG8gYWNoaWV2ZSBjb21iaW5hdGlv biBvZiBURSBjb25zdHJhaW50L29iamVjdGl2ZSBwYXR0ZXJucywgYXZvaWRpbmcgYSBsb3Qgb2Yg Y29tcGxleGl0eSBpbiB5YW5nL3Byb3RvY29sIG1vZGVsbGluZyBhdCB0aGUgY29zdCBvZiBtb3Jl IFNSIFBvbGljeSBoZWFkZW5kL2NvbnRyb2xsZXIgc3RhdGUgdG8gbWFuYWdlL2RlYWwvd29yayB3 aXRoLiBJIHRoaW5rIGl0IHdhcyBhIGdvb2QgaWRlYSB0byBoYXZlIHRoYXQgcmVzdHJpY3Rpb24g b2YgYSBkZXB0aCBvZiBvbmUuIE5vIG90aGVyIGNvbW1lbnRzIG9yIGZlZWRiYWNrIHlldCwgd2ls bCBsZXQgdGhpcyBzdGV3IGEgYml0Lg0KDQpUaGFua3MgYWdhaW4sDQpBbmRyZXcNCg0KDQrvu79P biAyMDIwLTExLTAxLCA4OjAyIFBNLCAic3ByaW5nIG9uIGJlaGFsZiBvZiBLZXRhbiBUYWxhdWxp a2FyIChrZXRhbnQpIiA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGtldGFu dD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBIZWxsbyBBbGwsDQoN CiAgICBXZSBoYXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZSBmb3IgdGhlIGRyYWZ0IGFuZCBmb2xs b3dpbmcgaXMgdGhlIHN1bW1hcnkgb2YgY2hhbmdlczoNCg0KICAgIDEpIEludHJvZHVjdGlvbiBv ZiB0aGUgQ29tcG9zaXRlIENhbmRpZGF0ZSBQYXRoIGNvbnN0cnVjdCB0byBhZGRyZXNzIGEgcGVu ZGluZyBjb21tZW50IGZyb20gdGhlIFdHIChSZWYgOiBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIGFuZCBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9kOW9TU2JncDBqQ0V4Ungw U1h5QlkwQ3lxWFUvKQ0KICAgIDIpIEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQs IHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2NiBTSUQg YW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhlIG5ldyB0eXBlIHRoYXQgd2FzIGludHJvZHVjZWQg Zm9yIGl0IGluIHRoZSB2MDguDQogICAgMykgQ2xhcmlmaWNhdGlvbiBvZiBoYW5kbGluZyBvZiBj b2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBvZmZsaW5lIGZlZWRi YWNrIHJlY2VpdmVkLg0KICAgIDQpIENsYXJpZmljYXRpb24gb24gY29uc2lkZXJhdGlvbnMgZm9y IFRJLUxGQSBmb3IgU1IgUG9saWN5IGFzIGRpc2N1c3NlZCBpbiB0aGUgV0cgKFJlZiA6IGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL0VWMXl0VXNkNVpna01IRE4w SXZGaHc5aWQ0MC8pDQoNCiAgICBQbGVhc2UgbGV0IGtub3cgeW91ciBjb21tZW50cy9mZWVkYmFj ay4NCg0KICAgIFRoYW5rcywNCiAgICBLZXRhbiAob24gYmVoYWxmIG9mIGNvLWF1dGhvcnMpDQoN CiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IHNwcmluZyA8c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN CiAgICBTZW50OiAwMiBOb3ZlbWJlciAyMDIwIDA2OjI3DQogICAgVG86IGktZC1hbm5vdW5jZUBp ZXRmLm9yZw0KICAgIENjOiBzcHJpbmdAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBbc3ByaW5nXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4 dA0KDQoNCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcgV0cgb2Yg dGhlIElFVEYuDQoNCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFNlZ21lbnQgUm91dGlu ZyBQb2xpY3kgQXJjaGl0ZWN0dXJlDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBDbGFy ZW5jZSBGaWxzZmlscw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgS2V0YW4gVGFsYXVs aWthcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuaWVsIFZveWVyDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBbGV4IEJvZ2Rhbm92DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQYXVsIE1hdHRlcw0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KICAgIAlQYWdlcyAgICAgICAg ICAgOiAzNw0KICAgIAlEYXRlICAgICAgICAgICAgOiAyMDIwLTExLTAxDQoNCiAgICBBYnN0cmFj dDoNCiAgICAgICBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8g c3RlZXIgYSBwYWNrZXQgZmxvdw0KICAgICAgIGFsb25nIGFueSBwYXRoLiAgSW50ZXJtZWRpYXRl IHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3MNCiAgICAgICB0byBzb3VyY2Ug cm91dGluZy4gIFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGlj eS4NCiAgICAgICBUaGUgaGVhZGVyIG9mIGEgcGFja2V0IHN0ZWVyZWQgaW4gYW4gU1IgUG9saWN5 IGlzIGF1Z21lbnRlZCB3aXRoIGFuDQogICAgICAgb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGFz c29jaWF0ZWQgd2l0aCB0aGF0IFNSIFBvbGljeS4gIFRoaXMNCiAgICAgICBkb2N1bWVudCBkZXRh aWxzIHRoZSBjb25jZXB0cyBvZiBTUiBQb2xpY3kgYW5kIHN0ZWVyaW5nIGludG8gYW4gU1INCiAg ICAgICBQb2xpY3kuDQoNCg0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kvDQoNCiAgICBUaGVyZSBhcmUg YWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkN CiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkNCg0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOQ0K DQoNCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCiAgICBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQog ICAgc3ByaW5nQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgIHNwcmluZ0BpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== From nobody Thu Nov 5 19:13:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A43A0855; Thu, 5 Nov 2020 19:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tBcXWAbJ6UXB; Thu, 5 Nov 2020 19:13:24 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214323A0844; Thu, 5 Nov 2020 19:13:24 -0800 (PST) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CS55Z08Q7z67H3T; Fri, 6 Nov 2020 11:11:46 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 6 Nov 2020 04:13:22 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 6 Nov 2020 04:13:21 +0100 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.130]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Fri, 6 Nov 2020 11:13:15 +0800 From: Mach Chen To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgB49COg Date: Fri, 6 Nov 2020 03:13:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F6F6B6dggeml530mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 03:13:26 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F6F6B6dggeml530mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Support as co-author. Best regards, Mach From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Wednesday, November 4, 2020 1:39 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please = note that this document has several changes from v-06 that were requested b= y the SPRING chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption. After review of the document please indicate support (or not) for WG adopti= on to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F6F6B6dggeml530mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Support as co-author.

 

Best regards,

Mach

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, November 4, 2020 1:39 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-seg= ment

 

Dear WG:

 

This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, end= ing November 24th 2020. Please note that this document has sever= al changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.

 

After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as silence= will not be considered as consent.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F6F6B6dggeml530mbschi_-- From nobody Thu Nov 5 19:56:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECB13A09A5; Thu, 5 Nov 2020 19:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 EdCr-WrncaPT; Thu, 5 Nov 2020 19:56:08 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id C0C883A0995; Thu, 5 Nov 2020 19:56:07 -0800 (PST) HMM_SOURCE_IP: 172.18.0.48:18864.601844277 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-14.25.171.161?logid-8202811683034e678f854cd4d8fee2af (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 1013F28008B; Fri, 6 Nov 2020 11:55:57 +0800 (CST) X-189-SAVE-TO-SEND: 44093218@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id 8202811683034e678f854cd4d8fee2af for james.n.guichard@futurewei.com; Fri Nov 6 11:56:01 2020 X-Transaction-ID: 8202811683034e678f854cd4d8fee2af X-filter-score: filter<0> X-Real-From: chenhuan6@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: chenhuan6@chinatelecom.cn Date: Fri, 6 Nov 2020 11:55:59 +0800 From: "chenhuan6@chinatelecom.cn" To: "James Guichard" , "SPRING WG" Cc: "spring-chairs@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <2020110611545826672927@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart372346422127_=----" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 03:56:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart372346422127_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGnvvIxXR++8jA0KICAgIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24uDQogICAgSSBoYXZlIGludGVy ZXN0aW5nIGluIGRlcGxveWluZyB0aGUgcGF0aCBzZWdtZW50IHRvIGdldCBlbmQtdG8tZW5kIHBh dGggcHJvdGVjdGlvbi4NCiAgIEJSLg0KICAgSFVBTkFOIENIRU7vvIjpmYjljY7ljZfvvIkNCkRh dGEgQ29tbXVuaWNhdGlvbiBSZXNlYXJjaCBEZXBhcnRtZW50DQpSZXNlYXJjaCBJbnN0aXR1dGUg b2YgQ2hpbmEgVGVsZWNvbSBDby4sTHRkLg0KRnJvbTogSmFtZXMgR3VpY2hhcmQNCkRhdGU6IDIw MjAtMTEtMDQgMDE6MzkNClRvOiBzcHJpbmdAaWV0Zi5vcmcNCkNDOiBzcHJpbmctY2hhaXJzQGll dGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1saS1z cHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQNCkRlYXIgV0c6DQogDQpUaGlzIG1lc3NhZ2Ugc3RhcnRz IGEgMyB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQtMDcsIGVuZGluZyBOb3ZlbWJlciAy NHRoIDIwMjAuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2ZXJhbCBjaGFu Z2VzIGZyb20gdi0wNiB0aGF0IHdlcmUgcmVxdWVzdGVkIGJ5IHRoZSBTUFJJTkcgY2hhaXJzLiBG b3IgdGhpcyByZWFzb24sIHRoZSBjaGFpcnMgaGF2ZSBleHRlbmRlZCB0aGUgYWRvcHRpb24gY2Fs bCBmb3IgYW4gYWRkaXRpb25hbCB3ZWVrIHRvIGFsbG93IHRoZSBXRyBlbm91Z2ggdGltZSB0byBy ZXZpZXcgdGhlc2UgY2hhbmdlcyBiZWZvcmUgZGVjaWRpbmcgb24gV0cgYWRvcHRpb24uIA0KIA0K QWZ0ZXIgcmV2aWV3IG9mIHRoZSBkb2N1bWVudCBwbGVhc2UgaW5kaWNhdGUgc3VwcG9ydCAob3Ig bm90KSBmb3IgV0cgYWRvcHRpb24gdG8gdGhlIG1haWxpbmcgbGlzdC4gUGxlYXNlIGFsc28gcHJv dmlkZSBjb21tZW50cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikg YXMgc2lsZW5jZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuDQogDQpUaGFua3Mh DQogDQpKaW0sIEJydW5vICYgSm9lbA0KIA0KIA0KIA0KIA0KIA0K ------=_001_NextPart372346422127_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A= =0A
=0A

Dear WG:

=0A

 = ;

=0A

This message sta= rts a 3 week WG adoption call for=0Ahttps://tools.ietf.org/html/draft-li-spring-srv= 6-path-segment-07, ending November 24th 2020. Please note t= hat this document has several changes from v-06 that were requested=0A by = the SPRING chairs. For this reason, the chairs have extended the adoption = call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.=0A

=0A

 

=0A

After review of the document please indicate support (or not) f= or WG adoption to the mailing list.=0APlease also provide comments/reasons for that= support (or lack thereof) as silence will not be considered as consent.

=0A

 

=0A

Than= ks!

=0A

 

=0A

J= im, Bruno & Joel

=0A<= p class=3D"MsoNormal" style=3D"margin: 0in; font-size: 11pt; font-family: = Calibri, sans-serif;"> 

=0A

=  

=0A

 

=0A

 

=0A

 <= /o:p>

=0A
=0A=0A ------=_001_NextPart372346422127_=------ From nobody Fri Nov 6 06:51:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2713A11EC; Fri, 6 Nov 2020 06:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 dbzt42uuzOWh; Fri, 6 Nov 2020 06:51:07 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2109.outbound.protection.outlook.com [40.107.220.109]) (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 272CA3A11EB; Fri, 6 Nov 2020 06:51:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CuXXagFVgAKJh/PXuwBNLMttlBB3vJ1osdJugwWE2NSzenTFGNTPBnXRWAlviavEcNKab4iRvt148WqP+G9Vi+EBXVxHMLQSXlp9UVk+06J5y0u6JNuNR72PiEH6Xr5TGp1ewUVThlPxr5YUfCDSz5bjBq8yR8M8vLeY607edlobb7Lgetd+8gi0r1mrHhUqUSqtUoOlv5TE1d/yfyYpa8Bky3m6hy7Y67TyIlvZa3SBu2diyuEuJH4NWa5iPjvWEZnIuX6IxIIyU4OGT8pepkxMcU3GIZcpLtxMo5AQLEpu6DYhLar0IAS7hAdLQpSKIA2G4yheuU0vLPvT4+JAcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O628XlL4ez+j794LnUiSRaJV4WVz0lLoX8ECyYJkkkM=; b=EhGNOHZFzQGYccl1ygvk40rqFZ9t0eKTxXvYEdLPuzCIGuP08/xIY2DLUg+52+fIBgQHGxSZiIvvZpnhooLpMICdoR2h2D6OxtTiy+nKOwvrTqZYs16TpjJit7KhWkM2egPE6qTUaUWIEGsReoQnSHdRQB+rzd+O8WeiXn2sINcBZPfpNA3PsbNHVQ9JhRTo+CFY6Hk+OL8pWTg7zHKvRRpQLWG0xlBrCgBDuIPn0HRuRzjB6SfkWKhNx3hfTIuvrNFcTdZKTDgHdghrE8iy8x+AZ1iFaUB13siIguuyPNRenO4h4ml8JOAS4rE5Z7I9CqEGR8H0E4ozmfCcA3YHDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O628XlL4ez+j794LnUiSRaJV4WVz0lLoX8ECyYJkkkM=; b=Mzh9oIsFSBmh3Hs+REJZdVUT3jaCYesfQ5Q7DHfboS/Y0mUlqv+uRZEAwZ76EJQmORbm/RaspWp4ckhyivFaV7qytHzAfEz9ZiIkWfZAD29/clh9Jh32mXQxVaYavkFhi9xqR8Kp8JQ4Go3IBeq0hroihlGjWRHovR1C8BOIg8E= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA0PR13MB4047.namprd13.prod.outlook.com (2603:10b6:806:9a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Fri, 6 Nov 2020 14:51:06 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::8c05:b4f5:cc16:eeb]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::8c05:b4f5:cc16:eeb%7]) with mapi id 15.20.3541.017; Fri, 6 Nov 2020 14:51:06 +0000 From: Linda Dunbar To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgB49COgABhlSNA= Date: Fri, 6 Nov 2020 14:51:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2603:8081:1700:ab:f5cd:e595:94d4:24de] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41fd2664-c3af-4df1-3e95-08d8826363d2 x-ms-traffictypediagnostic: SA0PR13MB4047: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yFEQA8WCMm3QBmSSgLOdBpRVaejMb4fBFuteHuigXi8SPKEesGoljcu+UUOBRHc5ePovGi3nH7c3Z40kvMS3317U1hT0FWjDYP02GaeNacdTc2Lva0SmmsNZzYNu6ny2hO8xE26iNuGmc2wJrHGeM1BUpzYoPx0PJINY9FeJ97FzsTT+ADGgEFuPDDek5KQOILYSWpTLAZWedlbzoYu7FTbNWCdmvntlVoWtN2a0o5GEzVjoLYpzlzCM96D2sEvwGjE2ftvQL7bWVESYfjaFIOm69Y4+Z69f5aRr8Uvqh1HPTFD2rTegdijr7LT0aJ+UQ077b+Y1UTdkN2hwuA1gYUjWKuDE9GvdZzFGbxq8RW3fFyNW2i/Lma6dxWuJIzH1a2OrejtNyQlnHyfSxjN8Ow== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(366004)(396003)(136003)(376002)(346002)(64756008)(66476007)(110136005)(478600001)(186003)(71200400001)(4326008)(316002)(7696005)(66446008)(450100002)(86362001)(8676002)(76116006)(2906002)(8936002)(66556008)(966005)(52536014)(166002)(9686003)(5660300002)(83380400001)(44832011)(6506007)(4744005)(53546011)(55016002)(33656002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: E2j6zx6K2HeAtwfnQxKJ7y5p0LPefYUOCgGlkh8vhpiczuvYJlB89euIQY7mVJ1V0/eZSX/OfMDkzpmxE7NB/jUj4nM+xNjNnyojGgwHa2U2sjothycDz/RiLXej7pD4fHH1fdAOcrHj4v1cZmsGT2Jm3Yc2m1lyaIq3aCg1OIbeoMrhVw2t6OOXs/J21TVtBeGIRpNSvvuruohR5KRGV42rQP4DikTshIPLLbiw70zNDu89HmTNKWdnjWzanUYs1osI1zsmRLb98DAXHyF5jaIhHAFqzuzg01bzT0AcXWr3wJYcXoQLDSY0IOE5DSIwzCLw96L7bhM3pbAUmN8RezHHsnm3zUjyShD1FR+1a32nAeI0NWO6OK1Pma4lB4rUL9MUEzYSz5eBoIbbp7XVH+qqO4dv3aHPg8w6ENQYNIaB1tKQC70CY8yelh3riZIamPgMjZMKIcqelQLCaoqT8xiFyQDhBRmrvB0wNsqySCqOFTQuJxsaMtdYM8NGOW92uvTqA4Hu7eh2TA5iePnA8WPUJtIqQe0PM3L0BWA1DEE9fgWrp4xru9j86P6Lcuom0xyNN7ZYPPswp9coQSqFBkw4IyruHkty6R5a7Nz97OQwpXina/A/F66w3MwGgyapK98ifyiGhv7+rsRCTgTpVYyRL3nCtHzXeMlTgYkhNwbDkW6P66/IfZ65o7Ka4DhjBvxOrdRBGSoKrzZryJOe4A== Content-Type: multipart/alternative; boundary="_000_SN6PR13MB233481836C562388E952430C85ED0SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41fd2664-c3af-4df1-3e95-08d8826363d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2020 14:51:05.9832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S4smVT8mN8kuN6pg07AMMl+yBehv+fHKXLwqDVK6uZDPOburrfykr+U2AQhbxr5OOkM3naPd1kooxldG1Yd7rQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB4047 Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 14:51:11 -0000 --_000_SN6PR13MB233481836C562388E952430C85ED0SN6PR13MB2334namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support the WG Adoption. Linda Dunbar From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Wednesday, November 4, 2020 1:39 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please note th= at this document has several changes from v-06 that were requested by the S= PRING chairs. For this reason, the chairs have extended the adoption call f= or an additional week to allow the WG enough time to review these changes b= efore deciding on WG adoption. After review of the document please indicate support (or not) for WG adopti= on to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel --_000_SN6PR13MB233481836C562388E952430C85ED0SN6PR13MB2334namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support the WG Adoption.

 

Linda Dunbar

=  

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, November 4, 2020 1:39 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org=
Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-seg= ment

 

Dear WG:

 

This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, endin= g November 24th 2020. Please note that this document has several= changes from v-06 that were requested by the SPRING chairs. For this reaso= n, the chairs have extended the adoption call for an additional week to allow the WG enough time to review= these changes before deciding on WG adoption.

 

After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as silence= will not be considered as consent.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

 

 

--_000_SN6PR13MB233481836C562388E952430C85ED0SN6PR13MB2334namp_-- From nobody Fri Nov 6 08:17:50 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E593A07EA; Fri, 6 Nov 2020 08:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vOQ65aKHeVea; Fri, 6 Nov 2020 08:17:43 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 A385C3A07E6; Fri, 6 Nov 2020 08:17:42 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id y16so1966158ljk.1; Fri, 06 Nov 2020 08:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zQ2rkobH08OxWqX025Bp/OvPZpEqPyuR6yedaAJNg8Y=; b=Trt+vmuxLDm2v3trq3l8jw1LyCTVlmsMFAQPs+O70eCMGThSePOBynKe2TY1SkataH +ZqM8geWCjDBwTAUMm/NrXnbKaLqtoiaetG1mB2DoR+yx5i20CehFZKv2Nf51JUnBqEK ZaSeOHD5Jf+dcyrVnMlBDZ2XEQijE0+ylJioMUfz8UewasiklJG4xlDY+P7p9hP2tAEp 77Q+71tQqwifM0MrJBZaYYCZpX33IjkJCgLp5yP1vyK7v1oZr2QXzh6Hw8Cf3afAzHDz 9IRZnu+lS/F7BOisa4McNypL0/o6gIZQ43ALNbetbu07+ifyyJ90LGZ3BMi026aELWB/ N+2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zQ2rkobH08OxWqX025Bp/OvPZpEqPyuR6yedaAJNg8Y=; b=ocC1g6fm+LyDKU3Csf+H6vd3BQqiH8gOg3mbUkaCCKtJTuZLWsJJ5seTNtHV11VA1U PqB7qwxmDpk/1x3/cHB8a7QH1kZ5CNcm8KMegpFQxVNg5G1MChpcxisHb9jGgUrNTtFn lhi7VT7lt3TSdnSsaMLL5OGWYu15g/mCeFGwRNSMEQ31upbVMwHkpOjVtpxmt31Fvuof Kg+/6lve8XjEBalLvB5Jp7SJVikM9/s2TcV7vrUucE5CzXDn3CA767OdswFnK1vdv9a3 qCv33ohoffCpqeykbiK/RlHg9kz4J9FnwxMW8yQB7BQILoxfRoh1yI4baUyajGU2ihoj //pw== X-Gm-Message-State: AOAM530rOIeG77TdPNoYxOaz5k7VbPQnCfaMEhaAouTMpgbCf84i6sP1 FxrEluFzas+Pj7dz1MHCKGpQ1hCgS0ADOsz8fEZnTVqO X-Google-Smtp-Source: ABdhPJzqYIk4CxeICGkS+ALAkOU4KiCyzh4Hie4REXSXTXsZQlNonT3WvynrGLYix7RZA9AQ6wRysn5ogl4eXtosQ4k= X-Received: by 2002:a2e:3314:: with SMTP id d20mr943123ljc.23.1604679460826; Fri, 06 Nov 2020 08:17:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 6 Nov 2020 08:17:29 -0800 Message-ID: To: James Guichard Cc: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000003db3c305b3728da9" Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 16:17:46 -0000 --0000000000003db3c305b3728da9 Content-Type: text/plain; charset="UTF-8" Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG APs in the SPRING and IPPM WG (with the possibility that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and comments in a single thread. I hope that would be acceptable and considered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers to these three questions: - Is the document(s) reasonably well-written It was a surprise finding out that both drafts don't use the terminology from RFC 8762 STAMP and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents without proper definitions. Other than that, both drafts are readable. - Does the document solve a real problem? No, it appears that the changes described in these drafts are only to achieve in-band collection of counters of "in-profile" packets. Firstly, drafts don't provide any arguments about why such collection should be performed using the in-band method rather than using the out-of-band collection approach. Secondly, even if there are any benefits of in-band collection, that can be more easily achieved by extending other OAM, e.g., ICMP, tools. - Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by the protocol on network security, to comprehensively evaluate the proposed solution. draft-gandhi-spring-stamp-srpm - Can you define a Link and how it is different from an SR Path? - It is not clear how the destination UDP port numbers are selected. Does the draft change procedure defined in Section 4.1 RFC 8762? - It is not clear what "the congruent path" means. The definition of the congruent in geometry tells that a congruent object has the same shape and size, but is allowed to flip, slide or turn. How a path can be congruent to another path? - An example of the provisional model is Section 3.1 seems well-suited for a YANG data model. What changes to the STAMP YANG data model defined in draft-ietf-ippm-stamp-yang proposed in these drafts? - In Section 4.1 noted that The probe messages defined in [RFC8762] are used for delay measurement for Links and end-to-end SR Paths including SR Policies. For loss measurement, the probe messages defined in [I-D.gandhi-ippm- stamp-srpm] are used. It necessary to point that RFC 8762 support packet delay and packet loss measurements in the same test session using test packets defined in the STAMP base specification. I believe that the need yet for another method to perform the loss measurement is not sufficiently demonstrated and does appear as duplication of functionality already available in STAMP. - Could you expand on the reasoning why in Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. I cannot find similar requirement in RFC 8762 and would appreciate a technical explanation of the choice made in this specification. - Section 4.2.1 refers to Sender Control Code (though it is defined in draft-gandhi-ippm-stamp-srpm. Could you explain why it is important to inform the Session-Reflector that the reflected test packet be sent out-of-band? What if only in-band return path is available? Would the Session-Reflector discard test packets in such situation? - I got confused by the following in Section 4.2.2 In two-way measurement mode, when using a bidirectional path, the probe response message as defined in Figure 6 is sent back to the sender node on the congruent path of the data traffic on the same reverse direction Link or associated reverse SR Policy [I-D.ietf-pce-sr-bidir-path]. If a Path Segment SID associated with the test session, there seems no need to require the Session-Reflector look for in-band path. Would you agree? - How's the method described in Section 4.2.3 is different from the method described in RFC 8403 ? What is distinctly unique about the loopback mode proposed in the section? Is the "liveness monitoring" functionally identical to path continuity monitoring provided by BFD? - It appears that second and third paragraphs on Section 4.3.1 contradict with the first paragraph. Need to point that RFC 8762 does not specify the value set in TTL/Hop Limit field, thus reference in the first paragraph seems misleading. I couldn't find ::FFFF:127/104 range being mentioned in the draft. Could you clarify when it is used? - Section 4.3.3 states that a zero-value UDP checksum may be used in some scenarios. RFC 8085 allows that but in very specific cases that are documented in detail in Section 3.4.1. Do you believe that the case of this protocol checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I believe that allowing the use of Zero UDP checksum in some scenarios, this protocol introduces a security threat that must be thoroughly analyzed in the Security Considerations section. - Section 7, as I understand it, suggests that performance measurement can be combined with "liveness monitoring", i.e.path continuity monitoring. How fast path failure detection you expect in such combination? How it is comparable to the the failure detection time guaranteed using BFD? draft-gandhi-ippm-stamp-srpm - Introduction states that The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. In fact, that is not accurate. RFC 8762 which provides the base specification of the STAMP protocol already supports packet delay and packet loss (a.k.a. synthetic packet loss) measurement. - Further, the draft concludes that However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization). I disagree that the the clock synchronization is required for STAMP. It is recommended for one-way delay measurement but even without the clock synchronization STAMP supports the round-trip delay measurement and one-way delay variation can be calculated. - The conclusion on Introduction is, in my view, misleading as the proposed solution is not an extension of STAMP but update of RFC 8762. And since this is changes the foundation of RFC 8762 that specifies active two-way performance measurement protocol, another method for collecting counters and/or other telemetry information should be sought. For example, ICMP using multi-part message extensions, as defined in RFC 4884 . Regards, Greg On Thu, Oct 22, 2020 at 5:52 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending > November 12th 2020. Please note that this document has several changes > from v-02 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING > and IPPM chairs considered those comments, and upon review of this version > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensions. > Several extensions including* Control Code Field Extension for STAMP > Messages*, *Loss Measurement Query Message Extensions*, *Loss > Measurement Response Message Extensions*, *Node Address TLV Extensions*, > and *Return Path TLV Extensions* were included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and > should be removed from the SPRING document. > - The STAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as consent. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000003db3c305b3728da9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Chairs of the SPRIN= G and IPPM WGs, Authors, et al.,
I've found myself in the situation= when two related drafts are in the WG APs in the SPRING and IPPM WG (with = the possibility that expertise from the third WG, BFD WG, might be desirabl= e to review the "liveness monitoring"). Because these drafts are = closely related, I've decided to combine my questions and comments in a= single thread. I hope that would be acceptable and considered by the SPRIN= G WG as well as IPPM WG.
Usually, the bar for the adoption of a d= ocument can be evaluated=C2=A0by answers to these three questions:
  • Is the document(s) reasonably well-written
<= /div>
=
It was a=C2=A0surprise finding out that both drafts d= on't use the terminology from RFC 8762 STAMP and introduce their own te= rminology for Session-Sender and Session-Reflector.=20 Also, many terms, e.g., Links, "congruent paths", are=20 used in the documents without proper definitions.=20 Other than that, both drafts are readable.
  • = Does the document solve a real problem?
No, it appears that the changes= described in these drafts are only to achieve in-band collection of counte= rs of "in-profile" packets. Firstly, drafts don't provide any= arguments about why such collection should be performed using the in-band = method rather than using the out-of-band collection approach. Secondly, eve= n if there are any benefits of in-band collection, that can be more easily = achieved by extending other OAM, e.g., ICMP, tools.
    Is the proposed solution technically viable?
There are too many unaddr= essed aspects, particularly the risk introduced by the protocol on network = security, to comprehensively evaluate the proposed solution.

draft-gandhi-spring-stamp-srpm
  • Can you define a Link = and how it is different from an SR Path?
  • It is not clear how the de= stination UDP port numbers are selected. Does the draft change procedure de= fined in Section 4.1 RFC 8762?
  • It is not clear what "the congr= uent path" means. The definition of the congruent in geometry tells th= at a congruent object has the same shape and size, but is allowed to flip, = slide or turn. How a path can be congruent to another path?
  • An exam= ple of the provisional model is Section 3.1 seems well-suited for a YANG da= ta model. What changes to the STAMP YANG data model defined in draft-ietf-ippm-stamp-yang=C2=A0=C2=A0proposed in these drafts?
  • In Section 4.1 noted that
=C2=A0 =C2=A0The probe messages def= ined in [RFC8762] are used for delay
=C2=A0 =C2=A0measurement for Links = and end-to-end SR Paths including SR Policies.
=C2=A0 =C2=A0For loss mea= surement, the probe messages defined in [I-D.gandhi-ippm-
=C2=A0 =C2=A0s= tamp-srpm] are used.
It necessary to point that RFC 8762 support pa= cket delay and packet loss measurements in the same test session using test= packets defined in the STAMP base specification. I believe that the need y= et for another method to perform the loss measurement is not sufficiently d= emonstrated and does appear as duplication of functionality already availab= le in STAMP.
  • Could you expand on the reasoning wh= y in Section 4.1.1.1 stated that
=C2=A0 =C2=A0A separate user-conf= igured
=C2=A0 =C2=A0destination UDP port is used for the delay measureme= nt in
=C2=A0 =C2=A0authentication mode due to the different probe messag= e format.
I cannot find similar requirement in RFC 8762 and would a= ppreciate a technical explanation of the choice made in this specification.=
  • Section 4.2.1 refers to Sender Control Code (tho= ugh it is defined in=C2=A0draft-gandhi-ippm-stamp-srpm. Could you explain w= hy it is important to inform the Session-Reflector that the reflected test = packet be sent out-of-band? What if only in-band return path is available? = Would the Session-Reflector discard test packets in such situation?
    • I got confused by the following in Section 4.2.2
=C2=A0 =C2=A0In = two-way measurement mode, when using a bidirectional path, the
=C2=A0 = =C2=A0probe response message as defined in Figure 6 is sent back to the
= =C2=A0 =C2=A0sender node on the congruent path of the data traffic on the s= ame
=C2=A0 =C2=A0reverse direction Link or associated reverse SR Policy<= br>=C2=A0 =C2=A0[I-D.ietf-pce-sr-bidir-path].
If a Path Segment SID= associated with the test session, there seems no need to require the Sessi= on-Reflector look for in-band path. Would you agree?
    =
  • How's the method described in Section 4.2.3 is different from the m= ethod described in RFC 8403? What is distinctly unique about the loopback mode= proposed in the section?=C2=A0 Is the "liveness monitoring" func= tionally identical to path continuity monitoring provided by BFD?
  • I= t appears that second and third paragraphs on Section 4.3.1 contradict with= the first paragraph. Need to point that RFC 8762 does not specify the valu= e set in TTL/Hop Limit field, thus reference in the first paragraph seems m= isleading. I couldn't find ::FFFF:127/104 range being mentioned in the = draft. Could you clarify when it is used?
  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as sp= ecified in RFC 8085? Also, I believe that allowing the use of Zero UDP chec= ksum in some scenarios, this protocol introduces a security threat that mus= t be thoroughly analyzed in the Security Considerations section.
  • Section 7, as I understand it, suggests that performance measureme= nt can be combined with "liveness monitoring", i.e.path continuit= y monitoring. How fast path failure detection you expect in such combinatio= n? How it is comparable to the the failure detection time guaranteed using = BFD?

draft-gandhi-ippm-stamp-srpm
  • Introduction states that
    • =C2=A0 The STAMP message with a TLV = for "direct measurement" can be used for
    =C2=A0 =C2=A0combined= Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv].
    <= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">In fact, tha= t is not accurate. RFC 8762 which provides the base specification of the ST= AMP protocol already supports packet delay and packet loss (a.k.a. syntheti= c packet loss) measurement.
    • Further, the draft conc= ludes that
    =C2=A0 =C2=A0However, in order to use only for loss mea= surement purpose, it
    =C2=A0 =C2=A0requires the node to support the delay= measurement messages and
    =C2=A0 =C2=A0support timestamp for these messa= ges (which may also require clock
    =C2=A0 =C2=A0synchronization).
    I disagree that the the clock synchronization is required for STAMP. It is= recommended for one-way delay measurement but even without the clock synch= ronization STAMP supports the round-trip delay measurement and one-way dela= y variation can be calculated.
    • The conclusion on = Introduction is, in my view, misleading as the proposed solution is not an = extension of STAMP but update of RFC 8762. And since this is changes the fo= undation of RFC 8762 that specifies active two-way performance measurement = protocol, another method for collecting counters and/or other telemetry inf= ormation should be sought. For example, ICMP using multi-part message exten= sions, as defined in RFC 4884.

    Regards,
    Greg

    =

    On Thu, Oct 22, 2020 at 5:52 AM James Guichard <= ;james.= n.guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending N= ovember 12th 2020. Please note that this document has several ch= anges from v-02 that were requested by the SPRING and IPPM chairs. For this= reason, the chairs have extended the adoption call for an additional week to allow the WG enough time to re= view these changes before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0

    =C2=A0

    Several review comments were received previously for= document https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02. The SPRING and IPPM chairs considered those comments, = and upon review of this version of the document, determined the following:<= u>

    =C2=A0

    • The SPRING document shou= ld describe only the procedures relevant to SPRING with pointers to non-SPR= ING document/s that define any extensions. Several extensions including Control Code Field Extension for = STAMP Messages,=C2=A0Loss Measurement Query Message Extensions,=C2=A0Loss Measurement Respons= e Message Extensions,=C2=A0Node Address TLV Extensions, and=C2= =A0Return Path TLV Extensions were inclu= ded in https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 and should be removed from the SPRING document.
    • The STAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 should be described in a new document published in the= IPPM WG. =C2=A0

    =C2=A0

    These conclusions were discusse= d with the authors of https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 the result of which is the publication of the following two = documents:

    =C2=A0

    =C2=A0

    After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack= thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like to thank the au= thors for their efforts in this matter.<= u>

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --0000000000003db3c305b3728da9-- From nobody Fri Nov 6 08:18:06 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37D63A0A71; Fri, 6 Nov 2020 08:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nPGiWpYK7RjG; Fri, 6 Nov 2020 08:17:52 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 06D6B3A08BB; Fri, 6 Nov 2020 08:17:52 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id z21so1397223lfe.12; Fri, 06 Nov 2020 08:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TtaLkdll6oCrH/Qaa5U2XFz9VE2rtAaPtYJOh4WChJc=; b=ehJwIuzTdLt+z8NlFPhXashQxJZrdDbBWKGkYaRbN4StbU21y7JdkFp0KXWz8URQIb MfaNTThm2m06EeJSQ4WNAB4WX8ldqB/IEnfNiNDaeDRv0GarHzxQ03IZkzcE+GMAjeB+ cMfdnVjSeFtLEk+E05JkqRRqnherD6F9cT2ykbGraJpggYwetAqQ76Qa62TbGzc5BiOC plqmxaqUOe1JQEdKSFMUSBxf15cQTTJq00BVgMngGuHwtSJPqcI20nLj0n7KTQa6GqI+ cjy8rb9ZV1jRK+cCD7hRA/oPxpvrFw1g2DOg/6ygdtDy204MwxFo66KS+Hn7lRjAsKsR Fkwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TtaLkdll6oCrH/Qaa5U2XFz9VE2rtAaPtYJOh4WChJc=; b=dTfjbk/2uab9DTUo4T2zznX/A35vT0+imC1bXj6Okit+7T/N4+vr6MxsYzvyku8YP/ eBbnoyOKrymob5djUrK5W9LrIQYPxZTSBgdZ/WdkatCefOf8j0m/0CMHa18uwupkI9t4 u94EcDZDowJxkUeaAimLCK94gwhejg0yyaHUmmB11wsWAP3a9S8oZF8PU9XzYfgbun0k BWCRRRgaIU7FUJJmtDqn4BuUOUXKFx4x5Ii4TU3b/r++wAtsCw5shhppLuOhSvy/DN2G I/cF1Qeuhi3aNenSuX1b1yDjiJpvDkk/Ox3yHuU5b8lZFZWPmmVdueLHFbS7G/Xe+iai FRlw== X-Gm-Message-State: AOAM533WriqH8K8XhfqIQv1MGCaPbCKQ9psSMf+45W9lapS/ROebV1Il Ut2eg2XBzW49DqY5/YBPKpuVECToX5RklaRO1fO++ejT X-Google-Smtp-Source: ABdhPJwJd6IhcR9rDUT61C574/4TewY3myT4yE5MmlaTIDTPWvRQ1SCWzZ0pvstv/KHx0OoSCT3WicWGIjygoJB46ho= X-Received: by 2002:a05:6512:36c5:: with SMTP id e5mr1093204lfs.433.1604679469805; Fri, 06 Nov 2020 08:17:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 6 Nov 2020 08:17:39 -0800 Message-ID: To: James Guichard Cc: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000c6b55105b3728dcb" Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 16:18:02 -0000 --000000000000c6b55105b3728dcb Content-Type: text/plain; charset="UTF-8" Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG APs in the SPRING and IPPM WG (with the possibility that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and comments in a single thread. I hope that would be acceptable and considered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers to these three questions: - Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 and 5357 and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents without proper definitions. Other than that both drafts are readable and reasonably well-written. - Does the document solve a real problem? No, it appears that these drafts define a new performance measurement protocol for the purpose of combining OWAMP and TWAMP functionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms like ICMP. - Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by the protocol on network security, to comprehensively evaluate the proposed solution. To summarize my review of these two drafts: - these propose a new protocol, not an update or enhancement of the TWAMP-like protocol; - several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, require detailed security analysis, which is currently absent; - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on the Informational track even though it is essential to the new protocol as it defines its key elements - I believe that draft-gandhi-spring-twamp-srpm should be anchored at IPPM WG as it does introduce the new PM protocol. Below, please find my detailed comments, questions on these drafts: - draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, I don't think we can have a draft that proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: - In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for control-channel signaling". Also, could you point where the referenced documents describe "provisioning UDP paths"? - It appears that the last paragraph in the Introduction describes the relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could you please specify which extensions of TWAMP Light have been used in this draft? - In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is related to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? - Also in Section 2.3 a Link is mentioned as an element directly connecting nodes in the presented reference model. Could you clarify what is a Link? Is it always a physical connection between two systems or a virtual? - In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as defined in RFC 5357. Could you provide a reference to an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way delay and synthetic loss measurement on a bidirectional SR tunnel? - Further, in Section 3 the selection of UDP port explained as the following: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in the same test session, using the same flow of TWAMP-Test packets. - Then the draft states that The sender uses the UDP port number following the guidelines specified in Section 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP port number of a test session? - At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the port number? - Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender and Session-Reflector respectively? - for both delay and loss measurements draft requires test packet be transmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruency in geometry tells us that an object B is congruent to object A if it has the same shape and size, but is allowed to flip, slide or turn. How a path can be congruent to another path? - The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships between iOAM and draft-gandhi-spring-twamp-srpm? - Section 3.1 presents an example of the provisioning model but puts the definition of the provisioning model outside the scope. Is there an accompanying specification that defines the provisioning model that can be used in multi-vendor deployment? Could that be YANG data model? What is the relationship with draft-ietf-ippm-twamp-yang ? Would the TWAMP YANG data model be augmented? - Section 4.1 states that a new message is introduced to perform the Loss Measurement in this protocol Why the capability of TWAMP to measure the loss in one-way and two-way is not sufficient? - Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measurement is unique throughout the particular domain? - Section 4.1.2 of RFC 5357 does not define "the delay measurement message" but refers to the definition of the Session-Sender's test packet in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet format to perform both delay and packet loss measurement. - Can you explain how "the DM probe query message contains the payload format defined in Section 4.2.1 of [RFC5357]" when the referenced section of RFC 5357 defines the format of a Session-Reflector's test packet? - Can clarify the applicability of RFC 6038 and the symmetrical packet size? Is it required? Can it be non-symmetrical? - Can you clarify the use of the timestamp format, NTP or PTPv2? It is not clear which is the default, mandatory or optional. - Also, is "hardware support in Segment Routing networks" of the PTPv2 format required, guaranteed, or something else? - Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and unauthenticated test sessions using this protocol? Would different authentication methods require using unique destination UDP port numbers? - Section 4.1.2 by introducing the dedicated Loss measurement packet format, effectively modifies the behavior defined in RFC 5357 for Session-Sender and Session-Reflector. But the document does not state that. Can you clarify whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for the support of packet loss measurement? - And a similar question about the use of the separate UDP port number for the authenticated of the packet loss measurement. - A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. - What are the addresses of a link? - In which scenarios an IPv6 LLA can be used? - Also, could the use of a routable destination IP address be used as a DDOS attack vector? Consider the scenario when an attacker generates SR-encapsulated packets with the destination IP address other than any of the SR-terminating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree? - Section 4.1.4.2 references Figure 5 that, as I understand it, displays the format of a probe query message. In figure two references to RFC 5357 are provided - a section that references RFC 4656 OWAMP definition of the Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is used for the delay measurement in the proposed protocol? - Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is sent not in-band but out-of-band? - How's the method described in Section 4.2.3 is different from the method described in RFC 8403 ? What is distinctly unique about the loopback mode proposed in the section? - What is the rationale for setting TTL/Hop Limit fields always to 255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)? - Section 4.3.3 states that a zero-value UDP checksum may be used in some scenarios. RFC 8085 allows that but in very specific cases that are documented in detail in Section 3.4.1. Do you believe that the case of this protocol checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I believe that allowing the use of Zero UDP checksum in some scenarios, this protocol introduces a security threat that must be thoroughly analyzed in the Security Considerations section. - Section 8 refers to "liveness monitoring of Links and SR Paths". This appears as the replication of functionality provided by BFD/S-BFD protocols. Is such comparison accurate? If it is, shouldn't the proposal be also reviewed by the BFD WG? - I found the Security Section of the proposed protocol inadequately terse and missing very important threats that this protocol introduces in the network. - draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in this specification is to collect "in-profile" counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled? In your opinion, how using an out-of-band method of collecting these counters, e.g., by using ICMP multi-part message extension per RFC 4884, could affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messages are in-band with the profiled flow? - Section 3.1 introduces the new field, Sender Control Code. The format of the packet, as I understand it, is presented in Figure 1. When comparing with the format of Session-Sender's test packet defined in RFC 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal? - Also, it appears that the Sequence Number field in TWAMP Session-Sender's test packet is absent in Figure 1. Is that intentional? Regards, Greg On Thu, Oct 22, 2020 at 5:51 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING > and IPPM chairs considered those comments, and upon review of this version > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensions. > Several extensions including *Control Code Field Extension for TWAMP > Light Messages*, *Loss Measurement Query Message Extensions*, and *Loss > Measurement Response Message Extensions *were included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > - The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as consent. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000c6b55105b3728dcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Chairs of the SPRIN= G and IPPM WGs, Authors, et al.,
    I've found myself in the situation= when two related drafts are in the WG APs in the SPRING and IPPM WG (with = the possibility that expertise from the third WG, BFD WG, might be desirabl= e to review the "liveness monitoring"). Because these drafts are = closely related, I've decided to combine my questions and comments in a= single thread. I hope that would be acceptable and considered by the SPRIN= G WG as well as IPPM WG.
    Usually, the bar for the adoption of a d= ocument can be evaluated=C2=A0by answers to these three questions:
    • Is the document(s) reasonably well-written
    <= /div>
    I've got surprised that the drafts don't use the te= rminology from RFC 4656 and 5357 and introduce their own terminology for Se= ssion-Sender and Session-Reflector. Also, many terms, e.g., Links, "co= ngruent paths", are=20 used in the documents without proper definitions. Other than that both draf= ts are readable and reasonably well-written.
      Does the document solve a real problem?
    No, it appears that these drafts de= fine a new performance measurement protocol for the purpose of combining OW= AMP and TWAMP functionality and adding the ability to collect counters of &= quot;in-profile" packets. I couldn't find sufficient technical arg= uments for using a PM protocol instead of, for example, extending the exist= ing OAM mechanisms like ICMP.
    • Is the proposed solut= ion technically viable?
    There are too many unaddressed aspects, particularly = the risk introduced by the protocol on network security, to comprehensively= evaluate the proposed solution.

    To summarize my review of=C2=A0these two drafts:
    • these propose a new protocol, not an update or enhancement = of the TWAMP-like protocol;
    • several parts of the proposed protocol,= e.g., Zero UDP checksum in IPv6, require detailed security analysis, which= is currently absent;
    • I was surprised to find out that=C2=A0draft-g= andhi-ippm-twamp-srpm is on the Informational track even though it is essen= tial to the new protocol as it defines its key elements
    • I believe t= hat=C2=A0draft-gandhi-spring-twamp-srpm should be anchored at IPPM WG as it= does introduce the new PM protocol.
    Below, please find my detaile= d=C2=A0comments, questions on these drafts:
    • draft-gandhi-= spring-twamp-srpm
    I have several questions about the re= lationships between this draft and Appendix I in RFC 5357 where the idea of= a mode known as TWAMP Light has been mentioned. The nature of the TWAMP Li= ght and what is required to make it a standard is well-explained in Section= 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):
    =C2=A0 = =C2=A0"TWAMP Light" is an idea described in Appendix I ("TWA= MP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light inc= ludes an unspecified
    =C2=A0 =C2=A0control protocol combined with the TWA= MP-Test protocol.=C2=A0 In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea = was relegated to Appendix I because
    =C2=A0 =C2=A0TWAMP Light failed to m= eet the requirements for IETF protocols (there
    =C2=A0 =C2=A0are no speci= fications for negotiating this form of operation and no
    =C2=A0 =C2=A0spe= cifications for mandatory-to-implement security features), as
    =C2=A0 =C2= =A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] and
    =C2= =A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light c= learly includes the TWAMP-Test
    =C2=A0 =C2=A0component of TWAMP, it is co= nsidered reasonable for future systems to
    =C2=A0 =C2=A0use the TWAMP-Tes= t well-known UDP port (whose reallocated assignment
    =C2=A0 =C2=A0is spec= ified in this document).=C2=A0 Clearly, the TWAMP Light idea
    =C2=A0 =C2= =A0envisions many components and communication capabilities beyond
    =C2= =A0 =C2=A0TWAMP-Test (implementing the security requirements, for example);=
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence l= ong
    =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).
    <= div>
    Since we don't have an IETF document that addressed = these open questions, I don't think we can have a draft that proposes e= xtensions to a non-standard mechanism (Appendix is for Informational materi= al, as I understand it) on the Standard track.
    Now a number of mo= re specific questions.
    draft-gandhi-spring-twamp-srpm:
    <= div>
    • In the Introduction it is stated that:
    =C2=A0 The TWAM= P Light [Appendix I in RFC5357] [BBF.TR-390] provides
    =C2=A0 =C2=A0simpl= ified mechanisms for active performance measurement in Customer
    =C2=A0 = =C2=A0IP networks by provisioning UDP paths and eliminates the need for
    = =C2=A0 =C2=A0control-channel signaling.
    I can not=C2=A0find where,= either Appendix I or TR-390, "eliminated the need for control-channel= signaling". Also, could you point where the referenced documents desc= ribe "provisioning UDP paths"?
    • It = appears that the last paragraph in the Introduction describes the relations= hip with Appendix I of RFC 5357:
    =C2=A0 =C2=A0The procedure uses t= he mechanisms defined in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its ex= tensions for Performance Measurement.
    I think that the refere= nce must be to Appendix I, not RFC 5357. Also, could you please specify whi= ch extensions of TWAMP Light have been used in this draft?
    • In Section 2.3 describing the reference model is noted:
    = =C2=A0 =C2=A0The probe response message is typically sent to the sender nod= e R1.
    In which scenarios the reflector acts differently? How = such behavior is related to the behavior of a TWAMP Session-Reflector, as d= efined in RFC 5357?
    • Also in Section 2.3 a Link is= mentioned as an element directly connecting nodes in the presented referen= ce model. Could you clarify what is a Link? Is it always a physical connect= ion between two systems or a virtual?
    • In Section 3 behavior of the = reflector described as
    =C2=A0 =C2=A0... no PM state for delay or l= oss measurement need to be created on the
    =C2=A0 =C2=A0reflector node R5= .
    That is in contradiction to the behavior of a TWAMP Session-Ref= lector as defined in RFC 5357. Could you provide a reference to an IETF sta= ndard where this behavior is defined? Also, how, without creating a state a= t the Session-Reflector, to achieve one-way delay and synthetic loss measur= ement on a bidirectional SR tunnel?
    • Further, in S= ection 3 the selection of UDP port explained as the following:
    =C2= =A0 =C2=A0As specified in [RFC8545], the reflector
    =C2=A0 =C2=A0supports= the destination UDP port 862 for delay measurement probe
    =C2=A0 =C2=A0m= essages by default.=C2=A0 This UDP port however, is not used for loss
    = =C2=A0 =C2=A0measurement probe messages.
    To the best of my unders= tanding, as one of the contributors and=C2=A0Editors of RFC 8545, it re-all= ocated UDP port 862 for use by a TWAMP Session-Reflector without excluding = any type of measurement. Besides, in TWAMP delay and packet loss are measur= ed in the same test session, using the same flow of TWAMP-Test packets.
    • Then the draft states that
    The sender uses = the UDP port number following the guidelines specified in Section 6 in [RFC= 6335].
    Could you point to the guidelines that a user can use when= selecting a UDP port number of a test session?
    • A= t the closing of the paragraph, we read that
    =C2=A0 The number of = UDP ports with PM functionality needs to be minimized due
    =C2=A0 =C2=A0t= o limited hardware resources.
    Does a UDP port number pose PM func= tionality? How it is assigned to the port number?
      Following the above-quoted text, in Section 3 is noted:
    =C2=A0 = =C2=A0For Performance Measurement, probe query and response messages are=C2=A0 =C2=A0sent as following:
    Could you clarify if the listed = further procedures deviate from OWAMP/TWAMP or follow procedures defined in= RFC 4656 and RFC 5357 for Session-Sender and Session-Reflector respectivel= y?
    • for both delay and loss measurements draft req= uires test packet be transmitted on a congruent path:
    =C2=A0 =C2= =A0 =C2=A0 the probe messages are sent on the
    =C2=A0 =C2=A0 =C2=A0 congr= uent path of the data traffic by the sender node
    It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?
    • The last paragraph in Section 3 refers to work o= n iOAM:
    =C2=A0 =C2=A0The In-Situ Operations, Administration, and M= aintenance (IOAM)
    =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.ga= ndhi-mpls-ioam-sr] and for
    =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-= ioam-srv6] are used to carry PM
    =C2=A0 =C2=A0information such as timesta= mp in-band as part of the data packets,
    =C2=A0 =C2=A0and are outside the= scope of this document.
    Is iOAM in the scope of this specificati= on? What are the relationships between iOAM and=C2=A0draft-gandhi-spring-tw= amp-srpm?
    • Section 3.1 presents an example of the = provisioning model but puts the definition of the provisioning model outsid= e the scope. Is there an accompanying specification that defines the provis= ioning model that can be used in multi-vendor deployment? Could that be YAN= G data model? What is the relationship with=C2=A0draft-ietf-ip= pm-twamp-yang? Would the TWAMP YANG data model be augmented?
    • Se= ction 4.1 states that a new message is introduced to perform the Loss Measu= rement in this protocol Why the capability of TWAMP to measure the loss in = one-way and two-way is not sufficient?
    • Section 4.1.1 requires that<= /li>
    =C2=A0 The Destination UDP port cannot be used as Source port, sin= ce
    =C2=A0 =C2=A0the message does not have any indication to distinguish = between the
    =C2=A0 =C2=A0query and response message.
    Does that imply that the Destination UDP port used for the Delay measure= ment is unique throughout the particular domain?
    • = Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.
    • Can = you explain how "the DM probe query message contains the payload forma= t defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet?
    • Can clarify the applicability of RFC 6038 and the symmetrical packet s= ize? Is it required? Can it be non-symmetrical?
    • Can you clarify the= use of the timestamp format, NTP or PTPv2? It is not clear which is the de= fault, mandatory or optional.
    • Also, is "hardware support in Se= gment Routing networks" of the PTPv2 format required, guaranteed, or s= omething else?
    • Section 4.1.1.1 stated that
    =C2=A0 =C2=A0A = separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for t= he delay measurement in
    =C2=A0 =C2=A0authentication mode due to the diff= erent probe message format.
    Can that be interpreted that there co= uld be concurrent authenticated and unauthenticated test sessions using thi= s protocol? Would different authentication methods require using unique des= tination UDP port numbers?
    • Section 4.1.2 by introduci= ng the dedicated Loss measurement packet format, effectively modifies the b= ehavior defined in RFC 5357 for Session-Sender and Session-Reflector. But t= he document does not state that. Can you clarify whether this specification= changes the behavior of a Session-Sender and Session-Reflector as defined = in RFC 4656 and RFC 5357 respectively for the support of packet loss measur= ement?
    • And a similar question about the use of the separate UDP por= t number for the authenticated of the packet loss measurement.
    • A co= uple of question to the following text in Section 4.1.3:
    =C2=A0 = =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are use= d as Source and Destination Addresses.
    =C2=A0 =C2=A0They can also be IPv= 6 link local address as probe messages are pre-
    =C2=A0 =C2=A0routed.
    =
      • What are the addresses of a link?
      • In which s= cenarios an IPv6 LLA can be used?
      • Also, could the use of a routable= destination IP address be used as a DDOS attack vector? Consider the scena= rio when an attacker generates SR-encapsulated packets with the destination= IP address other than any of the SR-terminating nodes. Such=C2=A0a=C2=A0pa= cket will be routed, correct? That does appear as a security threat, would = you agree?
    • Section 4.1.4.2 references Figure 5 that, as I unde= rstand it, displays the=C2=A0format of a probe query message. In figure two= references to RFC 5357 are provided - a section that references RFC 4656 O= WAMP definition of the Session-Sender test packet, and a section that defin= es the Session-Reflector's reflected packet. Which of the two is used f= or the delay measurement in the proposed protocol?
    • Section 4.2.1 st= ates that
    =C2=A0 =C2=A0In one-way measurement mode, the probe resp= onse message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-ban= d to the sender node ...
    Could you clarify how the responder = controls that the response packet is sent not in-band but out-of-band?
    • How's the method described in Section 4.2.3 is di= fferent from the method described in RFC 8403? What is distinctly unique about t= he loopback mode proposed in the section?
    • What is the rationale for= setting TTL/Hop Limit fields always to 255 for IPv4, MPLS, and IPv6 (per S= ection 4.3.1)?
    • Section 4.3.3 states that a zero-value UDP checksum = may be used in some scenarios. RFC 8085 allows that but in very specific ca= ses that are documented in detail in Section 3.4.1. Do you believe that the= case of this protocol checks all the requirements for allowing the use of = Zero UDP checksum as specified in RFC 8085? Also, I believe that allowing t= he use of Zero UDP checksum in some scenarios, this protocol introduces a s= ecurity threat that must be thoroughly analyzed in the Security Considerati= ons section.
    • Section 8 refers to "liveness monitoring of Links= and SR Paths". This appears as the replication of functionality provi= ded by BFD/S-BFD protocols. Is such comparison accurate? If it is, shouldn&= #39;t the proposal be also reviewed by the BFD WG?
    • I found the Secu= rity Section of the proposed protocol inadequately terse and missing very i= mportant threats that this protocol introduces in the network.

    • draft-gandhi-ippm-twamp-srpm
    As I und= erstand it, the motivation for the Loss Measurement mode defined in this sp= ecification is to collect "in-profile" counters. Is that correct?= Do you see as essential for this mode that the query messages are in-band = with the flow being profiled? In your opinion, how using an out-of-band met= hod of collecting these counters, e.g., by using ICMP multi-part=C2=A0messa= ge extension per RFC 4884, could affect the accuracy comparing with the met= hod in this protocol? How the impact changes if extended ICMP messages are = in-band with the profiled flow?
    • Section 3.1 introduces the new f= ield, Sender Control Code. The format of the packet, as I understand it, is= presented in Figure 1. When comparing with the format of Session-Sender= 9;s test packet defined in RFC 4656 OWAMP in Section 4.1.2 I've noticed= that there are no MBZ fields. Are these introduced by your proposal?
      • <= li>Also, it appears that the Sequence Number field in TWAMP Session-Sender&= #39;s test packet is absent in Figure 1. Is that intentional?

    Regards,
    Greg

    =

    = On Thu, Oct 22, 2020 at 5:51 AM James Guichard <james.n.guichard@futurewei.com<= /a>> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG adoption call for do= cument https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending No= vember 12th 2020. Please note that this document has several cha= nges from v-10 that were requested by the SPRING and IPPM chairs. For this = reason, the chairs have extended the adoption call for an additional week to allow the WG enough time to re= view these changes before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0

    =C2=A0

    Several review comments were received previously for= document https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm= -10. The SPRING and IPPM chairs considered those comments, = and upon review of this version of the document, determined the following:<= u>

    =C2=A0

    • The SPRING document shou= ld describe only the procedures relevant to SPRING with pointers to non-SPR= ING document/s that define any extensions. Several extensions including Control Code Field Extension for TWAMP L= ight Messages,=C2=A0Loss Measurement Query Message Extensions, and=C2=A0Loss Measurement Res= ponse Message Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-t= wamp-srpm-10 and should be removed from the SPRING document.
    • The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-twa= mp-srpm-10 should be described in a new document published in the= IPPM WG. =C2=A0

    =C2=A0

    These conclusions were discusse= d with the authors of =C2=A0https://tools.iet= f.org/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the= publication of the following two documents:

    =C2=A0

    =C2=A0

    After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack= thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like to thank the au= thors for their efforts in this matter.<= u>

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000c6b55105b3728dcb-- From nobody Sat Nov 7 07:34:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B823C3A08AB for ; Sat, 7 Nov 2020 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=Df+5FKBP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=h7mS9WtT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNFUavXCtpZY for ; Sat, 7 Nov 2020 07:34:23 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31153A084D for ; Sat, 7 Nov 2020 07:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6344; q=dns/txt; s=iport; t=1604763262; x=1605972862; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Q7zEMW9UgJK93lNwNW9JKB5r7UoxMjAoiQ+jeUD0DeQ=; b=Df+5FKBPKVPPytORLVD3F2sVV6OAz+qwcJhgQ0s9wVKrv3c0mk+GgVql BJJWpt3NWgU93Km5nH9foJvQ/TL/+ReLU6aWFkmD/ti837tcRqV7hOgx6 OQXKc4eU6tW+WLS0RC5quGztrOHqyMH6TC5Rb3JGX5nrep42njye1Kz8c U=; X-IPAS-Result: =?us-ascii?q?A0DwCAB9vaZffZpdJa1igQmDIVF7WS8uCoQzg0kDjVWZA?= =?us-ascii?q?YJTA1QLAQEBDQEBGA0IAgQBAYQGRAIXgXgCJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAyFcgEBAQEDAQEQEREMAQEsDAsEAgEIEQEDAQEDAiYCAgIlC?= =?us-ascii?q?xUCBggCBAESCBMHgwWCVQMtAQEOozkCgTuIaHaBMoMEAQEFgTMBAwIOQYMIG?= =?us-ascii?q?IIQCYEOKoJzgmVOQoJEhBMbgUE/gVSCTz6CXQEBAgEBFYFIFYMAM4IskCuDO?= =?us-ascii?q?qRFCoJtiQ2SIoMYgSqIaJRGk06Bfoh7kRuEMgIEAgQFAg4BAQWBayGBWXAVG?= =?us-ascii?q?iGCNQEBMglHFwINjisXg06FFIVEdAI2AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AI0PLkRz/0V9mEMrXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/Nqj17AG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK9NktUEYD1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,459,1596499200"; d="scan'208";a="601946731" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2020 15:34:21 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A7FYL8A023569 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2020 15:34:21 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Nov 2020 09:34:21 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Nov 2020 10:34:20 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 7 Nov 2020 10:34:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iw1isST6IKJks+qVCdcVd4E/uSegtPLN0JJcB3q+bak0qnyXjJQbJSZRsD2CsUCpvz2DaWFAFu/QJ07GhhgBzOpwZJ71zOUZXxtYBY7doV/XSW5VgoREbm2lq89KjfW0p87T66PazouCdBNn6/N9sB4hOtQduBrU4gQ0OQ8b1EyFclgOS2jJ7RgpVbVLwKr2DCdFbNvY/tt6BKF0WGWYxMV/bYvnAUXMjPcN5McvNDLkgwmWzIoE77L5nTNfEYp9KHEX5pfyl/EoxlQkS6Q4gxmEtc4uAgeqV/W52m/rDuirRGxwnj4sJe6LQT1KV5Mdlfm7jLlij5hR2o2Im0d9eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7zEMW9UgJK93lNwNW9JKB5r7UoxMjAoiQ+jeUD0DeQ=; b=Tn8pro4o/1BUDEevHGQ0fj8QM6M0B9lIdE3sRZ7Duc4qilbdqxUiyNWG46LZkLpRyD82Tofrj3bnFcjNMTostpE0NaT7v0zp+0CtJybZoosEt2wD99VAgrRF1CS6T+AoxJZ0RKU9OQH4e8FV+0PGDRXAwM34q/DUbcrXZ2V/jbo5BUHJVDie8kYX33fejY3np1kKLITf9Gwocr3QYXO6t+xqbnhfIRtKqRY0eFJZ5Xza6vuzeanqyrzwT4bc/IEGQCFic/4oXG7O+pmh1TxoeKIkjM2lt4scvtN9F4uL4jGynrkp65B7nxP439v9/mP1jEETgPdhP0Hqrg9hAzwPiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7zEMW9UgJK93lNwNW9JKB5r7UoxMjAoiQ+jeUD0DeQ=; b=h7mS9WtTbMDOOYg2L799HdBoJmiUG8C1oy5ROwI7FqyWjXUeskN20THkmo86zbxbJl4EkpiIVKMCeZUdwOfxMCDQKOnZ0jCN5AbccvkC+OXyWHxP5hIIpQdonEOkTl6y0uTHefytXcNhwljm333BErBflCw+H/riTgKLgKHhkGI= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB4882.namprd11.prod.outlook.com (2603:10b6:303:97::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Sat, 7 Nov 2020 15:34:19 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%6]) with mapi id 15.20.3499.032; Sat, 7 Nov 2020 15:34:19 +0000 From: "Ketan Talaulikar (ketant)" To: "Stone, Andrew (Nokia - CA/Ottawa)" , "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAXo/ICAAubDQA== Date: Sat, 7 Nov 2020 15:34:19 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <9C721BE5-F5FD-49DD-BC3E-4119E9105E7E@nokia.com> In-Reply-To: <9C721BE5-F5FD-49DD-BC3E-4119E9105E7E@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [1.39.169.255] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 133c7da0-5e0f-4cdb-061e-08d883329800 x-ms-traffictypediagnostic: CO1PR11MB4882: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5FXI1D7qb4wM3o4syIc6T+675FR5KncAfz5tqb5aM8y/S0t0+Aimq1CJ8wMsv9AlP5qE9VpFvyAYuhmBUaJijVN4iGq8Kb7hu9KwDMlPUZN9FZuIblrCI67WYR68ul/VAzN14/0MTfSr4Un4pvOMD+vXtdIpa2rY3Ep9jy4258NeJ6M8xvsGlklEh2+Js0jcmhg9iiBi02RFuLnn//jSOFkvte0meA8kzbSYtE0O1KKnFY1oKFZMhSfmt2Cr1BESRFqxOjwXx57uRAKLny5Zituh+6X2SkYhOd1YNykpMIsyBuqzrlZCDkr3v2d8HM3z/55s25P9/Wg0mj0dWhgAW1Udd6B30ZJ4swsllhhIq/UxoMtfShoDBGq6tg3a0gT3rRSATwUTVef01nP2MMOAIA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(39860400002)(136003)(366004)(6506007)(9686003)(966005)(2906002)(55016002)(8936002)(478600001)(64756008)(76116006)(7696005)(71200400001)(26005)(86362001)(53546011)(316002)(5660300002)(66574015)(66476007)(52536014)(110136005)(66446008)(8676002)(66946007)(296002)(186003)(33656002)(66556008)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ndp7qTMQoXLoH2EOxhwfcMLBtYCkaGEA4BJ2sMaXU6mD04uaiwHuGVXC1jmHHRnXSs5qYD6KMpZ3h9pqDbhZy246z2XWi8OmeO0skKb497nOQdbZcLrLepMMq/nVftodWphcgvOnkJqjc5QDZcF3tZ9u5IbZFyTgg1QJyuidJJkWbpY3rNrpzFV0/XsU03T0mOMEu+E+wTwiLSx7TpQagKgjgd61U6jBvGcNhSl66gkUf8prPqgmFwRttkzAEodZjRnJE3cT0ZilZuLGI/4RXjUwSfJhhJDbW72CmAbeQhWIgFft2lVbq2MiVZigxsFPuTX64A4oQM6/vELAXqtfj+uFhZkRU/XYm/rO/ldpbbfDOQ3hYIyNBsRXaPsdxrNswZTFRg2LZRF89Ky/DAuhf81nEy4lmcUt/95iyYxKn6dvRk5XOBNZc76P+XNC1GrQA+npt13ADwsNiEmoSBtqF/TepziAN4qdAxRuJaUlfuCLsiIRGicvL35dZdvQuGmZ5CpsqfVEGxFQvZ0SxMfspH/yMU1plH2IKWMpCWDUI3OsL/lLXwXbn+kQuYuLklSSKJ/1zRXWiKK5wnxIQMTxi+wgM+Yih+8ydy8+Jh5TgA3QibNHmqebcQv3qc/ybE+MGkTPXnoJG/oyX7rpWkCHwg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 133c7da0-5e0f-4cdb-061e-08d883329800 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2020 15:34:19.3492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kz7tP4LawiQb8b4GifuuhefVQgti9JnVpmM5qOMusjtcM3XIUd9IgEa/XfMMDrGpN0KnfMyEVHwfdwzhX26I/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4882 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 15:34:25 -0000 SGkgQW5kcmV3LA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIGl0IHdhcyBpbmRlZWQg dGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgc29sdXRpb24gZm9yIHRoZSB1c2UtY2FzZSBicm91Z2h0 IGZvcndhcmQuDQoNClRoYW5rcywNCktldGFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkgPGFuZHJldy5zdG9uZUBu b2tpYS5jb20+IA0KU2VudDogMDYgTm92ZW1iZXIgMjAyMCAwMDo0NQ0KVG86IEtldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb20+OyBzcHJpbmdAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctcG9saWN5LTA5LnR4dA0KDQpIaSBLZXRhbiwNCg0KVGhhbmtzIGZvciB0aGlzIHVwZGF0 ZSAvIHJlZmVyZW5jaW5nIHRoZSB5YW5nIHJlbGF0ZWQgcXVlc3Rpb24gSSBoYWQgYWJvdXQgbXVs dGlwbGUgb2JqZWN0aXZlL2NvbnN0cmFpbnRzICgxKS4gUmVnYXJkaW5nIGNvbXBvc2l0ZSBjYW5k aWRhdGUgcGF0aCwgcXVpY2tseSB0aGlua2luZyBhYm91dCBpdCBmcm9tIGEgY29udHJvbGxlci9w Y2UgcG9pbnQgb2YgdmlldywgaXQgZG9lcyBzZWVtIGxpa2UgYW4gZWxlZ2FudCBzb2x1dGlvbiB0 byByZS11c2UgdGhlIGVudGlyZSBTUiBQb2xpY3kgY29uc3RydWN0IGluIGEgbmVzdGVkIG1hbm5l ciB0byBhY2hpZXZlIGNvbWJpbmF0aW9uIG9mIFRFIGNvbnN0cmFpbnQvb2JqZWN0aXZlIHBhdHRl cm5zLCBhdm9pZGluZyBhIGxvdCBvZiBjb21wbGV4aXR5IGluIHlhbmcvcHJvdG9jb2wgbW9kZWxs aW5nIGF0IHRoZSBjb3N0IG9mIG1vcmUgU1IgUG9saWN5IGhlYWRlbmQvY29udHJvbGxlciBzdGF0 ZSB0byBtYW5hZ2UvZGVhbC93b3JrIHdpdGguIEkgdGhpbmsgaXQgd2FzIGEgZ29vZCBpZGVhIHRv IGhhdmUgdGhhdCByZXN0cmljdGlvbiBvZiBhIGRlcHRoIG9mIG9uZS4gTm8gb3RoZXIgY29tbWVu dHMgb3IgZmVlZGJhY2sgeWV0LCB3aWxsIGxldCB0aGlzIHN0ZXcgYSBiaXQuDQoNClRoYW5rcyBh Z2FpbiwNCkFuZHJldw0KDQoNCu+7v09uIDIwMjAtMTEtMDEsIDg6MDIgUE0sICJzcHJpbmcgb24g YmVoYWxmIG9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkiIDxzcHJpbmctYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2Yga2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCg0KICAgIEhlbGxvIEFsbCwNCg0KICAgIFdlIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRl IGZvciB0aGUgZHJhZnQgYW5kIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBvZiBjaGFuZ2VzOg0K DQogICAgMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlkYXRlIFBhdGggY29u c3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6IGh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2ZFcUU1VE93ZGgydkV5 Rm1fTUVqaVh5UDJ3cy8gYW5kIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv c3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS8pDQogICAgMikgQmFzZWQgb24gb2Zm bGluZSBmZWVkYmFjayByZWNlaXZlZCwgdXBkYXRlZCBTUnY2IHNlZ21lbnQgdHlwZXMgdG8gaW5j bHVkZSBvcHRpb25hbCBTUnY2IFNJRCBhbmQgYmVoYXZpb3IgaW5zdGVhZCBvZiB0aGUgbmV3IHR5 cGUgdGhhdCB3YXMgaW50cm9kdWNlZCBmb3IgaXQgaW4gdGhlIHYwOC4NCiAgICAzKSBDbGFyaWZp Y2F0aW9uIG9mIGhhbmRsaW5nIG9mIGNvbG9ycyBhbmQgQkdQIG11bHRpLXBhdGggc2NlbmFyaW9z IGJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQuDQogICAgNCkgQ2xhcmlmaWNhdGlv biBvbiBjb25zaWRlcmF0aW9ucyBmb3IgVEktTEZBIGZvciBTUiBQb2xpY3kgYXMgZGlzY3Vzc2Vk IGluIHRoZSBXRyAoUmVmIDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9z cHJpbmcvRVYxeXRVc2Q1WmdrTUhETjBJdkZodzlpZDQwLykNCg0KICAgIFBsZWFzZSBsZXQga25v dyB5b3VyIGNvbW1lbnRzL2ZlZWRiYWNrLg0KDQogICAgVGhhbmtzLA0KICAgIEtldGFuIChvbiBi ZWhhbGYgb2YgY28tYXV0aG9ycykNCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog ICAgRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgIFNlbnQ6IDAyIE5vdmVtYmVyIDIwMjAgMDY6MjcN CiAgICBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQogICAgQ2M6IHNwcmluZ0BpZXRmLm9yZw0K ICAgIFN1YmplY3Q6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCg0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N CiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTb3VyY2UgUGFja2V0IFJvdXRp bmcgaW4gTmV0d29ya2luZyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICAgICAgVGl0bGUgICAg ICAgICAgIDogU2VnbWVudCBSb3V0aW5nIFBvbGljeSBBcmNoaXRlY3R1cmUNCiAgICAgICAgICAg IEF1dGhvcnMgICAgICAgICA6IENsYXJlbmNlIEZpbHNmaWxzDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBLZXRhbiBUYWxhdWxpa2FyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBEYW5pZWwgVm95ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFsZXggQm9nZGFu b3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBhdWwgTWF0dGVzDQogICAgCUZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDku dHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDM3DQogICAgCURhdGUgICAgICAgICAgICA6IDIw MjAtMTEtMDENCg0KICAgIEFic3RyYWN0Og0KICAgICAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFs bG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93DQogICAgICAgYWxvbmcg YW55IHBhdGguICBJbnRlcm1lZGlhdGUgcGVyLWZsb3cgc3RhdGVzIGFyZSBlbGltaW5hdGVkIHRo YW5rcw0KICAgICAgIHRvIHNvdXJjZSByb3V0aW5nLiAgVGhlIGhlYWRlbmQgbm9kZSBzdGVlcnMg YSBmbG93IGludG8gYW4gU1IgUG9saWN5Lg0KICAgICAgIFRoZSBoZWFkZXIgb2YgYSBwYWNrZXQg c3RlZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVudGVkIHdpdGggYW4NCiAgICAgICBvcmRl cmVkIGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiAgVGhp cw0KICAgICAgIGRvY3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNSIFBvbGljeSBhbmQg c3RlZXJpbmcgaW50byBhbiBTUg0KICAgICAgIFBvbGljeS4NCg0KDQogICAgVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS8NCg0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOQ0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOQ0KDQog ICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA5DQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoN CiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg IHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICBzcHJpbmdAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzcHJpbmcgbWFpbGluZyBsaXN0 DQogICAgc3ByaW5nQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCg0K From nobody Mon Nov 9 05:57:40 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8763A10EC; Mon, 9 Nov 2020 05:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bt/LC9Az; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NWFtXGwg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAbiXJhTF1Sb; Mon, 9 Nov 2020 05:57:35 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E2A3A10E2; Mon, 9 Nov 2020 05:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9065; q=dns/txt; s=iport; t=1604930254; x=1606139854; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KqSOIVRONpdAKzcYg93A0RaVOoPbptqPF0+Z0sKdqIY=; b=bt/LC9AzgPspGku5quU9Ml9KKvwVkcNea9DMM/OGIX1Vlz47BU2+mQQ+ mK3lGZF/lg6dwtop0DXPKw4s/LiOfvklXud//drOYafVZlc/YSIwrTX+L q92B9nkP5QbTTOVXx0avfGGMAPBxKV0rkbG3jMkxSPkfM1LtNPwabRVoK A=; X-IPAS-Result: =?us-ascii?q?A0ByCQBwSKlffYENJK1ig3svUXtZLy4KhDODSQONLiaUE?= =?us-ascii?q?oRvgUKBEQNUCwEBAQ0BASMKAgQBAYRKAheBewIlOBMCAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBBQBAYY8DIVyAQEBBBILBh0BATgPAgEIEAEDAQIrAgICMB0IAgQBE?= =?us-ascii?q?iKDBAGBflcDLgEOojsCgTuIaHaBMoMEAQEFgTcCg1kYghADBoE4gnOCZU5Ch?= =?us-ascii?q?lcbgUE/gREnDBCCTz6BVIEJAQECAYEnARIBQQ2CajOCLJNlhxydKQqCbYkNk?= =?us-ascii?q?gADH4MYihKURpNOinmRG4QyAgQCBAUCDgEBBYFrIWlwcBVlAYI+UBcCDY5Wg?= =?us-ascii?q?zqFFIVEdAI2AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A9qd7HBA55xWSmGaKT0FbUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw30A3FWIzB4LRFhvbY9af6Vj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7ep3So5ngTFw?= =?us-ascii?q?nxcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="599500600" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 13:57:33 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9DvX20015166 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 13:57:33 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 07:57:33 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 07:57:32 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 07:57:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WovMDMKV5eQIb4GoIg8KbNRHWmhB9d+qbQGMzfZWLex2zSCbKbfIZJ6OVp1dUaGzxE5JQffjw3r6bBgllvHj1C+24GJ3ldmv0mYyi4aA+7nlYMLjigbBBhHT3+T9cELbTVHSfLYO2N9Wm3jK5Wd4OfCMNu+mgMvvxH2LcxMxy6ZOuwfizSm4GaInXHRol8MfW+UNCNC9pAlAvIe5w3IGqzUV2EL0jcNUyIip8JEqawufK9hvPr7F+wdwHKGGoo1xNhFwNmkiB/4cKa1uQ8zaqfRVfxYphPk0/wu0B3RhcJGnu4HaEsNYHZu08GzUNSgKOJ+3M+2kRQCpLtwZzAaEew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqSOIVRONpdAKzcYg93A0RaVOoPbptqPF0+Z0sKdqIY=; b=Gh7MYEK0EHPjkNwHjWznfp8L6O9PReTRupGNfCfNmBzFki0RiYgEaumVPduQmSkWHkGuD72XzBi/vtrfa6wXw97pDD67eb3sbCdMWMbZ/0JHFeG2nwHgmGpHK+Li0xPzOxAFrCZHJ/dLPLIRDH18O3z93V4FcwmZluIYdCIhFbP6V2CaKgd+lqOhuJNibGnqRy9BR9wHW+h+z8OpdVCouExdPNvI+Y3eCffbC4XpvdoePwu0crWCr59vIki92Wu/EQ8YTduBD42uCRHN31QV7rj9GldGPT+x07XSIkZ8SlNWL0h2g4UbS/bztXNjuadRCEEPc+LhfnzLXXsluVXXSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqSOIVRONpdAKzcYg93A0RaVOoPbptqPF0+Z0sKdqIY=; b=NWFtXGwgmXFKvmV0YdFyT0gVwQAdM65BXLEPcyxZAw94GXb0mVkf6qui1XUzSNwkkh5WZ+7vAiERDUp7/L4eTKCZeZPNC49X3p6WFI063qixRWNxiuuTMNbA6acg5qA+AZLmAXH1mu1QGBRD6hfnnaTxCNhNYofqeuTCZiO0yVo= Received: from DM5PR11MB0043.namprd11.prod.outlook.com (2603:10b6:4:69::17) by DM5PR11MB1644.namprd11.prod.outlook.com (2603:10b6:4:c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Mon, 9 Nov 2020 13:57:32 +0000 Received: from DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31]) by DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31%7]) with mapi id 15.20.3541.025; Mon, 9 Nov 2020 13:57:31 +0000 From: "Richard Vallee (rvallee)" To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" , "spring@ietf.org" , "spring@ietf.org" , IPPM Chairs Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KmxuS4AgA3VsAA= Date: Mon, 9 Nov 2020 13:57:31 +0000 Message-ID: <3F41FF05-C570-4E4E-8520-4FAB358390B1@cisco.com> References: <1CC38E78-DDE2-450C-B9FF-DB1EDEF230B5@cisco.com> In-Reply-To: <1CC38E78-DDE2-450C-B9FF-DB1EDEF230B5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [74.14.193.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1624c91c-3bb6-499e-cc14-08d884b76744 x-ms-traffictypediagnostic: DM5PR11MB1644: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 42nWmBX7LcFZYKaRu2vY4XSqVBreDUhe2e7NfMnE/esg51KFaqkVIoB+OTtUi5kS6iYborOJz/KnKUkXre0QzyCH/6B6cZ1N9kLI7iJzRzy8gol/6K2keiId27hSN4fcSgaZIUyAzNO3DvxRsNwdFkGOj/lwJF0c0eJZ/y1d0PqCDehzJ5CYSGtlcCGSe6Ay9iTj5WtIr84FRv/bw2k6ISrJtQDgg9l6JhfJjYtUu3Ja1nQ3sXqWNAIJVNUkSI9ZU6ikgAjElBymqSP0c0hKB2j3MMt4z6C4xHilC3BxdL7gzH8U98jfgGgk9H6jHy/AMw8Jo7g68QR4R8kshfjG/mEAZqv8+/nOVa22tpIyQycx6HMiOuYXKXm2kJ1yYzQU/Tg68lgGN/BJuz1QdTQqbg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB0043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(136003)(376002)(39860400002)(5660300002)(478600001)(966005)(8936002)(2906002)(83380400001)(36756003)(2616005)(6506007)(53546011)(166002)(6512007)(71200400001)(66556008)(66446008)(66476007)(33656002)(316002)(110136005)(64756008)(186003)(91956017)(26005)(6486002)(8676002)(86362001)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 05cZlz+mYeDx7zf5qEQaottXx8p0CTlvM4JqIRn8egsmNW1Wq/HCQeccPV0CEn5CgCNgTXOzRBemQsJPdp4VXmtdKERrhOdBNZle34Hy2B/LCNZ+PTOFshNnxa4KOc6vV4NczEQ1UReQGjOC75o2ZgLbCvTUSGO0R5QBBEc8icMeH79fBerPVRYfnLIIVlVARaa1zrPF0cZ8HKm1TMIE2XUAD+HWks2VEsBQn7XdOHLc8Wmf+mHAsPBGLbLe02MZiSl9Un3G3VGHzo8KHUo8TvGBWsH1iI4NFe7uvTV//466C0XOuL2Snov8UoSUs06mNSIrbWHUwTYMlAQxYhZV9Oeh62/QtcqbMZ7Dn7IDs2ISn5+lqaywItoYDhyN28EbJyl8dj0gOO0EzA1FblzpL6KI8DlKYe/mEwO9Ms67eHeM2K9rfHayeaJn3hlIxhi4Brx0sPI5uZ/cw59f7alFAAgiEi0F1utRY3L6ORdlWF0CCPW3iT1u5bkQp+sZHYVl8yiIMQuh2TVvIEpXi1v31eNrUNuktQTz3J+eWd127+f0ig19VijuT+au6mMkjZgOFIWyi8sSJg7Bwu9bG/vIaCaSZ2i4Mo8AUDm9J+4a5GlgNbuZj1PwVfZuMS7uaefz0UJfILwGi34+tMQm60jINg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3F41FF05C5704E4E85204FAB358390B1ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB0043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1624c91c-3bb6-499e-cc14-08d884b76744 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 13:57:31.8499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5Po0hHn46WRD6olvHRnpvsbxGP8DXxMaZ0pos9Nf9Gg2i8OaTbuMS0MB+rNhytqKEVYOd7EAqSLrZyErg0Iorg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1644 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 13:57:38 -0000 --_000_3F41FF05C5704E4E85204FAB358390B1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlc2UgZG9jdW1lbnRzDQoNClRoYW5rcw0KUmlj aGFyZA0KDQpGcm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBU b21teSBQYXVseSA8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJp ZGF5LCBPY3RvYmVyIDMwLCAyMDIwIGF0IDI6MzUgUE0NClRvOiAiSUVURiBJUFBNIFdHIChpcHBt QGlldGYub3JnKSIgPGlwcG1AaWV0Zi5vcmc+DQpDYzogSVBQTSBDaGFpcnMgPGlwcG0tY2hhaXJz QGlldGYub3JnPiwgInNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYu b3JnPg0KU3ViamVjdDogW2lwcG1dIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1nYW5kaGktaXBw bS10d2FtcC1zcnBtIGFuZCBkcmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtDQoNCkhlbGxvIElQ UE0sDQoNCkZvciB0aGUgcGFzdCBmZXcgbWVldGluZ3MsIHdl4oCZdmUgaGFkIHVwZGF0ZXMgb24g dGhlIHdvcmsgaW4gdGhlIFNQUklORyBXRyB0aGF0IHdhcyB1c2luZyBTVEFNUCBhbmQgVFdBTVAu IFNpbmNlIHRob3NlIGRvY3VtZW50cyBlbmRlZCB1cCBtYWtpbmcgZXh0ZW5zaW9ucyB0byB0aGUg YmFzZSBwcm90b2NvbHMsIHRoZSBjaGFpcnMgb2YgU1BSSU5HIGFuZCBJUFBNIGRlY2lkZWQgdGhh dCBpdCB3b3VsZCBiZSBiZXN0IHRvIHNwbGl0IHRoZSBkb2N1bWVudHMgYW5kIHRyYWNrIHRoZSBJ UFBNIGV4dGVuc2lvbiB3b3JrIGluIHRoZSBJUFBNIFdHLg0KDQpBcyBzdWNoLCB3ZSBhcmUgc3Rh cnRpbmcgYSBXb3JraW5nIEdyb3VwIGNhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC1nYW5kaGkt aXBwbS10d2FtcC1zcnBtIGFuZCBkcmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtLg0KDQpUaGUg ZG9jdW1lbnRzIGFyZSBoZXJlOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2FuZGhpLWlwcG0tc3RhbXAtc3JwbS0wMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWdhbmRoaS1pcHBtLXR3YW1wLXNycG0tMDANCg0KVGhlIHJlbGF0ZWQgU1BSSU5HIGRvY3Vt ZW50cyBhcmUgaGVyZToNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctc3RhbXAtc3JwbS0wMw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMQ0KDQpQbGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRi YWNrIG9uIHRoZXNlIGRvY3VtZW50cywgYW5kIHN0YXRlIHdoZXRoZXIgb3Igbm90IHlvdSBiZWxp ZXZlIHRoZSBJUFBNIFdHIHNob3VsZCBhZG9wdCB0aGlzIHdvcmsgYnkgcmVwbHlpbmcgdG8gdGhp cyBlbWFpbC4gUGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFjayBieSB0aGUgc3RhcnQgb2YgdGhl IElFVEYgMTA5IG1lZXRpbmcgd2Vlaywgb24gTW9uZGF5LCBOb3ZlbWJlciAxNi4NCg0KQmVzdCwN ClRvbW15ICYgSWFuDQo= --_000_3F41FF05C5704E4E85204FAB358390B1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6227B7B96F8F4446BA84479344F5C487@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJIHN1 cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZXNlIGRvY3VtZW50czxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJpY2hhcmQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmlwcG0gJmx0O2lwcG0t Ym91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5ICZsdDt0cGF1bHk9 NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwg T2N0b2JlciAzMCwgMjAyMCBhdCAyOjM1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtJRVRGIElQ UE0gV0cgKGlwcG1AaWV0Zi5vcmcpJnF1b3Q7ICZsdDtpcHBtQGlldGYub3JnJmd0Ozxicj4NCjxi PkNjOiA8L2I+SVBQTSBDaGFpcnMgJmx0O2lwcG0tY2hhaXJzQGlldGYub3JnJmd0OywgJnF1b3Q7 c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W2lwcG1dIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1n YW5kaGktaXBwbS10d2FtcC1zcnBtIGFuZCBkcmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IZWxsbyBJUFBNLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Gb3IgdGhlIHBhc3QgZmV3IG1lZXRpbmdzLCB3ZeKAmXZlIGhhZCB1cGRhdGVz IG9uIHRoZSB3b3JrIGluIHRoZSBTUFJJTkcgV0cgdGhhdCB3YXMgdXNpbmcgU1RBTVAgYW5kIFRX QU1QLiBTaW5jZSB0aG9zZSBkb2N1bWVudHMgZW5kZWQgdXAgbWFraW5nIGV4dGVuc2lvbnMgdG8g dGhlIGJhc2UgcHJvdG9jb2xzLCB0aGUgY2hhaXJzIG9mIFNQUklORyBhbmQgSVBQTSBkZWNpZGVk IHRoYXQgaXQgd291bGQgYmUgYmVzdA0KIHRvIHNwbGl0IHRoZSBkb2N1bWVudHMgYW5kIHRyYWNr IHRoZSBJUFBNIGV4dGVuc2lvbiB3b3JrIGluIHRoZSBJUFBNIFdHLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBzdWNoLCB3ZSBhcmUgc3Rh cnRpbmcgYSBXb3JraW5nIEdyb3VwIGNhbGwgZm9yIGFkb3B0aW9uIGZvciZuYnNwO2RyYWZ0LWdh bmRoaS1pcHBtLXR3YW1wLXNycG0gYW5kIGRyYWZ0LWdhbmRoaS1pcHBtLXN0YW1wLXNycG0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90OyI+VGhlIGRvY3VtZW50cyBhcmUgaGVyZTo8YnI+DQo8YnI+DQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0tc3RhbXAtc3Jw bS0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXN0YW1w LXNycG0tMDA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0tdHdhbXAtc3JwbS0wMDwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OyI+PGJyPg0KVGhlIHJlbGF0ZWQgU1BSSU5HIGRvY3VtZW50cyBhcmUgaGVyZTo8YnI+DQo8 YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNw cmluZy1zdGFtcC1zcnBtLTAzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2Fu ZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEx Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1z cnBtLTExPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRiYWNrIG9uIHRo ZXNlIGRvY3VtZW50cywgYW5kIHN0YXRlIHdoZXRoZXIgb3Igbm90IHlvdSBiZWxpZXZlIHRoZSBJ UFBNIFdHIHNob3VsZCBhZG9wdCB0aGlzIHdvcmsgYnkgcmVwbHlpbmcgdG8gdGhpcyBlbWFpbC4g UGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFjayBieSB0aGUgc3RhcnQgb2YgdGhlIElFVEYgMTA5 IG1lZXRpbmcgd2Vlaywgb24NCjxiPk1vbmRheSwgTm92ZW1iZXIgMTY8L2I+LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9tbXkgJmFtcDsg SWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3F41FF05C5704E4E85204FAB358390B1ciscocom_-- From nobody Mon Nov 9 06:00:17 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFFB3A10E2; Mon, 9 Nov 2020 06:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=dOMIwbXS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yWe92z8X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9wzPmF11DpJ; Mon, 9 Nov 2020 05:59:52 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422EF3A1105; Mon, 9 Nov 2020 05:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24567; q=dns/txt; s=iport; t=1604930392; x=1606139992; h=from:to:subject:date:message-id:mime-version; bh=fhjyIEnVY8xJRTqMc5+Lc7X8dNCgfN4orNEi4j20fxk=; b=dOMIwbXSXACuWU+4hCM306zEX5LDoRClpR2nw26wdNPVGI2QBR5VemCJ ySTSFCYHIZE+MqR32P/DlntARKOU6A08qm9qTWJ7JtG2RmPxPZ/9tHKhi hzamgvQ5bXcTr1Qrj5sFa5Io0xMj/S/Gc/9PBd93/aeZTFOwzIxo4MCum M=; X-IPAS-Result: =?us-ascii?q?A0BnCQAHS6lffYgNJK1ig3svUXtZLy4KhDODSQONLyaZA?= =?us-ascii?q?YFCgREDVAsBAQENAQEjCgIEAQGESgIXgXsCJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAyFcgEGEgsGHQEBLAwRAQgRAwECKwIEMB0KBAESIoMEAYF+V?= =?us-ascii?q?wMuAQ6iRQKBO4hodoEygwQBAQWBNwKDVxiCEAMGgTiCc4N1hlcbgUE/gREnD?= =?us-ascii?q?BCCTz6CXQEBA4EiIDoNgmozgiyTZYcci1g1kRwKgm2JDZIAAxYJggaBEooSi?= =?us-ascii?q?FyLaoYdjTGKeZVNAgQCBAUCDgEBBYFrIYFZcBU7KgGCPlAXAg2OVhiDIoUUh?= =?us-ascii?q?UR0AjYCBgoBAQMJfIw7AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AnEAKfRzU5AFUaQrXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaFt/twkELTUJrW6rRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFtviekffvXCzqzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="603182296" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 13:59:51 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9DxpC7030122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 13:59:51 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 07:59:50 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 08:59:49 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 07:59:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=efx0JIiOlaWauN9+DStW8vPsj70mdl1HozFBq1JI7Yi4m85MsbUxLAig8OyO+KOmY1m962Dkn4pinn/RpKYPfX+Y6mCBu1SPVjk1kdvdeCiRKHPlq8rCkyZt5bNwNuKHrylM5ofbcW6ksbeP6O4U7agMF6cxyQq4uVs/MBRZenXDoNKz0JHhXDpREQPucpuBmow5Q278sjIZPz7io7li6x+8JzHxMSz4443LlLmgRqT4xisaH/gtaXbf/+RP3WiQtsZaEiGWDSTBR6x5KZ7/8V92OvuYzhyOmHNq8ldqqqMppFSvO7iWVG5p+6312g2D9rHGMwL2xAAJy+nPlY5XBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fhjyIEnVY8xJRTqMc5+Lc7X8dNCgfN4orNEi4j20fxk=; b=EgotWxgFk2EJJMe/9PIPJrDpVemHcTRnYy0lMnwePxzxeKpoFGbUrqA0Y6Nrl9pKhibF5SUToEHigAml0WBqpdR4ulwHE8UnzEZlnAFiZkwmlIYoG0LEl2K15HZhkTLyYSkxI97mZlpCbF/yap0iXzAx6uSjISjBAWE9fAJJLJv2DntovzOEc0wQZr+Fy2MPBf+EeG2GaKRcswAtj4ybm+1iC1R3iye70G7h56V1SIHkui41y14+Pf8MGW7akPPV8nqXRaOSyifRfeNb6xAiXWCC6vcrhrfFA35n/vJxHuTS4HM3iil+44EO7Rfaw5epgD7arWYx745iLqY9VOX+8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fhjyIEnVY8xJRTqMc5+Lc7X8dNCgfN4orNEi4j20fxk=; b=yWe92z8XcijjxqZ3Dx6Wi/93bKu0vPvWhRUGdU4CjYj1JSyvP5zMN5P8mZw4KVW2afgDqR4IPXvlFweKVghcwpYmz3dTfMpcrXnP16f7BcIQfxBfEl86jt4PuBkzp+1IL1jG4NBuxnsMjhSRv3hWfIw+W4Mq/moKRoqetoNixYk= Received: from DM5PR11MB0043.namprd11.prod.outlook.com (2603:10b6:4:69::17) by DM5PR1101MB2218.namprd11.prod.outlook.com (2603:10b6:4:4f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Mon, 9 Nov 2020 13:59:48 +0000 Received: from DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31]) by DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31%7]) with mapi id 15.20.3541.025; Mon, 9 Nov 2020 13:59:48 +0000 From: "Richard Vallee (rvallee)" To: James Guichard , "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AQHWtqCVy5Xm6DrcY0O7zd4IbtvpYw== Date: Mon, 9 Nov 2020 13:59:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [74.14.193.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08d27281-ca5f-48d8-9e7e-08d884b7b890 x-ms-traffictypediagnostic: DM5PR1101MB2218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pg8ogx2949iZMAKRJKFAHdYkiPoX2EpeBiwNi8qrt27M/PUOiVn7ltVcptzzSs8epgLO97pvKAtBRD8hg/iC/QtpTv8V2OfDcOz7Flb7zUyJJ6p8Y9R3JtWxnoqD2w2IEJHAMGCQjRFSTVSXxx3H0Xfwx3vCcLwIdHXxQAklgBFJmwYk240rWd4UY8UPS9vriO2cAg2NdGRAtzfs8mNS3swooOp2TKqmtmbQaRo4aUlWnIeyCZVC4yUayLt7fe6zxCijNuR+YYdE1yH9DpDSxvys9MwcY//iTfue+jVlPJKSTZ/Ot71jdJEPeSY4b5CbPi3FlWYQ2JLjxMriGnVkkS+VSaujxddSjyuyRLcG9KUKVvULIzLgQX9kRF/5q+/KfkL5mwlQBhO8ePgqin/vkw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB0043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(39860400002)(136003)(366004)(346002)(53546011)(2906002)(478600001)(86362001)(166002)(8676002)(66446008)(64756008)(2616005)(76116006)(91956017)(6506007)(8936002)(66946007)(36756003)(186003)(6486002)(33656002)(66476007)(66556008)(316002)(5660300002)(83380400001)(966005)(26005)(71200400001)(6512007)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bVyXeQEOFYnameRWe/k0RXBvkWG39Wh8hRU9g4mrr6ZO6RYaDvdnN5Mkl5Ro3+O+lJyAXsJpmHz0iu7mKD6DbsK97pYbEN7py4IfGwG99zoEl+qCP4tCKdW5MBVRcR4Cw1xoaJoMvLbwxtlTa2Ei3s5+nIAq0pRpZXIMo2S7FU9JyxF9wWFokhlOPYm6FCmxWxMg9JO3PiWWPEdM9I4C7vxzRc4BykPtFVLWi7g1JxPE/ttdFdH9k/PTQfGHwZ49ZOqjuHutBpder1Njf+LXP0PjohooyvMCntubdjpwPck/SCakPpfQXvZNMYWmh1G3SetOjDZEv/L6lhX0PXfipKYPeIXWaozDQTqG5hydV+/I3/e/W/mw6AYf+qhFr544hZQ90gJHtp/UQ+DQIvA8uDm2Wcmy37taYRHO1WGBQ/4gbedRbqSfSXdFHPJGuMvGIiu4bQhNJTdxVtSfgwzH2yWYynbyyriePDJtLwhkcF158zGwcVq8nvd+K/5x3a9eX0m6BnDx6QQTqRHwJWa/OyrYeOmwnoWq0dqJyXWQ6uXe2SIu3Wtifmt9C3ElCfTeklxeNP6m7t6uEMu121qxqJjiR05DEcsJ+/Lsz4EQVDIoviZlgXuM+Q4j84rNLS/hkge1vavV95cY6PUukisMtQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E8EE8BAD904846A7B1D40E36617602FDciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB0043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08d27281-ca5f-48d8-9e7e-08d884b7b890 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 13:59:48.1873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: logMyc0lkUQZypCInBBD+CyI5vbmIb4VuPo30w9y9u3PUvXIeeXScHKsA5aamI//MBJUgRDDHfinLpw55NFz2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2218 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 14:00:16 -0000 --_000_E8EE8BAD904846A7B1D40E36617602FDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzDQoNClRoYW5rcw0KUmljaGFyZA0KDQoNCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW1lcyBH dWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTogVGh1cnNkYXks IE9jdG9iZXIgMjIsIDIwMjAgYXQgODo1MSBBTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJp bmdAaWV0Zi5vcmc+DQpDYzogImlwcG0tY2hhaXJzQGlldGYub3JnIiA8aXBwbS1jaGFpcnNAaWV0 Zi5vcmc+LCAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzDQoNCkRlYXIgV0c6 DQoNClRoaXMgbWVzc2FnZSBzdGFydHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0w MywgZW5kaW5nIE5vdmVtYmVyIDEydGggMjAyMC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3Vt ZW50IGhhcyBzZXZlcmFsIGNoYW5nZXMgZnJvbSB2LTAyIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkg dGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBo YXZlIGV4dGVuZGVkIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBhbiBhZGRpdGlvbmFsIHdlZWsgdG8g YWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0aGVzZSBjaGFuZ2VzIGJlZm9yZSBk ZWNpZGluZyBvbiBXRyBhZG9wdGlvbi4NCg0KU29tZSBiYWNrZ3JvdW5kOg0KDQpTZXZlcmFsIHJl dmlldyBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDIu IFRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzIGNvbnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFu ZCB1cG9uIHJldmlldyBvZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVk IHRoZSBmb2xsb3dpbmc6DQoNCg0KICAqICAgVGhlIFNQUklORyBkb2N1bWVudCBzaG91bGQgZGVz Y3JpYmUgb25seSB0aGUgcHJvY2VkdXJlcyByZWxldmFudCB0byBTUFJJTkcgd2l0aCBwb2ludGVy cyB0byBub24tU1BSSU5HIGRvY3VtZW50L3MgdGhhdCBkZWZpbmUgYW55IGV4dGVuc2lvbnMuIFNl dmVyYWwgZXh0ZW5zaW9ucyBpbmNsdWRpbmcgQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lvbiBm b3IgU1RBTVAgTWVzc2FnZXMsIExvc3MgTWVhc3VyZW1lbnQgUXVlcnkgTWVzc2FnZSBFeHRlbnNp b25zLCBMb3NzIE1lYXN1cmVtZW50IFJlc3BvbnNlIE1lc3NhZ2UgRXh0ZW5zaW9ucywgTm9kZSBB ZGRyZXNzIFRMViBFeHRlbnNpb25zLCBhbmQgUmV0dXJuIFBhdGggVExWIEV4dGVuc2lvbnMgd2Vy ZSBpbmNsdWRlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNw cmluZy1zdGFtcC1zcnBtLTAyIGFuZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcg ZG9jdW1lbnQuDQogICogICBUaGUgU1RBTVAgZXh0ZW5zaW9ucyBpbmNsdWRlZCBpbiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIHNo b3VsZCBiZSBkZXNjcmliZWQgaW4gYSBuZXcgZG9jdW1lbnQgcHVibGlzaGVkIGluIHRoZSBJUFBN IFdHLg0KDQpUaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3Jz IG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1w LXNycG0tMDIgdGhlIHJlc3VsdCBvZiB3aGljaCBpcyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZv bGxvd2luZyB0d28gZG9jdW1lbnRzOg0KDQoNCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMuIFRoZSBzdWJqZWN0IG9mIHRo aXMgV0cgYWRvcHRpb24gY2FsbC4NCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtLTAwLiBUaGlzIGRvY3VtZW50IHdpbGwgYmUgcHJv Z3Jlc3NlZCAoaWYgZGV0ZXJtaW5lZCBieSB0aGUgV0cpIHdpdGhpbiB0aGUgSVBQTSBXRy4NCg0K QWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcgZG9jdW1lbnQgcGxlYXNlIGluZGljYXRlIHN1cHBv cnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuIFBsZWFzZSBh bHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBwb3J0IChvciBsYWNrIHRo ZXJlb2YpIGFzIHNpbGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyBjb25zZW50Lg0KDQpG aW5hbGx5LCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRo ZWlyIGVmZm9ydHMgaW4gdGhpcyBtYXR0ZXIuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubywgJiBK b2VsDQo= --_000_E8EE8BAD904846A7B1D40E36617602FDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9B9C64918226F34CAC4E73FA3694E183@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFu b3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0NDA4MzMz NDQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMjU0 MzAzMDQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTgwMTA2Nzc1MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg4ODg2Nzk1Njt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEw OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTkzMzM5 NDczODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODgw MjA5NDMwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlk OjE5NDI3NTgyNDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzMjY2MjYxMDg7fQ0KQGxpc3Qg bDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMzwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWNoYXJkPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAmbHQ7c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwg T2N0b2JlciAyMiwgMjAyMCBhdCA4OjUxIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtzcHJpbmdA aWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O2lwcG0tY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtpcHBtLWNoYWlyc0BpZXRmLm9yZyZn dDssICZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZy1jaGFpcnNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltzcHJpbmddIFdHIEFkb3B0aW9uIENh bGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0 YW1wLXNycG0tMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGVhciBXRzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIHN0 YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzIj4NCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDM8 L2E+LCBlbmRpbmcgTm92ZW1iZXIgMTI8c3VwPnRoPC9zdXA+IDIwMjAuIFBsZWFzZSBub3RlIHRo YXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2ZXJhbCBjaGFuZ2VzIGZyb20gdi0wMiB0aGF0IHdlcmUg cmVxdWVzdGVkIGJ5IHRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzLiBGb3IgdGhpcyByZWFzb24s IHRoZSBjaGFpcnMgaGF2ZSBleHRlbmRlZA0KIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBhbiBhZGRp dGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0aGVzZSBj aGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBvbiBXRyBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U29tZSBiYWNrZ3JvdW5kOiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2V2 ZXJhbCByZXZpZXcgY29tbWVudHMgd2VyZSByZWNlaXZlZCBwcmV2aW91c2x5IGZvciBkb2N1bWVu dA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJp bmctc3RhbXAtc3JwbS0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctc3RhbXAtc3JwbS0wMjwvYT4uIFRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzIGNv bnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFuZCB1cG9uIHJldmlldyBvZiB0aGlzIHZlcnNpb24g b2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVkIHRoZQ0KIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBT UFJJTkcgZG9jdW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZh bnQgdG8gU1BSSU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQg ZGVmaW5lIGFueSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5nPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2s7YmFja2dyb3VuZDp3aGl0ZSI+DQogQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lvbiBmb3Ig U1RBTVAgTWVzc2FnZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8 Yj5Mb3NzIE1lYXN1cmVtZW50IFF1ZXJ5IE1lc3NhZ2UgRXh0ZW5zaW9uczwvYj4sJm5ic3A7PGI+ TG9zcyBNZWFzdXJlbWVudCBSZXNwb25zZSBNZXNzYWdlIEV4dGVuc2lvbnM8L2I+LCZuYnNwOzxi Pk5vZGUgQWRkcmVzcw0KIFRMViBFeHRlbnNpb25zPC9iPiwgYW5kJm5ic3A7PGI+UmV0dXJuIFBh dGggVExWIEV4dGVuc2lvbnM8L2I+PC9zcGFuPiB3ZXJlIGluY2x1ZGVkIGluDQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBt LTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFt cC1zcnBtLTAyPC9hPiBhbmQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgU1BSSU5HIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBTVEFNUCBleHRlbnNp b25zIGluY2x1ZGVkIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyPC9hPiBzaG91bGQgYmUgZGVzY3Jp YmVkIGluIGEgbmV3IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUgSVBQTSBXRy4gJm5ic3A7PG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vz c2VkIHdpdGggdGhlIGF1dGhvcnMgb2YgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyPC9hPiB0aGUgcmVz dWx0IG9mIHdoaWNoIGlzIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZm9sbG93aW5nIHR3byBkb2N1 bWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0Omwy IGxldmVsMSBsZm82Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzPC9hPi4gVGhlIHN1YmplY3Qgb2YgdGhp cyBXRyBhZG9wdGlvbiBjYWxsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzYiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS1zdGFt cC1zcnBtLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0t c3RhbXAtc3JwbS0wMDwvYT4uIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwcm9ncmVzc2VkIChpZiBk ZXRlcm1pbmVkDQogYnkgdGhlIFdHKSB3aXRoaW4gdGhlIElQUE0gV0cuPG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFz ZSBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGlu ZyBsaXN0Lg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5QbGVhc2Ug YWxzbyBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0 aGVyZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2VudC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RmluYWxseSwgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZv ciB0aGVpciBlZmZvcnRzIGluIHRoaXMgbWF0dGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5vLCAmYW1wOyBK b2VsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8EE8BAD904846A7B1D40E36617602FDciscocom_-- From nobody Mon Nov 9 06:01:00 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4023A1106; Mon, 9 Nov 2020 06:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=KSYTIlyQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=H2RRXuGe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nveTrZpE6dcg; Mon, 9 Nov 2020 06:00:56 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF0D3A10FB; Mon, 9 Nov 2020 06:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24673; q=dns/txt; s=iport; t=1604930456; x=1606140056; h=from:to:subject:date:message-id:mime-version; bh=qegHT0EPBoXv9gd0INO0FA+nbDzk0xigUiiSGxkk5Kc=; b=KSYTIlyQK5R9jMpygkuQ9Mt1Q9kcWiejAb7QD+DOD+Jm/CsLI9fu30xv UJzLHgxcJdHlUd1pY+Oi9sN6SY2mC+aAWJE7FojLJ/jQMPvnR7yq3JX1O gNPrGrJX8BOntrcNXwhbJfSUBV+AtG6ZRQ2K37uPriIyShavQc9gdKPtc k=; X-IPAS-Result: =?us-ascii?q?A0BnCQDCSqlffYENJK1ig3svUXtZLy4KhDODSQONLiaZA?= =?us-ascii?q?YFCgREDVAsBAQENAQEjCgIEAQGESgIXgXsCJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAyFcgEGEgsGHQEBLAwRAQgRAwECKwIEMB0KBAESIoMEAYF+V?= =?us-ascii?q?wMuAQ6iQAKBO4hodoEygwQBAQWBNwKDVxiCEAMGgTiCc4N1hlcbgUE/gREnD?= =?us-ascii?q?BCCTz6CXQEBA4EiIDoNgmozgiyTZYcci1g1kRwKgm2JDZIAAx+CBoESihKIX?= =?us-ascii?q?Itqhh2NMYp5lU0CBAIEBQIOAQEFgWshgVlwFTsqAYI+UBcCDY5WGIMihRSFR?= =?us-ascii?q?HQCNgIGCgEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3ACY16ph8SUvha3v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZhaN6+hxkUXEQojarflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtbBdrjfVDNr3z05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="584662071" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 14:00:28 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9E0RvP019286 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 14:00:27 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 08:00:26 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 08:00:26 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 09:00:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBUWqX/c2x5RLb2DVtEKAej52evwwZLnoRT+3KRlI/d54JFhO3ynQXrpYBN6+d80NGgLtDr8sszbnGWEGsLXPF0f42Efw3Zzd90aOJhQwy4dgkQJu2RVPeMVqK2LxUAinHIYdNr6PuJsvlFpCm8F8Q9G3t4WPXBmnYe0ZtWIh0NVRd/lQkmGbAb0bUa5GlCxzPF7J7uz8+9xSQy15NspYU030wFyb4AgmxjPZiKLr8YRo+AM77bAFWbiUZiIJXHP+J/YIrJoQ3QlXo2Z113bmvrRY4IY+IIaGPUmndvjvsUi76XEzjfVC3nXyKh11UD4FMF/57h0E80aBLmfufG/cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qegHT0EPBoXv9gd0INO0FA+nbDzk0xigUiiSGxkk5Kc=; b=a7BaFhX22qGkQHkQbnpNutsTZ1K+IJB0D0hnLBagcTTYZSILcuZBoejRF9ZgFF5CKg7q3r2/4jlmF0dbyczlE5An3bi8NCZsKb1l7ue/pZ2/66L+er4T/zp53UQvOO6M40IrImrOfC3SKXYkveB3AwZ3eWpI+eyvC8WiQV1gUPGcjW4BtXXDiy/z3bJ4wQZNXrpYpiEcaFbgXHM/MNKZ0I9DQgktAu1G4EF9g3xPRHt7ULLBptYraa825nefxBPkvfwSbNCioD5JRzRntlRb65fuUtGNdf65kY2j29tYRNzwyUBQJd670wlQJWhTq7tRLrAZjqJtkkZl7ppXXIFAzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qegHT0EPBoXv9gd0INO0FA+nbDzk0xigUiiSGxkk5Kc=; b=H2RRXuGetLyGuDaoip50WfqN5lqY4S0/aqAcIPftLs55UcrByVFsMVWX2CTLRLdcSKIRe+SZjZRxKwW+bleVy7rPvZlI6gniv49UGvzX8ILEcB3xUPZbYvPS7yKRYB+3GK6fkM8i3GX7zwVRoOSpRSpDSaNUsBoCF3do/pLlHpA= Received: from DM5PR11MB0043.namprd11.prod.outlook.com (2603:10b6:4:69::17) by DM5PR11MB1644.namprd11.prod.outlook.com (2603:10b6:4:c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Mon, 9 Nov 2020 14:00:25 +0000 Received: from DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31]) by DM5PR11MB0043.namprd11.prod.outlook.com ([fe80::d8bb:c0d7:f263:9d31%7]) with mapi id 15.20.3541.025; Mon, 9 Nov 2020 14:00:25 +0000 From: "Richard Vallee (rvallee)" To: James Guichard , "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWtqCrEa7qLxZukE2Fqfu9zGcSDg== Date: Mon, 9 Nov 2020 14:00:25 +0000 Message-ID: <78F83B80-9723-4848-B374-D9816F25E284@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [74.14.193.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d27dc03-3043-44ef-1603-08d884b7ce91 x-ms-traffictypediagnostic: DM5PR11MB1644: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MKd+S9P5VttZ3mY6B7Wlhs38t55MIjsVxkQUFdv+6ZqMDQetDLxw7ZQXG3GimYJm4hDFePPl72Wz6SACeNaYHN6IcMHE34lmiYtmE5/5cUTlyEVC4wnbx3yF2aczad4+HRaSXVJpjVMD9QAiVYtN85HhIzBTVVNYw4VbxoLzRD2rpiWHa3Ine8Pa0POKhB7zoXPHIOMCT4sPJxJorI67paG5epqgILljbmBMjbFxgyJr49/xpYqptgP9tUA5CDlas4A5vXOOWrRC9zTx7cti0eCK9jbReQ5jcuvMHRvU9/k1oTaBs2eRznxSr0RrMmBjjjpHRRy4NN9gYm+LSdIFxjQtP+96oJjQklQbISdl6HA0nn/pHhBReJHCxLXn9QzzZMu3nbvW415Icrgj4lLNlg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB0043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(136003)(376002)(39860400002)(5660300002)(478600001)(966005)(8936002)(2906002)(83380400001)(36756003)(2616005)(6506007)(53546011)(166002)(6512007)(71200400001)(66556008)(66446008)(66476007)(33656002)(316002)(110136005)(64756008)(186003)(91956017)(26005)(6486002)(8676002)(86362001)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZI283+sp6GazbaExDHvVGAsDoNPVD9RZEhGggvmi443+1WnCk5SCEYzizJoRfM+EGNNQVdOYbLCnW58LlBfBwfzWj5kpgNvqtaa17Vj9zNOpCZt14CAHXU6D4RU81LNboj3UKdnz6S8v9Z9O3l45JR1gv9OtAqsbT5TspwaY4XfDMCBzMJkusKnLPS0uSkLyZySYUVqokppxpSrwopaPZimZWZSH0Le7cEWXN64z9bnGiiJPhmLBg2Hle+r9gimpwca38GMSE9v/nPJ3Re6glz3T7RriS7EjLlThD3l+ZxsR+EMrBn7SZyDkEUaqUrhjZF9GuvxtseTAB7xz2dogkrCx289VGORnXWvYXm8UuR4ionrfgMuNcFHsNwnyRiVLiuykKnDKVeZZtlTFtpdlBkcGsjdA5fDR72OAD9vx2ptPFIwOya3aTiv7o4c4j0Vhm9VEn1WWysSYAmLOS9cyNXVLvHxHN5aM3f3wlkaKK8MY4jhSdndOtWjI3JA3otZJ6SucMpVgxEYZ1c4CnSHX1u6ouUm78JPRfiwZZ1SG4FDceOSPVaKm/DBOAdiKlcLJ2YG2N4N17ZUjAwfXvHU8B5RzihydvYwXidh/M2FRli/mCl4B0z20PIcRSnFSM/aeT6fz4kaF8FSXAfg4lmVOQA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_78F83B8097234848B374D9816F25E284ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB0043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d27dc03-3043-44ef-1603-08d884b7ce91 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 14:00:25.1672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eBsf0zHdlN4HO3ema6udAKZWpU3h826GcduM7s+mdlS69IgFlfEKVO6fZVkccOohLrHjWgdUZaCBPF4K0chRvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1644 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 14:00:58 -0000 --_000_78F83B8097234848B374D9816F25E284ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExDQoNClRoYW5rcw0KUmljaGFyZA0KDQoNCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW1lcyBH dWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTogVGh1cnNkYXks IE9jdG9iZXIgMjIsIDIwMjAgYXQgODo1MSBBTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJp bmdAaWV0Zi5vcmc+DQpDYzogImlwcG0tY2hhaXJzQGlldGYub3JnIiA8aXBwbS1jaGFpcnNAaWV0 Zi5vcmc+LCAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExDQoNCkRlYXIgV0c6 DQoNClRoaXMgbWVzc2FnZSBzdGFydHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgZG9j dW1lbnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdh bXAtc3JwbS0xMSBlbmRpbmcgTm92ZW1iZXIgMTJ0aCAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRo aXMgZG9jdW1lbnQgaGFzIHNldmVyYWwgY2hhbmdlcyBmcm9tIHYtMTAgdGhhdCB3ZXJlIHJlcXVl c3RlZCBieSB0aGUgU1BSSU5HIGFuZCBJUFBNIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUg Y2hhaXJzIGhhdmUgZXh0ZW5kZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwg d2VlayB0byBhbGxvdyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMg YmVmb3JlIGRlY2lkaW5nIG9uIFdHIGFkb3B0aW9uLg0KDQpTb21lIGJhY2tncm91bmQ6DQoNClNl dmVyYWwgcmV2aWV3IGNvbW1lbnRzIHdlcmUgcmVjZWl2ZWQgcHJldmlvdXNseSBmb3IgZG9jdW1l bnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAt c3JwbS0xMC4gVGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9zZSBjb21t ZW50cywgYW5kIHVwb24gcmV2aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGRl dGVybWluZWQgdGhlIGZvbGxvd2luZzoNCg0KDQogICogICBUaGUgU1BSSU5HIGRvY3VtZW50IHNo b3VsZCBkZXNjcmliZSBvbmx5IHRoZSBwcm9jZWR1cmVzIHJlbGV2YW50IHRvIFNQUklORyB3aXRo IHBvaW50ZXJzIHRvIG5vbi1TUFJJTkcgZG9jdW1lbnQvcyB0aGF0IGRlZmluZSBhbnkgZXh0ZW5z aW9ucy4gU2V2ZXJhbCBleHRlbnNpb25zIGluY2x1ZGluZyBDb250cm9sIENvZGUgRmllbGQgRXh0 ZW5zaW9uIGZvciBUV0FNUCBMaWdodCBNZXNzYWdlcywgTG9zcyBNZWFzdXJlbWVudCBRdWVyeSBN ZXNzYWdlIEV4dGVuc2lvbnMsIGFuZCBMb3NzIE1lYXN1cmVtZW50IFJlc3BvbnNlIE1lc3NhZ2Ug RXh0ZW5zaW9ucyB3ZXJlIGluY2x1ZGVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAgYW5kIHNob3VsZCBiZSByZW1vdmVkIGZy b20gdGhlIFNQUklORyBkb2N1bWVudC4NCiAgKiAgIFRoZSBUV0FNUCBleHRlbnNpb25zIGluY2x1 ZGVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3 YW1wLXNycG0tMTAgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiBhIG5ldyBkb2N1bWVudCBwdWJsaXNo ZWQgaW4gdGhlIElQUE0gV0cuDQoNClRoZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vzc2VkIHdp dGggdGhlIGF1dGhvcnMgb2YgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5k aGktc3ByaW5nLXR3YW1wLXNycG0tMTAgdGhlIHJlc3VsdCBvZiB3aGljaCBpcyB0aGUgcHVibGlj YXRpb24gb2YgdGhlIGZvbGxvd2luZyB0d28gZG9jdW1lbnRzOg0KDQoNCiAgKiAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEuIFRo ZSBzdWJqZWN0IG9mIHRoaXMgV0cgYWRvcHRpb24gY2FsbC4NCiAgKiAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwLiBUaGlzIGRvY3Vt ZW50IHdpbGwgYmUgcHJvZ3Jlc3NlZCAoaWYgZGV0ZXJtaW5lZCBieSB0aGUgV0cpIHdpdGhpbiB0 aGUgSVBQTSBXRy4NCg0KQWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcgZG9jdW1lbnQgcGxlYXNl IGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWlsaW5n IGxpc3QuIFBsZWFzZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBw b3J0IChvciBsYWNrIHRoZXJlb2YpIGFzIHNpbGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJlZCBh cyBjb25zZW50Lg0KDQpGaW5hbGx5LCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhl IGF1dGhvcnMgZm9yIHRoZWlyIGVmZm9ydHMgaW4gdGhpcyBtYXR0ZXIuDQoNClRoYW5rcyENCg0K SmltLCBCcnVubywgJiBKb2VsDQoNCg0KDQoNCg== --_000_78F83B8097234848B374D9816F25E284ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9A36499493CD354A854BF485C06E6A2E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFu b3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYxODMwNzgx Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM2MjU2MzYwO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNDQwODMzMzQ0Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzI1NDMwMzA0IDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE1MTM3NjEw MTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNDgxMDI2NzQ7fQ0KQGxpc3QgbDI6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE5MzMzOTQ3Mzg7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg4MDIwOTQzMCA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tQ0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTE8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3Vu Y2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgJmx0O2phbWVzLm4u Z3VpY2hhcmRAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE9j dG9iZXIgMjIsIDIwMjAgYXQgODo1MSBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c3ByaW5nQGll dGYub3JnJnF1b3Q7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtpcHBtLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7aXBwbS1jaGFpcnNAaWV0Zi5vcmcmZ3Q7 LCAmcXVvdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmctY2hhaXJzQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxs IGZvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2Ft cC1zcnBtLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRlYXIgV0c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVzc2FnZSBzdGFy dHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgZG9jdW1lbnQgPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMSI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1z cnBtLTExPC9hPiBlbmRpbmcgTm92ZW1iZXIgMTI8c3VwPnRoPC9zdXA+IDIwMjAuIFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2ZXJhbCBjaGFuZ2VzIGZyb20gdi0xMCB0aGF0 IHdlcmUgcmVxdWVzdGVkIGJ5IHRoZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzLiBGb3IgdGhpcyBy ZWFzb24sIHRoZSBjaGFpcnMgaGF2ZSBleHRlbmRlZA0KIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBh biBhZGRpdGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0 aGVzZSBjaGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBvbiBXRyBhZG9wdGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U29tZSBiYWNrZ3JvdW5kOiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2V2ZXJhbCByZXZpZXcgY29tbWVudHMgd2VyZSByZWNlaXZlZCBwcmV2aW91c2x5IGZvciBk b2N1bWVudA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctdHdhbXAtc3JwbS0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMDwvYT4uIFRoZSBTUFJJTkcgYW5kIElQUE0gY2hh aXJzIGNvbnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFuZCB1cG9uIHJldmlldyBvZiB0aGlzIHZl cnNpb24gb2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVkIHRoZQ0KIGZvbGxvd2luZzo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMi PlRoZSBTUFJJTkcgZG9jdW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMg cmVsZXZhbnQgdG8gU1BSSU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9z IHRoYXQgZGVmaW5lIGFueSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5n PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+DQogQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lv biBmb3IgVFdBTVAgTGlnaHQgTWVzc2FnZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hp dGUiPiwmbmJzcDs8Yj5Mb3NzIE1lYXN1cmVtZW50IFF1ZXJ5IE1lc3NhZ2UgRXh0ZW5zaW9uczwv Yj4sIGFuZCZuYnNwOzxiPkxvc3MgTWVhc3VyZW1lbnQgUmVzcG9uc2UgTWVzc2FnZSBFeHRlbnNp b25zDQo8L2I+PC9zcGFuPndlcmUgaW5jbHVkZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMCI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwPC9h PiBhbmQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgU1BSSU5HIGRvY3VtZW50LjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPlRoZSBUV0FNUCBleHRlbnNpb25zIGluY2x1ZGVk IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNw cmluZy10d2FtcC1zcnBtLTEwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2Fu ZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwPC9hPiBzaG91bGQgYmUgZGVzY3JpYmVkIGluIGEgbmV3 IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUgSVBQTSBXRy4gJm5ic3A7PG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vzc2VkIHdpdGggdGhl IGF1dGhvcnMgb2YgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMDwvYT4gdGhlIHJlc3VsdCBvZiB3 aGljaCBpcyB0aGUgcHVibGljYXRpb24gb2YgdGhlDQogZm9sbG93aW5nIHR3byBkb2N1bWVudHM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVs MSBsZm82Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhp LXNwcmluZy10d2FtcC1zcnBtLTExIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExPC9hPi4gVGhlIHN1YmplY3Qgb2YgdGhpcyBXRyBh ZG9wdGlvbiBjYWxsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBt LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0tdHdhbXAt c3JwbS0wMDwvYT4uIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwcm9ncmVzc2VkIChpZiBkZXRlcm1p bmVkDQogYnkgdGhlIFdHKSB3aXRoaW4gdGhlIElQUE0gV0cuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFzZSBpbmRp Y2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0 Lg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5QbGVhc2UgYWxzbyBw cm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0aGVyZW9m KSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2VudC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Rmlu YWxseSwgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZvciB0aGVp ciBlZmZvcnRzIGluIHRoaXMgbWF0dGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5vLCAmYW1wOyBKb2VsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_78F83B8097234848B374D9816F25E284ciscocom_-- From nobody Mon Nov 9 08:22:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BEC3A11C8; Mon, 9 Nov 2020 08:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wZNIE4e4gKKi; Mon, 9 Nov 2020 08:22:20 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 B28823A11BC; Mon, 9 Nov 2020 08:22:19 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id za3so13102762ejb.5; Mon, 09 Nov 2020 08:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5F5SZHBYylc2OrdGkOELiVfWku/Ni2N0SaamhPt4oUc=; b=Bbq2LUJk6lUqbmFQymySa0le3uA4lDmuMaFl1xX9IoU+Mgw69DVCsJHfmPLnOZhaAy ESX0HnJd6xwiGCTi5CGBYRb1Vq/gnfnxkO/mIDZkyksNkB3yS9VxKt/mddaN4aKgc+xE QJKK62M8oKoaNTvRAOZtbcThxFyBFYp+3L215GJsLK9fU9iSMGp6QjiEhizuDZ2xmSCG JnNcN7xoUjg8hszhJ8FaB80b2T3ro3ZQQqaWAgb1AZAeUyOvbRKhoIJXh5yULJ1zuzhQ zw7rTeueG3wwkxsuaFXRLtvZT4xNrgunyeDk+R8QYavvAueGIrOqNwb7bc30fMCwoHEQ 5myA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5F5SZHBYylc2OrdGkOELiVfWku/Ni2N0SaamhPt4oUc=; b=dxhI4MaIYbKp4RM2PZx6RPOzp0M0rm6nPOhYGUn0GZOla76DrRwEqBD/47t4UIeKrb /35Y4IFcR30sakjbwjDQ5wxU5x801UWUJVqqZDrrclPLXylEBH89s8BXehC5ePyvIJCy 5wf8KN92FjqEVQusS09gBTZMAotbv0NmLMFz9n7bRe2jgsx/iod4ALiseTjQKEsr+nxz B/ToIYWe/lnMsBbddGqghhtNRTUN/FSO7vijTxNZwCmktF32ubBMK4AcdtXYERNvzp7a j34gGf5pe1v8AZsSv1swRtRDsRFV65WQkTalQ6XfIFjp5OJqAGQEEi0zM3kS5oB422ux 1rxA== X-Gm-Message-State: AOAM530GqtCWz8isoZstDKiM8gjWdiT2gPJIu3hZhnjN2xcvAuyLlrey YpMAmituwwmuGbi6xJ6IK+1csNyY5BHEsZeU0LVgt8sABQ== X-Google-Smtp-Source: ABdhPJx8LlCLzcXYKbqzCkUfY1bywtps6RGvqjsizLeiIY2S+fKVggvQaIuSt5vtFgfK4wV696/t2Gmyx9jmz4k9gRc= X-Received: by 2002:a17:906:8496:: with SMTP id m22mr14955042ejx.298.1604938938176; Mon, 09 Nov 2020 08:22:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Mon, 9 Nov 2020 11:22:07 -0500 Message-ID: To: James Guichard Cc: "spring@ietf.org" , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004bd65805b3aef7f6" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 16:22:21 -0000 --0000000000004bd65805b3aef7f6 Content-Type: text/plain; charset="UTF-8" Hi WG, Support (as a co-author). Thanks, Rakesh On Tue, Nov 3, 2020 at 12:39 PM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending > November 24th 2020. Please note that this document has several changes > from v-06 that were requested by the SPRING chairs. For this reason, the > chairs have extended the adoption call for an additional week to allow the > WG enough time to review these changes before deciding on WG adoption. > > > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as consent. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000004bd65805b3aef7f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi WG,
    Support (as a co-author).
    =

    Thanks,
    Rakesh


    <= /div>

    On Tue, Nov 3, 2020 at 12:39 PM James Guichard <james.n.guichard@futurewei= .com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-s= egment-07, ending November 24th 2020. Please note that this = document has several changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.

    =C2=A0

    After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that s= upport (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --0000000000004bd65805b3aef7f6-- From nobody Mon Nov 9 08:39:20 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FAD3A11D8; Mon, 9 Nov 2020 08:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=NaqddUtc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UNfYFYKF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUzNHPf7aeDw; Mon, 9 Nov 2020 08:39:17 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555773A11B5; Mon, 9 Nov 2020 08:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7197; q=dns/txt; s=iport; t=1604939955; x=1606149555; h=from:to:cc:subject:date:message-id:mime-version; bh=AZgNsLHO5xne7tGWADwelDBiz3hlUE+ZzpidaXOqTHY=; b=NaqddUtcF4XEeDY8d771tzIydVD0IUubPyLYZHvxHoqaBaYYwQlXROb3 px+LMtWwZbtd4wS8f9d+zZ1HDoGKQSg6TxgQtQjJbvLLiaqhnUhHKBxYk tr7Z9Nju/QczVpLU5qRSEzE27WVzkrfiuDRu3EyFrjEoi4wme7DLTVsTG M=; X-IPAS-Result: =?us-ascii?q?A0DZCADNb6lffYUNJK1ig3svUXtZLy4KhDODSQONVJQSh?= =?us-ascii?q?G+BQoERA1QLAQEBDQEBIwoCBAEBhEoCF4F7AiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhjwMhXIBAgEDEgsGHQEBLAsBEQEIEQMBAisCBDAdCgQBDQUig?= =?us-ascii?q?wQBgX5XAy4BAgyjVAKBO4hodoEygwQBAQWBNwKBE4JBGIIQAwaBOIJzg3WGV?= =?us-ascii?q?xuBQT+BOByCTz6CXQEBA4EiWg2CajOCLJNlhxyMDZEcCoJtiQ2SAAMfgxiKE?= =?us-ascii?q?pRGk06KeZVNAgQCBAUCDgEBBYFrIYFZcBU7KgGCPlAXAg2SEIUUhUR0AjYCB?= =?us-ascii?q?gEJAQEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AVr7gvhAtU0NIkBTA0YRwUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw31g3HQJnG8f9bhuuQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFPPvmCo4CEfG1?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="605900749" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 16:39:14 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9GdENG001923 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 16:39:14 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 10:39:14 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 11:39:13 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 10:39:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WN9q82F/xM/C8pVdjnX2dVHKutgNR8pg6KjIXPsUw56nm3FHuvlSnd1nqWTelfimPsMXpBgEAbd630N6wt0S+YdaxrdvN8/btLmhSXcNLeyrD/z8jUbPwAEMDehIR1Vocplph0B0kNmV7aEPBBlEKcCJE3TCISl86H6f3+XKAhyZ27FGK2A9DyGSdgl75h/TLgQWAMJXhrbWF/CAO0xj0yH7pRPRBpX4RV5bE70nVUfmVGC6ivZPRvUkSlR5Yuu5ZttSEG1ZCBEK9/cnXAZKjP65dcExJQZVK8/dJZ+/FRe1f2F4+ng7PxvIIhk0XJLhLY/h1UJ+NY3iXHwyoc7Qaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AZgNsLHO5xne7tGWADwelDBiz3hlUE+ZzpidaXOqTHY=; b=Lq7utFD4hmDl51dKLbKFbnoVLx2A4Hkw6BXXY8hptkToCMhkJSWEnG/f1irolkfenHhyNRIFIHjAR7DeRE34wDF8FygPaYA8A1e3j/lF+umEbhS388Uu1WrvUeMKmz35H7jkafDLJ5u5vJSG/FYL+VpSNSiBgXwtCxcsCIYpQsRpQCf3DQ+nvOeQ83C5jukH/3NAa3ESm+B+blFJGZUG/NExmsgp6RBK1nBU0xA4U8mMLfbAodnM/tuRnNFOdJl2Lr7Dd8eb7RaS0LjVVitnlPFizUf3KtYIkI8irOr30yQBhVXSFnBC8bbE9bIAjrw75fpBpqRDbaeBMconQx1OaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AZgNsLHO5xne7tGWADwelDBiz3hlUE+ZzpidaXOqTHY=; b=UNfYFYKF8kub3JEdBtBrGSy94JdoxZLJX9H8/u1Nnw0fnjb84D48Q7yBRSNrweMXgPpLV1akmEWURy0BN+YjIOMaDphlXQscuezw/WzwvoV/Szaf+uGczAwpdE0kbtiVENbLye041d8nrFfzM+1wDiJJA8kD7l3YgZO0zefmM3E= Received: from DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) by DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.22; Mon, 9 Nov 2020 16:39:12 +0000 Received: from DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::31bb:ee91:659c:993a]) by DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::31bb:ee91:659c:993a%3]) with mapi id 15.20.3541.025; Mon, 9 Nov 2020 16:39:12 +0000 From: "Zafar Ali (zali)" To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" , "Zafar Ali (zali)" Thread-Topic: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AQHWtrbaBGpvNHcnYkuompUzIdUkow== Date: Mon, 9 Nov 2020 16:39:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [47.185.231.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f865e06-df6e-49fd-f88a-08d884cdfd52 x-ms-traffictypediagnostic: DM6PR11MB4692: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h+dciYnHdc5X/7Yrjb1swBGtTtuvIg5ECRuBNibfZctLiN19mAuoK8Wi4bL3zjprxMi4FySVLhb1AZmOHWvR0bOiTY8at8MIjpMK75B/a6NFSXN4RAijcOOzRcMA5bywNSaLCnaq4RR2MG1vsnomBVIjijSzUPXsVSuOD4yTfkJf/3urgbtOAGO35tejXfQSz4TtwigWOwCMz1Arz0MRqygs2GlIUVJdRLiI27dmSsX4bqnoc1neGUWqxCLFadgTggChdO6B8KZOPvr1sHQp9LZ78OUYprKQC87RRA3M8GWNHxdvt2zknQyWOfFROHbAqo8c/EQe0tEpnTMCiMndGkoNYqCjER9gQsG/nEk+r4+6jlfc/h7CZbhBZHCW9iD9OfLU25Wi4tZWKZNDoPYQOw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4692.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(136003)(376002)(166002)(83380400001)(71200400001)(36756003)(64756008)(66556008)(66476007)(91956017)(76116006)(66946007)(66446008)(5660300002)(2616005)(107886003)(2906002)(4326008)(54906003)(6506007)(53546011)(186003)(26005)(6512007)(8936002)(86362001)(8676002)(6486002)(478600001)(316002)(966005)(110136005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wVizFWlOoSQU7CaI+QqK9PwrFm4KItrqUI8Gkbd5jOn1M4hW755fg0Q8s7D0As1SgXy8AfcqC8X5HlJefuH+yVq6OhbW1IqKJpxPyt6wOEnIPYhiwEdDxU7Aic0XQ4xZe3gkQXHB//E2n/cTcZNpMbb1IBu3EOFXezuMw2SJNBz9N1RyD1wz+HVmlvno+QJzUiJLkoh4XzRXbS1euBly9jkabB92OKrDkA3Gw/EO8sw6uBifuWWbzQcQRD/d7yMqdaOpSAIKjPerCvAoqPntAa95hba1Yk1GfbscrjtUMCAjXFWz47XyhPhCtGFlZFUNehbAjaRt7uoS+SYgGNJBq1fLsUP51pAk5xpJlw6mgEckdHWwyjASVIiv2zMwlV295cX21QhkroK7vOM7bGQvNRCMndGTm8ebA84xumlEFvR4vQwNrsdBBNh+p2CIj3l+GN83iosi1XdIusX0LcGGxoyazdod3drdVTeLGT8qux8Zmd/vn+BsCy0+amu55K2gcCV2/+vanaCrDCzuTIRi6DjV7bSdTrL+6OUVtHodrDKQh+ON230odzJ5jEAgPHI5rOjrDXRFMplOxXAQleXjW5FknuW+040FrwLrEg36C7CAC7RFcBUiVSvlYpQixrJJ6FYo3DjPRXivs/SGgJ5MPLKMezwQbepJ+8FexD02FtRXyxz/qn09VPpuVJWi/vb6jGFRQotcICvPoTo0IYPbx+69fozoPeV21/UGrKR5np0d7IJUREody0k8LIIJiXSTFlJ8ZttplnfDFZFzO+PNFYBG49YTeNlf9qWVSkEs5RcYvimFlPcFiIyN5VQmsy3+QUXuIEgHuWNsrozzsHYoW7aIYKM1S+m33Fj9ZwBhQSVNrAO/lfw5k0i8p0NgU74tw7Ksh8Xzp0Z19xeTXDXXrA== Content-Type: multipart/alternative; boundary="_000_FC0DF753E9974E1D9FBFDDE3DE9FB37Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4692.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f865e06-df6e-49fd-f88a-08d884cdfd52 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 16:39:12.5234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Gp4sLM++Eirsdk+T/ZiUTv1tm8He85YUTkQticDEA1zPWE4dnpSY2ZUU/K8MSjwT X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4692 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 16:39:19 -0000 --_000_FC0DF753E9974E1D9FBFDDE3DE9FB37Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCENCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCkZyb206IHNwcmluZyA8 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW1lcyBHdWljaGFyZCA8amFt ZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMywg MjAyMCBhdCAxMjo0MSBQTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+ DQpDYzogInNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0K U3ViamVjdDogW3NwcmluZ10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtbGktc3ByaW5nLXNy djYtcGF0aC1zZWdtZW50DQoNCkRlYXIgV0c6DQoNClRoaXMgbWVzc2FnZSBzdGFydHMgYSAzIHdl ZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudC0wNywgZW5kaW5nIE5vdmVtYmVyIDI0dGggMjAy MC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIGNoYW5nZXMgZnJv bSB2LTA2IHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQUklORyBjaGFpcnMuIEZvciB0aGlz IHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4dGVuZGVkIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBh biBhZGRpdGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0 aGVzZSBjaGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBvbiBXRyBhZG9wdGlvbi4NCg0KQWZ0ZXIgcmV2 aWV3IG9mIHRoZSBkb2N1bWVudCBwbGVhc2UgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBmb3Ig V0cgYWRvcHRpb24gdG8gdGhlIG1haWxpbmcgbGlzdC4gUGxlYXNlIGFsc28gcHJvdmlkZSBjb21t ZW50cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMgc2lsZW5j ZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuDQoNClRoYW5rcyENCg0KSmltLCBC cnVubyAmIEpvZWwNCg0KDQoNCg0KDQo= --_000_FC0DF753E9974E1D9FBFDDE3DE9FB37Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7AFC23564F6FD7468BE3284B95D2A911@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvcnQhIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyDi gKYgWmFmYXIgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJp bmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSmFtZXMgR3Vp Y2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMywgMjAyMCBhdCAxMjo0MSBQTTxicj4NCjxiPlRvOiA8 L2I+JnF1b3Q7c3ByaW5nQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJp bmctY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc3ByaW5nXSBXRyBB ZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoaXMgbWVzc2FnZSBz dGFydHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3INCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21lbnQtMDciPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1zcHJpbmctc3J2Ni1wYXRoLXNlZ21l bnQtMDc8L2E+LCBlbmRpbmcgTm92ZW1iZXIgMjQ8c3VwPnRoPC9zdXA+IDIwMjAuIFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2ZXJhbCBjaGFuZ2VzIGZyb20gdi0wNiB0aGF0 IHdlcmUgcmVxdWVzdGVkDQogYnkgdGhlIFNQUklORyBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwg dGhlIGNoYWlycyBoYXZlIGV4dGVuZGVkIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBhbiBhZGRpdGlv bmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0aGVzZSBjaGFu Z2VzIGJlZm9yZSBkZWNpZGluZyBvbiBXRyBhZG9wdGlvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkFmdGVyIHJldmlldyBvZiB0aGUgZG9jdW1l bnQgcGxlYXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRo ZSBtYWlsaW5nIGxpc3QuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+UGxlYXNlIGFsc28gcHJvdmlkZSBjb21tZW50cy9yZWFzb25z IGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMgc2lsZW5jZSB3aWxsIG5vdCBi ZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ VGhhbmtzITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkppbSwgQnJ1bm8gJmFtcDsg Sm9lbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FC0DF753E9974E1D9FBFDDE3DE9FB37Bciscocom_-- From nobody Mon Nov 9 10:38:19 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AADC3A12BD for ; Mon, 9 Nov 2020 10:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sHh_aIJFj7IC for ; Mon, 9 Nov 2020 10:38:15 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 BBD953A1250 for ; Mon, 9 Nov 2020 10:38:15 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id n129so10869676iod.5 for ; Mon, 09 Nov 2020 10:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nP9Lc44+mY/2ZdsBW4x2BChWx3V7356+HLOJzFLiyjQ=; b=WrQlw4BAANaETemReruocYcYwKiDehBc6/sJq9sOg1jWD7ShkxKrKCUQJ0y+kC8iV/ cRYqGL8IQ+XQuXi9k5Zg+WFVF6KiPf8YCA8opF55iXihnH1R1rKL0MaKyczsY0t0HtgT iIHT/qgcMbHznbpzTW5yh/Up/bsgWZRLKVxJaG3Lh1j9iBP9fAmNvAZhs/EMxCUZ2Ik6 +h4xavdQ2EKLaIJ0WBOckp+ep4AMDDz0DYyEITF8ir6uiM6T5Jd1y7dA8DxAY8uNZNbd Ik/SmNX4QPAxHEZ91Dmeok1asuxGGlmDfr3kPTxJszPuqhm+y9mdtDoJG7NZ4zk6K8VR NPyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nP9Lc44+mY/2ZdsBW4x2BChWx3V7356+HLOJzFLiyjQ=; b=X/fvlR/oUY2sRuiTHsRtFje5WUnALd3u2SVifqXx3o85ppEucYZ4avSnXkNuSWNskj YBILHj7Y4ybcFJ6YxDXIvSRdkit4kJXEGCQq0IxAI2PjQosJYxqIGc62mkfBISodKRBQ ioMnw2FXI0L9stPNgQl+7NlLVb2TJrvGHuEC9xLOgS61a/KpHcscHMFDq5X7Am/z8ZDP hci8GA3R286ZgRO2AYMUB5wqp6m17CJy/VZRL+7uiyhHG//9y8UpkDfsk44UDEaA/uyW mxAN1YPL1ONa/CaVJe6X63jZpo9ymBbNf9IfKL/38u2YhFPwVSzvPaYbp/MXFmlOHkWC 6hXg== X-Gm-Message-State: AOAM531H/uymAXnkEWdqU/MU42+pIU4ak/WQhQmOBpmPqThSlQN+9QkS jx1vx7UnR0qqyN8aQZcGCjDjdPqCBC1LLSJG0cg= X-Google-Smtp-Source: ABdhPJzoQRw7MhD2cDPKkdsSKmdFs2g0AL3zu4sK/j40vJFTvwJJAT6+oyYhdrCSJ7l6+ySnt5DnQe3UDmYiIxGKeS8= X-Received: by 2002:a05:6602:2c92:: with SMTP id i18mr11337987iow.18.1604947094904; Mon, 09 Nov 2020 10:38:14 -0800 (PST) MIME-Version: 1.0 References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: From: Vishnu Pavan Beeram Date: Mon, 9 Nov 2020 12:38:03 -0600 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000079a4cf05b3b0dd34" Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 18:38:18 -0000 --00000000000079a4cf05b3b0dd34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ketan, Much Thanks for taking a stab at addressing the composite candidate path use-case! We seem to be converging. However, I don=E2=80=99t understand why= you need to use additional SR policies (and unnecessarily burn additional colors) to address this. Why can=E2=80=99t the composite candidate path jus= t be a grouping of explicit candidate paths and/or dynamic candidate paths? Consider the following changes: ** Section 2.2 OLD: A composite candidate path acts as a container for grouping of SR Policies. The composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies. The following criteria apply for inclusion of constituent SR Policies using a composite candidate path under a parent SR Policy: o the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical o The colors of each of the constituent SR Policies and the parent SR Policy MUST be different o the constituent SR Policies MUST NOT use composite candidate paths Each constituent SR Policy of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. NEW: A composite candidate path acts as a container for grouping of explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints. The composite candidate path construct enables load-balanced steering of packet-flows over a set of constituent candidate paths. The following criteria apply for constituent candidate paths under a composite candidate path: o the preference of the constituent candidate path MUST be ignored. o the constituent candidate path MUST NOT be a composite candidate path Each constituent candidate path of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. ** ** Section 2.11 OLD: When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load balancing of flows steered into a constituent SR Policy is performed based on the weights of the Segment-List of the active candidate path of that constituent SR Policy. NEW: When a composite candidate path is active, the fraction of flows steered into each constituent candidate path is equal to the relative weight of each constituent candidate path. Further load balancing of flows steered into a constituent candidate path is performed based on the weights of each associated Segment-List. ** ** Section 2.13 OLD: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path CP1 Preference 200 Weight W1, SR policy Weight W2, SR policy The constituent SR Policies POL1 and POL2 have information model as described at the start of this section. They are referenced only by color in the composite candidate path since their headend and endpoint are identical to the POL100. The valid Segment-Lists of the active candidate path of POL1 and POL2 are installed in the forwarding. Traffic steered on POL100 is flow-based hashed on POL1 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. NEW: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path Comp-CP Preference 200 Weight W1, Candidate-path CP1 Weight W2, Candidate-path CP2 Candidate-path CP1 Weight W11, SID-List1 Weight W12, SID-List2 Candidate-path CP2 Weight W21, SID-List3 Weight W22, SID-List4 Comp-CP is a composite candidate path with two constituents, CP1 and CP2. The preference is ignored for each of the two constituent candidate paths. The valid Segment-Lists of the two constituent candidate paths are installed in the forwarding. Traffic steered on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent candidate path, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. ** ** Section 5.3 OLD: A composite candidate path is specified as a group of its constituent SR Policies. A composite candidate path is valid when it has at least one valid constituent SR Policy. NEW: A composite candidate path is specified as a group of its constituent candidate paths. A composite candidate path is valid when it has at least one valid constituent candidate path. ** Regards, -Pavan On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) wrote: > Hello All, > > We have just posted an update for the draft and following is the summary > of changes: > > 1) Introduction of the Composite Candidate Path construct to address a > pending comment from the WG (Ref : > https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ > and > https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/= ) > 2) Based on offline feedback received, updated SRv6 segment types to > include optional SRv6 SID and behavior instead of the new type that was > introduced for it in the v08. > 3) Clarification of handling of colors and BGP multi-path scenarios based > on offline feedback received. > 4) Clarification on considerations for TI-LFA for SR Policy as discussed > in the WG (Ref : > https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/= ) > > Please let know your comments/feedback. > > Thanks, > Ketan (on behalf of co-authors) > > -----Original Message----- > From: spring On Behalf Of > internet-drafts@ietf.org > Sent: 02 November 2020 06:27 > To: i-d-announce@ietf.org > Cc: spring@ietf.org > Subject: [spring] I-D Action: > draft-ietf-spring-segment-routing-policy-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking WG o= f > the IETF. > > Title : Segment Routing Policy Architecture > Authors : Clarence Filsfils > Ketan Talaulikar > Daniel Voyer > Alex Bogdanov > Paul Mattes > Filename : draft-ietf-spring-segment-routing-policy-09.txt > Pages : 37 > Date : 2020-11-01 > > Abstract: > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate per-flow states are eliminated thanks > to source routing. The headend node steers a flow into an SR Policy. > The header of a packet steered in an SR Policy is augmented with an > ordered list of segments associated with that SR Policy. This > document details the concepts of SR Policy and steering into an SR > Policy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-09 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-pol= icy-09 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000079a4cf05b3b0dd34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Ketan,<= span>

    =C2=A0

    Much Thanks for taking a stab at addressing the composite candidate path use-cas= e!=C2=A0We seem to= be converging. However, I don=E2=80=99t understand why you need to = use additional SR policies (and unnecessarily burn additional colors) to address this. Why can=E2=80=99t the composite ca= ndidate path just be a grouping of explicit candidate paths and/or dynamic candidate pat= hs?

    =C2=A0<= /span>

    Consider the following changes:

    =C2=A0

    ** Section 2.2

    OLD:

    <=
span style=3D"color:black">=C2=A0=C2=A0 A composite candidate path acts as =
a container for grouping of SR
    =C2=A0=C2=A0 Policies.=C2=A0 The composite candidate path construct=
 enables combination
    =
=C2=A0=C2=A0 of SR Policies, each with explicit candidate paths and/or dyna=
mic
    =C2=A0=C2=A0 candid=
ate paths with potentially different optimization objectives
    =C2=A0=C2=A0 and constraints, for a l=
oad-balanced steering of packet flows over
    =C2=A0=C2=A0 its constituent SR Policies.=C2=A0 The fol=
lowing criteria apply for
    =C2=A0=C2=A0 inclusion of constituent SR Policies using a composite cand=
idate path
    =C2=A0=C2=A0=
 under a parent SR Policy:
    =C2=A0
    =C2=A0=C2=A0 o=C2=A0 the endpoints of the constituent SR Policies and the =
parent SR
    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Policy MUST be identical
    <=
span style=3D"color:black">=C2=A0
    =C2=A0=C2=A0 o=C2=A0 The colors of each of the constituen=
t SR Policies and the parent
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SR Policy MUST be different
    =C2=A0<=
/span>
    =C2=A0=C2=A0 o=C2=A0 the constituent=
 SR Policies MUST NOT use composite candidate paths
    =C2=A0
    <=
pre style=3D"font-variant-caps:normal;text-align:start;word-spacing:0px;mar=
gin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">=C2=A0=C2=A0 Each constituent SR Policy of a comp=
osite candidate path is
    =C2=A0=C2=A0 associated with a weight for load-balancing purposes (refer
    =C2=A0=C2=A0 Section 2.11 for details).=C2=A0 T=
he default weight is 1.
    =C2=A0
    NEW:
    =C2=A0=C2=A0 A composite candidate path acts as a container for =
grouping of
    =C2=A0=C2=
=A0 explicit candidate paths and/or dynamic candidate paths with 
    =C2=A0=C2=A0=C2=A0potentially di=
fferent optimization objectives and constraints.
    <= pre style=3D"font-variant-caps:normal;text-align:start;word-spacing:0px;mar= gin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">=C2=A0=C2=A0 The composite candidate path constru= ct enables load-balanced
    =C2=A0=C2=A0 steering of packet-flows over a set of constituent candidate=

    =C2=A0=C2=A0 paths. Th=
e following criteria apply for constituent candidate 
    =C2=A0=C2=A0=C2=A0paths under a composite candidate path:
    =C2=A0
    =C2=A0=C2=A0 o=C2=A0 the preference of the constituent =
candidate path MUST be 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ignored. =

    =C2=A0=

    =C2=A0=C2=A0 o=C2=A0 t=
he constituent candidate path MUST NOT be a composite candidate 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0path
    =C2=A0
    =C2=A0=C2=A0 Each =
constituent candidate path of a composite candidate path is
    =C2=A0=C2=A0 associated with a weight =
for load-balancing purposes (refer
    =C2=A0=C2=A0 Section 2=
.11 for details).=C2=A0 The default weight is 1.
    =C2=A0
    **
    =C2=A0
    ** Section 2.11
    =C2=A0=

    OLD:<=
/span>
    


    =C2=A0=C2=A0=C2=
=A0When a composite candidate path is
active, the fraction of flows
    


    =C2=A0=C2=A0=C2=
=A0steered into each constituent SR
Policy is equal to the relative
    


    =C2=A0=C2=A0=C2=
=A0weight of each constituent SR
Policy.=C2=A0=C2=A0Furth=
er load
balancing of
    


    =C2=A0=C2=A0=C2=
=A0flows steered into a constituent SR
Policy is performed based on the
    


    =C2=A0=C2=A0=C2=
=A0weights of the Segment-List of the
active candidate path of that
    


    =C2=A0=C2=A0=C2=
=A0constituent SR Policy.
    


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    NEW:
    


    =C2=A0=C2=A0=C2=
=A0When a composite candidate path is
active, the fraction of flows
    


    =C2=A0=C2=A0=C2=
=A0steered into each constituent
candidate path is equal to the relative
    


    =C2=A0=C2=A0=C2=
=A0weight of each constituent candidate
path.=C2=A0=C2=A0Further=
 load
balancing of
    


    =C2=A0=C2=A0=C2=
=A0flows steered into a constituent
candidate path is performed based on
    


    =C2=A0=C2=A0=C2=
=A0the weights of each associated Segment-List.<=
span style=3D"color:black">
    


    =C2=A0=

    


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">**
    =C2=A0=

    ** Section 2.13
    =C2=A0
    =
OLD:


    =C2=A0=C2=A0=C2=
=A0The information model of SR Policy
POL100 having a composite
    


    =C2=A0=C2=A0=C2=
=A0candidate path is the following:
    


    =C2=A0=

    


    =C2=A0=C2=A0=C2=
=A0SR policy POL100 <headend =3D H1,
color =3D 100, endpoint =3D E1>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path CP1 <protocol-orig=
in
=3D 20, originator =3D
    


    =C2=A0=C2=A0=C2=
=A0100:1.1.1.1, discriminator =3D 1>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0Preference 2=
00
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0Weight W1, S=
R policy <color =3D 1>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0Weight W2, S=
R policy <color =3D 2>
    


    =C2=A0=

    


    =C2=A0=C2=A0=C2=
=A0The constituent SR Policies POL1 and
POL2 have information model as
    


    =C2=A0=C2=A0=C2=
=A0described at the start of this
section.=C2=A0=C2=A0They=
 are
referenced only by
    


    =C2=A0=C2=A0=C2=
=A0color in the composite candidate path
since their headend and
    


    =C2=A0=C2=A0=C2=
=A0endpoint are identical to the
POL100.=C2=A0=C2=A0The v=
alid
Segment-Lists of the<=
/span>
    


    =C2=A0=C2=A0=C2=
=A0active candidate path of POL1 and POL2
are installed in the<=
/span>
    


    =C2=A0=C2=A0=C2=
=A0forwarding.=C2=A0=C2=
=A0Traffic steered on POL100 is
flow-based hashed on POL1
    


    =C2=A0=C2=A0=C2=
=A0with a ratio W1/(W1+W2).=C2=A0=C2=A0Within the POL1, the flow-based hashing<=
/span>
    


    =C2=A0=C2=A0=C2=
=A0over its Segment-Lists are performed
as described earlier in this
    


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


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    NEW:
    


    =C2=A0=C2=A0=C2=
=A0The information model of SR Policy
POL100 having a composite
    


    =C2=A0=C2=A0=C2=
=A0candidate path is the following:
    


    =C2=A0=

    


    =C2=A0=C2=A0=C2=
=A0SR policy POL100 <headend =3D H1,
color =3D 100, endpoint =3D E1>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path Comp-=
CP
<protocol-origin =3D 20, originator =3D
    


    =C2=A0=C2=A0=C2=
=A0100:1.1.1.1, discriminator =3D 1>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0Preference 2=
00
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
/span>Weight W1, Candidate-path CP1
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0Weight W2, C=
andidate-path CP2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path CP1 <protocol-orig=
in
=3D 20, originator =3D 
    


    =C2=A0=C2=A0 100:1.1.1.1,
discriminator =3D 2>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0Weight W11, SID-List1
<SID11...SID1i>=

    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Weight=
 W12, SID-List2
<SID21...SID2j>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Candidate-path CP2
<protocol-origin =3D 20, originator =3D 
    


    =C2=A0=C2=A0 100:1.1.1.1,
discriminator =3D 3>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0Weight W21, SID-List3 <SID31...SID3i>
    


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Weight=
 W22, SID-List4 <SID41...SID4j>
    


    =C2=A0
    


    =C2=A0=C2=A0 Comp-CP is a compo=
site
candidate path with two constituents, CP1
    


    =C2=A0=C2=A0=C2=
=A0and CP2. The preference is ignored for each of
the two constituent
    


    =C2=A0=C2=A0 candidate paths. T=
he
valid Segment-Lists of the two=
=C2=A0constituent

    


    =C2=A0=C2=A0 candidate paths ar=
e
installed in the forwarding.=C2=A0Traffic steered
    


    =C2=A0=C2=A0=C2=
=A0on Comp-CP is flow-based hashed on to
CP1 and CP2 with a ratio of=

    


    =C2=A0=C2=A0
W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent 
    


    =C2=A0=C2=A0 candidate path, th=
e=C2=A0flow=
-based hashing over
its Segment-Lists are 
    


    =C2=A0=C2=A0 performed as=C2=A0described e=
arlier in this
section.
    


    =C2=A0
    


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">**
    =C2=A0=

    ** Section 5.3
    =C2=A0
    =
OLD:


    =C2=A0=C2=A0=C2=
=A0A composite candidate path is
specified as a group of its constituent
    


    =C2=A0=C2=A0=C2=
=A0SR Policies.
    


    =C2=A0=

    


    =C2=A0=C2=A0=C2=
=A0A composite candidate path is valid
when it has at least one valid
    


    =C2=A0=C2=A0=C2=
=A0constituent SR Policy.
    


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    NEW:
    


    =C2=A0=C2=A0=C2=
=A0A composite candidate path is
specified as a group of its constituent
    


    =C2=A0=C2=A0=C2=
=A0candidate paths.<=
span>
    


    =C2=A0=

    


    =C2=A0=C2=A0=C2=
=A0A composite candidate path is valid
when it has at least one valid
    


    =C2=A0=C2=A0=C2=
=A0constituent candidate path.
    


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    


    **<=
/p>


    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
/span>
    Regards,
    -Pavan
    


    =C2=A0
    


    =C2=A0

    = On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>= wrote:
    Hello Al= l,

    We have just posted an update for the draft and following is the summary of= changes:

    1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2w= s/ and https://mailarch= ive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
    2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08.
    3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received.
    4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref : https://mail= archive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

    Please let know your comments/feedback.

    Thanks,
    Ketan (on behalf of co-authors)

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
    Sent: 02 November 2020 06:27
    To: i-d-announce= @ietf.org
    Cc: spring@ietf.org
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Segment Routing Policy Architecture
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Clar= ence Filsfils
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ketan Talaulikar
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Voyer
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alex Bogdanov
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Mattes
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-spring-segment-routing-policy-09.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 37
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-11-01

    Abstract:
    =C2=A0 =C2=A0Segment Routing (SR) allows a headend node to steer a packet f= low
    =C2=A0 =C2=A0along any path.=C2=A0 Intermediate per-flow states are elimina= ted thanks
    =C2=A0 =C2=A0to source routing.=C2=A0 The headend node steers a flow into a= n SR Policy.
    =C2=A0 =C2=A0The header of a packet steered in an SR Policy is augmented wi= th an
    =C2=A0 =C2=A0ordered list of segments associated with that SR Policy.=C2=A0= This
    =C2=A0 =C2=A0document details the concepts of SR Policy and steering into a= n SR
    =C2=A0 =C2=A0Policy.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/d= raft-ietf-spring-segment-routing-policy-09
    https://datatracker= .ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-09

    A diff from the previous version is available at:
    https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-policy-09


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

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


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

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --00000000000079a4cf05b3b0dd34-- From nobody Mon Nov 9 19:42:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514FA3A0603; Mon, 9 Nov 2020 19:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HURndfwdATTN; Mon, 9 Nov 2020 19:42:53 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905C73A05D0; Mon, 9 Nov 2020 19:42:53 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CVYYp41flz67K4y; Tue, 10 Nov 2020 11:41:18 +0800 (CST) Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Tue, 10 Nov 2020 04:42:50 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 10 Nov 2020 11:42:48 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Tue, 10 Nov 2020 11:42:48 +0800 From: "Dongjie (Jimmy)" To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgFC5zJg Date: Tue, 10 Nov 2020 03:42:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: multipart/alternative; boundary="_000_fd1627266c7142e38d9fea38d324b222huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 03:42:55 -0000 --_000_fd1627266c7142e38d9fea38d324b222huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. It provides a useful mechanism for path identification, and c= an be used for many related functions. Best regards, Jie From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Wednesday, November 4, 2020 1:39 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please = note that this document has several changes from v-06 that were requested b= y the SPRING chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption. After review of the document please indicate support (or not) for WG adopti= on to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel --_000_fd1627266c7142e38d9fea38d324b222huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Yes, support. It provides a useful mechanism for path identificat= ion, and can be used for many related functions.

     

    Best regards,

    Jie

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Wednesday, November 4, 2020 1:39 AM
    To: spring@ietf.org
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-seg= ment

     

    Dear WG:

     

    This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, end= ing November 24th 2020. Please note that this document has sever= al changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.

     

    After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as silence= will not be considered as consent.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

     

     

     

    --_000_fd1627266c7142e38d9fea38d324b222huaweicom_-- From nobody Tue Nov 10 01:27:32 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7F3A0E07; Tue, 10 Nov 2020 01:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GdGnC972V2qW; Tue, 10 Nov 2020 01:27:28 -0800 (PST) Received: from ESGRYBM04.stc.com.sa (esgrybm04.stc.com.sa [212.118.156.89]) by ietfa.amsl.com (Postfix) with ESMTP id 69A123A0E03; Tue, 10 Nov 2020 01:27:26 -0800 (PST) X-AuditID: d4769c59-ed3ff7000000d59b-bd-5faa5cfcca16 From: Ahmed MostafaSaleh ElSawaf To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AdayBseAKP01eLc1TGSQ0KydEKYaJgFPMSfA Date: Tue, 10 Nov 2020 09:27:23 +0000 Message-ID: <93bd482e02a0415886eb1d545bf142ed@stc.com.sa> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_93bd482e02a0415886eb1d545bf142edstccomsa_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA5VVa1ATVxh1kwhRWFwCgUsUjVuxAwjybGFKqMF3aasFpxVKjUuykghsMtmA 4LRClSmPgVZHeRSKRQwIEcWKIAqWkqJMFQraahGVOkixVbQVtARtsXcTHov+an7sfHO+u+c7 99xzN3yuoB8V8VWUjtRSRAJuNZdX45hf6/VPjEHm09O3POjMTQMv6JIhzzqovfsZsoK7ru74 mnV6/RhnIyc6HQmJJXTJkao4anloCEFRah2hI8UKkpZL8MhNK8VSC6RSUzQuVikkeAAu1iQQ cjKRpHQSnNBoSEqBh84Vv/QLgctUlJik5GqFioqT4OsjN3gFBQUGe/nioZuUpFhFbVNrE7fW 2SizTeesNfrlKV2FZ63TkavuOQifD7AAcGZ8aQ4yh2+FBYFrOc3WTO2IRYPaT/MRpuZigeBm 8XNz7YCtBEWfp3Mta1YBU3YLz1L7ge7Ox+aah7mB1mtPzTWKBYOxogZzLcBiQMa3GWaeOdhH YKR6hMPUCOYERi/WcCyznEHvwNfmGmAY0Dd3cS21EPxxZ3w2I5mLbQWDo54Wenvww5cDPMsS F9Ba1cPbiwiKWUzF028Us96wLFkGypqGrSy1J6g8dJ87WXd8d4fDxssQawPiuDpybURU2Ds+ Ad60Tu4tVyd608RJBEbh5+SvohqRqicPvY0IxkdwW/R2X55MMJtIplMTjUgmwufgIjTcN2KL wCFWrUhVErRSRifFJqpoGh46LkTL3jPIBHZTPW1SAknjjujRDyGMTsGxSQnxkOjyBxCdJqLI HXQCqYPJxBeia+IqZQJn1hBao5Kr1Em0LEmbYEQAnwtpw8arIK2CSN1JatWWYUZEDo9uH1ck lKthyCmdzNffL9jPz8/fz9c32P//wbgzuj2vWibA4mDO40lSQ2onpxTAA8FdUWTWrFkCJy0Z R6ZsUyVA6Ww7ALooGu7Qnt22OOKMdh9ieNkdsymuqLrliGwmI8uXxej8j+GWRTMHzrSGw5/D +DNX5EjD20ZqiSQddBzeWxkNL64R2Y3wbXEXi3IBrSESIcxW7YjqzKc12bIodkBHoiBqO4ma 1bqg85gNTrGwlLqi79PwBJ2mB7BVXkSOIfzW8wfLufxHBj18jpqfdaUV5VwBj1JTpGgB6nUA blXIECiTqJnWipzReEYkxuqadYqcUKUCvjaP1WCkQrpG8gW6abUiMepUC7suM4axBd9DKjjw QgC0TBK/RWAPv58vuOaAljBW2E50LKYJ0FIm4jYToNkzgMoY5ZMULMsWoKU6aJlwipwtwK8C gZ+YfVag9nmWDejLHLYDRb82zQNNvaMY6DnXKgA9Q98LwVjXBSH4xtS2ENQdrBKD8aL8xaAl f3QxOLkvFwd7cw/joPHEZRzs/8WEg7bi0VfA01KTG8h9sGcpyO0c9gSNzSXeoH+oxgeMF1zx AUfvZ/mD2oLOQDCy/zMp6CkyrAIPDw+tBQceZq8HdWXGt8DvHbvfBkPXCzYD09B41D0mX5zp fMG/g5fytVHKXNvJ1mS+THsqmXxNoBP5+psBp1hm5KtvtzlfUwPYbonSOT5EliLtdkDz6tMu p6+a7sZsiLAa4GzX2bhpK388cvFs1a6umPnHdbfvnvIoDrOzz7u0FtPwz0c/ztixM1mGS6t3 ubpv/6Tb5fLCzPznN1bmpKSVbemzta6P99pRV1jVsHes5HDya0TktYaKZYOZOc/eFW4ebPpi 1aljRR3drv2xaVcjouqNz+w8X62XLOn9t3dzuWe4PiPQJvvB42PhP4XbPCoKqdvJbyn57Upg mrFnxZKSmsE+pUO++z3bW8CuM9Y6xcmtcMGfko5F2xTVhalvjFxvaOcMa1P00oHXw6VvnmoL veFd3/9oveHWX+1WKZLGJ+5SfXt327nh6x4X9FjaCY/ymw1ZOI9WEr4eXC1N/AdRPZPK9QcA AA== Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 09:27:30 -0000 --_000_93bd482e02a0415886eb1d545bf142edstccomsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Isupport the adoption BR Ahmed El Sawaf From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Tuesday, November 3, 2020 7:39 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/htm= l/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please no= te that this document has several changes from v-06 that were requested by t= he SPRING chairs. For this reason, the chairs have extended the adoption cal= l for an additional week to allow the WG enough time to review these changes= before deciding on WG adoption. After review of the document please indicate support (or not) for WG adoptio= n to the mailing list. Please also provide comments/reasons for that support= (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Bruno & Joel The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_93bd482e02a0415886eb1d545bf142edstccomsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Isupport the adoption

     

     

     

    BR

    Ahmed El Sawaf

     

    From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of James Guichard
    Sent: Tuesday, November 3, 2020 7:39 PM
    To: spring@ietf.org
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segm= ent

     

    Dear WG:

     

    This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, endin= g November 24th 2020. Please note that this document has several= changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adoptio= n call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

     

    After review of the document ple= ase indicate support (or not) for WG adoption to the mailing list. Please also= provide comments/reasons for that support (or lack thereof) as silence will= not be considered as consent.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

     

     

     

    The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_93bd482e02a0415886eb1d545bf142edstccomsa_-- From nobody Tue Nov 10 02:04:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FACB3A0E82 for ; Tue, 10 Nov 2020 02:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=D66a4w4O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sgO1EqUm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf2mfM2mv-5v for ; Tue, 10 Nov 2020 02:04:20 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFE13A0E7E for ; Tue, 10 Nov 2020 02:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81526; q=dns/txt; s=iport; t=1605002660; x=1606212260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=D66a4w4OJ7kpmB89fpH//iKmCozozq2ayARwYHoF0Aofj+zFjH+IXelX ZH/qMLkJIzLV2sOsQ7oTbXsECMGDfrSCtffVjDLkUyDjb3Z0HtB8Wje3X X6IByOfVpNWqyBhjAoqjWUAz2qQUjUoNGeEn3kWQVYPqDiiem3Y8MuR+/ I=; X-IPAS-Result: =?us-ascii?q?A0B6BwBOZKpffZFdJa1iHQEBAQEJARIBBQUBgg+BIy8jL?= =?us-ascii?q?ntZLy4KhDODSQONVIoVjm2CUwNPBQsBAQENAQEYAQwIAgQBAYQGRAIXgXsCJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGDwglDIVyAQEBBAEBEBEKEwEBI?= =?us-ascii?q?wkLAQsEAgEIEQEDAQEhAQYDAgICHwYLFAMGCAIEDgUIGoMFgX5XAy4BDqI9A?= =?us-ascii?q?oE7iGh2gTKDBAEBBYEzAQMCDkGDCQ0LghAJgTiCc4JlTkKGVxuBQT+BEUOCT?= =?us-ascii?q?z6CG0IBAQIBARWBSAUHHwkCBoJZM4IskCyDOoccjA2QSlQKgm2JDYxwhTWDG?= =?us-ascii?q?IEqiGuSFIIzlVCIe4Juji+EMgIEAgQFAg4BAQWBQSohgVlwFRohgjUBATIJR?= =?us-ascii?q?xcCDYE0jFAbDBeDToUUhUR0AjYCBgEJAQEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AX7S+1BEvCY5+hCqhvwBHz51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208,217";a="585542443" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 10:04:18 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AAA4Ig9012582 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 10:04:18 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 04:04:18 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 04:04:17 -0600 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 05:04:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MWVh4bKBZR7T8y1C+0AopQVBtxDf4TjgzlX6pfD0jugNa/mOb8UnZ3wPbXlwJYpmxPJd7Xsyc/PgV8nyZJEWOsDflArdSG1vcGBtwtiO3RQ9FN401S7j12LDh2uhk3BTOjgER2va1d8Evz3PHX9Mg3asD8/jM2jmtOjo+N7DMM/bEzu/aZpjFTlI56uTzPuyvntUnhvsyQldzKtn9jFpq6fee2qemXNxlSxoPbZJ9z/xxik1/DSoTmAhnB69D1jJCGtIzqcmUXh07NZxajXm5aHHZ/LNtjYR5N2q7UCq1KxmBEA5UHyERqM7k16NYFVNJqFVq5jRHqhIYrkLB11KxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=JSsqirpwDT6qStj7C9aNh4ZW/bwjCEvQ8BKAoeG4IAY/dJlvr8dbVINtVYzaqUgP1UOTT2d1pAMyou6Uy7bwGsUbCaMWjfqXYLMZsOMWVBbDyxlX1q0c39CsvvdvFr21PpFX5MeyaTCr6usr7qmrI5iUdVRyarOurdxovghIijLQYmBSVWA/SUo1XN2PSDQIEqV+W02wrNec6jckCZlij20hPIzxDNrr3wx4iapmVBIQjAlsbQ/32XJPDp4bMZX2UxSPEGAZNG3ebObvc57b4g6kCQqLLlZfkfuire6bKWIgK1sDIpvGKWseZn8cZWLIL65dc5yy2i7BsFLpXSpABg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=sgO1EqUmTrtU3w+YYv1c9tOfI7+2beVHeTv373k02zURzBlpC0pmhWNk3vnkNPjaNhKt4K2Jeoh9T3kloimU+q7IPu7Rwpu7NDORxNNKCytwZCyGJsfjcxw3oWCBOsebd6vwjuXb1whzJz0tM8LgEdYtXmW2IlPOUR5PCDRt/Kc= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Tue, 10 Nov 2020 10:04:16 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 10:04:16 +0000 From: "Ketan Talaulikar (ketant)" To: Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAwoDICAAP2ogA== Date: Tue, 10 Nov 2020 10:04:16 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 784b889f-d97c-4ae2-79a6-08d8855ffbaf x-ms-traffictypediagnostic: MW3PR11MB4570: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nGUjOqOmL4PgLx/sP1WMfn9KyNBOCQjrXfsTXdf++s6SP+iZUS4x7yIDiYMq14BZAOPfQoHZsmKAxIPkHBglSYO2MftO9zQJeMlvSvss2XFrP0+F7g+WUShMEzGPMBef7Tk4YAUc7sMlqMORogcL7xu0spJ2MOa/Sh4hC9SZdrwu1nc7RJjea0qzvTGJyncWhTC/kTuOnLNxobUG0bOvuBXvRTKsQG6ft1PvbpiNgGP6wQcvMGepjRLmQT59aZ3JGt2z1kVnB1XcV+ZSMSBbGfxUCYUCM7N+LlxRhoIrymNtefjH1oF4uP5572hjl4piszU0nKnwglo3ql1swXe9u/moxnh3GjygMGzWQ5S0OslAFmZNPxpVn3+2+hZI8XnGMdapW1hwsRnsPQZM9nhp7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(376002)(39860400002)(136003)(366004)(6506007)(53546011)(66446008)(64756008)(76116006)(26005)(16350225007)(86362001)(66476007)(8676002)(55016002)(166002)(71200400001)(66556008)(9686003)(186003)(316002)(66574015)(2906002)(66946007)(478600001)(5660300002)(7696005)(9326002)(6916009)(4326008)(52536014)(966005)(33656002)(8936002)(83380400001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YfmAwOsy43nqonzbWVFZUOq2rrsVMWIx/yJcRGjoqqmyMV6aR1lLGea+DQUeCkhv8Tl6ri3s6dmsILjEKxKp9kHY1Vpyn18YW/5tocXBCQomJ/VMEYDp1CJvsZBVWg3j9QmuJYr4qVF3PRbV3FlRZiJYpyfdjmNDY/+xy9XntBg16480zos4F/Y/x5N/H2DGooZA7c+rMT2S2w6WD12kIMfeP16l5tSupjivk/G+rRActWDvbwUMY9qLIUj5cibs5NDHEoIk3UIfIykKxr2OC0aSWImwzKKBLxd4sGTEAJkcYHVWc1uHdc60Z37URIVtXET8RGv4OaNLAkSNC0DQZGaRvzSbVmDNlZ53aahCs9IqQRAOi7dT2A5IP396w5fp47R87rjwf7RJ+NOFwgF9F5f76r+gGlffV23q240B5lu1s9g+wRQKt50cu2oZg6/q0Pgax1Zz0RLIS+1VEy5hhKgo/gP8i7WuYgTbA5G1VkMrpppcrVRsBjYsss7vIhczYLzYpev3UwGoc3igKLNNdS7+fx/JE4a5q69tFAUFZQXoC6UVbvUrwNZCf4fySbCaZWneZzKNp7fAoRfchpm+5M7A/7h2wksbaqnN/s5hB+sfltDUus5xAfgpH758HDlC6y6zNTYQlaC1dG9tPGupeOnEWR2BCNykBDw4KqOhrQ0ZSqJHnqQCZ0yiXcMmaXXbvKMZu5FPdqOXd0e/7HVrg/TKZZxrg8Wx1olruH9Pjd0nBKRlTcmQvQj6712ZHpO9urdM5jyfiZ+VtGW5lta6lJsbzx76fOgbxzDppK+Pc0SMHdlBn1ALzN8MlxmVFXUGiY5sGPBO1Ajj8jkd3D/ZkOhKuOGF+rJVSiOT273xd1MlO9YcFytiPQIrFaD8C313cKXu/GeVWMzTbAhZxAtBEg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570D601ADC0D8E24B6B2675C1E90MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 784b889f-d97c-4ae2-79a6-08d8855ffbaf X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 10:04:16.3206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8EjO4nzSg6StsNWBljeUbJQaPFvyWwQc3C7iAX0/mBxxDQxTgVFH0PPGLEgmpVO976GtOO+6LFoMN9lO0nUZNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4570 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 10:04:24 -0000 --_000_MW3PR11MB4570D601ADC0D8E24B6B2675C1E90MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF2YW4sDQoNClBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuDQoNCkZyb206IFZpc2hudSBQ YXZhbiBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbT4NClNlbnQ6IDEwIE5vdmVtYmVyIDIw MjAgMDA6MDgNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29t Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCktldGFu LA0KDQpNdWNoIFRoYW5rcyBmb3IgdGFraW5nIGEgc3RhYiBhdCBhZGRyZXNzaW5nIHRoZSBjb21w b3NpdGUgY2FuZGlkYXRlIHBhdGggdXNlLWNhc2UhIFdlIHNlZW0gdG8gYmUgY29udmVyZ2luZy4N CltLVF0gVGhhbmtzIGZvciB0aGF0IGZlZWRiYWNrIGFuZCBjb25maXJtYXRpb24gdGhhdCB0aGUg cHJvcG9zYWwgaW4gdGhlIGRyYWZ0IGRvZXMgYWRkcmVzcyB0aGUgdXNlLWNhc2UuIEkgYmVsaWV2 ZSB3ZSBhcmUgbm93IGRpc2N1c3NpbmcgdGhlIG1lY2hhbmljcyBvZiBob3cgdGhpcyBpcyBhY2hp ZXZlZCB3aXRoaW4gdGhlIGN1cnJlbnQgU1IgUG9saWN5IGZyYW1ld29yay4NCg0KSG93ZXZlciwg SSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHlvdSBuZWVkIHRvIHVzZSBhZGRpdGlvbmFsIFNSIHBv bGljaWVzIChhbmQgdW5uZWNlc3NhcmlseSBidXJuIGFkZGl0aW9uYWwgY29sb3JzKSB0byBhZGRy ZXNzIHRoaXMuDQpbS1RdIEkgZG8gbm90IGZvbGxvdyB3aGF0IHlvdSBtZWFuIGJ5IOKAnGJ1cm4g YWRkaXRpb25hbCBjb2xvcnPigJ0uIENvbG9yIGlzIGp1c3QgYSAzMiBiaXQgbnVtYmVyIHRoYXQg aW5kaWNhdGVzIHRoZSDigJxpbnRlbnTigJ0gYW5kIGlzIG5vdCByZWFsbHkgYSBzY2FyY2UgcmVz b3VyY2UuIEFzc2lnbmluZyBhIGNvbG9yIHRvIOKAnGEgY29tcG9zaXRlIGludGVudOKAnSBzZWVt cyBsaWtlIGEgc2VhbWxlc3Mgd2F5IHRvIGludGVncmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlz bXMgZm9yIFN0ZWVyaW5nIG92ZXIgU1IgUG9saWNpZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmls aXR5IGZvciBzYXkgc29tZSBCR1Agc2VydmljZXMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25z dGl0dWVudCBleHBsaWNpdC9keW5hbWljIGludGVudCB3aGlsZSBvdGhlcnMgY2FuIHN0ZWVyIG92 ZXIgYSBjb21wb3NpdGUgaW50ZW50IHRoYXQgaW5jbHVkZXMgdGhvc2UgaW5kaXZpZHVhbCBleHBs aWNpdC9keW5hbWljIGludGVudHMuDQoNCldoeSBjYW7igJl0IHRoZSBjb21wb3NpdGUgY2FuZGlk YXRlIHBhdGgganVzdCBiZSBhIGdyb3VwaW5nIG9mIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBh bmQvb3IgZHluYW1pYyBjYW5kaWRhdGUgcGF0aHM/DQpbS1RdIFRoaXMgaXMgYmVjYXVzZSBpbiB0 aGUgU1IgUG9saWN5IGZyYW1ld29yaywgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBhY3RpdmUgQ1Ag 4oCTIGl0IG1heSBiZSBleHBsaWNpdCBvciBkeW5hbWljLiBOb3cgd2XigJl2ZSBhZGRlZCBhbm90 aGVyIENvbXBvc2l0ZSBDUCB0eXBlIHRvIGNvdmVyIHRoaXMgc3BlY2lmaWMgdXNlLWNhc2UuIFlv dXIgcHJvcG9zYWwgd2lsbCByZXN1bHQgaW4gMyBjYW5kaWRhdGUgcGF0aHMgYmVpbmcgYWN0aXZl IHdpdGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kg4oCTIG9uZSBlYWNoIG9mIHRoZSBleHBsaWNpdCBh bmQgZHluYW1pYyBDUCBhbmQgdGhlbiBhZGRpdGlvbmFsbHkgdGhlIENvbXBvc2l0ZSBDUC4gVGhp cyBicmVha3MgdGhlIGV4aXN0aW5nIHJ1bGVzIGZvciBzZWxlY3Rpb24gb2YgQ1AgYmFzZWQgb24g cHJlZmVyZW5jZSBhbmQgbWVjaGFuaXNtcyBsaWtlIGZhbGxiYWNrIGJldHdlZW4gQ1BzLiBXaGls ZSB0aGUgY3VycmVudCBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgcHJvdmlkZXMgYSB3YXkgdG8gYWRk cmVzcyB0aGUgbmV3IHVzZS1jYXNlIHdpdGggYSBiYWNrd2FyZHMgY29tcGF0aWJsZSBleHRlbnNp b24gdG8gdGhlIFNSIFBvbGljeSBmcmFtZXdvcmsuDQoNClRoYW5rcywNCktldGFuDQoNCkNvbnNp ZGVyIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KKiogU2VjdGlvbiAyLjINCk9MRDoNCg0KICAg QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3JvdXBp bmcgb2YgU1INCg0KICAgUG9saWNpZXMuICBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNv bnN0cnVjdCBlbmFibGVzIGNvbWJpbmF0aW9uDQoNCiAgIG9mIFNSIFBvbGljaWVzLCBlYWNoIHdp dGggZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWljDQoNCiAgIGNhbmRpZGF0 ZSBwYXRocyB3aXRoIHBvdGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24gb2JqZWN0aXZl cw0KDQogICBhbmQgY29uc3RyYWludHMsIGZvciBhIGxvYWQtYmFsYW5jZWQgc3RlZXJpbmcgb2Yg cGFja2V0IGZsb3dzIG92ZXINCg0KICAgaXRzIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzLiAgVGhl IGZvbGxvd2luZyBjcml0ZXJpYSBhcHBseSBmb3INCg0KICAgaW5jbHVzaW9uIG9mIGNvbnN0aXR1 ZW50IFNSIFBvbGljaWVzIHVzaW5nIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoDQoNCiAgIHVu ZGVyIGEgcGFyZW50IFNSIFBvbGljeToNCg0KDQoNCiAgIG8gIHRoZSBlbmRwb2ludHMgb2YgdGhl IGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIGFuZCB0aGUgcGFyZW50IFNSDQoNCiAgICAgIFBvbGlj eSBNVVNUIGJlIGlkZW50aWNhbA0KDQoNCg0KICAgbyAgVGhlIGNvbG9ycyBvZiBlYWNoIG9mIHRo ZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudA0KDQogICAgICBTUiBQb2xp Y3kgTVVTVCBiZSBkaWZmZXJlbnQNCg0KDQoNCiAgIG8gIHRoZSBjb25zdGl0dWVudCBTUiBQb2xp Y2llcyBNVVNUIE5PVCB1c2UgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRocw0KDQoNCg0KICAgRWFj aCBjb25zdGl0dWVudCBTUiBQb2xpY3kgb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMN Cg0KICAgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3Nl cyAocmVmZXINCg0KICAgU2VjdGlvbiAyLjExPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rpb24tMi4xMT4g Zm9yIGRldGFpbHMpLiAgVGhlIGRlZmF1bHQgd2VpZ2h0IGlzIDEuDQoNCg0KDQpORVc6DQoNCiAg IEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3Vw aW5nIG9mDQoNCiAgIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYyBjYW5k aWRhdGUgcGF0aHMgd2l0aA0KDQogICBwb3RlbnRpYWxseSBkaWZmZXJlbnQgb3B0aW1pemF0aW9u IG9iamVjdGl2ZXMgYW5kIGNvbnN0cmFpbnRzLg0KDQogICBUaGUgY29tcG9zaXRlIGNhbmRpZGF0 ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGxvYWQtYmFsYW5jZWQNCg0KICAgc3RlZXJpbmcgb2Yg cGFja2V0LWZsb3dzIG92ZXIgYSBzZXQgb2YgY29uc3RpdHVlbnQgY2FuZGlkYXRlDQoNCiAgIHBh dGhzLiBUaGUgZm9sbG93aW5nIGNyaXRlcmlhIGFwcGx5IGZvciBjb25zdGl0dWVudCBjYW5kaWRh dGUNCg0KICAgcGF0aHMgdW5kZXIgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGg6DQoNCg0KDQog ICBvICB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggTVVT VCBiZQ0KDQogICAgICBpZ25vcmVkLg0KDQoNCg0KICAgbyAgdGhlIGNvbnN0aXR1ZW50IGNhbmRp ZGF0ZSBwYXRoIE1VU1QgTk9UIGJlIGEgY29tcG9zaXRlIGNhbmRpZGF0ZQ0KDQogICAgICBwYXRo DQoNCg0KDQogICBFYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIG9mIGEgY29tcG9zaXRl IGNhbmRpZGF0ZSBwYXRoIGlzDQoNCiAgIGFzc29jaWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9h ZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyDQoNCiAgIFNlY3Rpb24gMi4xMTxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eS0wOSNzZWN0aW9uLTIuMTE+IGZvciBkZXRhaWxzKS4gIFRoZSBkZWZhdWx0IHdlaWdodCBpcyAx Lg0KDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rpb24gMi4xMQ0KDQoNCg0KT0xEOg0KICAgV2hlbiBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93 cw0KICAgc3RlZXJlZCBpbnRvIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIGVxdWFsIHRv IHRoZSByZWxhdGl2ZQ0KICAgd2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5LiAg RnVydGhlciBsb2FkIGJhbGFuY2luZyBvZg0KICAgZmxvd3Mgc3RlZXJlZCBpbnRvIGEgY29uc3Rp dHVlbnQgU1IgUG9saWN5IGlzIHBlcmZvcm1lZCBiYXNlZCBvbiB0aGUNCiAgIHdlaWdodHMgb2Yg dGhlIFNlZ21lbnQtTGlzdCBvZiB0aGUgYWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9mIHRoYXQNCiAg IGNvbnN0aXR1ZW50IFNSIFBvbGljeS4NCg0KDQoNCk5FVzoNCiAgIFdoZW4gYSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggaXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3MNCiAgIHN0ZWVy ZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIGlzIGVxdWFsIHRvIHRoZSBy ZWxhdGl2ZQ0KICAgd2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGguICBG dXJ0aGVyIGxvYWQgYmFsYW5jaW5nIG9mDQogICBmbG93cyBzdGVlcmVkIGludG8gYSBjb25zdGl0 dWVudCBjYW5kaWRhdGUgcGF0aCBpcyBwZXJmb3JtZWQgYmFzZWQgb24NCiAgIHRoZSB3ZWlnaHRz IG9mIGVhY2ggYXNzb2NpYXRlZCBTZWdtZW50LUxpc3QuDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rp b24gMi4xMw0KDQoNCg0KT0xEOg0KICAgVGhlIGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGlj eSBQT0wxMDAgaGF2aW5nIGEgY29tcG9zaXRlDQogICBjYW5kaWRhdGUgcGF0aCBpcyB0aGUgZm9s bG93aW5nOg0KDQogICBTUiBwb2xpY3kgUE9MMTAwIDxoZWFkZW5kID0gSDEsIGNvbG9yID0gMTAw LCBlbmRwb2ludCA9IEUxPg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDEgPHByb3RvY29sLW9y aWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0g MT4NCiAgICAgICAgICAgIFByZWZlcmVuY2UgMjAwDQogICAgICAgICAgICBXZWlnaHQgVzEsIFNS IHBvbGljeSA8Y29sb3IgPSAxPg0KICAgICAgICAgICAgV2VpZ2h0IFcyLCBTUiBwb2xpY3kgPGNv bG9yID0gMj4NCg0KICAgVGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIFBPTDEgYW5kIFBPTDIg aGF2ZSBpbmZvcm1hdGlvbiBtb2RlbCBhcw0KICAgZGVzY3JpYmVkIGF0IHRoZSBzdGFydCBvZiB0 aGlzIHNlY3Rpb24uICBUaGV5IGFyZSByZWZlcmVuY2VkIG9ubHkgYnkNCiAgIGNvbG9yIGluIHRo ZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggc2luY2UgdGhlaXIgaGVhZGVuZCBhbmQNCiAgIGVu ZHBvaW50IGFyZSBpZGVudGljYWwgdG8gdGhlIFBPTDEwMC4gIFRoZSB2YWxpZCBTZWdtZW50LUxp c3RzIG9mIHRoZQ0KICAgYWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9mIFBPTDEgYW5kIFBPTDIgYXJl IGluc3RhbGxlZCBpbiB0aGUNCiAgIGZvcndhcmRpbmcuICBUcmFmZmljIHN0ZWVyZWQgb24gUE9M MTAwIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIFBPTDENCiAgIHdpdGggYSByYXRpbyBXMS8oVzEr VzIpLiAgV2l0aGluIHRoZSBQT0wxLCB0aGUgZmxvdy1iYXNlZCBoYXNoaW5nDQogICBvdmVyIGl0 cyBTZWdtZW50LUxpc3RzIGFyZSBwZXJmb3JtZWQgYXMgZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhp cw0KICAgc2VjdGlvbi4NCg0KDQoNCk5FVzoNCiAgIFRoZSBpbmZvcm1hdGlvbiBtb2RlbCBvZiBT UiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZQ0KICAgY2FuZGlkYXRlIHBhdGggaXMg dGhlIGZvbGxvd2luZzoNCg0KICAgU1IgcG9saWN5IFBPTDEwMCA8aGVhZGVuZCA9IEgxLCBjb2xv ciA9IDEwMCwgZW5kcG9pbnQgPSBFMT4NCiAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ29tcC1DUCA8 cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPQ0KICAgMTAwOjEuMS4xLjEsIGRpc2Ny aW1pbmF0b3IgPSAxPg0KICAgICAgICAgICAgUHJlZmVyZW5jZSAyMDANCiAgICAgICAgICAgIFdl aWdodCBXMSwgQ2FuZGlkYXRlLXBhdGggQ1AxDQogICAgICAgICAgICBXZWlnaHQgVzIsIENhbmRp ZGF0ZS1wYXRoIENQMg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDEgPHByb3RvY29sLW9yaWdp biA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMj4N CiAgICAgICAgICAgICBXZWlnaHQgVzExLCBTSUQtTGlzdDEgPFNJRDExLi4uU0lEMWk+DQogICAg ICAgICAgICAgV2VpZ2h0IFcxMiwgU0lELUxpc3QyIDxTSUQyMS4uLlNJRDJqPg0KICAgICAgICBD YW5kaWRhdGUtcGF0aCBDUDIgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAg IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMz4NCiAgICAgICAgICAgICBXZWlnaHQgVzIx LCBTSUQtTGlzdDMgPFNJRDMxLi4uU0lEM2k+DQogICAgICAgICAgICAgV2VpZ2h0IFcyMiwgU0lE LUxpc3Q0IDxTSUQ0MS4uLlNJRDRqPg0KDQogICBDb21wLUNQIGlzIGEgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoIHdpdGggdHdvIGNvbnN0aXR1ZW50cywgQ1AxDQogICBhbmQgQ1AyLiBUaGUgcHJl ZmVyZW5jZSBpcyBpZ25vcmVkIGZvciBlYWNoIG9mIHRoZSB0d28gY29uc3RpdHVlbnQNCiAgIGNh bmRpZGF0ZSBwYXRocy4gVGhlIHZhbGlkIFNlZ21lbnQtTGlzdHMgb2YgdGhlIHR3byBjb25zdGl0 dWVudA0KICAgY2FuZGlkYXRlIHBhdGhzIGFyZSBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcu IFRyYWZmaWMgc3RlZXJlZA0KICAgb24gQ29tcC1DUCBpcyBmbG93LWJhc2VkIGhhc2hlZCBvbiB0 byBDUDEgYW5kIENQMiB3aXRoIGEgcmF0aW8gb2YNCiAgIFcxLyhXMStXMikgYW5kIFcyLyhXMStX MikgcmVzcGVjdGl2ZWx5LiBXaXRoaW4gZWFjaCBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBh dGgsIHRoZSBmbG93LWJhc2VkIGhhc2hpbmcgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUNCiAg IHBlcmZvcm1lZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzIHNlY3Rpb24uDQoNCg0KKioN Cg0KDQoNCioqIFNlY3Rpb24gNS4zDQoNCg0KDQpPTEQ6DQogICBBIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aCBpcyBzcGVjaWZpZWQgYXMgYSBncm91cCBvZiBpdHMgY29uc3RpdHVlbnQNCiAgIFNS IFBvbGljaWVzLg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyB2YWxpZCB3aGVu IGl0IGhhcyBhdCBsZWFzdCBvbmUgdmFsaWQNCiAgIGNvbnN0aXR1ZW50IFNSIFBvbGljeS4NCg0K DQoNCk5FVzoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHNwZWNpZmllZCBhcyBh IGdyb3VwIG9mIGl0cyBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBhdGhzLg0KDQogICBBIGNv bXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyB2YWxpZCB3aGVuIGl0IGhhcyBhdCBsZWFzdCBvbmUg dmFsaWQNCiAgIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLg0KDQoNCioqDQoNCg0KDQpSZWdh cmRzLA0KDQotUGF2YW4NCg0KDQoNCk9uIFN1biwgTm92IDEsIDIwMjAgYXQgNzowMiBQTSBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIZWxsbyBBbGwsDQoN CldlIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlIGZvciB0aGUgZHJhZnQgYW5kIGZvbGxvd2lu ZyBpcyB0aGUgc3VtbWFyeSBvZiBjaGFuZ2VzOg0KDQoxKSBJbnRyb2R1Y3Rpb24gb2YgdGhlIENv bXBvc2l0ZSBDYW5kaWRhdGUgUGF0aCBjb25zdHJ1Y3QgdG8gYWRkcmVzcyBhIHBlbmRpbmcgY29t bWVudCBmcm9tIHRoZSBXRyAoUmVmIDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9zcHJpbmcvZkVxRTVUT3dkaDJ2RXlGbV9NRWppWHlQMndzLyBhbmQgaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZDlvU1NiZ3AwakNFeFJ4MFNYeUJZMEN5 cVhVLykNCjIpIEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2 NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9y IGluc3RlYWQgb2YgdGhlIG5ldyB0eXBlIHRoYXQgd2FzIGludHJvZHVjZWQgZm9yIGl0IGluIHRo ZSB2MDguDQozKSBDbGFyaWZpY2F0aW9uIG9mIGhhbmRsaW5nIG9mIGNvbG9ycyBhbmQgQkdQIG11 bHRpLXBhdGggc2NlbmFyaW9zIGJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQuDQo0 KSBDbGFyaWZpY2F0aW9uIG9uIGNvbnNpZGVyYXRpb25zIGZvciBUSS1MRkEgZm9yIFNSIFBvbGlj eSBhcyBkaXNjdXNzZWQgaW4gdGhlIFdHIChSZWYgOiBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvKQ0KDQpQbGVh c2UgbGV0IGtub3cgeW91ciBjb21tZW50cy9mZWVkYmFjay4NCg0KVGhhbmtzLA0KS2V0YW4gKG9u IGJlaGFsZiBvZiBjby1hdXRob3JzKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiAwMiBOb3ZlbWJlciAyMDIwIDA2OjI3DQpU bzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpD Yzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3By aW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LTA5LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIFNvdXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIFdHIG9mIHRo ZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFNlZ21lbnQgUm91dGluZyBQb2xp Y3kgQXJjaGl0ZWN0dXJlDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENsYXJlbmNlIEZpbHNm aWxzDQogICAgICAgICAgICAgICAgICAgICAgICAgIEtldGFuIFRhbGF1bGlrYXINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgRGFuaWVsIFZveWVyDQogICAgICAgICAgICAgICAgICAgICAgICAg IEFsZXggQm9nZGFub3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBNYXR0ZXMNCiAg ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LXBvbGljeS0wOS50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMzcNCiAgICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAyMC0xMS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFNlZ21lbnQgUm91dGlu ZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93DQogICBh bG9uZyBhbnkgcGF0aC4gIEludGVybWVkaWF0ZSBwZXItZmxvdyBzdGF0ZXMgYXJlIGVsaW1pbmF0 ZWQgdGhhbmtzDQogICB0byBzb3VyY2Ugcm91dGluZy4gIFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJz IGEgZmxvdyBpbnRvIGFuIFNSIFBvbGljeS4NCiAgIFRoZSBoZWFkZXIgb2YgYSBwYWNrZXQgc3Rl ZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVudGVkIHdpdGggYW4NCiAgIG9yZGVyZWQgbGlz dCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQb2xpY3kuICBUaGlzDQogICBk b2N1bWVudCBkZXRhaWxzIHRoZSBjb25jZXB0cyBvZiBTUiBQb2xpY3kgYW5kIHN0ZWVyaW5nIGlu dG8gYW4gU1INCiAgIFBvbGljeS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kvDQoNClRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMDkNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K --_000_MW3PR11MB4570D601ADC0D8E24B6B2675C1E90MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTpnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t SU47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFBhdmFu LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5QbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFZpc2hudSBQYXZhbiBCZWVyYW0gJmx0O3Zpc2hu dXBhdmFuQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxMCBOb3ZlbWJlciAyMDIw IDAwOjA4PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRh bnRAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPktldGFuLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPk11Y2ggVGhhbmtzIGZvciB0YWtpbmcgYSBzdGFiIGF0IGFkZHJlc3NpbmcgdGhlIGNv bXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB1c2UtY2FzZSE8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDtXZSBzZWVtIHRvIGJlIGNvbnZlcmdpbmcuPC9zcGFuPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bS1RdIFRoYW5rcyBmb3IgdGhhdCBmZWVk YmFjayBhbmQgY29uZmlybWF0aW9uIHRoYXQgdGhlIHByb3Bvc2FsIGluIHRoZSBkcmFmdCBkb2Vz IGFkZHJlc3MgdGhlIHVzZS1jYXNlLiBJIGJlbGlldmUgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIHRo ZSBtZWNoYW5pY3Mgb2YgaG93IHRoaXMgaXMgYWNoaWV2ZWQgd2l0aGluIHRoZSBjdXJyZW50IFNS IFBvbGljeSBmcmFtZXdvcmsuPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SG93ZXZl ciwgSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHlvdSBuZWVkIHRvIHVzZSBhZGRpdGlvbmFsIFNS IHBvbGljaWVzIChhbmQgdW5uZWNlc3NhcmlseSBidXJuIGFkZGl0aW9uYWwgY29sb3JzKSB0byBh ZGRyZXNzIHRoaXMuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltLVF0gSSBkbyBu b3QgZm9sbG93IHdoYXQgeW91IG1lYW4gYnkg4oCcYnVybiBhZGRpdGlvbmFsIGNvbG9yc+KAnS4g Q29sb3IgaXMganVzdCBhIDMyIGJpdCBudW1iZXIgdGhhdCBpbmRpY2F0ZXMgdGhlIOKAnGludGVu dOKAnSBhbmQgaXMgbm90IHJlYWxseSBhIHNjYXJjZSByZXNvdXJjZS4gQXNzaWduaW5nIGEgY29s b3IgdG8g4oCcYSBjb21wb3NpdGUgaW50ZW504oCdIHNlZW1zIGxpa2UgYSBzZWFtbGVzcyB3YXkg dG8NCiBpbnRlZ3JhdGUgd2l0aCBleGlzdGluZyBtZWNoYW5pc21zIGZvciBTdGVlcmluZyBvdmVy IFNSIFBvbGljaWVzLiBUaGlzIGdpdmVzIHRoZSBmbGV4aWJpbGl0eSBmb3Igc2F5IHNvbWUgQkdQ IHNlcnZpY2VzIHRvIGJlIHN0ZWVyZWQgb3ZlciB0aGUgY29uc3RpdHVlbnQgZXhwbGljaXQvZHlu YW1pYyBpbnRlbnQgd2hpbGUgb3RoZXJzIGNhbiBzdGVlciBvdmVyIGEgY29tcG9zaXRlIGludGVu dCB0aGF0IGluY2x1ZGVzIHRob3NlIGluZGl2aWR1YWwNCiBleHBsaWNpdC9keW5hbWljIGludGVu dHMuPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxv OnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+V2h5IGNhbuKAmXQgdGhlIGNvbXBv c2l0ZSBjYW5kaWRhdGUgcGF0aCBqdXN0IGJlIGEgZ3JvdXBpbmcgb2YgZXhwbGljaXQgY2FuZGlk YXRlIHBhdGhzIGFuZC9vciBkeW5hbWljIGNhbmRpZGF0ZSBwYXRocz88L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPltLVF0gVGhpcyBpcyBiZWNhdXNlIGluIHRoZSBTUiBQb2xpY3kgZnJh bWV3b3JrLCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIGFjdGl2ZSBDUCDigJMgaXQgbWF5IGJlIGV4 cGxpY2l0IG9yIGR5bmFtaWMuIE5vdyB3ZeKAmXZlIGFkZGVkIGFub3RoZXIgQ29tcG9zaXRlIENQ IHR5cGUgdG8gY292ZXIgdGhpcyBzcGVjaWZpYyB1c2UtY2FzZS4gWW91ciBwcm9wb3NhbCB3aWxs IHJlc3VsdCBpbiAzIGNhbmRpZGF0ZQ0KIHBhdGhzIGJlaW5nIGFjdGl2ZSB3aXRoaW4gdGhlIHNh bWUgU1IgUG9saWN5IOKAkyBvbmUgZWFjaCBvZiB0aGUgZXhwbGljaXQgYW5kIGR5bmFtaWMgQ1Ag YW5kIHRoZW4gYWRkaXRpb25hbGx5IHRoZSBDb21wb3NpdGUgQ1AuIFRoaXMgYnJlYWtzIHRoZSBl eGlzdGluZyBydWxlcyBmb3Igc2VsZWN0aW9uIG9mIENQIGJhc2VkIG9uIHByZWZlcmVuY2UgYW5k IG1lY2hhbmlzbXMgbGlrZSBmYWxsYmFjayBiZXR3ZWVuIENQcy4gV2hpbGUgdGhlIGN1cnJlbnQN CiBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgcHJvdmlkZXMgYSB3YXkgdG8gYWRkcmVzcyB0aGUgbmV3 IHVzZS1jYXNlIHdpdGggYSBiYWNrd2FyZHMgY29tcGF0aWJsZSBleHRlbnNpb24gdG8gdGhlIFNS IFBvbGljeSBmcmFtZXdvcmsuPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT5UaGFua3MsPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPktldGFuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Db25zaWRlciB0aGUgZm9sbG93aW5nIGNoYW5nZXM6 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Kiog U2VjdGlvbiAyLjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBBIGNvbXBvc2l0ZSBjYW5k aWRhdGUgcGF0aCBhY3RzIGFzIGEgY29udGFpbmVyIGZvciBncm91cGluZyBvZiBTUjwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgUG9saWNpZXMuJm5ic3A7IFRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGggY29uc3RydWN0IGVuYWJsZXMgY29tYmluYXRpb248L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9m IFNSIFBvbGljaWVzLCBlYWNoIHdpdGggZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBk eW5hbWljPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMgd2l0aCBwb3RlbnRp YWxseSBkaWZmZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXM8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGFuZCBjb25zdHJhaW50cywgZm9yIGEgbG9hZC1iYWxhbmNlZCBzdGVlcmluZyBvZiBwYWNr ZXQgZmxvd3Mgb3Zlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaXRzIGNvbnN0aXR1ZW50IFNSIFBv bGljaWVzLiZuYnNwOyBUaGUgZm9sbG93aW5nIGNyaXRlcmlhIGFwcGx5IGZvcjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgaW5jbHVzaW9uIG9mIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIHVzaW5nIGEg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB1bmRlciBhIHBh cmVudCBTUiBQb2xpY3k6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZu YnNwOyB0aGUgZW5kcG9pbnRzIG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhl IHBhcmVudCBTUjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUG9saWN5 IE1VU1QgYmUgaWRlbnRpY2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg byZuYnNwOyBUaGUgY29sb3JzIG9mIGVhY2ggb2YgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVz IGFuZCB0aGUgcGFyZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT UiBQb2xpY3kgTVVTVCBiZSBkaWZmZXJlbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBvJm5ic3A7IHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBNVVNUIE5PVCB1c2Ug Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IEVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0 ZSBwYXRoIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGggYSB3ZWlnaHQg Zm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChyZWZlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1wb2xpY3ktMDkjc2VjdGlvbi0yLjExIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+U2VjdGlvbiAyLjExPC9zcGFuPjwvYT4gZm9yIGRldGFpbHMpLiZuYnNwOyBUaGUg ZGVmYXVsdCB3ZWlnaHQgaXMgMS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5FVzo8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBj b250YWluZXIgZm9yIGdyb3VwaW5nIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBleHBsaWNpdCBj YW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMgY2FuZGlkYXRlIHBhdGhzIHdpdGggPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO3BvdGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24g b2JqZWN0aXZlcyBhbmQgY29uc3RyYWludHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgY29t cG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGxvYWQtYmFsYW5jZWQ8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IHN0ZWVyaW5nIG9mIHBhY2tldC1mbG93cyBvdmVyIGEgc2V0IG9m IGNvbnN0aXR1ZW50IGNhbmRpZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGF0aHMuIFRoZSBm b2xsb3dpbmcgY3JpdGVyaWEgYXBwbHkgZm9yIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSA8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtwYXRocyB1bmRlciBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aDo8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIHByZWZlcmVuY2Ugb2YgdGhlIGNvbnN0 aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIE1VU1QgYmUgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7aWdub3JlZC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IHRo ZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIE5PVCBiZSBhIGNvbXBvc2l0ZSBjYW5k aWRhdGUgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhdGg8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBFYWNoIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRoIG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGggYSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1 cnBvc2VzIChyZWZlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDkjc2VjdGlvbi0yLjExIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAyLjEx PC9zcGFuPjwvYT4gZm9yIGRldGFpbHMpLiZuYnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS48 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4qKiBTZWN0aW9uIDIuMTE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUg cGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zdGVlcmVk IGludG8gZWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kgaXMgZXF1YWwgdG8gdGhlIHJlbGF0aXZl PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPndlaWdodCBvZiBlYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeS4mbmJzcDs8 c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnVy dGhlciBsb2FkIGJhbGFuY2luZyBvZjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mbG93cyBzdGVlcmVkIGludG8gYSBj b25zdGl0dWVudCBTUiBQb2xpY3kgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj53ZWlnaHRzIG9mIHRoZSBTZWdtZW50LUxpc3Qgb2YgdGhlIGFjdGl2ZSBjYW5kaWRhdGUgcGF0 aCBvZiB0aGF0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5F Vzo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5k aWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5z dGVlcmVkIGludG8gZWFjaCBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBpcyBlcXVhbCB0byB0 aGUgcmVsYXRpdmU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgY2FuZGlk YXRlIHBhdGguJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkZ1cnRoZXIgbG9hZCBiYWxhbmNpbmcgb2Y8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Zmxvd3Mg c3RlZXJlZCBpbnRvIGEgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggaXMgcGVyZm9ybWVkIGJh c2VkIG9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPnRoZSB3ZWlnaHRzIG9mIGVhY2ggYXNzb2NpYXRlZCBTZWdtZW50 LUxpc3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDIuMTM8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGhlIGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2 aW5nIGEgY29tcG9zaXRlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dp bmc6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIHBvbGljeSBQT0wxMDAgJmx0O2hlYWRlbmQgPSBI MSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0gRTEmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENQMSAmbHQ7cHJvdG9jb2wtb3JpZ2lu ID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRv ciA9IDEmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlByZWZlcmVuY2UgMjAwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMSwgU1Ig cG9saWN5ICZsdDtjb2xvciA9IDEmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMiwgU1IgcG9saWN5ICZs dDtjb2xvciA9IDImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZSBjb25zdGl0dWVudCBTUiBQ b2xpY2llcyBQT0wxIGFuZCBQT0wyIGhhdmUgaW5mb3JtYXRpb24gbW9kZWwgYXM8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+ZGVzY3JpYmVkIGF0IHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uJm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZXkgYXJlIHJl ZmVyZW5jZWQgb25seSBieTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb2xvciBpbiB0aGUgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoIHNpbmNlIHRoZWlyIGhlYWRlbmQgYW5kPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmVuZHBvaW50IGFy ZSBpZGVudGljYWwgdG8gdGhlIFBPTDEwMC4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIHZhbGlkIFNlZ21lbnQtTGlzdHMgb2Yg dGhlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPmFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiBQT0wxIGFuZCBQT0wyIGFy ZSBpbnN0YWxsZWQgaW4gdGhlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZvcndhcmRpbmcuJm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRyYWZmaWMgc3Rl ZXJlZCBvbiBQT0wxMDAgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gUE9MMTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53 aXRoIGEgcmF0aW8gVzEvKFcxK1cyKS4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2l0aGluIHRoZSBQT0wxLCB0aGUgZmxvdy1iYXNl ZCBoYXNoaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm92ZXIgaXRzIFNlZ21lbnQtTGlzdHMgYXJlIHBlcmZvcm1l ZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNlY3Rpb24uPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZSBpbmZvcm1hdGlv biBtb2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5jYW5kaWRhdGUgcGF0aCBpcyB0aGUgZm9sbG93aW5nOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5T UiBwb2xpY3kgUE9MMTAwICZsdDtoZWFkZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9 IEUxJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5kaWRhdGUtcGF0aCBDb21w LUNQICZsdDtwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjEw MDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMSZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UHJlZmVyZW5jZSAyMDA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2Vp Z2h0IFcxLCBDYW5kaWRhdGUtcGF0aCBDUDE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcyLCBDYW5kaWRhdGUt cGF0aCBDUDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENQMSAmbHQ7cHJvdG9jb2wtb3Jp Z2luID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAyJmd0Ozwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5XZWlnaHQgVzExLCBTSUQtTGlzdDEgJmx0O1NJRDExLi4uU0lEMWkmZ3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPldlaWdodCBXMTIsIFNJRC1MaXN0MiAmbHQ7U0lEMjEuLi5TSUQyaiZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FuZGlkYXRlLXBhdGggQ1AyICZsdDtwcm90b2NvbC1v cmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDMmZ3Q7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPldlaWdodCBXMjEsIFNJRC1MaXN0MyAmbHQ7U0lEMzEuLi5TSUQzaSZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+V2VpZ2h0IFcyMiwgU0lELUxpc3Q0ICZsdDtTSUQ0MS4uLlNJRDRqJmd0Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBDb21wLUNQIGlzIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHdpdGggdHdvIGNvbnN0 aXR1ZW50cywgQ1AxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFuZCBDUDIuIFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9y ZWQgZm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0dWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMuIFRo ZSB2YWxpZCBTZWdtZW50LUxpc3RzIG9mIHRoZSB0d288c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29uc3RpdHVlbnQNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUg cGF0aHMgYXJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZy4mbmJzcDtUcmFmZmljIHN0ZWVy ZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDtvbg0KPC9zcGFuPkNvbXAtQ1AgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gdG8gQ1Ax IGFuZCBDUDIgd2l0aCBhIHJhdGlvIG9mPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFcxLyhXMStXMikgYW5kIFcy LyhXMStXMikgcmVzcGVjdGl2ZWx5LiBXaXRoaW4gZWFjaCBjb25zdGl0dWVudA0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNhbmRp ZGF0ZSBwYXRoLCB0aGU8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+Zmxvdy1iYXNlZCBoYXNoaW5nIG92ZXIgaXRzIFNlZ21lbnQtTGlzdHMgYXJl DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcGVyZm9ybWVkIGFzPHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPmRlc2NyaWJlZCBlYXJsaWVyIGluIHRoaXMgc2VjdGlvbi48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUg c3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Kio8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPioqIFNlY3Rpb24gNS4zPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkEgY29tcG9zaXRlIGNh bmRpZGF0ZSBwYXRoIGlzIHNwZWNpZmllZCBhcyBhIGdyb3VwIG9mIGl0cyBjb25zdGl0dWVudDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5TUiBQb2xpY2llcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iZ21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggaXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5FVzo8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3Bl Y2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0 ZSBwYXRocy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg aXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0 aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4qKjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LVBhdmFuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBOb3Yg MSwgMjAyMCBhdCA3OjAyIFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudD08 YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KV2UgaGF2 ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGUgZm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRo ZSBzdW1tYXJ5IG9mIGNoYW5nZXM6PGJyPg0KPGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBD b21wb3NpdGUgQ2FuZGlkYXRlIFBhdGggY29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNv bW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nwcmlu Zy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlC WTBDeXFYVS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS88L2E+KTxicj4NCjIp IEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50 IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQg b2YgdGhlIG5ldyB0eXBlIHRoYXQgd2FzIGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguPGJy Pg0KMykgQ2xhcmlmaWNhdGlvbiBvZiBoYW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1w YXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBvZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLjxicj4NCjQp IENsYXJpZmljYXRpb24gb24gY29uc2lkZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5 IGFzIGRpc2N1c3NlZCBpbiB0aGUgV0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAv IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvPC9hPik8YnI+DQo8YnI+DQpQbGVh c2UgbGV0IGtub3cgeW91ciBjb21tZW50cy9mZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KS2V0YW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKTxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48 YnI+DQpTZW50OiAwMiBOb3ZlbWJlciAyMDIwIDA2OjI3PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0 bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0 Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW3NwcmluZ10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8 YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcg V0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRp dGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFNlZ21lbnQgUm91 dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyZW5jZSBGaWxz Zmlsczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLZXRhbiBUYWxhdWxp a2FyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhbmllbCBWb3llcjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGV4IEJvZ2Rhbm92PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhdWwgTWF0dGVzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogMzc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0 ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0xMS0wMTxi cj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRpbmcgKFNS KSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgZmxvdzxicj4NCiZuYnNw OyAmbmJzcDthbG9uZyBhbnkgcGF0aC4mbmJzcDsgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRl cyBhcmUgZWxpbWluYXRlZCB0aGFua3M8YnI+DQombmJzcDsgJm5ic3A7dG8gc291cmNlIHJvdXRp bmcuJm5ic3A7IFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGlj eS48YnI+DQombmJzcDsgJm5ic3A7VGhlIGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFu IFNSIFBvbGljeSBpcyBhdWdtZW50ZWQgd2l0aCBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlcmVk IGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBU aGlzPGJyPg0KJm5ic3A7ICZuYnNwO2RvY3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNS IFBvbGljeSBhbmQgc3RlZXJpbmcgaW50byBhbiBTUjxicj4NCiZuYnNwOyAmbmJzcDtQb2xpY3ku PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDki IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOTwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDk8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50 b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmlu Z0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW3PR11MB4570D601ADC0D8E24B6B2675C1E90MW3PR11MB4570namp_-- From nobody Tue Nov 10 07:33:30 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DE83A0147; Tue, 10 Nov 2020 07:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=Z1u/sJAB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W/3DJW73 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13d57tX9eBCc; Tue, 10 Nov 2020 07:33:19 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DAE3A0138; Tue, 10 Nov 2020 07:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=181660; q=dns/txt; s=iport; t=1605022399; x=1606231999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vaYDYJ9QqH6R2NSMo0LlSXz69/2uUgcdgeWmuhwJ9Xs=; b=Z1u/sJABTi0q+lnUscAmBUsYxfaDrgE0VD1qlRmiPGAlmxe0FblyxbxO iT1b5g2nYFOVlRdKuTcEy44rqZqhVC/AZUqis9ZRIjn4MqMX1H7Kd7bYz fJN7ZEkHZ6HGENe7jq5BAkjGG8F9SzWcSiWtjY0PR9/47mzGl+VVks2ZC o=; X-IPAS-Result: =?us-ascii?q?A0D5CAA1sqpffZ1dJa1igQmCci8jLntZLy4Kh3wDjVaBB?= =?us-ascii?q?Zd9gUKBEQNPBQsBAQENAQEYAQoKAgQBAYQGRAKCFAIlOBMCAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBBQBAYY8DIVyAQEBBAEBEAgBAiMBASkDBAcBDwIBCBEDAQIhA?= =?us-ascii?q?QIEBycLFAkIAQEEAQ0FCBMHgwWBflcDLgEOo1ECgTuIaHSBNIMEAQEFgTMBA?= =?us-ascii?q?wIOQYMFGIIQAwaBOIJziAGBIIErG4FBP4EQAUOCGjU+gl0BAQMBgR0EEQEOH?= =?us-ascii?q?AUZBgcJAoMSgiyQGhoaIgOKDyeDAogvNZASgQwKgm2JDYpphzyCBlg6ihWFT?= =?us-ascii?q?IMQi2uGHo0zgX+Ie5VPAgQCBAUCDgEBBYFrIYFZcBU7gjUBATJQFwINjisXF?= =?us-ascii?q?BiDIoUUhUMBdAI2AgYKAQEDCXyLBgEngQ0BgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AOZ2QYhC7bCxLsgt+Z4wNUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3GWIza77RPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208,217";a="622567682" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 15:33:09 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AAFX2io006758 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 15:33:08 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 09:33:04 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 09:33:03 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 09:33:03 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QXYWH7koyddBENk3CThWr3eoAh59+QxE1oFTeyepyyK777ZR+dMpUW9/FQHSbVuucTNR3bnxPq//MlZ3NzglyqhJDthWX2RxGW3MjHE9PZOHSlLG1Uo0y6nB5QENNDbj6a4XSZoSgOEZ+e6yAFDryD2bcJ3w7n7JdXRkMmzg7efpBLLcNU/sAuvZYHdpZ8ZnFtGnBv3YNAPcoIqnWTUOBp4c9svzxGEAOBM2hDQt57wexrmK3DpJSrxOVEWiAxHwapd9zunQo2K3kfaR1MNpT5uYfUn4eUFlC6SL5h8lMHtn5xnzpGQyVUWgOg+GD4q0TFK95WShakdWnYw53J47vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rcGWuo2QDrzTnEfzmA5KmrxjcG1ySjqDfnL2KzGrV9k=; b=H9660ZrzBKj9kQeUSwOqlyVD827spyseLq10GGBiqqU/VKUrvx1u6thTHd+d0xbj9/T24vxTGRoVBRrd9zlzyvKIcY1lerT1/1y496UAOO2FObY3FKVmIji0vB60Y+w+JERvHLTyOO3kkdYS8F+jzCZbPAC1TR18+KwjSxlf9FFTlMT5EWe1PWGWUBGXqPkNclMx7ohSB551w2LhocVwNyhM8YHwo+du32VjjR3wJcB/mdx0rq3+rTzzvA3+7jM+Ghv3GZSrZmIjmWhmKIudYWGNxIChHAOADJUi14LqZH/eBDiuol+fr45fXtpAQLDJQvVCVKmue+IJI+zJ/a1IZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rcGWuo2QDrzTnEfzmA5KmrxjcG1ySjqDfnL2KzGrV9k=; b=W/3DJW73zGqU2OXBsuhpNh68X3L72i63naqdt2k3jIS8A0HM3OJ5/EsMMJuu93BLik+8VmpN7kBur4oxeCZRgNWMO2OoB3lOHW86mc/0zJ1qVQ66DNyB6BhVh5XZcOIWsDtnu2+HTtzOL8Kw9IaQj3xV8x2Y6z6wPXTnW4u8UQc= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 15:33:01 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36%7]) with mapi id 15.20.3541.024; Tue, 10 Nov 2020 15:33:01 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky , James Guichard CC: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQL6RqWAAMdcBWE= Date: Tue, 10 Nov 2020 15:33:01 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8fd304c-e97d-495c-d66c-08d8858de8b7 x-ms-traffictypediagnostic: DM6PR11MB3115: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w9PBp0MonRfbjp4XUvlYTjpF+Omz2gLyjrIwoimQWhLd07rQ3v2sP2FxkRFN/VF2k2RZkkP9ZcHbv7T3dRbb1e8XTjcEBxFeoPyQsglXKU0Gqk6R8FVTGCRvq/kjvwTdr2QrCf/XTF/TpHBaxVQwQiBc9xlBiTvkcsQm+kIkKfwt8qdvC9Ok2sxZtHVY8NDDOLbSyTvQwDezXN2yTtlfBiKOFJOQP8gF5DmedDwyXUE37M1YEq1MgemUGDFIIeYNhCweXob3JeSnc1Gug4vwjtTTNH4nkA37wRK25HSMVpnDQZ8nL7FgqDUa77idi1bTaWdJpZPvfBCH4bZSjmozILZrFIe79poAbo44G7X1UycE/yP1CbF7PWNfUQ43G31idRnADsXKuZ17O1LWDqP1Mw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(136003)(366004)(346002)(396003)(71200400001)(7696005)(6506007)(186003)(53546011)(316002)(110136005)(83380400001)(5660300002)(8676002)(8936002)(2906002)(30864003)(33656002)(55016002)(86362001)(54906003)(66946007)(66446008)(64756008)(66556008)(66476007)(52536014)(166002)(76116006)(91956017)(478600001)(9686003)(4326008)(26005)(966005)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WqCPGixnZqn69CDc2asoiCVthC6g5IivBqc9/dDh0GK4nFZ4eKQpOueKZN+N4YVJ/OKZwegywPUbSJrQRlv1zfpT5MYsPP9I51ojwzJbc/WywyMgwNNT5FuzO1AxFFlL0FxVVeJJ79gZScw5bOi1NHtox8RUe62VO/B3FXpzR6ztZkscUsTa8tjEoW9+jmoGUtCBjA9ULCC0fOp+/e+aBpIdhBWIWh7MFRqb97A47o1W8xoLQeUeCMFztElcJ1DDy8w3mBUPxjij+dWVxRo4Ona51r8BZ6UMM/9Gwibx019qXarUNE2oaslFLF5tX/au6hKM2HqQYQoFwqKFVSkiCsm2uNNK7RBJqzxROKfIL9jCZYsQGhy/DgD9NcxI5cabwsQTgfb73cBRlVra57IA9S682k0hcQvrlM6JGVZhsQgM4mZgLSRsjuVz2oi0MSAyqpsNaOym0kxwUc2ObOudVQcMxnQ0S6/0f37cbAl3qe3pQ6HYmv82QnnkcB2HCcPlP2p71m0xPfCc3H0XuoyRrKcIUfG4+2Nhbi7HymhMcBa97n/lNfbA2GtXs8n3Grj0TcMOFG05m3JbT90m2gXaMfy1uSnDz629fVpPYjQkIC45/XfoCt7s05yUBqCdw7Dh22UnYrJUQinHUBlfcyK/zpOosdtVbGo9G0nosR8Xy+zuopSkYOkl7MmaR2iEBpqvg5htGj6zsDr7YoReBm0ii0CgjXdAY89shwqyePUA6O1jMWhJfPb6GEfYEnKlVmhW0u5CJoW3r3TZZn5wKVGutfh+C2evgkwW1TLRhk7RKIC9GwKP2c90kE73qEm1+IPFs/VvUjmM0pcmctxA01QO7+yk7D8aLFAd67f2C+E/LtM/bo51y54DdWoegG/5ADsu+Fkhf44glIwnZngoAcIB2w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3115E21076C99CDE5D0B4B25BFE90DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8fd304c-e97d-495c-d66c-08d8858de8b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 15:33:01.3340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 24/hir1K6AQbwgiWqxmH+et2cvs0OpGXQGTLaCVQcbud+p9eJt7QTCBLqEiVgcL6IQuanxPM5UXHkanCBcn8iQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3115 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 15:33:26 -0000 --_000_DM6PR11MB3115E21076C99CDE5D0B4B25BFE90DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard Cc: spring@ietf.org , ippm-chairs@ietf.org , spring-chairs@ietf.org , IETF IPPM WG Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. * several parts of the proposed protocol, e.g., Zero UDP checksum in IP= v6, require detailed security analysis, which is currently absent; This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. * I believe that draft-gandhi-spring-twamp-srpm should be anchored at I= PPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, I= don't think we can have a draft that proposes extensions to a non-standard= mechanism (Appendix is for Informational material, as I understand it) on = the Standard track. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Quoting the text from Appendix I in RFC 5357. We can quote the text as= is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 * Further, in Section 3 the selection of UDP port explained as the foll= owing: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? This is user-defined and is up to the user what UDP port to provision = in a domain. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? As mentioned earlier, I am not sure extending ICMP to do PM is a good = option here. Both TWAMP and OWAMP are widely deployed today for delay and s= ynthetic loss measurement. * Section 3.1 introduces the new field, Sender Control Code. The format= of the packet, as I understand it, is presented in Figure 1. When comparin= g with the format of Session-Sender's test packet defined in RFC 4656 OWAMP= in Section 4.1.2 I've noticed that there are no MBZ fields. Are these intr= oduced by your proposal? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. * Also, it appears that the Sequence Number field in TWAMP Session-Send= er's test packet is absent in Figure 1. Is that intentional? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. Thanks, Rakesh Regards, Greg On Thu, Oct 22, 2020 at 5:51 AM James Guichard > wrote: Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_DM6PR11MB3115E21076C99CDE5D0B4B25BFE90DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

    Please see replies inline with <RG>=85<= o:p>

     

    From: ippm <ippm-bounc= es@ietf.org>
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf.org <spring@ietf.org>, ippm-chairs@ietf.org &l= t;ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.o= rg>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two related = drafts are in the WG APs in the SPRING and IPPM WG (with the possibility th= at expertise from the third WG, BFD WG, might be desirable to review the &q= uot;liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and comme= nts in a single thread. I hope that would be acceptable and considered by t= he SPRING WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use the ter= minology from RFC 4656 and 5357 and introduce their own terminology for Ses= sion-Sender and Session-Reflector. Also, many terms, e.g., Links, "con= gruent paths", are used in the documents without proper definitions. Other than that both drafts are readable and r= easonably well-written.

     

    <RG> We are ok to change Sender to Sess= ion-Sender and Reflector to Session-Reflector if it helps.

    <RG> There are many existing RFCs that = use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congruent= Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is becau= se these are well-known terms. Having said that, we can add a reference for them if it helps.

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile&q= uot; packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the e= xisting OAM mechanisms like ICMP.

     

    <RG> There is a requirement to measure = performance delay as well as synthetic and direct-mode packet loss in segme= nt-routing networks. OWAMP and TWAMP protocols are widely deployed for perf= ormance delay and synthetic packet loss measurement today. I am not sure extending ICMP for LM is a good option he= re.

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    To summarize my review of these two drafts:

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twam= p-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Light.

    • several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, re= quire detailed security analysis, which is currently absent;

    <RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment qu=
oted as:
     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Li= ght is not a standard but its idea is

       described in the informational = text only, I think that the Informational

      track is more appropriate for this sp= ecification.=94

    https://mailarchive.ietf.or= g/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS.

    • I believe that draft-gandhi-spring-twamp-srpm should be anchored at IP= PM WG as it does introduce the new PM protocol.

    <RG> The TWAMP L= ight extension = draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The SPRING draft only defines SR PM procedures.

     

    Below, please find my detailed comments, questi= ons on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is= required to make it a standard is well-explained in Section 4 of RFC 8545 (apologies for the long= quote):

       "TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
       (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
       control protocol combined with the TWAMP-Test protocol.  = In
       [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
       TWAMP Light failed to meet the requirements for IETF protocols= (there
       are no specifications for negotiating this form of operation a= nd no
       specifications for mandatory-to-implement security features), = as
       described in Appendix A of this memo.  See also [LarsAD] = and
       [TimDISCUSS].

       Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
       use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
       is specified in this document).  Clearly, the TWAMP Light= idea
       envisions many components and communication capabilities beyon= d
       TWAMP-Test (implementing the security requirements, for exampl= e);
       otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

     

    Since we don't have an IETF document that addressed = these open questions, I don't think we can have a draft that proposes exten= sions to a non-standard mechanism (Appendix is for Informational material, = as I understand it) on the Standard track.

     

    <RG> This was to address your previous comment qu=
oted as
     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Li= ght is not a standard but its idea is

       described in the informational = text only, I think that the Informational

       track is more appropriate for t= his specification.=94

    https://mailarchive.ietf.or= g/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS as you mentioned above.

    <RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    Now a number of more specific questions.<= /p>

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

      The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
       simplified mechanisms for active performance measurement in Cu= stomer
       IP networks by provisioning UDP paths and eliminates the need = for
       control-channel signaling.

    I can not find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UD= P paths"?

     

    <RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

     
    

    =93This example eliminates the need=
 for the TWAMP-Control protocol, and
    

       assumes that the Session-Re=
flector is configured=94
    

      

    • 
It appears that the last paragraph in the Introduction describes the relati=
onship with Appendix I of RFC 5357:
    

       The procedure uses the mechanisms defin=
ed in [RFC5357]
    
   (TWAMP Light) and its extensions for Performance Measurement.<=
o:p>
    

    I think that the reference must be to Appendix I, no=
t RFC 5357. Also, could you please specify which extensions of TWAMP Light =
have been used in this draft?
    

    
<RG> We can add the Appendix I as refer=
ence in the next revision. Extensions are defined in draft-gandhi-ippm-twam=
p-srpm, we can add this reference.
    --_000_DM6PR11MB3115E21076C99CDE5D0B4B25BFE90DM6PR11MB3115namp_-- From nobody Tue Nov 10 08:01:53 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEFF3A08BB; Tue, 10 Nov 2020 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=htUWdHU3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U9R/ZCMO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOfXzyv59yiG; Tue, 10 Nov 2020 08:01:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339F33A0957; Tue, 10 Nov 2020 08:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93877; q=dns/txt; s=iport; t=1605024106; x=1606233706; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dQVKg1Y0hqScShPBpWK8Q/pPjGU/Czo2JfYeQ6piVSU=; b=htUWdHU3HqZAf2xKhLtCMl7bULzFlE5z0NBdyqlGFODoYpeY/rBb2JkZ m5iilkV6gckRAixWnpHWo2e3UXVgTyus8BnzFpe2zrPMW+JIwcElJCZ9l Lic7CHiFa9DznIeN+6a7oiTqgOGQemmw0heYpoBVGZ0KkICrNovYomZLL g=; X-IPAS-Result: =?us-ascii?q?A0DtCQABuapf/4YNJK1igQmCci8jLgd0WS8uCod8A41Wg?= =?us-ascii?q?QWXfYFCgREDTwULAQEBDQEBGAEKCgIEAQGEBkQCghQCJTgTAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgRxhWEMhXIBAQEEAQEQCAMjAQEpAwsBDwIBCBEDAQIhAQIEB?= =?us-ascii?q?ycLFAkIAQEEAQ0FCBMHgwWBflcDLgEOo1kCgTuIaHSBNIMEAQEFgTcCDkGDC?= =?us-ascii?q?BiCEAMGgTiCc4pMG4FBP4ERQ4IaNT6CXQEBAwGBIRIOHAUZDQkCgxKCLJAZA?= =?us-ascii?q?VaKEotYNZASFHgKgm2JDYIZg3ZSi0SCBoESihWIXItrhh6NM4F/iHuVTwIEA?= =?us-ascii?q?gQFAg4BAQWBayOBV3AVO4JpUBcCDY4rFxQYgyKFFIVDAXQCNgIGCgEBAwl8i?= =?us-ascii?q?weBNAGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AY2Fc/RegFAIjf/E6HBIURryflGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208,217";a="577696481" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 16:01:06 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AAG15hw018507 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 16:01:05 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 10:01:05 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 10:01:05 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 11:01:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PmAa3QzrU/5KWZLxQDz2jq/Afi5J/gmbeKGMnpv78kI299DTFtNIsragAO/wqk5tAq7GJ1gDAO104mLmtm90DIgltP5tpvnG8XMixG2EFhewv2cKnioHWT4DyIDo77c5IctdqGynlDbbn7Qlq0ZCfy3Cl5rqQS73NHC96GRRYNDZdEDjhnHzi2jcPPplGZrhmIpPA/L9ajVa4sLPrGuHEtjYs/AZYk0aZHT7oti91xYtGhKocziHhdYeC773UbdNVcEWqa18WQGkEIoxbk3lgzzV+ab4oN0DxGk0sedzl9UWzuyeojMFSOHqy1XsCX2zErGeShwn45KBUYOGnMhe/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=09SAlZC5lKXkCbnPCJjH9DhKw1osKtDSUngTV/BGHDY=; b=FON/61QimdfazOGrodR8/JZiSdbLPm5W+Z3oG0DTuGaUkwuU51WJaOMGEBeJ00Bzggd71ZGLVe/oP+u8eeTsrgGFApp8e5PrJ2mebzpYoaeF8DmwZJBdwYrhEV9oTi2rurpZzJMuMB8G5U8Id5wyrnxUcUw9YWLLuaFvxoqEh6lM4oJp1uCfm3RfBJ3spsKOzMptrPq1hCjFfU7uwzEgn7w6w4H8WlRy2OnHA0sEIZvdXhevDJ4NCVaX5+NCVtSGXCyTlvNeLZatF/bqovZa+WgyIU5MKjUI+NYAANzsrwYWqPcAeiWH4Hc3TjWeNlBAQhYCeAHNrXOavowX62fWuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=09SAlZC5lKXkCbnPCJjH9DhKw1osKtDSUngTV/BGHDY=; b=U9R/ZCMO935/6cnoatynKFCs+FyffF7baOOVoGfZR6OYRepXZ+aT0UkSiZ7hYhGGJdKHagwavPt538zbzoCDw9KbH3SG2M8y4LgIb63gc/akXcCw9bUB7kAA3Is70qgJfq5VkkVkM0yWOLHo81huKb2/vZpNhTFEZAnMwqIz/nY= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM5PR1101MB2283.namprd11.prod.outlook.com (2603:10b6:4:50::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 16:01:02 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36%7]) with mapi id 15.20.3541.024; Tue, 10 Nov 2020 16:01:02 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky , James Guichard CC: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Thread-Topic: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: Adaoaxv73543NQYjR7aQ9fY490xJIQL7TaeAAMgAnhc= Date: Tue, 10 Nov 2020 16:01:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1bfee53a-6809-4840-cda4-08d88591d2fa x-ms-traffictypediagnostic: DM5PR1101MB2283: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vrGHdmo4oRTgW+kHQ5avnSH9KDxFngnSUJg2IW7GrpBoNOTLraWo+zE3O9PXGwZQZx78JuTF3157QAIT1UlQ+O9Wy6xLUUwrTyZ1vE2cIVPUFPtzZ2JYCZeuHVfV6W6jUOOsBgJIGQzHqmeTCFEiG9L9BGmq3jPSvSrk4qeMwslvRwW5rlLi1bLxFgdhd8Mko5BuTi7nvr9R6PCi3GKMdpZhpI1xMaFb6bdrGv3MkdV2iKwqIN3t8LF6EvpI+/G0uEwViD+5rn7tK3m8cVPCsoee4yq4CfkgmBaqVQvyWircm9QeyarkDY+XEEN5+NyD9gey+TYl4Qcj9c0E4B4fbnPWKmt7IWkB7n4S4mmzT4jWcmbMniYx1UoG1mTVxBGCcadWx8quKaWswCiadZdZcQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(376002)(39860400002)(136003)(66556008)(66946007)(4326008)(186003)(91956017)(8936002)(71200400001)(8676002)(66446008)(5660300002)(6506007)(52536014)(316002)(110136005)(86362001)(33656002)(2906002)(54906003)(7696005)(30864003)(478600001)(9686003)(166002)(966005)(55016002)(83380400001)(64756008)(26005)(66476007)(76116006)(53546011)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fWrKpAo1lTHlFeVZgKPZGLjZ+PsUcGx1ccwOskRSaUp0y+e1wQOQrA+yZa480zC21J3/VQdIuUec4bltzyUCQh6YactSLJilcveLHgxdVB75j9+A0itOZKxtEYu7F9jHiwv91if3Y9XKZFtCsfwdY9BxtI587X/zgA2gkoO1aMkbRQ67rdYqG9Wegs2dMvnSbBa7iQ7FzWPvihOXIgN/Vk/ZQ7N0KK+g79U4fKi0ia87MHB0Oq+cK55GlRHkS4WqMevfiTzE7GGZR5AiQGymny9luXkly0VWS1A/HzPIzk7bFkir4UowA05Cm16Y+UCPcvHZXWlzYMHnEZTAkkQ56SZ82wtBVzLusTDkHqRlk4jBV+QdyqXLoMIFHLiaOg4FbG7+iO/j+Zc1UH7dR2fxTxMomaW8IxS6JqRJ5IwDBdXaf0+xQlXk1N5loa18B5+o/zZFHprSZRmCkYkykS4mkg/c4AD0ZtRmBrhXRkntK+XI6Fx7HDONxxanPjXlHOO/c32AjL3msbzFNgeu1viULey4znw8aV67mhKAKa9IaqW9mVFhLPCXhdmKKoiOlWqWMbe3HiPX2GLMDqA0t2+ZYsDgCKnajynkk0uNpjsV90qwxv/b9C3+irfG5yNgQtEjOS4A0gX0LowGfWFZyVqiMIEY2lAVPMZsOONGCiXeG1Co67/8a8m7Nxtuy1yEMkfCVaFVF+q8v7Si3nBaK/QPh93126OBOAUPMgoyxAwHElbrxHwSYQdJGDtjdIjxA4qbw2ORqzdNgp1G/PE081DACjBiv9UrOdQCSDzVtTUXzVI40eVGslzPZ7ft5G/880ZjVgsvMTSIZ9cr4nR7Eb96VMosSp8+bvX80hA3LINCGRYCy0w87PcIlfpEBc8/IoMnTh7eUIAWApBUph202xbg+A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31150631EC8ABD652B97B5FCBFE90DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1bfee53a-6809-4840-cda4-08d88591d2fa X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 16:01:02.8160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kCfdqJn97aMKkhLw9R5gEYbHxYuGlBrODMledwg0ORlXMDtKXspMi1t35qTtJunpm0Ib7X/t3qEEdbeco2BNOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2283 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 16:01:51 -0000 --_000_DM6PR11MB31150631EC8ABD652B97B5FCBFE90DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Note that many of the comments here on STAMP draft a= re repeated from the previous comments on the TWAMP Light draft. Please see= replies inline with . The repeated comments are tagged with to = avoid duplicated discussions. From: ippm Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard Cc: spring@ietf.org , ippm-chairs@ietf.org , spring-chairs@ietf.org , IETF IPPM WG Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-stamp-srpm-03 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written It was a surprise finding out that both drafts don't use the terminology fr= om RFC 8762 STAMP and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are = used in the documents without proper definitions. Other than that, both dra= fts are readable. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. * Does the document solve a real problem? No, it appears that the changes described in these drafts are only to achie= ve in-band collection of counters of "in-profile" packets. Firstly, drafts = don't provide any arguments about why such collection should be performed u= sing the in-band method rather than using the out-of-band collection approa= ch. Secondly, even if there are any benefits of in-band collection, that ca= n be more easily achieved by extending other OAM, e.g., ICMP, tools. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP. Other than this, I did not find any oth= er security related issue in your review below. draft-gandhi-spring-stamp-srpm * Can you define a Link and how it is different from an SR Path? There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613= , 5340, 8330, etc.). Similarly term =93SR Path=94 has been used in existing= RFCs (e.g. 8664). I suspect these are well-known terms. * It is not clear how the destination UDP port numbers are selected. Do= es the draft change procedure defined in Section 4.1 RFC 8762? There is no change. * It is not clear what "the congruent path" means. The definition of th= e congruent in geometry tells that a congruent object has the same shape an= d size, but is allowed to flip, slide or turn. How a path can be congruent = to another path? There are many existing RFCs that use term =93Congruent Path=94 (e.g= . RFC 5921, 6669) without defining them. I suspect it is because it is well= -known term. Having said that, we can add a reference for it if it helps re= ader. * An example of the provisional model is Section 3.1 seems well-suited = for a YANG data model. What changes to the STAMP YANG data model defined in= draft-ietf-ippm-stamp-yang proposed in these drafts? Yes, this can be Yang model. We can review draft-ietf-ippm-stamp-yan= g and add an= y missing items in a separate draft. We can also add a reference in this dr= aft. * In Section 4.1 noted that The probe messages defined in [RFC8762] are used for delay measurement for Links and end-to-end SR Paths including SR Policies. For loss measurement, the probe messages defined in [I-D.gandhi-ippm- stamp-srpm] are used. It necessary to point that RFC 8762 support packet delay and packet loss me= asurements in the same test session using test packets defined in the STAMP= base specification. I believe that the need yet for another method to perf= orm the loss measurement is not sufficiently demonstrated and does appear a= s duplication of functionality already available in STAMP. This is explained in the third paragraph of Section 1. * Could you expand on the reasoning why in Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. I cannot find similar requirement in RFC 8762 and would appreciate a techni= cal explanation of the choice made in this specification. Does RFC 8762 support simultaneous sessions for authenticated and non-= authenticated modes? If yes, can you please point to the procedure in the R= FC 8762 and we can simply refer to it? I am not sure how both packet forma= ts be distinguished by a reflector node when using the same UDP port. * Section 4.2.1 refers to Sender Control Code (though it is defined in = draft-gandhi-ippm-stamp-srpm. Could you explain why it is important to info= rm the Session-Reflector that the reflected test packet be sent out-of-band= ? What if only in-band return path is available? Would the Session-Reflecto= r discard test packets in such situation? Out-of-band is the current behaviour and there is no change in the e= xisting behaviour. We can clarify in the next revision. * I got confused by the following in Section 4.2.2 In two-way measurement mode, when using a bidirectional path, the probe response message as defined in Figure 6 is sent back to the sender node on the congruent path of the data traffic on the same reverse direction Link or associated reverse SR Policy [I-D.ietf-pce-sr-bidir-path]. If a Path Segment SID associated with the test session, there seems no need= to require the Session-Reflector look for in-band path. Would you agree? No. Existence of Path Segment ID does not mean in-band reply. It may b= e needed for RX counter for direct-mode loss measurement. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or STAMP / TWAMP / RFC 5357 / R= FC 8762 in RFC 8403. Is the "liveness monitoring" functionally identical to path continuity moni= toring provided by BFD? STAMP probe messages are used for synthetic packet loss which can b= e used to detect connection loss. The draft simply highlights this obvious = metric. * It appears that second and third paragraphs on Section 4.3.1 contradi= ct with the first paragraph. Need to point that RFC 8762 does not specify t= he value set in TTL/Hop Limit field, thus reference in the first paragraph = seems misleading. I couldn't find ::FFFF:127/104 range being mentioned in t= he draft. Could you clarify when it is used? We can update the sentence in the first paragraph as following: The TTL field in the IPv4 and MPLS headers of the probe query messages is s= et to 255 [RFC5357] except following two cases. The IPv6 address ::1/128 is mentioned in the draft at couple of places= . We can update the above text. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP p= ort provisioned for STAMP. We will add reference to RFC 6936 in Security Se= ction. * Section 7, as I understand it, suggests that performance measurement = can be combined with "liveness monitoring", i.e.path continuity monitoring.= How fast path failure detection you expect in such combination? How it is = comparable to the the failure detection time guaranteed using BFD? STAMP probe messages are used for synthetic packet loss which can b= e used to detect connection loss (performance metric). The draft simply hig= hlights this obvious metric. draft-gandhi-ippm-stamp-srpm * Introduction states that The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. In fact, that is not accurate. RFC 8762 which provides the base specificati= on of the STAMP protocol already supports packet delay and packet loss (a.k= .a. synthetic packet loss) measurement. Ok, we can update the text to indicate synthetic loss. * Further, the draft concludes that However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization). I disagree that the the clock synchronization is required for STAMP. It is = recommended for one-way delay measurement but even without the clock synchr= onization STAMP supports the round-trip delay measurement and one-way delay= variation can be calculated. We can update text to : (which requires clock synchronization for one-= way delay measurement). * The conclusion on Introduction is, in my view, misleading as the prop= osed solution is not an extension of STAMP but update of RFC 8762. And sinc= e this is changes the foundation of RFC 8762 that specifies active two-way = performance measurement protocol, another method for collecting counters an= d/or other telemetry information should be sought. For example, ICMP using = multi-part message extensions, as defined in RFC 4884. As mentioned earlier, I am not sure extending ICMP to do PM is a goo= d option here. Thanks, Rakesh Regards, Greg On Thu, Oct 22, 2020 at 5:52 AM James Guichard > wrote: Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-stamp-srpm-03, ending November 12th 2020. Please not= e that this document has several changes from v-02 that were requested by t= he SPRING and IPPM chairs. For this reason, the chairs have extended the ad= option call for an additional week to allow the WG enough time to review th= ese changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for STAMP Messages,= Loss Measurement Query Message Extensions, Loss Measurement Response Messa= ge Extensions, Node Address TLV Extensions, and Return Path TLV Extensions = were included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02 and should be removed from the SPRING document. * The STAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-02 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.org= /html/draft-gandhi-spring-stamp-srpm-02 the result of which is the publicat= ion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_DM6PR11MB31150631EC8ABD652B97B5FCBFE90DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments. Note that many of the = comments here on STAMP draft are repeated from the previous comments on the= TWAMP Light draft. Please see replies inline with <RG>. The repeated comments are tagged with <RG00>= to avoid duplicated discussions.

     

    From: ippm <ippm-bounc= es@ietf.org>
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf.org <spring@ietf.org>, ippm-chairs@ietf.org &l= t;ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.o= rg>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-stamp-srpm-03

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two related = drafts are in the WG APs in the SPRING and IPPM WG (with the possibility th= at expertise from the third WG, BFD WG, might be desirable to review the &q= uot;liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and comme= nts in a single thread. I hope that would be acceptable and considered by t= he SPRING WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated by answers to these three questions:

    • Is the document(s) reasonably well-written

    It was a surprise finding out that both drafts = don't use the terminology from RFC 8762 STAMP and introduce their own termi= nology for Session-Sender and Session-Reflector. Also, many terms, e.g., Li= nks, "congruent paths", are used in the documents without proper definitions. Other than that, both drafts are rea= dable.

     

    <RG00> We can ch= ange Sender to Session-Sender and Reflector to Session-Reflector if it help= s.

    <RG00> There are= many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) an= d term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspec= t it is because these are well-known terms. Having said that, we can add a reference for them if it helps.<= /span>

    • Does the document solve a real problem?

    No, it appears that the changes described in these d= rafts are only to achieve in-band collection of counters of "in-profil= e" packets. Firstly, drafts don't provide any arguments about why such= collection should be performed using the in-band method rather than using the out-of-band collection approach. Secondly, ev= en if there are any benefits of in-band collection, that can be more easily= achieved by extending other OAM, e.g., ICMP, tools.

     

    <RG00> There is = a requirement to measure performance delay as well as synthetic and direct-= mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are= widely deployed for performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for = LM is a good option here.

    • Is the proposed solution technically viable?

    There are too many un= addressed aspects, particularly the risk introduced by the protocol on netw= ork security, to comprehensively evaluate the proposed solution.=

    <RG00> About your comment on z= ero checksum, this is described in Security section in RFC 6936. We will ad= d reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP. Other than this, I did not find any other= security related issue in your review below.

    draft-gandhi-spring-stamp-srpm

    • Can you define a Link and how it is different from an SR Path?

    <RG00> There are many existing= RFCs that use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.). Similarly= term =93SR Path=94 has been used in existing RFCs (e.g. 8664). I suspect these are well-known terms.

    --_000_DM6PR11MB31150631EC8ABD652B97B5FCBFE90DM6PR11MB3115namp_-- From nobody Tue Nov 10 10:56:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29343A0E4D for ; Tue, 10 Nov 2020 10:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Pt1JSB_UWbvH for ; Tue, 10 Nov 2020 10:56:35 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 8E1BC3A0E45 for ; Tue, 10 Nov 2020 10:56:35 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id o11so15385108ioo.11 for ; Tue, 10 Nov 2020 10:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zMMFcItTidhuFLRoqaxu8JIIjg90psYMRgeWCbu8UpU=; b=TfBhBmkvJUWIs9aImSt1L+0DlvIaR0I9MnLwJYCp3WNLiCa4JuCHKMIgTyEH5th4dA BiyO8h21IkjWr4GthTkb8S6v5AvhDBbfcB/42fRDbdJxsmrghmlY/hxcTBIYhJeGX+Nq lDK2oTta3FainuW/lfwDNoBzeV/aMa55eorcf2nbuTUwyDRhO9S9rQDg8nMOeTl7b/DM JmWHVqN1rmNwqqQi7K6rN/nBkCzHXnZdPuBn1QNa/AQXFqXStALQBZ3Zbih4rgVI9JIT jg5+9kaYvM7f8IKiZ/JAYdjWzy7e9GFcHKFleWR9j0vLFuhTaB+69aq43VUgfRSZCLkA zMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zMMFcItTidhuFLRoqaxu8JIIjg90psYMRgeWCbu8UpU=; b=ixnLI4N6u/oO6PT7iKSsKo6a2UHGfJrBU6N+JtFF/tAQv6YByh/0t/ZOfkPcoOOODm 3wAe9Ef+XwCRf3NXFBUeJD62dh7WA2kzKSg7ervu0smRHnPzZ4cN0F0fulp6gzs3Z5EX cy+T2nnYUcjbu+OpsQ8DW9fb8dcO5Lzz5t+pZCajaCOsYP3/cwLaSlYrtSn8nNMqWXjh fa9DaLCP2crhU0UrujEPyIpR8+QcigJO+eddCUuC1Trbh6Yun19bUqgUy9wL2wKK1Sbx o1kSDdsgDwCvhsaDArUTf9d5xsT3eyZaG78w9QHAcwb/z+pMS9D5rJdKgux/CycKefMi kqqw== X-Gm-Message-State: AOAM531OPqKg0zFtWg63Qx3/i7gEGlw64OYC+15qDxWl3Lf9Bxms8CRE NVUXRh/PJ2rVWeXkgvm5NsP3KWmfG+o1Tg2z3Sk= X-Google-Smtp-Source: ABdhPJz19hd0tlaPY6xW6zgkfiVVoLlSLu3v3O+5Aqh9NO/JcXCKCqrVF/4iT+fz1Sgt/PyDtc87gGVfvxstlLa6D/w= X-Received: by 2002:a5d:9d48:: with SMTP id k8mr15298085iok.62.1605034594821; Tue, 10 Nov 2020 10:56:34 -0800 (PST) MIME-Version: 1.0 References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: From: Vishnu Pavan Beeram Date: Tue, 10 Nov 2020 12:56:22 -0600 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e06af405b3c53c8f" Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:56:39 -0000 --000000000000e06af405b3c53c8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ketan, Hi! Please see inline for responses (prefixed VPB). Regards, -Pavan On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) wrote: > Hi Pavan, > > > > Please check inline below. > > > > *From:* Vishnu Pavan Beeram > *Sent:* 10 November 2020 00:08 > *To:* Ketan Talaulikar (ketant) > *Cc:* spring@ietf.org > *Subject:* Re: [spring] I-D Action: > draft-ietf-spring-segment-routing-policy-09.txt > > > > Ketan, > > > > Much Thanks for taking a stab at addressing the composite candidate path > use-case! We seem to be converging. > > *[KT] Thanks for that feedback and confirmation that the proposal in the > draft does address the use-case. I believe we are now discussing the > mechanics of how this is achieved within the current SR Policy framework.= * > > > > However, I don=E2=80=99t understand why you need to use additional SR pol= icies > (and unnecessarily burn additional colors) to address this. > > *[KT] I do not follow what you mean by =E2=80=9Cburn additional colors=E2= =80=9D. Color is > just a 32 bit number that indicates the =E2=80=9Cintent=E2=80=9D and is n= ot really a scarce > resource. Assigning a color to =E2=80=9Ca composite intent=E2=80=9D seems= like a seamless > way to integrate with existing mechanisms for Steering over SR Policies. > This gives the flexibility for say some BGP services to be steered over t= he > constituent explicit/dynamic intent while others can steer over a composi= te > intent that includes those individual explicit/dynamic intents.* > [VPB] The =E2=80=9Cflexibility=E2=80=9D that you are referring to is undesi= rable for this use-case. For the traffic-split use-case, we don=E2=80=99t want any other s= ervices to be directly steered over the constituents when they are part of a composite candidate path. The current proposal in the draft would have been acceptable if the constituent SR Policies were uncolored =E2=80=93 but that= would violate the current rules imposed by the draft. > > Why can=E2=80=99t the composite candidate path just be a grouping of expl= icit > candidate paths and/or dynamic candidate paths? > > *[KT] This is because in the SR Policy framework, there is only a single > active CP =E2=80=93 it may be explicit or dynamic. Now we=E2=80=99ve adde= d another > Composite CP type to cover this specific use-case. Your proposal will > result in 3 candidate paths being active within the same SR Policy =E2=80= =93 one > each of the explicit and dynamic CP and then additionally the Composite C= P. > This breaks the existing rules for selection of CP based on preference an= d > mechanisms like fallback between CPs. While the current proposal in the > draft provides a way to address the new use-case with a backwards > compatible extension to the SR Policy framework.* > [VPB] The proposal in my previous email is backwards compatible and does not intend to break any existing rules for deeming a candidate path active. As per the rules that are outlined in Section 2.9, only the composite candidate path is =E2=80=9Cactive=E2=80=9D given its preference. The consti= tuent candidate paths will never be active on their own. If it is necessary, we can add a statement in Section 2.9 to explicitly state that the candidate path selection criteria does not apply to the constituent candidate paths. > > *Thanks,* > > *Ketan* > > > > Consider the following changes: > > > > ** Section 2.2 > > OLD: > > A composite candidate path acts as a container for grouping of SR > > Policies. The composite candidate path construct enables combination > > of SR Policies, each with explicit candidate paths and/or dynamic > > candidate paths with potentially different optimization objectives > > and constraints, for a load-balanced steering of packet flows over > > its constituent SR Policies. The following criteria apply for > > inclusion of constituent SR Policies using a composite candidate path > > under a parent SR Policy: > > > > o the endpoints of the constituent SR Policies and the parent SR > > Policy MUST be identical > > > > o The colors of each of the constituent SR Policies and the parent > > SR Policy MUST be different > > > > o the constituent SR Policies MUST NOT use composite candidate paths > > > > Each constituent SR Policy of a composite candidate path is > > associated with a weight for load-balancing purposes (refer > > Section 2.11 for details). The default weight is 1. > > > > NEW: > > A composite candidate path acts as a container for grouping of > > explicit candidate paths and/or dynamic candidate paths with > > potentially different optimization objectives and constraints. > > The composite candidate path construct enables load-balanced > > steering of packet-flows over a set of constituent candidate > > paths. The following criteria apply for constituent candidate > > paths under a composite candidate path: > > > > o the preference of the constituent candidate path MUST be > > ignored. > > > > o the constituent candidate path MUST NOT be a composite candidate > > path > > > > Each constituent candidate path of a composite candidate path is > > associated with a weight for load-balancing purposes (refer > > Section 2.11 for details). The default weight is 1. > > > > ** > > > > ** Section 2.11 > > > > OLD: > > When a composite candidate path is active, the fraction of flows > > steered into each constituent SR Policy is equal to the relative > > weight of each constituent SR Policy. Further load balancing of > > flows steered into a constituent SR Policy is performed based on the > > weights of the Segment-List of the active candidate path of that > > constituent SR Policy. > > > > NEW: > > When a composite candidate path is active, the fraction of flows > > steered into each constituent candidate path is equal to the relative > > weight of each constituent candidate path. Further load balancing of > > flows steered into a constituent candidate path is performed based on > > the weights of each associated Segment-List. > > > > ** > > > > ** Section 2.13 > > > > OLD: > > The information model of SR Policy POL100 having a composite > > candidate path is the following: > > > > SR policy POL100 > > Candidate-path CP1 > 100:1.1.1.1, discriminator =3D 1> > > Preference 200 > > Weight W1, SR policy > > Weight W2, SR policy > > > > The constituent SR Policies POL1 and POL2 have information model as > > described at the start of this section. They are referenced only by > > color in the composite candidate path since their headend and > > endpoint are identical to the POL100. The valid Segment-Lists of the > > active candidate path of POL1 and POL2 are installed in the > > forwarding. Traffic steered on POL100 is flow-based hashed on POL1 > > with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing > > over its Segment-Lists are performed as described earlier in this > > section. > > > > NEW: > > The information model of SR Policy POL100 having a composite > > candidate path is the following: > > > > SR policy POL100 > > Candidate-path Comp-CP > 100:1.1.1.1, discriminator =3D 1> > > Preference 200 > > Weight W1, Candidate-path CP1 > > Weight W2, Candidate-path CP2 > > Candidate-path CP1 > 100:1.1.1.1, discriminator =3D 2> > > Weight W11, SID-List1 > > Weight W12, SID-List2 > > Candidate-path CP2 > 100:1.1.1.1, discriminator =3D 3> > > Weight W21, SID-List3 > > Weight W22, SID-List4 > > > > Comp-CP is a composite candidate path with two constituents, CP1 > > and CP2. The preference is ignored for each of the two constituent > > candidate paths. The valid Segment-Lists of the two constituent > > candidate paths are installed in the forwarding. Traffic steered > > on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of > > W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent > > candidate path, the flow-based hashing over its Segment-Lists are > > performed as described earlier in this section. > > > > ** > > > > ** Section 5.3 > > > > OLD: > > A composite candidate path is specified as a group of its constituent > > SR Policies. > > > > A composite candidate path is valid when it has at least one valid > > constituent SR Policy. > > > > NEW: > > A composite candidate path is specified as a group of its constituent > > candidate paths. > > > > A composite candidate path is valid when it has at least one valid > > constituent candidate path. > > > > ** > > > > Regards, > > -Pavan > > > > > > > > On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) 40cisco.com@dmarc.ietf.org> wrote: > > Hello All, > > We have just posted an update for the draft and following is the summary > of changes: > > 1) Introduction of the Composite Candidate Path construct to address a > pending comment from the WG (Ref : > https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ > and > https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/= ) > 2) Based on offline feedback received, updated SRv6 segment types to > include optional SRv6 SID and behavior instead of the new type that was > introduced for it in the v08. > 3) Clarification of handling of colors and BGP multi-path scenarios based > on offline feedback received. > 4) Clarification on considerations for TI-LFA for SR Policy as discussed > in the WG (Ref : > https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/= ) > > Please let know your comments/feedback. > > Thanks, > Ketan (on behalf of co-authors) > > -----Original Message----- > From: spring On Behalf Of > internet-drafts@ietf.org > Sent: 02 November 2020 06:27 > To: i-d-announce@ietf.org > Cc: spring@ietf.org > Subject: [spring] I-D Action: > draft-ietf-spring-segment-routing-policy-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking WG o= f > the IETF. > > Title : Segment Routing Policy Architecture > Authors : Clarence Filsfils > Ketan Talaulikar > Daniel Voyer > Alex Bogdanov > Paul Mattes > Filename : draft-ietf-spring-segment-routing-policy-09.txt > Pages : 37 > Date : 2020-11-01 > > Abstract: > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate per-flow states are eliminated thanks > to source routing. The headend node steers a flow into an SR Policy. > The header of a packet steered in an SR Policy is augmented with an > ordered list of segments associated with that SR Policy. This > document details the concepts of SR Policy and steering into an SR > Policy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-09 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-pol= icy-09 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --000000000000e06af405b3c53c8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ketan, Hi!

    Please see inline for responses (pr= efixed VPB).

    Regards,
    -Pavan

    =
    On Tue, Nov 10, 2020 at 4:04 AM Ketan= Talaulikar (ketant) <ketant@cisco.c= om> wrote:

    Hi Pavan,

    =C2=A0

    Please check inline below.

    =C2=A0

    From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Sent: 10 November 2020 00:08
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf= .org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    =C2=A0

    Ketan,

    =C2=A0

    Much Thanks for taking a stab at= addressing the composite candidate path use-case!=C2=A0We seem to be convergin= g.

    [KT] Thanks for that feedback and confirmation= that the proposal in the draft does address the use-case. I believe we are= now discussing the mechanics of how this is achieved within the current SR= Policy framework.=C2=A0

    <= b>

    =C2=A0

    However, = I don=E2=80=99t understand why you need to use additional SR policies (and = unnecessarily burn additional colors) to address this.

    [KT] I do not follow what you mean by =E2=80= =9Cburn additional colors=E2=80=9D. Color is just a 32 bit number that indi= cates the =E2=80=9Cintent=E2=80=9D and is not really a scarce resource. Ass= igning a color to =E2=80=9Ca composite intent=E2=80=9D seems like a seamles= s way to integrate with existing mechanisms for Steering over SR Policies. This giv= es the flexibility for say some BGP services to be steered over the constit= uent explicit/dynamic intent while others can steer over a composite intent= that includes those individual explicit/dynamic intents.

    <= br>
    [VPB] The =E2=80=9Cflexibility=E2=80=9D that you are referrin= g to is undesirable for this use-case. For the traffic-split use-case, we d= on=E2=80=99t want any other services to be directly steered over the consti= tuents when they are part of a composite candidate path. The current propos= al in the draft would have been acceptable if the constituent SR Policies w= ere uncolored =E2=80=93 but that would violate the current rules imposed by= the draft.=C2=A0

    <= /p>

    =C2=A0

    Why can= =E2=80=99t the composite candidate path just be a grouping of explicit cand= idate paths and/or dynamic candidate paths?

    [KT] This is because in the SR Policy framewor= k, there is only a single active CP =E2=80=93 it may be explicit or dynamic= . Now we=E2=80=99ve added another Composite CP type to cover this specific = use-case. Your proposal will result in 3 candidate paths being active within the same SR Policy =E2=80=93 one each of the exp= licit and dynamic CP and then additionally the Composite CP. This breaks th= e existing rules for selection of CP based on preference and mechanisms lik= e fallback between CPs. While the current proposal in the draft provides a way to address the new use-case with a ba= ckwards compatible extension to the SR Policy framework.

    <= /div>

    [VPB] The proposal in my previo= us email is backwards compatible and does not intend to break any existing = rules for deeming a candidate path active. As per the rules that are outlin= ed in Section 2.9, only the composite candidate path is =E2=80=9Cactive=E2= =80=9D given its preference. The constituent candidate paths will never be = active on their own. If it is necessary, we can add a statement in Section = 2.9 to explicitly state that the candidate path selection criteria does not= apply to the constituent candidate paths.=C2=A0

    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

    =C2=A0

    Thanks,

    Ketan

    =C2=A0

    Consider the following changes:<= /span>

    =C2=A0

    ** Section 2.2

    OLD:

    <=
span style=3D"color:black">=C2=A0=C2=A0 A composite candidate path acts as =
a container for grouping of SR
    <=
span style=3D"color:black">=C2=A0=C2=A0 Policies.=C2=A0 The composite candi=
date path construct enables combination
    <=
span style=3D"color:black">=C2=A0=C2=A0 of SR Policies, each with explicit =
candidate paths and/or dynamic
    <=
span style=3D"color:black">=C2=A0=C2=A0 candidate paths with potentially di=
fferent optimization objectives
    <=
span style=3D"color:black">=C2=A0=C2=A0 and constraints, for a load-balance=
d steering of packet flows over
    <=
span style=3D"color:black">=C2=A0=C2=A0 its constituent SR Policies.=C2=A0 =
The following criteria apply for
    <=
span style=3D"color:black">=C2=A0=C2=A0 inclusion of constituent SR Policie=
s using a composite candidate path
    <=
span style=3D"color:black">=C2=A0=C2=A0 under a parent SR Policy:=

    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 o=C2=A0 the endpoints of the consti=
tuent SR Policies and the parent SR
    <=
span style=3D"color:black">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Policy MUST be id=
entical
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 o=C2=A0 The colors of each of the c=
onstituent SR Policies and the parent
    <=
span style=3D"color:black">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SR Policy MUST be=
 different
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 o=C2=A0 the constituent SR Policies=
 MUST NOT use composite candidate paths
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 Each constituent SR Policy of a com=
posite candidate path is
    <=
span style=3D"color:black">=C2=A0=C2=A0 associated with a weight for load-b=
alancing purposes (refer
    <=
span style=3D"color:black">=C2=A0=C2=A0 Section 2.11 for deta=
ils).=C2=A0 The default weight is 1.
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">NEW:
    <=
span style=3D"color:black">=C2=A0=C2=A0 A composite candidate path acts as =
a container for grouping of
    <=
span style=3D"color:black">=C2=A0=C2=A0 explicit candidate paths and/or dyn=
amic candidate paths with 
    <=
span style=3D"color:black">=C2=A0=C2=A0=C2=A0potentially different optimiza=
tion objectives and constraints.
    <=
span style=3D"color:black">=C2=A0=C2=A0 The composite candidate path constr=
uct enables load-balanced
    <=
span style=3D"color:black">=C2=A0=C2=A0 steering of packet-flows over a set=
 of constituent candidate
    <=
span style=3D"color:black">=C2=A0=C2=A0 paths. The following criteria apply=
 for constituent candidate 
    =C2=A0=C2=A0=C2=A0paths under a composite =
candidate path:
    =C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 o=C2=A0 the preference of the const=
ituent candidate path MUST be 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ignore=
d. 
    =C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 o=C2=A0 the constituent candidate p=
ath MUST NOT be a composite candidate 
    <=
span style=3D"color:black">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0path<=
u>
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"color:black">=C2=A0=C2=A0 Each constituent candidate path of =
a composite candidate path is
    <=
span style=3D"color:black">=C2=A0=C2=A0 associated with a weight for load-b=
alancing purposes (refer
    <=
span style=3D"color:black">=C2=A0=C2=A0 Section 2.11 for deta=
ils).=C2=A0 The default weight is 1.
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">**
    <=
span style=3D"color:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">** Section 2.11
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">OLD:

    =C2=A0=C2=A0=C2=A0When a composite candidate path is active, the fra= ction of flows

    =C2=A0=C2=A0=C2=A0steered into each constituent SR Policy is equal t= o the relative

    =C2=A0=C2=A0=C2=A0weight of each constituent SR Policy.=C2=A0=C2=A0Further load balancing of=

    =C2=A0=C2=A0=C2=A0flows steered into a constituent SR Policy is perf= ormed based on the

    =C2=A0=C2=A0=C2=A0weights of the Segment-List of the active candidat= e path of that

    =C2=A0=C2=A0=C2=A0constituent SR Policy.

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">NEW:

    =C2=A0=C2=A0=C2=A0When a composite candidate path is active, the fra= ction of flows

    =C2=A0=C2=A0=C2=A0steered into each constituent candidate path is eq= ual to the relative

    =C2=A0=C2=A0=C2=A0weight of each constituent candidate path.=C2=A0=C2=A0= Further load balancing of

    =C2=A0=C2=A0=C2=A0flows steered into a constituent candidate path is= performed based on

    =C2=A0=C2=A0=C2=A0the weights of each associated Segment-List.

    =C2=A0

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">**
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">** Section 2.13
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">OLD:

    =C2=A0=C2=A0=C2=A0The information model of SR Policy POL100 having a= composite

    =C2=A0=C2=A0=C2=A0candidate path is the following:

    =C2=A0

    =C2=A0=C2=A0=C2=A0SR policy POL100 <headend =3D H1, color =3D 100= , endpoint =3D E1>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path CP1 &= lt;protocol-origin =3D 20, originator =3D

    =C2=A0=C2=A0=C2=A0100:1.1.1.1, discriminator =3D 1>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Preference 200

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Weight W1, SR policy <color =3D 1>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Weight W2, SR policy <color =3D 2>

    =C2=A0

    =C2=A0=C2=A0=C2=A0The constituent SR Policies POL1 and POL2 have inf= ormation model as

    =C2=A0=C2=A0=C2=A0described at the start of this section.=C2=A0=C2=A0They are referenced only by

    =C2=A0=C2=A0=C2=A0color in the composite candidate path since their = headend and

    =C2=A0=C2=A0=C2=A0endpoint are identical to the POL100.=C2=A0=C2=A0The valid Segment-Lists of the

    =C2=A0=C2=A0=C2=A0active candidate path of POL1 and POL2 are install= ed in the

    =C2=A0=C2=A0=C2=A0forwarding.=C2=A0=C2=A0Traffic steered on POL10= 0 is flow-based hashed on POL1=

    =C2=A0=C2=A0=C2=A0with a ratio W1/(W1+W2).=C2=A0=C2=A0Within the = POL1, the flow-based hashing

    =C2=A0=C2=A0=C2=A0over its Segment-Lists are performed as described = earlier in this<= /p>

    =C2=A0=C2=A0=C2=A0section.<= /u>

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">NEW:

    =C2=A0=C2=A0=C2=A0The information model of SR Policy POL100 having a= composite

    =C2=A0=C2=A0=C2=A0candidate path is the following:

    =C2=A0

    =C2=A0=C2=A0=C2=A0SR policy POL100 <headend =3D H1, color =3D 100= , endpoint =3D E1>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path Comp-CP <protocol-origin =3D 20, originator =3D=

    =C2=A0=C2=A0=C2=A0100:1.1.1.1, discriminator =3D 1>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Preference 200

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Weight W1, Candidate-path CP1

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Weight W2, Candidate-path CP2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Candidate-path CP1 &= lt;protocol-origin =3D 20, originator =3D

    =C2=A0=C2=A0 100:1.1.1.1, discriminator =3D 2>= ;

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Weight W11, SID-List1 <SID11...SID1i>= ;

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0= =C2=A0Weight W12, SID-List2 <SID21...SID2j>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Candi= date-path CP2 <protocol-origin =3D 20, originator =3D

    =C2=A0=C2=A0 100:1.1.1.1, discriminator =3D 3>= ;

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Weight W21, SID-List3 <SID31...SID3i>= ;

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0= =C2=A0Weight W22, SID-List4 <SID41...SID4j>

    =C2=A0

    =C2=A0=C2=A0 Comp-CP is a composite candidate pa= th with two constituents, CP1<= u>

    =C2=A0=C2=A0=C2=A0and CP2. The preference is ignored for each of the= two constituent=

    =C2=A0=C2=A0 candidate paths. The valid Segment-= Lists of the two=C2=A0constituent

    =C2=A0=C2=A0 candidate paths are installed in th= e forwarding.=C2=A0Traffic steered=

    =C2=A0=C2=A0=C2=A0on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of

    =C2=A0=C2=A0 W1/(W1+W2) and W2/(W1+W2) respectively. Within each consti= tuent

    =C2=A0=C2=A0 candidate path, the=C2=A0flow-ba= sed hashing over its Segment-Lists are

    =C2=A0=C2=A0 performed as=C2=A0described earl= ier in this section.

    =C2=A0<= /u>

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">**
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">** Section 5.3
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">OLD:

    =C2=A0=C2=A0=C2=A0A composite candidate path is specified as a group= of its constituent

    =C2=A0=C2=A0=C2=A0SR Policies.=

    =C2=A0

    =C2=A0=C2=A0=C2=A0A composite candidate path is valid when it has at= least one valid=

    =C2=A0=C2=A0=C2=A0constituent SR Policy.

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">NEW:

    =C2=A0=C2=A0=C2=A0A composite candidate path is specified as a group= of its constituent

    =C2=A0=C2=A0=C2=A0candidate paths.

    =C2=A0

    =C2=A0=C2=A0=C2=A0A composite candidate path is valid when it has at= least one valid=

    =C2=A0=C2=A0=C2=A0constituent candidate path.

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0

    **

    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">=C2=A0
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">Regards,
    <=
span style=3D"font-size:11pt;font-family:"Calibri",sans-serif;col=
or:black">-Pavan

    =C2=A0

    =C2=A0<= /span>

    =C2=A0

    On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ket= ant) <ketant=3D40cisco.com@dmarc.ietf.org> wrote:

    Hello All,

    We have just posted an update for the draft and following is the summary of= changes:

    1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
    2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08.
    3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received.
    4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref :     https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

    Please let know your comments/feedback.

    Thanks,
    Ketan (on behalf of co-authors)

    -----Original Message-----
    From: spring <    spring-bounces@ietf.org> On Behalf Of internet-draf= ts@ietf.org
    Sent: 02 November 2020 06:27
    To: i-d-announce= @ietf.org
    Cc: spring@ietf.org
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Segment Routing Policy Architecture
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Clar= ence Filsfils
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ketan Talaulikar
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Voyer
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alex Bogdanov
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Mattes
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-spring-segment-routing-policy-09.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 37
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-11-01

    Abstract:
    =C2=A0 =C2=A0Segment Routing (SR) allows a headend node to steer a packet f= low
    =C2=A0 =C2=A0along any path.=C2=A0 Intermediate per-flow states are elimina= ted thanks
    =C2=A0 =C2=A0to source routing.=C2=A0 The headend node steers a flow into a= n SR Policy.
    =C2=A0 =C2=A0The header of a packet steered in an SR Policy is augmented wi= th an
    =C2=A0 =C2=A0ordered list of segments associated with that SR Policy.=C2=A0= This
    =C2=A0 =C2=A0document details the concepts of SR Policy and steering into a= n SR
    =C2=A0 =C2=A0Policy.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-spring-se= gment-routing-policy-09
    https://datatracker.ietf.org/doc/html/= draft-ietf-spring-segment-routing-policy-09

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-spring-segment-routing-policy-09


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

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


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

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

    --000000000000e06af405b3c53c8f-- From nobody Tue Nov 10 16:13:19 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78753A1243; Tue, 10 Nov 2020 16:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=jkGtIIFT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fqTXd68c Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnRY0HdDm6tA; Tue, 10 Nov 2020 16:13:15 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FA53A1258; Tue, 10 Nov 2020 16:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14415; q=dns/txt; s=iport; t=1605053528; x=1606263128; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PB1eyjSoyaVV4ewlJG+aiFF47HxgOBhwG5+mrMe+1rk=; b=jkGtIIFT7GETG4u71olYN0s6CVOeYAGItlkPfCHoQ46DqXnMOkNSDX7n Zx9XZtX7bjZVm6zdJEM4lLoGZbzyWyIyRgD9unoIv+Ay+3ds+B7nctNxO KeYV99rzScDZtDr09vs7EpNK5BGphjNtQv2utDVu+anoktRE01RjU4ZiZ 0=; X-IPAS-Result: =?us-ascii?q?A0B1BwC8K6tffZNdJa1iHQEBAQEJARIBBQUBQIFPgSMvU?= =?us-ascii?q?XtZLy4Kh3wDjVaKFYl+hG+BQoERA1QLAQEBDQEBGAEKCgIEAQGEBkQCghQCJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDAQEQCyMBASkDC?= =?us-ascii?q?wENAgIBCBEDAQEBAScHGwYGCxQJCAEBBAENBQgagwWBflcDLgEOpCACgTuIa?= =?us-ascii?q?HSBNIMEAQEFgTcCg1oNC4IQAwYFgTOCc4pMG4FBP4ERQ4JPPoIbQgEBA4EiB?= =?us-ascii?q?QESAQccBBoNCYMUgiyQFopsi1iQf1QKgm2JDYxxhTWCBoESihWIXItrhh6NN?= =?us-ascii?q?IF/iH2CbpJhAgQCBAUCDgEBBYFrIWlwcBU7gmlQFwINjh8LGBQYgyKEfReFR?= =?us-ascii?q?HQCNgIGCgEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AChfZCBzKJM3JjezXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRSBt+1sylnUDs3X6PNB3uzRta2oGWkN+o2Iv31KdptQHw?= =?us-ascii?q?QEhsMbk01FYoaFBET3IeSsY3k8G8JPB0dkuXemYgBZHc/kbAjUpXu/pTcZBh?= =?us-ascii?q?T4M19zIeL4Uo7fhsi6zaa84ZrWNg5JnzG6J7h1KUa7?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,468,1596499200"; d="scan'208,217";a="601188571" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 00:11:48 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AB0BmWM009422 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 00:11:48 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 18:11:48 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 18:11:47 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 18:11:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NqKob0UG4NxUchtPwVm/Z890g5Hm8GFaWcVsYy+oukOD6K2TXZnogLxxRTAzOQaY5KOCUC8c5IcsDUoylbrXFgZ2w3fbdtBQuMhU3Kkk/db8V/DQoXgZTEfy4LOfSVbzED/EghSjQs0x8rbELr0lzLF/b1ciQYoQaNC28LzTdcBTv8co9gB5tiWkf1bBNsYsHMVkiNxzC5LaH02CjahyBW7rYXp2N4IwxEO41ykI01Tt7LnYzsXQK2A+8bNRLDadkbjfn+cVKJxbtX4YV2UbIslj5JZwf92J4CptL+MTIP60fCPg7HMjhdB+fMh6Mmp2o3POGv+eHUd55yHUt+BpSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bf10/d3waJdNDPX9vKxq4jQHgG/lANU5L77FUHtZym0=; b=LNFO5Cvz9r6HWQ4bRjBf8maqxv2+HKTXReid8HgfDoPnfWc7mfq6lnZefnuWendZpT6egnNpOoP2SnFRj7U3IM4rbQGo2n0fFheX+xLUHT/yJg6ipKLZw2BYgexcA+BSi47OA0oSvdW6PvchEKIhRTfz28KmjTC5/ks7TGbVk17HrotRKhZItAtnAjvQGfDeaxhsS/irGZ/lI1wRukEZG9ggbO59xkz5YwNZ+rF502tx7nbjXSS20r3RfuF572hlC7WlOMp6cyhFDrZ8iwkeHVkDhUK2bkfCaRIT8BT3ssLW9+c8iGfWE04xBOAPxtB+mdlNKlNKbrYW2xBqxWYGhw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bf10/d3waJdNDPX9vKxq4jQHgG/lANU5L77FUHtZym0=; b=fqTXd68cdNU7+7GQcrlDXMpGP71n+RossQYkzh1np1jol72KGC7X6oRJCIB8wE8TjYcPolHBewJTZ3Xfog7NaAbA+IfJvNeSsrLNgVMTerkotzFmYi1qBeP2HyUzka+F4XiUBYCAwGnwk/VS3aeoMfLvAPtoeuhIr+opYI/jNIw= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM5PR1101MB2283.namprd11.prod.outlook.com (2603:10b6:4:50::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 00:11:45 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36%7]) with mapi id 15.20.3541.024; Wed, 11 Nov 2020 00:11:45 +0000 From: "Rakesh Gandhi (rgandhi)" To: Loa Andersson , "Chengli (Cheng Li)" , "James Guichard" , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQF8P8agAAVGqAACUm/tFA== Date: Wed, 11 Nov 2020 00:11:45 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 769b0e27-a55f-4cee-9891-08d885d65ff8 x-ms-traffictypediagnostic: DM5PR1101MB2283: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vRu75YGurKCbJ8j4fxvADEzpthPmLsEcw4Z8jamrJeMib2Te96+vL1kxVLCwKVZ2Tc6rj3e+ZHdTjVvFEwjT+CdkTctnQEu63kRT/5Yn1mYjajr//0kfIudscQlklJqmxxpmOu83sBgvzC1fkkGYbchJsKPv6+7gdEg2wFJ7qF7vUwEKnqExMyGxoPaSFB0axYcRDAgjRPwI++0YKfU2M/GLKOjWKg7vngAVvaNbrUmQheHYynu7N6xKsa6pIGBGTJ8loUWffX6JOBqOtdQf6F6xelIuUW/AqYp4ko58J63U0A+FrRqINIAGSz1pK45M3b+lgKVlavf0du9d5/kB0SOYV6q5GUVtoeKRvyPtXrTD6cWU7onMCyK/4mCEdpLU5i9EYJt8KJzmtaXrxJmi2A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(396003)(376002)(39860400002)(66556008)(8936002)(66946007)(186003)(91956017)(71200400001)(8676002)(5660300002)(26005)(6506007)(52536014)(316002)(66446008)(86362001)(2906002)(54906003)(33656002)(7696005)(110136005)(9686003)(478600001)(166002)(966005)(55016002)(83380400001)(76116006)(66476007)(64756008)(4326008)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FeEY3ftnsaLBeM9GE5hSs6Ux05dVIhOhynaMTsyTH+zOpK1xFMv2LNCuwoINYg9FYu+6Ozm5BsA9pEagIjdKx3ckXgYGImqU/r8nC2IImMGCH0CbheXOJvI1tNqsC1IoWBlBQDGd1TadTPIo55AiJRH7e42HNBb2avv4yAwX6DOSGxlCrMFt6qattDgmpScHbEyp4qvM/GYcKJTuWdh4v7Tn/XFwj4lAB7W/qCPVrRZb6d7BP+gmMe3VPOHDBW4IpNhyFH5Z43jh0eLyHoijI02uqWMJCpe0YLS1FhXu9IF81z961s7lUmS4Yg7wmjEtJ5KbLKJ9eXRcnZhQ87LYaYro5fymieOfw6oSWoFNFJbTyQPNphwEYjDfb31RU5emv9H6zUr8KBufD1HdWhdkEE8wU4o8/ks5gxcv96tKGK1xEoLP5r6qoIF+thBzLytQgC0Wo60JHuJ18su3R/m4ov4TR6rfktW5CTCxosvzL+8Y0+azqCG53dlYsHQmvJjk656fV34LRgHU+NO9ClrFdqpZRk9envbj+8YVj+mm5H8ypDJZ0zzLlwHpzxAd3BjUlK90wsNb7IjfHTtSGuMw+m95/Yowlh8MQjF1qRaHJWoPT1igKCrDHGam/sj6xVIE26h2H9vsxrOEmKEolFryZoGPM1J1EgeDoqOnD8E+kiYdT6DpA4HZUO8jR3BGGB4fIcCUUPn2T3R4yZrDerZJlt5ug/iqUNaL6CqtwJXj8wliVdP6BLQ13HGRhzLR7jjLhy5wJ3EfUbHBj5AZcOTtZ9PfRUaNfcZb9Fy1M+I1pFJNhTiLt1+rR8l1o2tcr4ShtlRa3QdlHz6MV/wjQ8l0aXpWjt2/txoCHSGzTMRCANAl8AUDHtGmMmDBKqJqDAMrC0lOaOp1IsA+WMzKjCtfRQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB311554F1A306DDFE70CAF38ABFE80DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 769b0e27-a55f-4cee-9891-08d885d65ff8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 00:11:45.1758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XCglULd4sAUAi1NPCrmyI2Xqt3ffMjS3KFqdi1rbCN7ncB1Mxy+7k9lU+8NP7c7yjzz/n3kCSFe2dFcwO3qIfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2283 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 00:13:18 -0000 --_000_DM6PR11MB311554F1A306DDFE70CAF38ABFE80DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Loa, We will add the expansion of the abbreviation in the next update. Thanks, Rakesh From: spring Date: Friday, October 30, 2020 at 12:31 AM To: Chengli (Cheng Li) , James Guichard , spring@ietf.org Cc: ippm-chairs@ietf.org , spring-chairs@ietf.org Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draf= t-gandhi-spring-twamp-srpm-11 Working Group, I support adopting this document. However I have one question; if it leads to (very small) changes in the document, this can be done after the adoption. I'm looking at HMAC-SHA: Consists of two parts HMAC: Hashed Message Authentication Code (expanded in the document). SHA: Secure Hash Algorithm (not expanded, but on the other hand it an well-known abbreviation) When we combine two abbreviations what rules apply, is it enough that eachpart is expanded "somewhere" even if the parts are found at different places. Or does the rule "expand at first occurrence apply? I guess that in part this depends on whether we view HMAC-SHA as one unit or two separate parts? And how familiar we believe our readers are with the abbreviations. I don't have a strong opinion on this, but would suggest that we place HMAC-SHA in the "Abbreviations" in section 2.2 and expamnd it fully. On 30/10/2020 10:01, Chengli (Cheng Li) wrote: > Hi WG, > > Support. However, there are some encoding format changes among versions, > hope the encoding format can be stable in the following revision ASAP. > > Many thanks for the authors=92 contribution! > > Thanks, > > Cheng > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *James > Guichard > *Sent:* Thursday, October 22, 2020 8:52 PM > *To:* spring@ietf.org > *Cc:* ippm-chairs@ietf.org; spring-chairs@ietf.org > *Subject:* [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear WG: > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12^th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional > week to allow the WG enough time to review these changes before deciding > on WG adoption. > > Some background: > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The > SPRING and IPPM chairs considered those comments, and upon review of > this version of the document, determined the following: > > * The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any > extensions. Several extensions including*Control Code Field > Extension for TWAMP Light Messages*, *Loss Measurement Query Message > Extensions*, and *Loss Measurement Response Message Extensions *were > included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > * The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the > IPPM WG. > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons > for that support (or lack thereof) as silence will not be considered as > consent. > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > Thanks! > > Jim, Bruno, & Joel > > // > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_DM6PR11MB311554F1A306DDFE70CAF38ABFE80DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thanks Loa,

    We will add the expansion of the abbreviation in the= next update.

     

    Thanks,

    Rakesh

     

    From: spring <spring-b= ounces@ietf.org>
    Date: Friday, October 30, 2020 at 12:31 AM
    To: Chengli (Cheng Li) <c.l@huawei.com>, James Guichard <ja= mes.n.guichard@futurewei.com>, spring@ietf.org <spring@ietf.org> Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs= @ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11

    Working Group,

    I support adopting this document.

    However I have one question; if it leads to (very small) changes in the document, this can be done after the adoption.

    I'm looking at

        HMAC-SHA: Consists of two parts
        HMAC: Hashed Message Authentication Code (expanded in th= e document).
        SHA: Secure Hash Algorithm (not expanded, but on the oth= er hand it an
             well-known abbreviation)
    When we combine two abbreviations what rules apply, is it enough that
    eachpart is expanded "somewhere" even if the parts are found at <= br> different places. Or does the rule "expand at first occurrence apply?<= br>
    I guess that in part this depends on whether we view HMAC-SHA as one
    unit or two separate parts? And how familiar we believe our readers are with the abbreviations.

    I don't have a strong opinion on this, but would suggest that we place
    HMAC-SHA in the "Abbreviations" in section 2.2 and expamnd it ful= ly.

    On 30/10/2020 10:01, Chengli (Cheng Li) wrote:
    > Hi WG,
    >
    > Support. However, there are some encoding format changes among version= s,
    > hope the encoding format can be stable in the following revision ASAP.=
    >
    > Many thanks for the authors=92 contribution!
    >
    > Thanks,
    >
    > Cheng
    >
    > *From:* spring [mailto:spri= ng-bounces@ietf.org] *On Behalf Of *James
    > Guichard
    > *Sent:* Thursday, October 22, 2020 8:52 PM
    > *To:* spring@ietf.org
    > *Cc:* ippm-chairs@ietf.org; spring-chairs@ietf.org
    > *Subject:* [spring] WG Adoption Call for
    > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
    >
    > Dear WG:
    >
    > This message starts a 3 week WG adoption call for document
    > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 endin= g
    > November 12^th 2020. Please note that this document has several change= s
    > from v-10 that were requested by the SPRING and IPPM chairs. For this =
    > reason, the chairs have extended the adoption call for an additional <= br> > week to allow the WG enough time to review these changes before decidi= ng
    > on WG adoption.
    >
    > Some background:
    >
    > Several review comments were received previously for document
    > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The
    > SPRING and IPPM chairs considered those comments, and upon review of <= br> > this version of the document, determined the following:
    >
    >   * The SPRING document should describe only the procedures = relevant to
    >     SPRING with pointers to non-SPRING document/s = that define any
    >     extensions. Several extensions including*Contr= ol Code Field
    >     Extension for TWAMP Light Messages*, *Loss Mea= surement Query Message
    >     Extensions*, and *Loss Measurement Response Me= ssage Extensions *were
    >     included in
    >     https://tools.ietf.org/html/draft-gandhi-spring= -twamp-srpm-10 and
    >     should be removed from the SPRING document. >   * The TWAMP extensions included in
    >     https://tools.ietf.org/html/draft-gandhi-spring= -twamp-srpm-10 should
    >     be described in a new document published in th= e IPPM WG.
    >
    > These conclusions were discussed with the authors of
    > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the r= esult
    > of which is the publication of the following two documents:
    >
    >   * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srp= m-11. The
    >     subject of this WG adoption call.
    >   * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00= . This
    >     document will be progressed (if determined by = the WG) within the
    >     IPPM WG.
    >
    > After review of the SPRING document please indicate support (or not) f= or
    > WG adoption to the mailing list. Please also provide comments/reasons =
    > for that support (or lack thereof) as silence will not be considered a= s
    > consent.
    >
    > Finally, the chairs would like to thank the authors for their efforts = in
    > this matter.
    >
    > Thanks!
    >
    > Jim, Bruno, & Joel
    >
    > //
    >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.i= etf.org/mailman/listinfo/spring
    >

    --

    Loa Andersson          &n= bsp;            = ; email: loa@pi.nu
    Senior MPLS Expert         &nb= sp;            =     loa.pi.nu@gmail.com
    Bronze Dragon Consulting        &nb= sp;    phone: +46 739 81 21 64

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/spring

    --_000_DM6PR11MB311554F1A306DDFE70CAF38ABFE80DM6PR11MB3115namp_-- From nobody Tue Nov 10 17:16:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD53A3A127D; Tue, 10 Nov 2020 17:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciena.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 sAtyVk-935_K; Tue, 10 Nov 2020 17:16:21 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 968A13A1287; Tue, 10 Nov 2020 17:16:21 -0800 (PST) Received: from pps.filterd (m0174892.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AB1AN7i006428; Tue, 10 Nov 2020 20:16:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=06252019; bh=JOnCOmNntVMKsB1qwdwF++SfVsZ06JzmlHtqSWpEPB4=; b=G5T0xVyCGA6jo8oL1WLIFs1pxD2f0n7RrpzCIlUFZxD5hFCxnH+767qKST5yM3LqKzJU s0jytH0c3ElqxsGJuN8dDcv4LNAJGbCkUvVPmAIRC3e861d7/YdN894fNJ1Zsxe09krt YmAlcY+8k0vIuSt/4TzQckysVdYuNhN72sFmaK7+HMNoUZz5QQ6lGn04KjeK+TH+IGFX 5Nb6LdZ2rFF4YyOfagz+UdtKhOskKgLyofzefsfUhcFAmfMq2Xk1EmDC7WxefQq6Wyy6 74gmlPnvmO2nnjQirKIjToC7e2qTeUuZWWch94mPLI3KyyrUXKIBDJayvl45l1TnP1Gb wQ== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2056.outbound.protection.outlook.com [104.47.38.56]) by mx0a-00103a01.pphosted.com with ESMTP id 34ns77fre7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2020 20:16:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mpfUUTGwxO/hRUtWcNPjnMymUxdGUp0D9p9KFHmIoTB9CG2iJtK2d/s7hPYzkjxv9Ee6XTjy/aByNv+h51WUj4f+ZK+i0HqwQQTvAh8sMvxqDxiJZzdjlSd89Mmh2WXthQjI0MrMsh4lWY390vhyWqu9RBXcqoAJgt2XQxXhEu9Zs865S5OrXhKD3wFB4qnCk3E6Fs03dUwFF6IL0ffApFy6+uwrBIDcKbkkDThwvUCQL06vGfHLvImtfaB5f2Lq5prsZk8jsSus2YR4dg4DyLRlZ2J0ZNpc6pUlEdQs70zv92TJT44yFZwhow4sodspjvOKDCO1JClmbKgxa/wBCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JOnCOmNntVMKsB1qwdwF++SfVsZ06JzmlHtqSWpEPB4=; b=d/DpYRoOzWa5+c+wLzkZ8WS3GNMfq+e3q9RcZAaXnH9Z+FbzZ9at/4hmw5GDiuv1QWBvjqwLhq9QClkxoU3dtbB6/DeonvX/56Ce350ofPI4ysgv/2ufQPEOaZz5cKRQH7rX6u/qYS8Mq+kU9ZJSIVx7pYvl3NwjKTzvLkWoydSr/MLnCY7NKoBjdgdSfB43dM7U1nja5PAebmoeX8SU7ixOYTSLcFTdk7L03Edc3ttPQotIoV5hoq80q2ex82+y857PtMqGtYbLBqoMvuLvvi1eRNScJs7MR7GC3CJ01dfMtj/emDHkbJU6VNiTTR0zcDOkEUxdf5RlbmFbbMmDRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none Received: from BY5PR04MB6407.namprd04.prod.outlook.com (2603:10b6:a03:1e1::17) by BYAPR04MB4198.namprd04.prod.outlook.com (2603:10b6:a02:fd::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Wed, 11 Nov 2020 01:16:15 +0000 Received: from BY5PR04MB6407.namprd04.prod.outlook.com ([fe80::eca7:bda7:f0b9:f4ec]) by BY5PR04MB6407.namprd04.prod.outlook.com ([fe80::eca7:bda7:f0b9:f4ec%8]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 01:16:15 +0000 From: "Yadav, Bhupendra" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "Rakesh Gandhi (rgandhi)" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AQHWrGeRzJZJco7cXUmrSmzpjZ4qmqnCNvv+ Date: Wed, 11 Nov 2020 01:16:15 +0000 Message-ID: References: <038360BF-72E4-4777-BA0B-B0E4F0316156@cisco.com> In-Reply-To: <038360BF-72E4-4777-BA0B-B0E4F0316156@cisco.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=ciena.com; x-originating-ip: [184.144.114.156] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 290dd87d-28c4-471d-0cd6-08d885df62ce x-ms-traffictypediagnostic: BYAPR04MB4198: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YoI5+5J3ce/cmq4Fd5ak3qeHPnJIDZWaV/c8rAqK6UONz6M7M5s1eXLIU0nUNibgd7/sOsxuPYcmeXhVUdBNdH6eTPNDdlI0En0EqqdLd/CzPYDje5n9pc6RbxqAgUOGgjI+9cfbSuq2gdf2ngMNpCroC9pHJS8Kq5d0CvGkC29Hert3kr+KsJQzjqB9808EGhZo4eHNaNvGE/kAd6QORx5gUJpGY8REHUzTqlf7sTUrj2wApE2exNWXIeD3qo+5F+4pamuZ4H/vW8Q9tqIlP3ST/RuJaT0tPMv6Ld7meHj04iYzBQF5Ge2l2ku+ut4Bm7rXq06AJo62rjesWo5dhgu3gbgYLiyQSbEbgMczCmIzLo7nvzNf0bbRIf1FSHBB4pNQvY2f28OKDpqxxycXdg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR04MB6407.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(39850400004)(366004)(396003)(316002)(86362001)(6506007)(53546011)(8676002)(71200400001)(5660300002)(7696005)(9686003)(19627405001)(8936002)(55016002)(110136005)(83380400001)(166002)(54906003)(4326008)(186003)(33656002)(26005)(2906002)(966005)(66556008)(52536014)(66476007)(76116006)(66946007)(91956017)(478600001)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aBhC9TGo7wOn3CLeMiD7I0SKD8/r0mukGU7Zh/eqBvDKByq/0qxeN9jzlttbJlTjv0+fbUUtDZbcewU6j+Ia9AiYiSKQClPDDs9JMlwXhQD8WWdBuycQc/IDsOFYEuezOIAZvtc8DO0zkm2Y8sVX0hBikwepAnqi6QJVkPNgJbPQhZJv/QJLnjJBD72E7aBhn49LWx4QzWEsC3daKM6/MrQ3XazqumRhAuwxLkHyze2c8ZIyuhYTj2i5/Hc2A8DB77eojK2SKtUsT4U5bp6qbKGL/OE0AMPdoz1JQDy9YHvUGvO9vH7JBcbl41C3Q2CJlOz+mliGiNA+6tRyoWRQFnnoJ6kmcd1ZxRDgv+TZ0khe689j7vNXZCBpPrTQKb1GiSAOAMm9Tn8llIXvEubTR8fvk9z4hREDqiWg/kw3t9kD00ag2tV390dlHw/DpDHxIxnVhBCfT68RPzbD4vHY5AgxpIqMQHMKkG6WSkvFVfpMIKt5gen5HllhI0vo1fdPisBFx+BkiWr3YO+PIX2l1/fwyg6MhyfAANVuXKP6CwvAjI2skgLOom4nkNXIdhcKheLSxOC67k/5ycvwzDqb5jvbYmjD7EErIoQfJBm/bWwbtpBCm8jRilUQxFMECuSoAwT21O8oME5A1k4rU9MEfg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR04MB64074E0C486C078B820F96FEDCE80BY5PR04MB6407namp_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR04MB6407.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 290dd87d-28c4-471d-0cd6-08d885df62ce X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 01:16:15.3980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZGn6R9rDslpvNKzubQ/b39sLuHfxAhQdgVJ9riDSg8R06p8JhjBVxkpPmAAHGvWHoKc7LfHpfR4rbUba0IY/1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4198 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-10_09:2020-11-10, 2020-11-10 signatures=0 Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 01:16:24 -0000 --_000_BY5PR04MB64074E0C486C078B820F96FEDCE80BY5PR04MB6407namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support WG adoption. Thanks, Bhupendra From: spring on behalf of James Guichard Date: Thursday, October 22, 2020 at 8:52 AM To: "spring@ietf.org" Cc: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org"= Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-03 [tools.ietf.org] Dear WG: This message starts a 3 week WG adoption call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-stamp-srpm-03 [tools.ietf.org], ending= November 12th 2020. Please note that this document has several changes fro= m v-02 that were requested by the SPRING and IPPM chairs. For this reason, = the chairs have extended the adoption call for an additional week to allow = the WG enough time to review these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-stamp-srpm-02 [tools.ietf.org]. The SPRING and IPPM chairs considered those comments, and upon review= of this version of the document, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for STAMP Messages,= Loss Measurement Query Message Extensions, Loss Measurement Response Messa= ge Extensions, Node Address TLV Extensions, and Return Path TLV Extensions = were included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02 [tools.ietf.org] and should be removed from the SPRING do= cument. * The STAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-stamp-srpm-02 [tools.ietf.org] should be describe= d in a new document published in the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.org= /html/draft-gandhi-spring-stamp-srpm-02 [tools.ietf.org] the = result of which is the publication of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 [tools.= ietf.org]. The subject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 [tools.ie= tf.org]. This document will be progressed (if determined by the= WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_BY5PR04MB64074E0C486C078B820F96FEDCE80BY5PR04MB6407namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi,

    I support WG adoption.

    Thanks,
    Bhupendra


    From: spring <spring-bounces@ietf.org&g= t; on behalf of James Guichard <james.n.guichard@futurewei.com>
    Date: Thursday, October 22, 2020 at 8:52 AM
    To: "spring@ietf.org" <spring@ietf.org>
    Cc: "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, &= quot;spring-chairs@ietf.org" <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 [tools.ietf.o= rg]

     

    Dear WG:

     

    This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 [tools.ietf.o= rg], ending November 12th 2020. Please note that this docume= nt has several changes from v-02 that were requested by the SPRING and IPPM= chairs. For this reason, the chairs have extended the adoption call for an additional week to allow the WG eno= ugh time to review these changes before deciding on WG adoption.

     

    Some background:  

     

    Several review comments were received previously for document https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 [tools.ietf.o= rg]. The SPRING and IPPM chairs considered those comments, = and upon review of this version of the document, determined the following:<= /span>

     

     

    These conclusions were discussed with the authors of <= /span>https://tools.ietf.org/html/draft-gandhi-spr= ing-stamp-srpm-02 [tools.ietf.org] the result of which is the publication of the followi= ng two documents:

     

     

    After review of the SPRING document please indicate su= pport (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that suppo= rt (or lack thereof) as silence will not be considered as consent.

     

    Finally, the chairs would like to thank the authors for th= eir efforts in this matter.

     

    Thanks!

     

    Jim, Bruno, & Joel

    --_000_BY5PR04MB64074E0C486C078B820F96FEDCE80BY5PR04MB6407namp_-- From nobody Tue Nov 10 17:21:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B443A1293; Tue, 10 Nov 2020 17:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6_5t6-I1iMxL; Tue, 10 Nov 2020 17:21:33 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000243A1290; Tue, 10 Nov 2020 17:21:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CW6Q45bsdz6G99s; Tue, 10 Nov 2020 17:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605057692; bh=S53ASYK8pv9Pq6yp/OTOA+VucsnsebVp04sgOIPetq0=; h=Subject:References:To:From:Date:In-Reply-To:From; b=aeBl/7Dg+OBUl7HcyBQx/lvDQvLQSgUtSQyWkJF8rVZRMVMBA2apD3GNdoCXA1pcX vOqP0Xpla0ztNl/tFyhbhXGGynLgOg/jj6eH+UoMju93QtnqB3No22ceY54oP+XP+o vFF2kNN1pmqCosG7p5c74pXnCiDRs91Pxb+no6RA= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (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 4CW6Q372Ptz6G7wp; Tue, 10 Nov 2020 17:21:31 -0800 (PST) References: <160505341655.5428.1552478254085102351@ietfa.amsl.com> To: "lisp@ietf.org" , "sfc@ietf.org" , "spring@ietf.org" From: "Joel M. Halpern" X-Forwarded-Message-Id: <160505341655.5428.1552478254085102351@ietfa.amsl.com> Message-ID: <665f0427-5c4f-e99b-6fec-1a4564a05d50@joelhalpern.com> Date: Tue, 10 Nov 2020 20:21:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <160505341655.5428.1552478254085102351@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Fwd: NomCom needs your feedback! X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 01:21:35 -0000 This request came from the nomcom chair. The nomcom needs your input. Please. Thank you, Joel -------- Forwarded Message -------- Subject: NomCom needs your feedback! Date: Tue, 10 Nov 2020 16:10:17 -0800 From: NomCom Chair 2020 To: IETF Announcement List CC: ietf@ietf.org Hi IETF, NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, and IETF Trust. We need more input from the community both on specific nominees and on over-arching topics regarding what the community wants from these specific groups and wants from its leadership in general. We need *your* input. ** Deadline for community feedback is Friday November 20. ** We've paid attention to discussions on the ietf list. Issues raised there have been brought up in interviews. We've also asked questions of nominees based on feedback received, and based on the "Topics" that people said were important. We're listening to you. But most of the input to date has come from a few consistently vocal people. We need to hear from more of you. I scheduled our office hours during the 2 weeks before next week's IETF, because IETF week is so busy. We have one more left (18:00-19:00 UTC November 11). No-one but NomCom members showed up for our first 3. ☹ If there is demand for more office hours, I'll schedule them; but this really doesn't seem to be the preferred format for input. Most input is coming in as either - email to nomcom20@ietf.org - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/ On the feedback page, the specific nominees are all listed at the top. General Topics are at the bottom. We pay attention to all the comments we get through these channels. I'll also try to hang out in Gather.Town during IETF breaks next week. I'm not going to have a specific NomCom area in Gather.Town, because it was really lonely hanging out there during IETF 108. But please feel free to hunt me down and bend my ear -- on NomCom issues or just to chat. I miss seeing all of y'all! Barbara Barbara Stark NomCom 2020 Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Tue Nov 10 19:26:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0D3A08BB for ; Tue, 10 Nov 2020 19:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kiR6LFLWlfYu for ; Tue, 10 Nov 2020 19:26:13 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D763A08A6 for ; Tue, 10 Nov 2020 19:26:13 -0800 (PST) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CW97k743jz67KPv for ; Wed, 11 Nov 2020 11:24:18 +0800 (CST) Received: from fraeml703-chm.china.huawei.com (10.206.15.52) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 11 Nov 2020 04:26:10 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 11 Nov 2020 04:26:10 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.102]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Wed, 11 Nov 2020 11:26:04 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" Thread-Topic: IETF109 SPRING WG Agenda Thread-Index: Ada32epD+7qTa3FnRMmDENcMid1GBg== Date: Wed, 11 Nov 2020 03:26:04 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE1957B202@dggeml512-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.114] Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE1957B202dggeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] IETF109 SPRING WG Agenda X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 03:26:15 -0000 --_000_4278D47A901B3041A737953BAA078ADE1957B202dggeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The SPRING Agenda has been published. Please let us know if any change is n= eeded. https://datatracker.ietf.org/meeting/109/materials/agenda-109-spring-00 To the presenters, please send your slides to spring-chairs@ietf.org and/or upload them in the data tracker before Sund= ay evening. https://datatracker.ietf.org/meeting/109/session/spring Thank you! Best regards, Shuping --_000_4278D47A901B3041A737953BAA078ADE1957B202dggeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    The SPRING Agenda has been publ= ished. Please let us know if any change is needed.

    https://datatracker.ie= tf.org/meeting/109/materials/agenda-109-spring-00

     

    To the presenters, please send = your slides to spring-chairs@ietf.org and/or= upload them in the data tracker before Sunday evening.

    https://datatracker.ietf.org/meeting/1= 09/session/spring

     

    Thank you!

     

    Best regards,

    Shuping

     

    --_000_4278D47A901B3041A737953BAA078ADE1957B202dggeml512mbxchi_-- From nobody Tue Nov 10 19:33:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1478D3A08E7 for ; Tue, 10 Nov 2020 19:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=R/UmsT7k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TLBvSY3E Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr9_7KLPP80Y for ; Tue, 10 Nov 2020 19:33:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4555A3A0934 for ; Tue, 10 Nov 2020 19:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95936; q=dns/txt; s=iport; t=1605065593; x=1606275193; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XjkKG8awzR8r2//emusyKSmOAC16GwV2iJ5r6lYgRhw=; b=R/UmsT7kveJkvG4orl7uTB3sP10hlDegcMPXwNg6+mZ/+h1ciZt8Y3Iu R127hLXRvlSmw31eyzXgoBtPWmYGit60GwpqxIvd92aV5jrna9U4wJnrK ddlhT+AYiO3B3ihZiU6hencOAkk4UzLhmzyp+hfTZ8Eb0rZZ0NaM7G6zy M=; X-IPAS-Result: =?us-ascii?q?A0D/CAAfW6tffYYNJK1iHgEBCxIMgzIvIy57WS8uCoQzg?= =?us-ascii?q?0kDjVaKFY5tgUKBEQNUCwEBAQ0BARgBDAgCBAEBhAZEAheBfQIlOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBBQBAYYPCCUMhXIBAQEBAwEBEAgJChMBASMJCwELB?= =?us-ascii?q?AIBCBEBAwEBIQEGAwICAh8GCxQDBggCBA4FCBqDBYF+VwMuAQ6kFQKBO4hod?= =?us-ascii?q?oEygwQBAQWBMwEDAg5Bgw8NC4IQCYE4gnOCZU5CgQaFURuBQT+BEUOCTz6CG?= =?us-ascii?q?0IBAQIBARWBEQESASMFBx8JAgaCWTOCLJAsGYMhhxyMDZBKVAqCbYkNjHGFN?= =?us-ascii?q?YMYgSqIa4EtkGeCM5VRiH2Cbo4vhDICBAIEBQIOAQEFgUEqIWlwcBUaIYI1A?= =?us-ascii?q?QEyCUcXAg2BNIxQGwwXg06FFIVEdAI2AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AUU/PkxeA0oxy5Q5s0CLHxryLlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,468,1596499200"; d="scan'208,217";a="604984719" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 03:33:11 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AB3XBdu009917 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 03:33:11 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 21:33:11 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 21:33:10 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 21:33:10 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k+yoYl+juIKis5vULYBHJd4OM+G2rbgdodHyeYgWBKikeG3xZIux8AkvlZ+GclmG5+0flkzHBuHe1fUkToKCU599CKtuiun5rQIiXwSslpLc8WtJgrlblW2LxEK6Yi9vmOc9IMjytWNFIuHqMt/Y2AwU20f1mfLCpCc959sWePodjoEG4+ow7HbjVSIU0sAREs69vME32oecEM7cx4fe8U9MlA1W6ydRvCsNapo5BCEbXT39RUDfVxhF7OsNfAc63DhCjb+m7CFI8FoesK7y6Ln0LXY8b1xRQxaKBGkTePZ2/i+Mv5ZS8PFSgPDKoPEJW53LeZbGFZXRJ0NHeI3PGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XjkKG8awzR8r2//emusyKSmOAC16GwV2iJ5r6lYgRhw=; b=LjEBkA6P+ph0bJUPddkP8Zti8AjEU2uNoyaiYn6wX8Qy9/Q3gLkjdEX4Rf/Ppi228RlpX7opcWC2xg29g49HO92Q7koKW3yERNVTAcXWIKOgWCGd1fDqljawstW3kxGr2WKCMzxEZ4fd1v34F/keQ5jPOiIdq4tw/8wrADuhLPOa9/yNAEwYRl/9IxGi2vUKBnsgtgarPf3xoSiUJofkHKv3VeGgdoLfhwroVKqNcIOxNdJnC3krpjCZwPZAPsBw56Nks0NSSO+jwc11uD9he9/AGWHb60aG0oCxhK1lzjYihLS33PyPRL0mwcJjGKeE57c2nCSQJizb/FRkrLqRhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XjkKG8awzR8r2//emusyKSmOAC16GwV2iJ5r6lYgRhw=; b=TLBvSY3ErbBh0Yx6OebY6Z/kmFj3CXnIAget45VO0dVoo14a3oRKR3KvGGjOljNYEL+jCSvJ8WXkj6wzNKH2gNuiroKuOjB+XSS7jpwunIVMrT0wvSSLmmWpJB3Zl0FzSejOSTh23WtftN6mCCQQObXbKLgibsMuyjKrhnHsDoA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1519.namprd11.prod.outlook.com (2603:10b6:301:d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Wed, 11 Nov 2020 03:33:09 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 03:33:09 +0000 From: "Ketan Talaulikar (ketant)" To: Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAwoDICAAP2ogIAAmcsAgACMyMA= Date: Wed, 11 Nov 2020 03:33:09 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14293e36-22b9-417b-2c5b-08d885f28281 x-ms-traffictypediagnostic: MWHPR11MB1519: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /vNA/7UyTalnOeDPNNwsv2gyWIm2H44L4xUVfqjSw9UbVjEGo6RNYhKEU5f8JzI95erYQvmLNp1zAWQkhwx2yXb4FclH3kumGfHfRRzfZyVwr26SAdK8OW4yzlim5Z3Q+7kojCX56kdkxUemUo3nrsiEU489TotAsdI2RVEBfGoNLaDXBllwx81SjDqmERfk5t//t1qqrkvhK+Nax05MiUUKyT6/PQih9noLMQAzRsqTvoFvvNNWMn9gNqWqjpe9ar9fcxYVJkz+A6S7CxJ3bEkSwsXSePNd82pCh6s9oVKrw/fgfU4JD692RnWYl58/HGHYE+TZ9imTCSXGyJjOkAbLjl9uRno9rTLSg2wjflwnB8RQ1ZlcDvVWm/bdUNiCFUvsINWidmk/Bz5YjYFelw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(136003)(39860400002)(396003)(8676002)(86362001)(4326008)(6916009)(16350225007)(64756008)(2906002)(166002)(8936002)(6506007)(9686003)(55016002)(66446008)(53546011)(52536014)(5660300002)(66556008)(66574015)(66946007)(71200400001)(7696005)(9326002)(316002)(76116006)(83380400001)(66476007)(33656002)(478600001)(26005)(966005)(186003)(30864003)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: l8fxsTfSyf0d/1Xj/nWgXPRavxKv5wZsz2HfmtNkpMoZz9Z3lY6uEpW9pveZWWV5irPwCuJsyhXtYjYCFOi4ea2Fz4F5lvkb1L8qoc/QWN5+aNPmYJcQua5kPbtlKgIipp5AR9xxlt0v+UM0xib28x6NunVZ778TNl5WV2Hain7qAdNVMvtS7bVtbtbBOeFyHUd4lf7tFHR/1ZW/3UCMS6xP9ds61SLwpIvUsTjPKc3YE3zsG7oMtYBJ3mxIIXL98WYeGxwF2jHr79Vy2U7WXpM0cMNysWopAl1Evk1P5rNMpMZmOHF16p2SaAv0zxFIBK0qkMW2qnYWLK9rFns8mVF+W1DNcEjxm1DRonXE9HobuEMOnV++QJfdzCLjObUF/zs8Kq01jTaIsIYqHjrYGfj8n1IDT3qWAisl2FuAV0MgV4ZU3bGrnjLfazUxe4uksk56uEBUYY0rNYL+pEJS5FdFgr+FTuJGq7G1gI1cxlC8JJiNw52s8WktvrTbY2FSSdS6tJNIy8aFA5NFhNeAkSJZm7QIZ1UQi1ct0/wbwsAwWfxUNj7CgAkYQB32M9CiPDQwKGIjsGH7BLcnmDXZ3vlzdvX/1iQzxTsj+SHPop2Psqp1GltMur/FA3azjR4jzAnnZbKskNrJZQfxOgNL1yk1E6ULrDh5aEy/ql2C4vJP6+Mz1UkGQyq89etpZ9EFSWHgcy0Rg+GzaUk2Na8lKD2fNHfGcu+oCsX8kMOcSMXyjOxVZ8uBbenuwQmUeR6S3mBEVGU+G6gFK60fXRunXVr8fk8u6rww+rz1+c2tvfUrQD4yrPHJ8E7cktttd+np7ClY158Dfa5CUwDtdSynTolGe8mrVoYNcletugaNev818oJCJsN4SqILDz9uA/ah33w+wyT/FfV5SKs2ZT84ng== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45708212D3D166F34006C0C5C1E80MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14293e36-22b9-417b-2c5b-08d885f28281 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 03:33:09.0690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fFxKgKc4a57Gy49CMr4hUhkwJr/7k3F4ya6MXT5bkZl2jTU23m+E+jHdsCbAtGRKSZMlCuDqjYpZ74SNnUL+CA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1519 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 03:33:16 -0000 --_000_MW3PR11MB45708212D3D166F34006C0C5C1E80MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF2YW4sDQoNClBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuDQoNCkZyb206IFZpc2hudSBQ YXZhbiBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbT4NClNlbnQ6IDExIE5vdmVtYmVyIDIw MjAgMDA6MjYNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29t Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCktldGFu LCBIaSENCg0KUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHJlc3BvbnNlcyAocHJlZml4ZWQgVlBCKS4N Cg0KUmVnYXJkcywNCi1QYXZhbg0KDQpPbiBUdWUsIE5vdiAxMCwgMjAyMCBhdCA0OjA0IEFNIEtl dGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFudEBj aXNjby5jb20+PiB3cm90ZToNCkhpIFBhdmFuLA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93 Lg0KDQpGcm9tOiBWaXNobnUgUGF2YW4gQmVlcmFtIDx2aXNobnVwYXZhbkBnbWFpbC5jb208bWFp bHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+DQpTZW50OiAxMCBOb3ZlbWJlciAyMDIwIDAwOjA4 DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86 a2V0YW50QGNpc2NvLmNvbT4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0KS2V0YW4sDQoNCk11Y2ggVGhhbmtz IGZvciB0YWtpbmcgYSBzdGFiIGF0IGFkZHJlc3NpbmcgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUg cGF0aCB1c2UtY2FzZSEgV2Ugc2VlbSB0byBiZSBjb252ZXJnaW5nLg0KW0tUXSBUaGFua3MgZm9y IHRoYXQgZmVlZGJhY2sgYW5kIGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBwcm9wb3NhbCBpbiB0aGUg ZHJhZnQgZG9lcyBhZGRyZXNzIHRoZSB1c2UtY2FzZS4gSSBiZWxpZXZlIHdlIGFyZSBub3cgZGlz Y3Vzc2luZyB0aGUgbWVjaGFuaWNzIG9mIGhvdyB0aGlzIGlzIGFjaGlldmVkIHdpdGhpbiB0aGUg Y3VycmVudCBTUiBQb2xpY3kgZnJhbWV3b3JrLg0KDQpIb3dldmVyLCBJIGRvbuKAmXQgdW5kZXJz dGFuZCB3aHkgeW91IG5lZWQgdG8gdXNlIGFkZGl0aW9uYWwgU1IgcG9saWNpZXMgKGFuZCB1bm5l Y2Vzc2FyaWx5IGJ1cm4gYWRkaXRpb25hbCBjb2xvcnMpIHRvIGFkZHJlc3MgdGhpcy4NCltLVF0g SSBkbyBub3QgZm9sbG93IHdoYXQgeW91IG1lYW4gYnkg4oCcYnVybiBhZGRpdGlvbmFsIGNvbG9y c+KAnS4gQ29sb3IgaXMganVzdCBhIDMyIGJpdCBudW1iZXIgdGhhdCBpbmRpY2F0ZXMgdGhlIOKA nGludGVudOKAnSBhbmQgaXMgbm90IHJlYWxseSBhIHNjYXJjZSByZXNvdXJjZS4gQXNzaWduaW5n IGEgY29sb3IgdG8g4oCcYSBjb21wb3NpdGUgaW50ZW504oCdIHNlZW1zIGxpa2UgYSBzZWFtbGVz cyB3YXkgdG8gaW50ZWdyYXRlIHdpdGggZXhpc3RpbmcgbWVjaGFuaXNtcyBmb3IgU3RlZXJpbmcg b3ZlciBTUiBQb2xpY2llcy4gVGhpcyBnaXZlcyB0aGUgZmxleGliaWxpdHkgZm9yIHNheSBzb21l IEJHUCBzZXJ2aWNlcyB0byBiZSBzdGVlcmVkIG92ZXIgdGhlIGNvbnN0aXR1ZW50IGV4cGxpY2l0 L2R5bmFtaWMgaW50ZW50IHdoaWxlIG90aGVycyBjYW4gc3RlZXIgb3ZlciBhIGNvbXBvc2l0ZSBp bnRlbnQgdGhhdCBpbmNsdWRlcyB0aG9zZSBpbmRpdmlkdWFsIGV4cGxpY2l0L2R5bmFtaWMgaW50 ZW50cy4NCg0KW1ZQQl0gVGhlIOKAnGZsZXhpYmlsaXR54oCdIHRoYXQgeW91IGFyZSByZWZlcnJp bmcgdG8gaXMgdW5kZXNpcmFibGUgZm9yIHRoaXMgdXNlLWNhc2UuIEZvciB0aGUgdHJhZmZpYy1z cGxpdCB1c2UtY2FzZSwgd2UgZG9u4oCZdCB3YW50IGFueSBvdGhlciBzZXJ2aWNlcyB0byBiZSBk aXJlY3RseSBzdGVlcmVkIG92ZXIgdGhlIGNvbnN0aXR1ZW50cyB3aGVuIHRoZXkgYXJlIHBhcnQg b2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGguDQpbS1RdIEkgYmVsaWV2ZSB0aGUgdXNlLWNh c2UgdGhhdCB5b3UgYXJlIHJlZmVycmluZyB0byB3YXMgZm9yIHNwbGl0dGluZyBzb21lIHRyYWZm aWMgZm9yIGEgc2VydmljZSBvdmVyIGEgYmx1ZSBwbGFuZSBhbmQgdGhlIHJlc3Qgb3ZlciBhIHJl ZCBwbGFuZS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUgbWF5IGJlIG90aGVyIHNlcnZpY2VzIHRo YXQgdXRpbGl6ZSBvbmx5IGEgc2luZ2xlIHBsYW5lLiBUaGUgZmxleGliaWxpdHkgdGhhdCBJIHdh cyByZWZlcnJpbmcgdG8gd2FzIHRvIGVuYWJsZS9hbGxvdyBmb3IgZWl0aGVyIG9mIHRoZSB0d28g c2NlbmFyaW9zIGFuZCB0aGVyZSBtYXkgYmUgb3RoZXIvbW9yZSB1c2UtY2FzZXMgZm9yIHdoaWNo IHdlIG5lZWQgYSBtb3JlIGdlbmVyaWMgZnJhbWV3b3JrLg0KDQpUaGUgY3VycmVudCBwcm9wb3Nh bCBpbiB0aGUgZHJhZnQgd291bGQgaGF2ZSBiZWVuIGFjY2VwdGFibGUgaWYgdGhlIGNvbnN0aXR1 ZW50IFNSIFBvbGljaWVzIHdlcmUgdW5jb2xvcmVkIOKAkyBidXQgdGhhdCB3b3VsZCB2aW9sYXRl IHRoZSBjdXJyZW50IHJ1bGVzIGltcG9zZWQgYnkgdGhlIGRyYWZ0Lg0KDQoNCldoeSBjYW7igJl0 IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgganVzdCBiZSBhIGdyb3VwaW5nIG9mIGV4cGxp Y2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYyBjYW5kaWRhdGUgcGF0aHM/DQpbS1Rd IFRoaXMgaXMgYmVjYXVzZSBpbiB0aGUgU1IgUG9saWN5IGZyYW1ld29yaywgdGhlcmUgaXMgb25s eSBhIHNpbmdsZSBhY3RpdmUgQ1Ag4oCTIGl0IG1heSBiZSBleHBsaWNpdCBvciBkeW5hbWljLiBO b3cgd2XigJl2ZSBhZGRlZCBhbm90aGVyIENvbXBvc2l0ZSBDUCB0eXBlIHRvIGNvdmVyIHRoaXMg c3BlY2lmaWMgdXNlLWNhc2UuIFlvdXIgcHJvcG9zYWwgd2lsbCByZXN1bHQgaW4gMyBjYW5kaWRh dGUgcGF0aHMgYmVpbmcgYWN0aXZlIHdpdGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kg4oCTIG9uZSBl YWNoIG9mIHRoZSBleHBsaWNpdCBhbmQgZHluYW1pYyBDUCBhbmQgdGhlbiBhZGRpdGlvbmFsbHkg dGhlIENvbXBvc2l0ZSBDUC4gVGhpcyBicmVha3MgdGhlIGV4aXN0aW5nIHJ1bGVzIGZvciBzZWxl Y3Rpb24gb2YgQ1AgYmFzZWQgb24gcHJlZmVyZW5jZSBhbmQgbWVjaGFuaXNtcyBsaWtlIGZhbGxi YWNrIGJldHdlZW4gQ1BzLiBXaGlsZSB0aGUgY3VycmVudCBwcm9wb3NhbCBpbiB0aGUgZHJhZnQg cHJvdmlkZXMgYSB3YXkgdG8gYWRkcmVzcyB0aGUgbmV3IHVzZS1jYXNlIHdpdGggYSBiYWNrd2Fy ZHMgY29tcGF0aWJsZSBleHRlbnNpb24gdG8gdGhlIFNSIFBvbGljeSBmcmFtZXdvcmsuDQoNCltW UEJdIFRoZSBwcm9wb3NhbCBpbiBteSBwcmV2aW91cyBlbWFpbCBpcyBiYWNrd2FyZHMgY29tcGF0 aWJsZSBhbmQgZG9lcyBub3QgaW50ZW5kIHRvIGJyZWFrIGFueSBleGlzdGluZyBydWxlcyBmb3Ig ZGVlbWluZyBhIGNhbmRpZGF0ZSBwYXRoIGFjdGl2ZS4gQXMgcGVyIHRoZSBydWxlcyB0aGF0IGFy ZSBvdXRsaW5lZCBpbiBTZWN0aW9uIDIuOSwgb25seSB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBw YXRoIGlzIOKAnGFjdGl2ZeKAnSBnaXZlbiBpdHMgcHJlZmVyZW5jZS4gVGhlIGNvbnN0aXR1ZW50 IGNhbmRpZGF0ZSBwYXRocyB3aWxsIG5ldmVyIGJlIGFjdGl2ZSBvbiB0aGVpciBvd24uIElmIGl0 IGlzIG5lY2Vzc2FyeSwgd2UgY2FuIGFkZCBhIHN0YXRlbWVudCBpbiBTZWN0aW9uIDIuOSB0byBl eHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVjdGlvbiBjcml0ZXJp YSBkb2VzIG5vdCBhcHBseSB0byB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGhzLg0KW0tU XSBXaGVuIGEgQ1AgaXMg4oCcYWN0aXZl4oCdIGl0IGlzIGFjdHVhbGx5IHRoZSBvbmUgdGhhdCBp cyBiZWluZyB1c2VkIGZvciBmb3J3YXJkaW5nLg0KDQpUaGFua3MsDQpLZXRhbg0KDQoNClRoYW5r cywNCktldGFuDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KKiogU2VjdGlv biAyLjINCk9MRDoNCg0KICAgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNv bnRhaW5lciBmb3IgZ3JvdXBpbmcgb2YgU1INCg0KICAgUG9saWNpZXMuICBUaGUgY29tcG9zaXRl IGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGNvbWJpbmF0aW9uDQoNCiAgIG9mIFNS IFBvbGljaWVzLCBlYWNoIHdpdGggZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5h bWljDQoNCiAgIGNhbmRpZGF0ZSBwYXRocyB3aXRoIHBvdGVudGlhbGx5IGRpZmZlcmVudCBvcHRp bWl6YXRpb24gb2JqZWN0aXZlcw0KDQogICBhbmQgY29uc3RyYWludHMsIGZvciBhIGxvYWQtYmFs YW5jZWQgc3RlZXJpbmcgb2YgcGFja2V0IGZsb3dzIG92ZXINCg0KICAgaXRzIGNvbnN0aXR1ZW50 IFNSIFBvbGljaWVzLiAgVGhlIGZvbGxvd2luZyBjcml0ZXJpYSBhcHBseSBmb3INCg0KICAgaW5j bHVzaW9uIG9mIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIHVzaW5nIGEgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoDQoNCiAgIHVuZGVyIGEgcGFyZW50IFNSIFBvbGljeToNCg0KDQoNCiAgIG8gIHRo ZSBlbmRwb2ludHMgb2YgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIGFuZCB0aGUgcGFyZW50 IFNSDQoNCiAgICAgIFBvbGljeSBNVVNUIGJlIGlkZW50aWNhbA0KDQoNCg0KICAgbyAgVGhlIGNv bG9ycyBvZiBlYWNoIG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVu dA0KDQogICAgICBTUiBQb2xpY3kgTVVTVCBiZSBkaWZmZXJlbnQNCg0KDQoNCiAgIG8gIHRoZSBj b25zdGl0dWVudCBTUiBQb2xpY2llcyBNVVNUIE5PVCB1c2UgY29tcG9zaXRlIGNhbmRpZGF0ZSBw YXRocw0KDQoNCg0KICAgRWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kgb2YgYSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggaXMNCg0KICAgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2Fk LWJhbGFuY2luZyBwdXJwb3NlcyAocmVmZXINCg0KICAgU2VjdGlvbiAyLjExPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LTA5I3NlY3Rpb24tMi4xMT4gZm9yIGRldGFpbHMpLiAgVGhlIGRlZmF1bHQgd2VpZ2h0IGlzIDEu DQoNCg0KDQpORVc6DQoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBj b250YWluZXIgZm9yIGdyb3VwaW5nIG9mDQoNCiAgIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBh bmQvb3IgZHluYW1pYyBjYW5kaWRhdGUgcGF0aHMgd2l0aA0KDQogICBwb3RlbnRpYWxseSBkaWZm ZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXMgYW5kIGNvbnN0cmFpbnRzLg0KDQogICBUaGUg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGxvYWQtYmFsYW5jZWQN Cg0KICAgc3RlZXJpbmcgb2YgcGFja2V0LWZsb3dzIG92ZXIgYSBzZXQgb2YgY29uc3RpdHVlbnQg Y2FuZGlkYXRlDQoNCiAgIHBhdGhzLiBUaGUgZm9sbG93aW5nIGNyaXRlcmlhIGFwcGx5IGZvciBj b25zdGl0dWVudCBjYW5kaWRhdGUNCg0KICAgcGF0aHMgdW5kZXIgYSBjb21wb3NpdGUgY2FuZGlk YXRlIHBhdGg6DQoNCg0KDQogICBvICB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgY29uc3RpdHVlbnQg Y2FuZGlkYXRlIHBhdGggTVVTVCBiZQ0KDQogICAgICBpZ25vcmVkLg0KDQoNCg0KICAgbyAgdGhl IGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIE1VU1QgTk9UIGJlIGEgY29tcG9zaXRlIGNhbmRp ZGF0ZQ0KDQogICAgICBwYXRoDQoNCg0KDQogICBFYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBw YXRoIG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzDQoNCiAgIGFzc29jaWF0ZWQgd2l0 aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyDQoNCiAgIFNlY3Rp b24gMi4xMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTE+IGZvciBkZXRhaWxzKS4gIFRoZSBk ZWZhdWx0IHdlaWdodCBpcyAxLg0KDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rpb24gMi4xMQ0KDQoN Cg0KT0xEOg0KICAgV2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRo ZSBmcmFjdGlvbiBvZiBmbG93cw0KICAgc3RlZXJlZCBpbnRvIGVhY2ggY29uc3RpdHVlbnQgU1Ig UG9saWN5IGlzIGVxdWFsIHRvIHRoZSByZWxhdGl2ZQ0KICAgd2VpZ2h0IG9mIGVhY2ggY29uc3Rp dHVlbnQgU1IgUG9saWN5LiAgRnVydGhlciBsb2FkIGJhbGFuY2luZyBvZg0KICAgZmxvd3Mgc3Rl ZXJlZCBpbnRvIGEgY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIHBlcmZvcm1lZCBiYXNlZCBvbiB0 aGUNCiAgIHdlaWdodHMgb2YgdGhlIFNlZ21lbnQtTGlzdCBvZiB0aGUgYWN0aXZlIGNhbmRpZGF0 ZSBwYXRoIG9mIHRoYXQNCiAgIGNvbnN0aXR1ZW50IFNSIFBvbGljeS4NCg0KDQoNCk5FVzoNCiAg IFdoZW4gYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24g b2YgZmxvd3MNCiAgIHN0ZWVyZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRo IGlzIGVxdWFsIHRvIHRoZSByZWxhdGl2ZQ0KICAgd2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQg Y2FuZGlkYXRlIHBhdGguICBGdXJ0aGVyIGxvYWQgYmFsYW5jaW5nIG9mDQogICBmbG93cyBzdGVl cmVkIGludG8gYSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBpcyBwZXJmb3JtZWQgYmFzZWQg b24NCiAgIHRoZSB3ZWlnaHRzIG9mIGVhY2ggYXNzb2NpYXRlZCBTZWdtZW50LUxpc3QuDQoNCg0K KioNCg0KDQoNCioqIFNlY3Rpb24gMi4xMw0KDQoNCg0KT0xEOg0KICAgVGhlIGluZm9ybWF0aW9u IG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2aW5nIGEgY29tcG9zaXRlDQogICBjYW5kaWRh dGUgcGF0aCBpcyB0aGUgZm9sbG93aW5nOg0KDQogICBTUiBwb2xpY3kgUE9MMTAwIDxoZWFkZW5k ID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUxPg0KICAgICAgICBDYW5kaWRhdGUtcGF0 aCBDUDEgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4x LCBkaXNjcmltaW5hdG9yID0gMT4NCiAgICAgICAgICAgIFByZWZlcmVuY2UgMjAwDQogICAgICAg ICAgICBXZWlnaHQgVzEsIFNSIHBvbGljeSA8Y29sb3IgPSAxPg0KICAgICAgICAgICAgV2VpZ2h0 IFcyLCBTUiBwb2xpY3kgPGNvbG9yID0gMj4NCg0KICAgVGhlIGNvbnN0aXR1ZW50IFNSIFBvbGlj aWVzIFBPTDEgYW5kIFBPTDIgaGF2ZSBpbmZvcm1hdGlvbiBtb2RlbCBhcw0KICAgZGVzY3JpYmVk IGF0IHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uICBUaGV5IGFyZSByZWZlcmVuY2VkIG9ubHkg YnkNCiAgIGNvbG9yIGluIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggc2luY2UgdGhlaXIg aGVhZGVuZCBhbmQNCiAgIGVuZHBvaW50IGFyZSBpZGVudGljYWwgdG8gdGhlIFBPTDEwMC4gIFRo ZSB2YWxpZCBTZWdtZW50LUxpc3RzIG9mIHRoZQ0KICAgYWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9m IFBPTDEgYW5kIFBPTDIgYXJlIGluc3RhbGxlZCBpbiB0aGUNCiAgIGZvcndhcmRpbmcuICBUcmFm ZmljIHN0ZWVyZWQgb24gUE9MMTAwIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIFBPTDENCiAgIHdp dGggYSByYXRpbyBXMS8oVzErVzIpLiAgV2l0aGluIHRoZSBQT0wxLCB0aGUgZmxvdy1iYXNlZCBo YXNoaW5nDQogICBvdmVyIGl0cyBTZWdtZW50LUxpc3RzIGFyZSBwZXJmb3JtZWQgYXMgZGVzY3Jp YmVkIGVhcmxpZXIgaW4gdGhpcw0KICAgc2VjdGlvbi4NCg0KDQoNCk5FVzoNCiAgIFRoZSBpbmZv cm1hdGlvbiBtb2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZQ0KICAg Y2FuZGlkYXRlIHBhdGggaXMgdGhlIGZvbGxvd2luZzoNCg0KICAgU1IgcG9saWN5IFBPTDEwMCA8 aGVhZGVuZCA9IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9pbnQgPSBFMT4NCiAgICAgICAgQ2FuZGlk YXRlLXBhdGggQ29tcC1DUCA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPQ0KICAg MTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAxPg0KICAgICAgICAgICAgUHJlZmVyZW5jZSAy MDANCiAgICAgICAgICAgIFdlaWdodCBXMSwgQ2FuZGlkYXRlLXBhdGggQ1AxDQogICAgICAgICAg ICBXZWlnaHQgVzIsIENhbmRpZGF0ZS1wYXRoIENQMg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBD UDEgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBk aXNjcmltaW5hdG9yID0gMj4NCiAgICAgICAgICAgICBXZWlnaHQgVzExLCBTSUQtTGlzdDEgPFNJ RDExLi4uU0lEMWk+DQogICAgICAgICAgICAgV2VpZ2h0IFcxMiwgU0lELUxpc3QyIDxTSUQyMS4u LlNJRDJqPg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDIgPHByb3RvY29sLW9yaWdpbiA9IDIw LCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMz4NCiAgICAg ICAgICAgICBXZWlnaHQgVzIxLCBTSUQtTGlzdDMgPFNJRDMxLi4uU0lEM2k+DQogICAgICAgICAg ICAgV2VpZ2h0IFcyMiwgU0lELUxpc3Q0IDxTSUQ0MS4uLlNJRDRqPg0KDQogICBDb21wLUNQIGlz IGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHdpdGggdHdvIGNvbnN0aXR1ZW50cywgQ1AxDQog ICBhbmQgQ1AyLiBUaGUgcHJlZmVyZW5jZSBpcyBpZ25vcmVkIGZvciBlYWNoIG9mIHRoZSB0d28g Y29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBwYXRocy4gVGhlIHZhbGlkIFNlZ21lbnQtTGlzdHMg b2YgdGhlIHR3byBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBhdGhzIGFyZSBpbnN0YWxsZWQg aW4gdGhlIGZvcndhcmRpbmcuIFRyYWZmaWMgc3RlZXJlZA0KICAgb24gQ29tcC1DUCBpcyBmbG93 LWJhc2VkIGhhc2hlZCBvbiB0byBDUDEgYW5kIENQMiB3aXRoIGEgcmF0aW8gb2YNCiAgIFcxLyhX MStXMikgYW5kIFcyLyhXMStXMikgcmVzcGVjdGl2ZWx5LiBXaXRoaW4gZWFjaCBjb25zdGl0dWVu dA0KICAgY2FuZGlkYXRlIHBhdGgsIHRoZSBmbG93LWJhc2VkIGhhc2hpbmcgb3ZlciBpdHMgU2Vn bWVudC1MaXN0cyBhcmUNCiAgIHBlcmZvcm1lZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlz IHNlY3Rpb24uDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rpb24gNS4zDQoNCg0KDQpPTEQ6DQogICBB IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBzcGVjaWZpZWQgYXMgYSBncm91cCBvZiBpdHMg Y29uc3RpdHVlbnQNCiAgIFNSIFBvbGljaWVzLg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUg cGF0aCBpcyB2YWxpZCB3aGVuIGl0IGhhcyBhdCBsZWFzdCBvbmUgdmFsaWQNCiAgIGNvbnN0aXR1 ZW50IFNSIFBvbGljeS4NCg0KDQoNCk5FVzoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRo IGlzIHNwZWNpZmllZCBhcyBhIGdyb3VwIG9mIGl0cyBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRl IHBhdGhzLg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyB2YWxpZCB3aGVuIGl0 IGhhcyBhdCBsZWFzdCBvbmUgdmFsaWQNCiAgIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLg0K DQoNCioqDQoNCg0KDQpSZWdhcmRzLA0KDQotUGF2YW4NCg0KDQoNCk9uIFN1biwgTm92IDEsIDIw MjAgYXQgNzowMiBQTSBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnQ9NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQpIZWxsbyBBbGwsDQoNCldlIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlIGZvciB0aGUg ZHJhZnQgYW5kIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBvZiBjaGFuZ2VzOg0KDQoxKSBJbnRy b2R1Y3Rpb24gb2YgdGhlIENvbXBvc2l0ZSBDYW5kaWRhdGUgUGF0aCBjb25zdHJ1Y3QgdG8gYWRk cmVzcyBhIHBlbmRpbmcgY29tbWVudCBmcm9tIHRoZSBXRyAoUmVmIDogaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZkVxRTVUT3dkaDJ2RXlGbV9NRWppWHlQMndz LyBhbmQgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZDlvU1Ni Z3AwakNFeFJ4MFNYeUJZMEN5cVhVLykNCjIpIEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVj ZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2 NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhlIG5ldyB0eXBlIHRoYXQgd2FzIGludHJv ZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguDQozKSBDbGFyaWZpY2F0aW9uIG9mIGhhbmRsaW5nIG9m IGNvbG9ycyBhbmQgQkdQIG11bHRpLXBhdGggc2NlbmFyaW9zIGJhc2VkIG9uIG9mZmxpbmUgZmVl ZGJhY2sgcmVjZWl2ZWQuDQo0KSBDbGFyaWZpY2F0aW9uIG9uIGNvbnNpZGVyYXRpb25zIGZvciBU SS1MRkEgZm9yIFNSIFBvbGljeSBhcyBkaXNjdXNzZWQgaW4gdGhlIFdHIChSZWYgOiBodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2 Rmh3OWlkNDAvKQ0KDQpQbGVhc2UgbGV0IGtub3cgeW91ciBjb21tZW50cy9mZWVkYmFjay4NCg0K VGhhbmtzLA0KS2V0YW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiAwMiBOb3Zl bWJlciAyMDIwIDA2OjI3DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5u b3VuY2VAaWV0Zi5vcmc+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNvdXJjZSBQYWNrZXQgUm91dGluZyBpbiBO ZXR3b3JraW5nIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFNl Z21lbnQgUm91dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJlDQogICAgICAgIEF1dGhvcnMgICAgICAg ICA6IENsYXJlbmNlIEZpbHNmaWxzDQogICAgICAgICAgICAgICAgICAgICAgICAgIEtldGFuIFRh bGF1bGlrYXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuaWVsIFZveWVyDQogICAgICAg ICAgICAgICAgICAgICAgICAgIEFsZXggQm9nZGFub3YNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgUGF1bCBNYXR0ZXMNCiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAg IDogMzcNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAyMC0xMS0wMQ0KDQpBYnN0cmFjdDoN CiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBh IHBhY2tldCBmbG93DQogICBhbG9uZyBhbnkgcGF0aC4gIEludGVybWVkaWF0ZSBwZXItZmxvdyBz dGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtzDQogICB0byBzb3VyY2Ugcm91dGluZy4gIFRoZSBo ZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGljeS4NCiAgIFRoZSBoZWFk ZXIgb2YgYSBwYWNrZXQgc3RlZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVudGVkIHdpdGgg YW4NCiAgIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQ b2xpY3kuICBUaGlzDQogICBkb2N1bWVudCBkZXRhaWxzIHRoZSBjb25jZXB0cyBvZiBTUiBQb2xp Y3kgYW5kIHN0ZWVyaW5nIGludG8gYW4gU1INCiAgIFBvbGljeS4NCg0KDQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kv DQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LTA5DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkNCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4N Cg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0K c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0K --_000_MW3PR11MB45708212D3D166F34006C0C5C1E80MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1JTjt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tSU4iIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUGF2YW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmlzaG51cGF2 YW5AZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDExIE5vdmVtYmVyIDIwMjAgMDA6 MjY8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudEBj aXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V0YW4sIEhpITxicj4NCjxicj4NClBsZWFzZSBzZWUgaW5s aW5lIGZvciByZXNwb25zZXMgKHByZWZpeGVkIFZQQikuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+ DQotUGF2YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgTm92IDEwLCAyMDIwIGF0IDQ6MDQgQU0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBQYXZhbiw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpc2hudXBhdmFuQGdt YWlsLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgTm92ZW1iZXIgMjAyMCAwMDow ODxicj4NCjxiPlRvOjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtldGFudEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXRhbnRAY2lzY28uY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5LTA5LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5LZXRh biw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk11Y2ggVGhhbmtzIGZvciB0YWtpbmcgYSBzdGFiIGF0 IGFkZHJlc3NpbmcgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB1c2UtY2FzZSE8c3BhbiBj bGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwO1dlIHNlZW0gdG8gYmUgY29udmVyZ2luZy48L3NwYW4+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltLVF0gVGhhbmtzIGZvciB0 aGF0IGZlZWRiYWNrIGFuZCBjb25maXJtYXRpb24gdGhhdCB0aGUgcHJvcG9zYWwgaW4gdGhlIGRy YWZ0IGRvZXMgYWRkcmVzcyB0aGUgdXNlLWNhc2UuIEkgYmVsaWV2ZSB3ZSBhcmUgbm93IGRpc2N1 c3NpbmcgdGhlIG1lY2hhbmljcyBvZiBob3cgdGhpcyBpcyBhY2hpZXZlZA0KIHdpdGhpbiB0aGUg Y3VycmVudCBTUiBQb2xpY3kgZnJhbWV3b3JrLjwvaT48L2I+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SG93ZXZlciwgSSBkb27igJl0IHVuZGVyc3Rh bmQgd2h5IHlvdSBuZWVkIHRvIHVzZSBhZGRpdGlvbmFsIFNSIHBvbGljaWVzIChhbmQgdW5uZWNl c3NhcmlseSBidXJuIGFkZGl0aW9uYWwgY29sb3JzKSB0byBhZGRyZXNzIHRoaXMuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltLVF0gSSBkbyBu b3QgZm9sbG93IHdoYXQgeW91IG1lYW4gYnkg4oCcYnVybiBhZGRpdGlvbmFsIGNvbG9yc+KAnS4g Q29sb3IgaXMganVzdCBhIDMyIGJpdCBudW1iZXIgdGhhdCBpbmRpY2F0ZXMgdGhlIOKAnGludGVu dOKAnSBhbmQgaXMgbm90IHJlYWxseSBhIHNjYXJjZSByZXNvdXJjZS4gQXNzaWduaW5nIGENCiBj b2xvciB0byDigJxhIGNvbXBvc2l0ZSBpbnRlbnTigJ0gc2VlbXMgbGlrZSBhIHNlYW1sZXNzIHdh eSB0byBpbnRlZ3JhdGUgd2l0aCBleGlzdGluZyBtZWNoYW5pc21zIGZvciBTdGVlcmluZyBvdmVy IFNSIFBvbGljaWVzLiBUaGlzIGdpdmVzIHRoZSBmbGV4aWJpbGl0eSBmb3Igc2F5IHNvbWUgQkdQ IHNlcnZpY2VzIHRvIGJlIHN0ZWVyZWQgb3ZlciB0aGUgY29uc3RpdHVlbnQgZXhwbGljaXQvZHlu YW1pYyBpbnRlbnQgd2hpbGUgb3RoZXJzIGNhbiBzdGVlcg0KIG92ZXIgYSBjb21wb3NpdGUgaW50 ZW50IHRoYXQgaW5jbHVkZXMgdGhvc2UgaW5kaXZpZHVhbCBleHBsaWNpdC9keW5hbWljIGludGVu dHMuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltWUEJdIFRoZSDigJxmbGV4 aWJpbGl0eeKAnSB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIGlzIHVuZGVzaXJhYmxlIGZvciB0 aGlzIHVzZS1jYXNlLiBGb3IgdGhlIHRyYWZmaWMtc3BsaXQgdXNlLWNhc2UsIHdlIGRvbuKAmXQg d2FudCBhbnkgb3RoZXIgc2VydmljZXMgdG8gYmUgZGlyZWN0bHkgc3RlZXJlZCBvdmVyIHRoZSBj b25zdGl0dWVudHMgd2hlbiB0aGV5IGFyZSBwYXJ0IG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZQ0K IHBhdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzQ0NzJDNCI+W0tUXSBJIGJlbGlldmUgdGhlIHVzZS1jYXNlIHRoYXQgeW91 IGFyZSByZWZlcnJpbmcgdG8gd2FzIGZvciBzcGxpdHRpbmcgc29tZSB0cmFmZmljIGZvciBhIHNl cnZpY2Ugb3ZlciBhIGJsdWUgcGxhbmUgYW5kIHRoZSByZXN0IG92ZXIgYSByZWQgcGxhbmUuIEF0 IHRoZSBzYW1lIHRpbWUsIHRoZXJlIG1heSBiZSBvdGhlciBzZXJ2aWNlcyB0aGF0IHV0aWxpemUN CiBvbmx5IGEgc2luZ2xlIHBsYW5lLiBUaGUgZmxleGliaWxpdHkgdGhhdCBJIHdhcyByZWZlcnJp bmcgdG8gd2FzIHRvIGVuYWJsZS9hbGxvdyBmb3IgZWl0aGVyIG9mIHRoZSB0d28gc2NlbmFyaW9z IGFuZCB0aGVyZSBtYXkgYmUgb3RoZXIvbW9yZSB1c2UtY2FzZXMgZm9yIHdoaWNoIHdlIG5lZWQg YSBtb3JlIGdlbmVyaWMgZnJhbWV3b3JrLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjojNDQ3MkM0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHBy b3Bvc2FsIGluIHRoZSBkcmFmdCB3b3VsZCBoYXZlIGJlZW4gYWNjZXB0YWJsZSBpZiB0aGUgY29u c3RpdHVlbnQgU1IgUG9saWNpZXMgd2VyZSB1bmNvbG9yZWQg4oCTIGJ1dCB0aGF0IHdvdWxkIHZp b2xhdGUgdGhlIGN1cnJlbnQgcnVsZXMgaW1wb3NlZCBieSB0aGUgZHJhZnQuJm5ic3A7DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+V2h5IGNhbuKAmXQgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBqdXN0 IGJlIGEgZ3JvdXBpbmcgb2YgZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWlj IGNhbmRpZGF0ZSBwYXRocz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPltLVF0gVGhpcyBpcyBiZWNhdXNlIGluIHRoZSBTUiBQb2xpY3kgZnJhbWV3 b3JrLCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIGFjdGl2ZSBDUCDigJMgaXQgbWF5IGJlIGV4cGxp Y2l0IG9yIGR5bmFtaWMuIE5vdyB3ZeKAmXZlIGFkZGVkIGFub3RoZXIgQ29tcG9zaXRlIENQIHR5 cGUgdG8gY292ZXIgdGhpcw0KIHNwZWNpZmljIHVzZS1jYXNlLiBZb3VyIHByb3Bvc2FsIHdpbGwg cmVzdWx0IGluIDMgY2FuZGlkYXRlIHBhdGhzIGJlaW5nIGFjdGl2ZSB3aXRoaW4gdGhlIHNhbWUg U1IgUG9saWN5IOKAkyBvbmUgZWFjaCBvZiB0aGUgZXhwbGljaXQgYW5kIGR5bmFtaWMgQ1AgYW5k IHRoZW4gYWRkaXRpb25hbGx5IHRoZSBDb21wb3NpdGUgQ1AuIFRoaXMgYnJlYWtzIHRoZSBleGlz dGluZyBydWxlcyBmb3Igc2VsZWN0aW9uIG9mIENQIGJhc2VkIG9uIHByZWZlcmVuY2UNCiBhbmQg bWVjaGFuaXNtcyBsaWtlIGZhbGxiYWNrIGJldHdlZW4gQ1BzLiBXaGlsZSB0aGUgY3VycmVudCBw cm9wb3NhbCBpbiB0aGUgZHJhZnQgcHJvdmlkZXMgYSB3YXkgdG8gYWRkcmVzcyB0aGUgbmV3IHVz ZS1jYXNlIHdpdGggYSBiYWNrd2FyZHMgY29tcGF0aWJsZSBleHRlbnNpb24gdG8gdGhlIFNSIFBv bGljeSBmcmFtZXdvcmsuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltWUEJd IFRoZSBwcm9wb3NhbCBpbiBteSBwcmV2aW91cyBlbWFpbCBpcyBiYWNrd2FyZHMgY29tcGF0aWJs ZSBhbmQgZG9lcyBub3QgaW50ZW5kIHRvIGJyZWFrIGFueSBleGlzdGluZyBydWxlcyBmb3IgZGVl bWluZyBhIGNhbmRpZGF0ZSBwYXRoIGFjdGl2ZS4gQXMgcGVyIHRoZSBydWxlcyB0aGF0IGFyZSBv dXRsaW5lZCBpbiBTZWN0aW9uIDIuOSwgb25seSB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRo IGlzDQog4oCcYWN0aXZl4oCdIGdpdmVuIGl0cyBwcmVmZXJlbmNlLiBUaGUgY29uc3RpdHVlbnQg Y2FuZGlkYXRlIHBhdGhzIHdpbGwgbmV2ZXIgYmUgYWN0aXZlIG9uIHRoZWlyIG93bi4gSWYgaXQg aXMgbmVjZXNzYXJ5LCB3ZSBjYW4gYWRkIGEgc3RhdGVtZW50IGluIFNlY3Rpb24gMi45IHRvIGV4 cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUgY2FuZGlkYXRlIHBhdGggc2VsZWN0aW9uIGNyaXRlcmlh IGRvZXMgbm90IGFwcGx5IHRvIHRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUNCiBwYXRocy4mbmJz cDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzQ0NzJDNCI+W0tUXSBXaGVuIGEgQ1AgaXMg4oCcYWN0aXZl4oCdIGl0IGlzIGFj dHVhbGx5IHRoZSBvbmUgdGhhdCBpcyBiZWluZyB1c2VkIGZvciBmb3J3YXJkaW5nLjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiM0NDcyQzQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5LZXRhbjwvc3Bhbj48L2k+PC9i PjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PGk+VGhhbmtzLDwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxpPktldGFuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Db25zaWRlciB0aGUg Zm9sbG93aW5nIGNoYW5nZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDIuMjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3Jv dXBpbmcgb2YgU1I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFBvbGljaWVzLiZuYnNwOyBUaGUgY29t cG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGNvbWJpbmF0aW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBvZiBTUiBQb2xpY2llcywgZWFjaCB3aXRoIGV4cGxpY2l0IGNhbmRp ZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2FuZGlkYXRl IHBhdGhzIHdpdGggcG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVz PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgY29uc3RyYWludHMsIGZvciBhIGxvYWQtYmFsYW5j ZWQgc3RlZXJpbmcgb2YgcGFja2V0IGZsb3dzIG92ZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGl0 cyBjb25zdGl0dWVudCBTUiBQb2xpY2llcy4mbmJzcDsgVGhlIGZvbGxvd2luZyBjcml0ZXJpYSBh cHBseSBmb3I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluY2x1c2lvbiBvZiBjb25zdGl0dWVudCBT UiBQb2xpY2llcyB1c2luZyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgdW5kZXIgYSBwYXJlbnQgU1IgUG9saWN5Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGVuZHBvaW50cyBvZiB0aGUgY29uc3RpdHVlbnQg U1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQgU1I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFBvbGljeSBNVVNUIGJlIGlkZW50aWNhbDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGNvbG9ycyBvZiBlYWNoIG9mIHRoZSBjb25z dGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU1IgUG9saWN5IE1VU1QgYmUgZGlmZmVyZW50PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgY29uc3RpdHVlbnQgU1IgUG9s aWNpZXMgTVVTVCBOT1QgdXNlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aHM8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBFYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBvZiBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXNzb2Np YXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3NlcyAocmVmZXI8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rpb24tMi4xMSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5TZWN0aW9uIDIuMTE8 L3NwYW4+PC9hPiBmb3IgZGV0YWlscykuJm5ic3A7IFRoZSBkZWZhdWx0IHdlaWdodCBpcyAxLjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBj b21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3JvdXBpbmcg b2Y8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3Ig ZHluYW1pYyBjYW5kaWRhdGUgcGF0aHMgd2l0aCA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 cG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVzIGFuZCBjb25zdHJh aW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg Y29uc3RydWN0IGVuYWJsZXMgbG9hZC1iYWxhbmNlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3Rl ZXJpbmcgb2YgcGFja2V0LWZsb3dzIG92ZXIgYSBzZXQgb2YgY29uc3RpdHVlbnQgY2FuZGlkYXRl PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXRocy4gVGhlIGZvbGxvd2luZyBjcml0ZXJpYSBhcHBs eSBmb3IgY29uc3RpdHVlbnQgY2FuZGlkYXRlIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3BhdGhzIHVuZGVy IGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg byZuYnNwOyB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGgg TVVTVCBiZSA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpZ25vcmVkLiA8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGNvbnN0aXR1ZW50IGNhbmRpZGF0 ZSBwYXRoIE1VU1QgTk9UIGJlIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSA8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGF0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IEVhY2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggb2YgYSBjb21w b3NpdGUgY2FuZGlkYXRlIHBhdGggaXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFzc29jaWF0ZWQg d2l0aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTEiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAyLjExPC9zcGFu PjwvYT4gZm9yIGRldGFpbHMpLiZuYnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKiBT ZWN0aW9uIDIuMTE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XaGVuIGEgY29tcG9z aXRlIGNhbmRpZGF0ZSBwYXRoIGlzIGFjdGl2ZSwgdGhlIGZyYWN0aW9uIG9mIGZsb3dzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnN0ZWVyZWQgaW50 byBlYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEz OTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0IG9m IGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5LiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PkZ1cnRoZXINCiBsb2FkIGJhbGFuY2luZyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mbG93cyBzdGVlcmVkIGludG8gYSBjb25zdGl0dWVudCBT UiBQb2xpY3kgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53ZWlnaHRzIG9mIHRoZSBTZWdtZW50LUxpc3Qg b2YgdGhlIGFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zdGVlcmVkIGludG8gZWFjaCBjb25zdGl0dWVu dCBjYW5kaWRhdGUgcGF0aCBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0IG9mIGVhY2ggY29uc3Rp dHVlbnQgY2FuZGlkYXRlIHBhdGguJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzEx MDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnVydGhl cg0KIGxvYWQgYmFsYW5jaW5nIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPmZsb3dzIHN0ZWVyZWQgaW50byBhIGNvbnN0aXR1ZW50IGNhbmRpZGF0 ZSBwYXRoIGlzIHBlcmZvcm1lZCBiYXNlZCBvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aGUgd2VpZ2h0cyBvZiBlYWNoIGFzc29jaWF0ZWQgU2Vn bWVudC1MaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDIuMTM8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPk9MRDo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5UaGUgaW5mb3JtYXRpb24gbW9kZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZp bmcgYSBjb21wb3NpdGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+Y2FuZGlkYXRlIHBhdGggaXMgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlNSIHBvbGljeSBQT0wxMDAgJmx0O2hlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50 ID0gRTEmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENQMSAmbHQ7 cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9 IDEmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBy ZWZlcmVuY2UgMjAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPldlaWdodCBXMSwgU1IgcG9saWN5ICZsdDtjb2xvciA9IDEmZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMiwgU1IgcG9saWN5ICZs dDtjb2xvciA9IDImZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgY29uc3RpdHVlbnQgU1IgUG9saWNp ZXMgUE9MMSBhbmQgUE9MMiBoYXZlIGluZm9ybWF0aW9uIG1vZGVsIGFzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlc2NyaWJlZCBhdCB0aGUgc3Rh cnQgb2YgdGhpcyBzZWN0aW9uLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAx Mzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZXkNCiBh cmUgcmVmZXJlbmNlZCBvbmx5IGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPmNvbG9yIGluIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggc2lu Y2UgdGhlaXIgaGVhZGVuZCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+ZW5kcG9pbnQgYXJlIGlkZW50aWNhbCB0byB0aGUgUE9MMTAwLiZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZQ0KIHZhbGlkIFNlZ21lbnQtTGlzdHMgb2YgdGhl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFjdGl2 ZSBjYW5kaWRhdGUgcGF0aCBvZiBQT0wxIGFuZCBQT0wyIGFyZSBpbnN0YWxsZWQgaW4gdGhlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAx Mzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZvcndhcmRp bmcuJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHJhZmZpYyBzdGVlcmVkIG9uIFBPTDEw MA0KIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIFBPTDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2l0aCBhIHJhdGlvIFcxLyhXMStXMikuJm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2l0aGluIHRoZQ0KIFBPTDEsIHRoZSBmbG93LWJhc2Vk IGhhc2hpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00 NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+b3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUgcGVyZm9ybWVkIGFzIGRlc2NyaWJlZCBlYXJs aWVyIGluIHRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWls LW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+c2VjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUy NjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIGluZm9ybWF0 aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2aW5nIGEgY29tcG9zaXRlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBwYXRo IGlzIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TUiBwb2xpY3kgUE9MMTAwICZsdDto ZWFkZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUxJmd0Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENvbXAtQ1AgJmx0O3Byb3RvY29sLW9yaWdpbg0KID0gMjAs IG9yaWdpbmF0b3IgPTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21h aWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4xMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDEmZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlByZWZlcmVuY2UgMjAwPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcxLCBDYW5kaWRhdGUt cGF0aA0KIENQMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0 MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5XZWlnaHQgVzIsIENhbmRpZGF0ZS1wYXRoIENQMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3 MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5k aWRhdGUtcGF0aCBDUDEgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMiZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzExLCBT SUQtTGlzdDENCiAmbHQ7U0lEMTEuLi5TSUQxaSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcxMiwgU0lELUxpc3QyICZsdDtT SUQyMS4uLlNJRDJqJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDYW5kaWRhdGUtcGF0aCBDUDIgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIw LCBvcmlnaW5hdG9yID08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5h dG9yID0gMyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt bTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5XZWlnaHQgVzIxLCBTSUQtTGlzdDMNCiAmbHQ7U0lEMzEuLi5TSUQzaSZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEz OTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcy MiwgU0lELUxpc3Q0ICZsdDtTSUQ0MS4uLlNJRDRqJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ29tcC1DUCBpcyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUg cGF0aCB3aXRoIHR3byBjb25zdGl0dWVudHMsIENQMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQgQ1AyLiBUaGUgcHJlZmVyZW5jZSBpcyBpZ25v cmVkIGZvciBlYWNoIG9mIHRoZSB0d28gY29uc3RpdHVlbnQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgY2FuZGlkYXRlIHBhdGhzLiBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUgdHdvPHNw YW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29uc3RpdHVlbnQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBjYW5kaWRhdGUgcGF0aHMgYXJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZy4mbmJzcDtU cmFmZmljIHN0ZWVyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDtvbg0KPC9zcGFuPkNvbXAtQ1AgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gdG8gQ1AxIGFuZCBD UDIgd2l0aCBhIHJhdGlvIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXMS8oVzErVzIp IGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGluIGVhY2ggY29uc3RpdHVlbnQNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aCwgdGhlPHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+Zmxvdy1iYXNlZA0KIGhhc2hpbmcgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHBlcmZvcm1lZCBhczxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmRlc2NyaWJlZCBlYXJsaWVyDQogaW4gdGhpcyBzZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Kio8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqIFNlY3Rpb24g NS4zPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRl IHBhdGggaXMgc3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIFBvbGljaWVzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgdmFsaWQgd2hlbiBp dCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFz IGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBwYXRocy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkEg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4gaXQgaGFzIGF0IGxlYXN0IG9u ZSB2YWxpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0 MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5jb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJl IHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LVBhdmFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBTdW4sIE5vdiAxLCAyMDIwIGF0IDc6MDIgUE0gS2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSAmbHQ7a2V0YW50PTxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50 Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KV2UgaGF2ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGUg Zm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRoZSBzdW1tYXJ5IG9mIGNoYW5nZXM6PGJy Pg0KPGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlkYXRlIFBhdGgg Y29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6 DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9m RXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlY eVAyd3MvPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdw MGpDRXhSeDBTWHlCWTBDeXFYVS88L2E+KTxicj4NCjIpIEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJh Y2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9u YWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhlIG5ldyB0eXBlIHRoYXQgd2Fz IGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguPGJyPg0KMykgQ2xhcmlmaWNhdGlvbiBvZiBo YW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBv ZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLjxicj4NCjQpIENsYXJpZmljYXRpb24gb24gY29uc2lk ZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5IGFzIGRpc2N1c3NlZCBpbiB0aGUgV0cg KFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nw cmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSERO MEl2Rmh3OWlkNDAvPC9hPik8YnI+DQo8YnI+DQpQbGVhc2UgbGV0IGtub3cgeW91ciBjb21tZW50 cy9mZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW4gKG9uIGJlaGFsZiBvZiBj by1hdXRob3JzKTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBP Zg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiAwMiBOb3ZlbWJlciAy MDIwIDA2OjI3PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PGJyPg0KU3ViamVjdDogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU291 cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IFNlZ21lbnQgUm91dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJl PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyZW5jZSBGaWxzZmlsczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBLZXRhbiBUYWxhdWxpa2FyPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERhbmllbCBWb3llcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBbGV4IEJvZ2Rhbm92PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFBhdWwgTWF0dGVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZp bGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMzc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0xMS0wMTxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUg dG8gc3RlZXIgYSBwYWNrZXQgZmxvdzxicj4NCiZuYnNwOyAmbmJzcDthbG9uZyBhbnkgcGF0aC4m bmJzcDsgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3M8 YnI+DQombmJzcDsgJm5ic3A7dG8gc291cmNlIHJvdXRpbmcuJm5ic3A7IFRoZSBoZWFkZW5kIG5v ZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGljeS48YnI+DQombmJzcDsgJm5ic3A7VGhl IGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFuIFNSIFBvbGljeSBpcyBhdWdtZW50ZWQg d2l0aCBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2Np YXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO2Rv Y3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNSIFBvbGljeSBhbmQgc3RlZXJpbmcgaW50 byBhbiBTUjxicj4NCiZuYnNwOyAmbmJzcDtQb2xpY3kuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5Lzwv YT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS0wOTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJyPg0KQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4uPGJyPg0K PGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0 YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJy Pg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW3PR11MB45708212D3D166F34006C0C5C1E80MW3PR11MB4570namp_-- From nobody Wed Nov 11 04:15:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103A3A0876; Wed, 11 Nov 2020 04:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pWyU45CS5_QT; Wed, 11 Nov 2020 04:15:53 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 CF2423A0869; Wed, 11 Nov 2020 04:15:52 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id s10so2082177ioe.1; Wed, 11 Nov 2020 04:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lFQU8sPins1EWx3Bgx5Yktj+10tMMbMSYDf/Are5PRc=; b=XjNhcNyYsfoc74htOUtK0Q2bybzuNCTEow/Q1qdXtkrzIJEBTscm8hzVV5UbvL3Ja2 oMBKjrAugBphSYP/OeHIJaA80TGmGgmn0gG6RcmfFDwu06pwDBdyXVZ4N5h/zbX+iT1Y PLKChv9Ncxpnz3VWgawFEArA/FFliMFKkxsV1ZFNneqDVf+sxOg44ZKB1ikRCJAngmO2 MipWRl92l21Gwv3uWRzufsWbd9OI/dtu8h5zrjIJcgzLOWmJ/+7ya2+RLH2u7+8rKfs/ hRfeatPqt7ihjk8RMcfTG72S/TcCg4snxhIivcQpnfMu3OaqDhZqNDA0rsGbqglwrjrL +WLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lFQU8sPins1EWx3Bgx5Yktj+10tMMbMSYDf/Are5PRc=; b=mVZSTCKKQDV57jUzymqS3TSrR/WBioup/1rddXhtVfV2vcqoTqeVp6oCchgXBaSl2G rDBZA4ggy6VJ3I5qVIrMOiIkqtZbJe2rO0PoVUs94kb5XdxgdOsHfnQKDtGhonPHXsi/ EEbqBvBpNuLiDilJYiD00u6iK+AlhMF17DO9IgumT7Zh65kwSsJFODM4i1X9iC8NFzaU S6R0cHtOQvksnq2reszKxoeKl5vgTWpDzMG0oT48JfNxIGDHDHZSZyDRhSbm3Fl3um2w +63RRcjlxxQ7j+GLEhHHA7csDCMukpobuDZ+Xrle/v0buTc1eEz/K3PfIrVEyPnh8SM0 FFvA== X-Gm-Message-State: AOAM5314+/TcwkOkk7GAAUw2S6dW5HgMTnnqCZe16r8DZ2XuB+KXJvNt G3Og5A9CQ8NAbUHf/+FS8WB0rxtY1yWvzb1pL1Q= X-Google-Smtp-Source: ABdhPJx9ENE/crHqgwrSe/YpJTd7a04Ct64ZqyLe0FqOc6PF5F7OhxBU3MS8v97VF+RYAqcqT7nYMRwv3DjKLYNEJ3Q= X-Received: by 2002:a05:6638:626:: with SMTP id h6mr19103720jar.15.1605096951624; Wed, 11 Nov 2020 04:15:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Wed, 11 Nov 2020 17:45:15 +0530 Message-ID: To: James Guichard Cc: "spring@ietf.org" , "spring-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 12:15:55 -0000 Hi Chairs, I support adoption of this draft. It describes a useful feature for SRv6 path identification. I am a co-author of this draft. Thanks! Dhruv On Tue, Nov 3, 2020 at 11:09 PM James Guichard wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for https://tools.ietf.org/= html/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Pleas= e note that this document has several changes from v-06 that were requested= by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption. > > > > After review of the document please indicate support (or not) for WG adop= tion to the mailing list. Please also provide comments/reasons for that sup= port (or lack thereof) as silence will not be considered as consent. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Nov 11 15:15:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222B93A11E2 for ; Wed, 11 Nov 2020 15:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 PsLXJNHqu1cv for ; Wed, 11 Nov 2020 15:15:53 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2110.outbound.protection.outlook.com [40.107.223.110]) (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 D6F013A11E5 for ; Wed, 11 Nov 2020 15:15:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XpmSb2OZxz9ixi5ATtItmnmThjYohCm8UKD101wpRBY75pyjSiyrwG3lfj3CBeI/67TLsIza4UiR3hE0+akXW272FMSh61wUYj4ylBGs6ptqWYN8w0ttThQgpwC5fHSFIGgJrGmoimWv92BOdlCpInMWUu3L+NB4F7JDe9h1PsWeAL3kLS5jpWOHg8ESgzY51Luft2wVIBgpIAtHW8kdPAdJt/U7F4O7fau0Lcxjk7OlYDG3MZC/ZGtR/ALbrliWqzbII+r/lGEaNJivnnoInY+JJGFkybel3jmzAUNDH0i3mAltleUEO3QGsma6bg7/p9bhIGzwsKQHF6DDYsMggg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f4mH0DH/YB6TNSb+x5suNTycB2FeyR0iklGHhcPrVj8=; b=g/Abs//RqchgnoKJTxPt7M7t0g+AgK+GW7yvM0XkKfzOsUPtgKGlfG08Y35M6/awBFBgwpIRrAIqDNFDzIid7MMd1POzDp9QlZGupMTRz2jH7EL3ylGVXLrCKNsgUN32/aQeN9+9TrrtRwnmIm9CB34utXbhWLv3CGAyfYraW5Qp/r6HD0RR3YGzZKWrIIWQ6O193Nmeu6rLMtZjTWvpTjwiXvlx30ENLyxfi/zJPHtl3T9Nni0osrHdufe0R8sF5W1JBKIyOBQrzI1CX6s5RZCZYCbge+4V0Hh/BgSxgpPRK5a5Fw2e9QUWBVp2WFtUQ17DbLWRFkXPJJIfVkungg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f4mH0DH/YB6TNSb+x5suNTycB2FeyR0iklGHhcPrVj8=; b=puc9vHJc9np/EveYAkdg4A6pVVulG6PBsgHEXZvryzzTK2+Fmb/yGa5MQFR5tiOQI/4iw6oHTSeYI7RiadKu/WfOx4XCftYE02GqUoy8qqJMDVCG07G6uGR+oS5EKDV7PcnSxEnvoieaOM6TzNGyfnn6q3OI50Kyl5fA5pIxaBQ= Received: from DM6PR08MB4393.namprd08.prod.outlook.com (2603:10b6:5:a2::21) by DM6PR08MB4763.namprd08.prod.outlook.com (2603:10b6:5:43::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 23:15:48 +0000 Received: from DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424]) by DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 23:15:48 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: "Ketan Talaulikar (ketant)" , Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLM70syLdU1bpku3yUTxttqV3Km0BkEAgAwnQoCAAQLIAIAAlKsAgACQY4CAAPaaAA== Date: Wed, 11 Nov 2020 23:15:47 +0000 Message-ID: <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a046dfca-1bbc-4ab7-84dc-08d88697b988 x-ms-traffictypediagnostic: DM6PR08MB4763: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GrcsxDGPhfipzItkqAfsFeeIWX/UvkgSXahbXzDx/wbCqyJiA74mVOXIkQq/D/gEUL7cdT6Zk2gx8UFWEKTUVXxDHmPAMNJeBL4Dp/v/gMe39czR2e0Cz/2V2LMnhaSVhWExDr3Yf5SUQrXCeDXjmUM4KQ6Luy2Ab9OlBRN/4QwxRS8YU9VALUoM2ODiRkz1s4KWlndfTGf8IwlE4exwWeOWyzOv68cG+KoLibxrW16x/gPSK+/3VXmjsCTMathx3qc3k8X5UOm+2F8H82AhFmS+POfY9eMX6jUGKNnFoA6211L7AZYQxsNBgCOi2FDTgNwmdPbBbWjSR45id/NKBVn3P5fl/ddQmgb3bAtFTbELSzykqdZt+Mq50bA0EsyeUHIDFCrVhtnQFEdVqZtHEg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4393.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(8936002)(4326008)(966005)(2906002)(110136005)(166002)(66574015)(26005)(8676002)(36756003)(316002)(53546011)(86362001)(83380400001)(6486002)(186003)(66446008)(2616005)(6506007)(33656002)(91956017)(66556008)(76116006)(478600001)(66946007)(5660300002)(16350225007)(71200400001)(64756008)(30864003)(6512007)(66476007)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CvUeldsPquMTh8N17UZNsG4qk7EoL2ZSUIZSnq+6RbXDfWklLB1GbhP3goGI/Yw/0jA31AtssSb9bgUFHEagyl8vgGHrvIFlHn8P3xGWeUNRlRmVXUaHGP0ShtO9oAxKR9bcg5k0pSn3SRGBbCvzORLj+N3Tp1AkH/eSp8ADPDk3XF14ECmMEwxt6FWUtcP5B3HIcOw9eoq2IWcwDkm+t+qqMYWpIxufZnSpu4XiO3a+7deNxWAhlXYvjQ8Kx2sXeZibx3wEuOSy04PA0C1CHz80MkqVlppOZnFxJ0BcZ08yDUnJBzXpWUvnYHR9/e086Q1TN+fLayyLykTyI6gpnTSMEBM3yrCFOQd/XPMB9kgv9mGugMWt5CXjS6Lxh9ZMb3qQdOtR9gRKQA7dkjoIm4M2cz1IFniL2Ujvh6m3zhI+Ku23kdEoIiKiezPKHitSvPImlCwilLNTFQPZLWnBlP+IEAtnL1OGtW1eZUslWuz/VuzBgClaCfbEKYrUiu5cjKjLER0kfSDZAKQTKeFYV+1fE+Eldq+EU8xHRrAuUIqZ4jsktT7mms76IhL44G4gty4Fj2xwQt0NEAKtU2z89Bu/f8zc9opECOk2VhhHOv6JenCythIQLVppAaXbAZDt9BIzugWCrI8vyWxh95xePQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3E1EC6677B1745AC9CDEF121FB75F14Bnokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB4393.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a046dfca-1bbc-4ab7-84dc-08d88697b988 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 23:15:48.2891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gUcNQvVMoAgkFOuCbN3w0aSVpcoUXKLmrXhISEKIChYyOIrDH1ONEojBnhxu2JuvGEPlZ5sI2DgV5quZ1WSGsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4763 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 23:15:57 -0000 --_000_3E1EC6677B1745AC9CDEF121FB75F14Bnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4sIFBhdmFuLA0KDQpHb29kIGRpc2N1c3Npb24uIEp1c3QgZ29pbmcgdG8gY2hpcCBp biBzb21lIHRob3VnaHRz4oCmDQoNCk9uZSBvZiB0aGUgZWxlbWVudHMgSSBwZXJzb25hbGx5IGxp a2Ugb2YgdGhlIFNSIFBvbGljeSBtb2RlbCBpcyB0aGF0IG1hbnkgQ2FuZGlkYXRlIFBhdGhzIG1h eSBleGlzdCwgYnV0IG9ubHkgb25lIG1heSBiZSBhY3RpdmUgYW5kIGEgY2FuZGlkYXRlIHBhdGgg Y29udGFpbnMgMSBvciBtYW55IFNJRCBsaXN0cy4gSXTigJlzIGEgc2ltcGxlIHBhcmVudC9jaGls ZCAtIHJvb3QvbGVhZiB0cmVlIHdpdGggdmVyeSBjbGVhciBydWxlcyB3aXRoaW4gdGhlIFNSIHBv bGljeSBjb250ZXh0IGluc3RhbmNlLiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHdoYXQgaXMgYmVp bmcgcHJvcG9zZWQgaW4gdGhlIC0wOSBkb2N1bWVudCBzdGlsbCBmb2xsb3dzIHRob3NlIHJ1bGVz IGFuZCB0aGUgZ2VuZXJhbCB0b3AtZG93biB0cmVlIGJlaGF2aW91ci4gRGVzcGl0ZSB0aGUgY29t cG9zaXRlIENQIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IFNSIFBvbGljeSwgdGhhdCBTUiBQb2xp Y3kgc3RpbGwgZm9sbG93cyBhbGwgb2YgdGhlIHNhbWUgcnVsZXMgdG9wIGRvd24gaW4gaXRzIG93 biBpc29sYXRlZCBjb250ZXh0LiBDb21wYXJlIHRoYXQgdG8gc2F5LCBoYXZpbmcgYSBjYW5kaWRh dGUgcGF0aCBjb250YWluIGEgY2hpbGQgdGhhdCBwb2ludHMgdG8gb3RoZXIgY2FuZGlkYXRlIHBh dGhzIHdpdGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kgY29udGV4dDogd2l0aGluIHRoZSBzYW1lIGNv bnRleHQgYSBjaGlsZCBpcyBwb2ludGluZyB0byBhIHNpYmxpbmcgb2YgaXRzIHBhcmVudC4gVGhl IHJ1bGVzIG5vdyBoYXZlIHRvIGJlbmQgc2xpZ2h0bHkuIEFzIG5vdGVkIGJlbG93LCBzb21lIG9m IHRoZSBydWxlcyBhcm91bmQgd2hhdCBpcyBjb25zaWRlcmVkIGFuIGFjdGl2ZSBjYW5kaWRhdGUg cGF0aCB3b3VsZCBuZWVkIHRvIGNoYW5nZSwgc2luY2UgdGhlIGNvbnN0aXR1ZW50cyBlc3NlbnRp YWxseSBhcmUgYWN0aXZlICh0aGV54oCZcmUgaW5zdGFsbGVkKSBkZXNwaXRlIG5vdCBiZWluZyB0 aG91Z2h0IG9mIGFzIGJlaW5nIGFjdGl2ZS4gTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBuZXcgdGV4 dCBiZWxvdyBzYXlzIOKAnFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhl IHR3byBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMiIHdoaWNoIGlzIGFsc28gYSBuZXcgcnVs ZSwgaG93ZXZlciBvbmUgY291bGQgcGVyaGFwcyB3b3JrIGFyb3VuZCB0aGF0IGJ5IGp1c3QgcmVx dWlyaW5nIHRoZSBwcmVmZXJlbmNlIG9uIHRoZSBjb25zdGl0dWVudHMgYmUgbGVzcyBwcmVmZXJy ZWQgdGhhbiBhbnkgb3RoZXIgc3RhbmRhcmQgb3IgY29tcG9zaXRlIENQIOKAkyBidXQgdGhhdCBy YWlzZXMgaXRzIG93biB0cm91YmxlcyB3aXRoIG11bHRpcGxlIHNvdXJjZXMgb2YgcHJvdmlzaW9u aW5nIOKAkyB3aGljaCBsZWFkcyB0byBhIHJ1bGUgYXNraW5nIHRvIGlnbm9yZSB0aGUgcHJlZmVy ZW5jZS4gSW4gc3VtbWFyeSwgZnJvbSBteSBwLm8udiBuZXcgcnVsZXMgaW4gdGhlIGhpZXJhcmNo eSB3b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQuDQoNClJlZ2FyZGluZyBzdGVlcmluZyBpbnRv IGFuIFNSIFBvbGljeSwgeWVzLCB5b3UgYnVybiBjb2xvcnMgaW4gZG9pbmcgdGhpcyAoMzJiaXRz Li4uKSBhbmQgaXQgd291bGQgcmVxdWlyZSBkZXBsb3lpbmcgYW4gZW50aXJlbHkgZGVkaWNhdGVk IFNSIFBvbGljeSBjb25zdHJ1Y3QsIGFuZCBydW4gdGhlIHJpc2sgb2Ygc3RlZXJpbmcg4oCYb3Ro ZXLigJkgdHJhZmZpYyBpbnRvIHRoYXQgcG9saWN5LiBJZiB0aGlzIGlzIGEgY29uY2Vybiwgd291 bGQgdGhlIGNvbXBvc2l0ZSBTUiBQb2xpY2llcyBub3QgYmUgZW5naW5lZXJlZCBpbiBhIHdheSB3 aGVyZSB0aGUgY29sb3IgYmxvY2sgdXNlZCBpcyBkZXNpZ25lZCB0byBub3QgYmUgdXNlZCBlbHNl d2hlcmUgaW4gdGhlIG5ldHdvcmsgZm9yIG90aGVyIHB1cnBvc2VzPyBJcyB0aGVyZSBub3QgYSBk aWZmZXJlbnQgYnV0IGtpbmQgb2Ygc2ltaWxhciBwcm9ibGVtIHdpdGggQmluZGluZyBTSURzLCBp biB0aGF0IHRoZXnigJlyZSBlbGlnaWJsZSBmb3IgdXNlIGJ5IG90aGVyIGNvbnN1bWVycyBldmVu IGlmIG5vdCBkaXJlY3RseSBpbnRlbmRlZD8gKGFsdGhvdWdoIGF0IGxlYXN0IEJTSURzIGFyZSBv cHRpb25hbCBhbmQgbm90IG1hbmRhdG9yeSkuIEluIGFkZGl0aW9uIHRvIHRoZSBzcGxpdCBURSBj YXNlcywgYmVpbmcgYWJsZSB0byBoYXZlIGFuIFNSIFBvbGljeSBzdGVlciBpbnRvIGFub3RoZXIg U1IgUG9saWN5IG1pZ2h0IGFsc28gaGF2ZSBzb21lIHZhbHVlIGluIGEgYmFja3VwIGNhbmRpZGF0 ZSBzY2VuYXJpbyB3aGVuIG9uZSBoYXMgbXVsdGlwbGUgU1IgUG9saWNpZXMgd2l0aCB0aGUgc2Ft ZSBlbmRwb2ludCwgYnV0IGNhbiBzaGFyZSBhIGNvbW1vbiBmYWxsYmFjay9iZXN0IGVmZm9ydCBj YW5kaWRhdGUgcGF0aC4gVGhlIGVudGl0eSAoSSdtIHRoaW5raW5nIFBDRSkgbWFuYWdpbmcgdGhh dCB3b3VsZCBvbmx5IG5lZWQgdG8gbWFpbnRhaW4gdGhlIGZhbGxiYWNrL2Jlc3QgZWZmb3J0IENQ IFNJRCBsaXN0KHMpLCBpbnN0ZWFkIG9mIG9uZSBmb3IgZWFjaCBOICogQ1BzLg0KDQpTb21ldGhp bmcgSSBoYXZlbuKAmXQgY29uY2x1ZGVkIHRvIG15c2VsZiB5ZXQgYXJlIHF1ZXN0aW9ucyBzdWNo IGFzOg0KDQoNCiAgKiAgIGRvZXMgaGF2aW5nIGEgY2FuZGlkYXRlIHBhdGggc3RlZXIgaW50byBh bm90aGVyIFNSIFBvbGljeSBzYXRpc2Z5IHRoZSBhYmlsaXR5IHRvIGRvIHZhcmlvdXMgc3ViLXBh dGggc3BlY2lmaWMgVEUvY29uc3RyYWludC9vYmplY3QgY29tYmluYXRpb25zIHN1ZmZpY2llbnRs eT8NCiAgKiAgIGlzIHRoZSBtb2RlbCByZWxhdGl2ZWx5IHN0cmFpZ2h0IGZvcndhcmQgdG8gbWFw IGludG8geWFuZy9iZ3AvcGNlcCBldGMuLj8NCiAgKiAgIGRvZXMgdXNpbmcgYW4gYWRkaXRpb25h bCBTUiBQb2xpY3kgY3JlYXRlIHRvbyBtdWNoIG92ZXJoZWFkIG9yIHN0YXRlIGJ1cm4gdG8gY29u ZmlndXJlLCBkZXBsb3ksIG1hbmFnZSwgdHJhY2sgZXRjLi4gPw0KDQpDaGVlcnMNCkFuZHJldw0K DQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIktl dGFuIFRhbGF1bGlrYXIgKGtldGFudCkiIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5v cmc+DQpEYXRlOiBUdWVzZGF5LCBOb3ZlbWJlciAxMCwgMjAyMCBhdCAxMDozMyBQTQ0KVG86IFZp c2hudSBQYXZhbiBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbT4NCkNjOiAic3ByaW5nQGll dGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCkhp IFBhdmFuLA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBWaXNobnUgUGF2 YW4gQmVlcmFtIDx2aXNobnVwYXZhbkBnbWFpbC5jb20+DQpTZW50OiAxMSBOb3ZlbWJlciAyMDIw IDAwOjI2DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbT4N CkNjOiBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQpLZXRhbiwg SGkhDQoNClBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNwb25zZXMgKHByZWZpeGVkIFZQQikuDQoN ClJlZ2FyZHMsDQotUGF2YW4NCg0KT24gVHVlLCBOb3YgMTAsIDIwMjAgYXQgNDowNCBBTSBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lz Y28uY29tPj4gd3JvdGU6DQpIaSBQYXZhbiwNCg0KUGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdy4N Cg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2YW5AZ21haWwuY29tPG1haWx0 bzp2aXNobnVwYXZhbkBnbWFpbC5jb20+Pg0KU2VudDogMTAgTm92ZW1iZXIgMjAyMCAwMDowOA0K VG86IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtl dGFudEBjaXNjby5jb20+Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCktldGFuLA0KDQpNdWNoIFRoYW5rcyBm b3IgdGFraW5nIGEgc3RhYiBhdCBhZGRyZXNzaW5nIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGggdXNlLWNhc2UhIFdlIHNlZW0gdG8gYmUgY29udmVyZ2luZy4NCltLVF0gVGhhbmtzIGZvciB0 aGF0IGZlZWRiYWNrIGFuZCBjb25maXJtYXRpb24gdGhhdCB0aGUgcHJvcG9zYWwgaW4gdGhlIGRy YWZ0IGRvZXMgYWRkcmVzcyB0aGUgdXNlLWNhc2UuIEkgYmVsaWV2ZSB3ZSBhcmUgbm93IGRpc2N1 c3NpbmcgdGhlIG1lY2hhbmljcyBvZiBob3cgdGhpcyBpcyBhY2hpZXZlZCB3aXRoaW4gdGhlIGN1 cnJlbnQgU1IgUG9saWN5IGZyYW1ld29yay4NCg0KSG93ZXZlciwgSSBkb27igJl0IHVuZGVyc3Rh bmQgd2h5IHlvdSBuZWVkIHRvIHVzZSBhZGRpdGlvbmFsIFNSIHBvbGljaWVzIChhbmQgdW5uZWNl c3NhcmlseSBidXJuIGFkZGl0aW9uYWwgY29sb3JzKSB0byBhZGRyZXNzIHRoaXMuDQpbS1RdIEkg ZG8gbm90IGZvbGxvdyB3aGF0IHlvdSBtZWFuIGJ5IOKAnGJ1cm4gYWRkaXRpb25hbCBjb2xvcnPi gJ0uIENvbG9yIGlzIGp1c3QgYSAzMiBiaXQgbnVtYmVyIHRoYXQgaW5kaWNhdGVzIHRoZSDigJxp bnRlbnTigJ0gYW5kIGlzIG5vdCByZWFsbHkgYSBzY2FyY2UgcmVzb3VyY2UuIEFzc2lnbmluZyBh IGNvbG9yIHRvIOKAnGEgY29tcG9zaXRlIGludGVudOKAnSBzZWVtcyBsaWtlIGEgc2VhbWxlc3Mg d2F5IHRvIGludGVncmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlzbXMgZm9yIFN0ZWVyaW5nIG92 ZXIgU1IgUG9saWNpZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmlsaXR5IGZvciBzYXkgc29tZSBC R1Agc2VydmljZXMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudCBleHBsaWNpdC9k eW5hbWljIGludGVudCB3aGlsZSBvdGhlcnMgY2FuIHN0ZWVyIG92ZXIgYSBjb21wb3NpdGUgaW50 ZW50IHRoYXQgaW5jbHVkZXMgdGhvc2UgaW5kaXZpZHVhbCBleHBsaWNpdC9keW5hbWljIGludGVu dHMuDQoNCltWUEJdIFRoZSDigJxmbGV4aWJpbGl0eeKAnSB0aGF0IHlvdSBhcmUgcmVmZXJyaW5n IHRvIGlzIHVuZGVzaXJhYmxlIGZvciB0aGlzIHVzZS1jYXNlLiBGb3IgdGhlIHRyYWZmaWMtc3Bs aXQgdXNlLWNhc2UsIHdlIGRvbuKAmXQgd2FudCBhbnkgb3RoZXIgc2VydmljZXMgdG8gYmUgZGly ZWN0bHkgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudHMgd2hlbiB0aGV5IGFyZSBwYXJ0IG9m IGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoLg0KW0tUXSBJIGJlbGlldmUgdGhlIHVzZS1jYXNl IHRoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gd2FzIGZvciBzcGxpdHRpbmcgc29tZSB0cmFmZmlj IGZvciBhIHNlcnZpY2Ugb3ZlciBhIGJsdWUgcGxhbmUgYW5kIHRoZSByZXN0IG92ZXIgYSByZWQg cGxhbmUuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXJlIG1heSBiZSBvdGhlciBzZXJ2aWNlcyB0aGF0 IHV0aWxpemUgb25seSBhIHNpbmdsZSBwbGFuZS4gVGhlIGZsZXhpYmlsaXR5IHRoYXQgSSB3YXMg cmVmZXJyaW5nIHRvIHdhcyB0byBlbmFibGUvYWxsb3cgZm9yIGVpdGhlciBvZiB0aGUgdHdvIHNj ZW5hcmlvcyBhbmQgdGhlcmUgbWF5IGJlIG90aGVyL21vcmUgdXNlLWNhc2VzIGZvciB3aGljaCB3 ZSBuZWVkIGEgbW9yZSBnZW5lcmljIGZyYW1ld29yay4NCg0KVGhlIGN1cnJlbnQgcHJvcG9zYWwg aW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgYmVlbiBhY2NlcHRhYmxlIGlmIHRoZSBjb25zdGl0dWVu dCBTUiBQb2xpY2llcyB3ZXJlIHVuY29sb3JlZCDigJMgYnV0IHRoYXQgd291bGQgdmlvbGF0ZSB0 aGUgY3VycmVudCBydWxlcyBpbXBvc2VkIGJ5IHRoZSBkcmFmdC4NCg0KDQpXaHkgY2Fu4oCZdCB0 aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGp1c3QgYmUgYSBncm91cGluZyBvZiBleHBsaWNp dCBjYW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMgY2FuZGlkYXRlIHBhdGhzPw0KW0tUXSBU aGlzIGlzIGJlY2F1c2UgaW4gdGhlIFNSIFBvbGljeSBmcmFtZXdvcmssIHRoZXJlIGlzIG9ubHkg YSBzaW5nbGUgYWN0aXZlIENQIOKAkyBpdCBtYXkgYmUgZXhwbGljaXQgb3IgZHluYW1pYy4gTm93 IHdl4oCZdmUgYWRkZWQgYW5vdGhlciBDb21wb3NpdGUgQ1AgdHlwZSB0byBjb3ZlciB0aGlzIHNw ZWNpZmljIHVzZS1jYXNlLiBZb3VyIHByb3Bvc2FsIHdpbGwgcmVzdWx0IGluIDMgY2FuZGlkYXRl IHBhdGhzIGJlaW5nIGFjdGl2ZSB3aXRoaW4gdGhlIHNhbWUgU1IgUG9saWN5IOKAkyBvbmUgZWFj aCBvZiB0aGUgZXhwbGljaXQgYW5kIGR5bmFtaWMgQ1AgYW5kIHRoZW4gYWRkaXRpb25hbGx5IHRo ZSBDb21wb3NpdGUgQ1AuIFRoaXMgYnJlYWtzIHRoZSBleGlzdGluZyBydWxlcyBmb3Igc2VsZWN0 aW9uIG9mIENQIGJhc2VkIG9uIHByZWZlcmVuY2UgYW5kIG1lY2hhbmlzbXMgbGlrZSBmYWxsYmFj ayBiZXR3ZWVuIENQcy4gV2hpbGUgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHBy b3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIG5ldyB1c2UtY2FzZSB3aXRoIGEgYmFja3dhcmRz IGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBTUiBQb2xpY3kgZnJhbWV3b3JrLg0KDQpbVlBC XSBUaGUgcHJvcG9zYWwgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgYmFja3dhcmRzIGNvbXBhdGli bGUgYW5kIGRvZXMgbm90IGludGVuZCB0byBicmVhayBhbnkgZXhpc3RpbmcgcnVsZXMgZm9yIGRl ZW1pbmcgYSBjYW5kaWRhdGUgcGF0aCBhY3RpdmUuIEFzIHBlciB0aGUgcnVsZXMgdGhhdCBhcmUg b3V0bGluZWQgaW4gU2VjdGlvbiAyLjksIG9ubHkgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aCBpcyDigJxhY3RpdmXigJ0gZ2l2ZW4gaXRzIHByZWZlcmVuY2UuIFRoZSBjb25zdGl0dWVudCBj YW5kaWRhdGUgcGF0aHMgd2lsbCBuZXZlciBiZSBhY3RpdmUgb24gdGhlaXIgb3duLiBJZiBpdCBp cyBuZWNlc3NhcnksIHdlIGNhbiBhZGQgYSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiAyLjkgdG8gZXhw bGljaXRseSBzdGF0ZSB0aGF0IHRoZSBjYW5kaWRhdGUgcGF0aCBzZWxlY3Rpb24gY3JpdGVyaWEg ZG9lcyBub3QgYXBwbHkgdG8gdGhlIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRocy4NCltLVF0g V2hlbiBhIENQIGlzIOKAnGFjdGl2ZeKAnSBpdCBpcyBhY3R1YWxseSB0aGUgb25lIHRoYXQgaXMg YmVpbmcgdXNlZCBmb3IgZm9yd2FyZGluZy4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KDQpUaGFua3Ms DQpLZXRhbg0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCioqIFNlY3Rpb24g Mi4yDQpPTEQ6DQoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBjb250 YWluZXIgZm9yIGdyb3VwaW5nIG9mIFNSDQoNCiAgIFBvbGljaWVzLiAgVGhlIGNvbXBvc2l0ZSBj YW5kaWRhdGUgcGF0aCBjb25zdHJ1Y3QgZW5hYmxlcyBjb21iaW5hdGlvbg0KDQogICBvZiBTUiBQ b2xpY2llcywgZWFjaCB3aXRoIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1p Yw0KDQogICBjYW5kaWRhdGUgcGF0aHMgd2l0aCBwb3RlbnRpYWxseSBkaWZmZXJlbnQgb3B0aW1p emF0aW9uIG9iamVjdGl2ZXMNCg0KICAgYW5kIGNvbnN0cmFpbnRzLCBmb3IgYSBsb2FkLWJhbGFu Y2VkIHN0ZWVyaW5nIG9mIHBhY2tldCBmbG93cyBvdmVyDQoNCiAgIGl0cyBjb25zdGl0dWVudCBT UiBQb2xpY2llcy4gIFRoZSBmb2xsb3dpbmcgY3JpdGVyaWEgYXBwbHkgZm9yDQoNCiAgIGluY2x1 c2lvbiBvZiBjb25zdGl0dWVudCBTUiBQb2xpY2llcyB1c2luZyBhIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aA0KDQogICB1bmRlciBhIHBhcmVudCBTUiBQb2xpY3k6DQoNCg0KDQogICBvICB0aGUg ZW5kcG9pbnRzIG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudCBT Ug0KDQogICAgICBQb2xpY3kgTVVTVCBiZSBpZGVudGljYWwNCg0KDQoNCiAgIG8gIFRoZSBjb2xv cnMgb2YgZWFjaCBvZiB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQN Cg0KICAgICAgU1IgUG9saWN5IE1VU1QgYmUgZGlmZmVyZW50DQoNCg0KDQogICBvICB0aGUgY29u c3RpdHVlbnQgU1IgUG9saWNpZXMgTVVTVCBOT1QgdXNlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aHMNCg0KDQoNCiAgIEVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IG9mIGEgY29tcG9zaXRlIGNh bmRpZGF0ZSBwYXRoIGlzDQoNCiAgIGFzc29jaWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9hZC1i YWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyDQoNCiAgIFNlY3Rpb24gMi4xMTxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0w OSNzZWN0aW9uLTIuMTE+IGZvciBkZXRhaWxzKS4gIFRoZSBkZWZhdWx0IHdlaWdodCBpcyAxLg0K DQoNCg0KTkVXOg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBhY3RzIGFzIGEgY29u dGFpbmVyIGZvciBncm91cGluZyBvZg0KDQogICBleHBsaWNpdCBjYW5kaWRhdGUgcGF0aHMgYW5k L29yIGR5bmFtaWMgY2FuZGlkYXRlIHBhdGhzIHdpdGgNCg0KICAgcG90ZW50aWFsbHkgZGlmZmVy ZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVzIGFuZCBjb25zdHJhaW50cy4NCg0KICAgVGhlIGNv bXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBjb25zdHJ1Y3QgZW5hYmxlcyBsb2FkLWJhbGFuY2VkDQoN CiAgIHN0ZWVyaW5nIG9mIHBhY2tldC1mbG93cyBvdmVyIGEgc2V0IG9mIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZQ0KDQogICBwYXRocy4gVGhlIGZvbGxvd2luZyBjcml0ZXJpYSBhcHBseSBmb3IgY29u c3RpdHVlbnQgY2FuZGlkYXRlDQoNCiAgIHBhdGhzIHVuZGVyIGEgY29tcG9zaXRlIGNhbmRpZGF0 ZSBwYXRoOg0KDQoNCg0KICAgbyAgdGhlIHByZWZlcmVuY2Ugb2YgdGhlIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRoIE1VU1QgYmUNCg0KICAgICAgaWdub3JlZC4NCg0KDQoNCiAgIG8gIHRoZSBj b25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIE5PVCBiZSBhIGNvbXBvc2l0ZSBjYW5kaWRh dGUNCg0KICAgICAgcGF0aA0KDQoNCg0KICAgRWFjaCBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0 aCBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcw0KDQogICBhc3NvY2lhdGVkIHdpdGgg YSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChyZWZlcg0KDQogICBTZWN0aW9u IDIuMTE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDkjc2VjdGlvbi0yLjExPiBmb3IgZGV0YWlscykuICBUaGUgZGVm YXVsdCB3ZWlnaHQgaXMgMS4NCg0KDQoNCioqDQoNCg0KDQoqKiBTZWN0aW9uIDIuMTENCg0KDQoN Ck9MRDoNCiAgIFdoZW4gYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgYWN0aXZlLCB0aGUg ZnJhY3Rpb24gb2YgZmxvd3MNCiAgIHN0ZWVyZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IFNSIFBv bGljeSBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmUNCiAgIHdlaWdodCBvZiBlYWNoIGNvbnN0aXR1 ZW50IFNSIFBvbGljeS4gIEZ1cnRoZXIgbG9hZCBiYWxhbmNpbmcgb2YNCiAgIGZsb3dzIHN0ZWVy ZWQgaW50byBhIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBwZXJmb3JtZWQgYmFzZWQgb24gdGhl DQogICB3ZWlnaHRzIG9mIHRoZSBTZWdtZW50LUxpc3Qgb2YgdGhlIGFjdGl2ZSBjYW5kaWRhdGUg cGF0aCBvZiB0aGF0DQogICBjb25zdGl0dWVudCBTUiBQb2xpY3kuDQoNCg0KDQpORVc6DQogICBX aGVuIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIGFjdGl2ZSwgdGhlIGZyYWN0aW9uIG9m IGZsb3dzDQogICBzdGVlcmVkIGludG8gZWFjaCBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBp cyBlcXVhbCB0byB0aGUgcmVsYXRpdmUNCiAgIHdlaWdodCBvZiBlYWNoIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRoLiAgRnVydGhlciBsb2FkIGJhbGFuY2luZyBvZg0KICAgZmxvd3Mgc3RlZXJl ZCBpbnRvIGEgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggaXMgcGVyZm9ybWVkIGJhc2VkIG9u DQogICB0aGUgd2VpZ2h0cyBvZiBlYWNoIGFzc29jaWF0ZWQgU2VnbWVudC1MaXN0Lg0KDQoNCioq DQoNCg0KDQoqKiBTZWN0aW9uIDIuMTMNCg0KDQoNCk9MRDoNCiAgIFRoZSBpbmZvcm1hdGlvbiBt b2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZQ0KICAgY2FuZGlkYXRl IHBhdGggaXMgdGhlIGZvbGxvd2luZzoNCg0KICAgU1IgcG9saWN5IFBPTDEwMCA8aGVhZGVuZCA9 IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9pbnQgPSBFMT4NCiAgICAgICAgQ2FuZGlkYXRlLXBhdGgg Q1AxIDxwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQogICAxMDA6MS4xLjEuMSwg ZGlzY3JpbWluYXRvciA9IDE+DQogICAgICAgICAgICBQcmVmZXJlbmNlIDIwMA0KICAgICAgICAg ICAgV2VpZ2h0IFcxLCBTUiBwb2xpY3kgPGNvbG9yID0gMT4NCiAgICAgICAgICAgIFdlaWdodCBX MiwgU1IgcG9saWN5IDxjb2xvciA9IDI+DQoNCiAgIFRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2ll cyBQT0wxIGFuZCBQT0wyIGhhdmUgaW5mb3JtYXRpb24gbW9kZWwgYXMNCiAgIGRlc2NyaWJlZCBh dCB0aGUgc3RhcnQgb2YgdGhpcyBzZWN0aW9uLiAgVGhleSBhcmUgcmVmZXJlbmNlZCBvbmx5IGJ5 DQogICBjb2xvciBpbiB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHNpbmNlIHRoZWlyIGhl YWRlbmQgYW5kDQogICBlbmRwb2ludCBhcmUgaWRlbnRpY2FsIHRvIHRoZSBQT0wxMDAuICBUaGUg dmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUNCiAgIGFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiBQ T0wxIGFuZCBQT0wyIGFyZSBpbnN0YWxsZWQgaW4gdGhlDQogICBmb3J3YXJkaW5nLiAgVHJhZmZp YyBzdGVlcmVkIG9uIFBPTDEwMCBpcyBmbG93LWJhc2VkIGhhc2hlZCBvbiBQT0wxDQogICB3aXRo IGEgcmF0aW8gVzEvKFcxK1cyKS4gIFdpdGhpbiB0aGUgUE9MMSwgdGhlIGZsb3ctYmFzZWQgaGFz aGluZw0KICAgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUgcGVyZm9ybWVkIGFzIGRlc2NyaWJl ZCBlYXJsaWVyIGluIHRoaXMNCiAgIHNlY3Rpb24uDQoNCg0KDQpORVc6DQogICBUaGUgaW5mb3Jt YXRpb24gbW9kZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZpbmcgYSBjb21wb3NpdGUNCiAgIGNh bmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIFNSIHBvbGljeSBQT0wxMDAgPGhl YWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0gRTE+DQogICAgICAgIENhbmRpZGF0 ZS1wYXRoIENvbXAtQ1AgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEw MDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMT4NCiAgICAgICAgICAgIFByZWZlcmVuY2UgMjAw DQogICAgICAgICAgICBXZWlnaHQgVzEsIENhbmRpZGF0ZS1wYXRoIENQMQ0KICAgICAgICAgICAg V2VpZ2h0IFcyLCBDYW5kaWRhdGUtcGF0aCBDUDINCiAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ1Ax IDxwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQogICAxMDA6MS4xLjEuMSwgZGlz Y3JpbWluYXRvciA9IDI+DQogICAgICAgICAgICAgV2VpZ2h0IFcxMSwgU0lELUxpc3QxIDxTSUQx MS4uLlNJRDFpPg0KICAgICAgICAgICAgIFdlaWdodCBXMTIsIFNJRC1MaXN0MiA8U0lEMjEuLi5T SUQyaj4NCiAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ1AyIDxwcm90b2NvbC1vcmlnaW4gPSAyMCwg b3JpZ2luYXRvciA9DQogICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDM+DQogICAgICAg ICAgICAgV2VpZ2h0IFcyMSwgU0lELUxpc3QzIDxTSUQzMS4uLlNJRDNpPg0KICAgICAgICAgICAg IFdlaWdodCBXMjIsIFNJRC1MaXN0NCA8U0lENDEuLi5TSUQ0aj4NCg0KICAgQ29tcC1DUCBpcyBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB3aXRoIHR3byBjb25zdGl0dWVudHMsIENQMQ0KICAg YW5kIENQMi4gVGhlIHByZWZlcmVuY2UgaXMgaWdub3JlZCBmb3IgZWFjaCBvZiB0aGUgdHdvIGNv bnN0aXR1ZW50DQogICBjYW5kaWRhdGUgcGF0aHMuIFRoZSB2YWxpZCBTZWdtZW50LUxpc3RzIG9m IHRoZSB0d28gY29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBwYXRocyBhcmUgaW5zdGFsbGVkIGlu IHRoZSBmb3J3YXJkaW5nLiBUcmFmZmljIHN0ZWVyZWQNCiAgIG9uIENvbXAtQ1AgaXMgZmxvdy1i YXNlZCBoYXNoZWQgb24gdG8gQ1AxIGFuZCBDUDIgd2l0aCBhIHJhdGlvIG9mDQogICBXMS8oVzEr VzIpIGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGluIGVhY2ggY29uc3RpdHVlbnQN CiAgIGNhbmRpZGF0ZSBwYXRoLCB0aGUgZmxvdy1iYXNlZCBoYXNoaW5nIG92ZXIgaXRzIFNlZ21l bnQtTGlzdHMgYXJlDQogICBwZXJmb3JtZWQgYXMgZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhpcyBz ZWN0aW9uLg0KDQoNCioqDQoNCg0KDQoqKiBTZWN0aW9uIDUuMw0KDQoNCg0KT0xEOg0KICAgQSBj b21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNv bnN0aXR1ZW50DQogICBTUiBQb2xpY2llcy4NCg0KICAgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGggaXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkDQogICBjb25zdGl0dWVu dCBTUiBQb2xpY3kuDQoNCg0KDQpORVc6DQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBp cyBzcGVjaWZpZWQgYXMgYSBncm91cCBvZiBpdHMgY29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBw YXRocy4NCg0KICAgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgdmFsaWQgd2hlbiBpdCBo YXMgYXQgbGVhc3Qgb25lIHZhbGlkDQogICBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aC4NCg0K DQoqKg0KDQoNCg0KUmVnYXJkcywNCg0KLVBhdmFuDQoNCg0KDQpPbiBTdW4sIE5vdiAxLCAyMDIw IGF0IDc6MDIgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50PTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KSGVsbG8gQWxsLA0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZSBmb3IgdGhlIGRy YWZ0IGFuZCBmb2xsb3dpbmcgaXMgdGhlIHN1bW1hcnkgb2YgY2hhbmdlczoNCg0KMSkgSW50cm9k dWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlkYXRlIFBhdGggY29uc3RydWN0IHRvIGFkZHJl c3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6IGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2ZFcUU1VE93ZGgydkV5Rm1fTUVqaVh5UDJ3cy8g YW5kIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdw MGpDRXhSeDBTWHlCWTBDeXFYVS8pDQoyKSBCYXNlZCBvbiBvZmZsaW5lIGZlZWRiYWNrIHJlY2Vp dmVkLCB1cGRhdGVkIFNSdjYgc2VnbWVudCB0eXBlcyB0byBpbmNsdWRlIG9wdGlvbmFsIFNSdjYg U0lEIGFuZCBiZWhhdmlvciBpbnN0ZWFkIG9mIHRoZSBuZXcgdHlwZSB0aGF0IHdhcyBpbnRyb2R1 Y2VkIGZvciBpdCBpbiB0aGUgdjA4Lg0KMykgQ2xhcmlmaWNhdGlvbiBvZiBoYW5kbGluZyBvZiBj b2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBvZmZsaW5lIGZlZWRi YWNrIHJlY2VpdmVkLg0KNCkgQ2xhcmlmaWNhdGlvbiBvbiBjb25zaWRlcmF0aW9ucyBmb3IgVEkt TEZBIGZvciBTUiBQb2xpY3kgYXMgZGlzY3Vzc2VkIGluIHRoZSBXRyAoUmVmIDogaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvRVYxeXRVc2Q1WmdrTUhETjBJdkZo dzlpZDQwLykNCg0KUGxlYXNlIGxldCBrbm93IHlvdXIgY29tbWVudHMvZmVlZGJhY2suDQoNClRo YW5rcywNCktldGFuIChvbiBiZWhhbGYgb2YgY28tYXV0aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU2VudDogMDIgTm92ZW1i ZXIgMjAyMCAwNjoyNw0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91 bmNlQGlldGYub3JnPg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pg0KU3ViamVjdDogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0 d29ya2luZyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZWdt ZW50IFJvdXRpbmcgUG9saWN5IEFyY2hpdGVjdHVyZQ0KICAgICAgICBBdXRob3JzICAgICAgICAg OiBDbGFyZW5jZSBGaWxzZmlscw0KICAgICAgICAgICAgICAgICAgICAgICAgICBLZXRhbiBUYWxh dWxpa2FyDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbCBWb3llcg0KICAgICAgICAg ICAgICAgICAgICAgICAgICBBbGV4IEJvZ2Rhbm92DQogICAgICAgICAgICAgICAgICAgICAgICAg IFBhdWwgTWF0dGVzDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6 IDM3DQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMjAtMTEtMDENCg0KQWJzdHJhY3Q6DQog ICBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYSBw YWNrZXQgZmxvdw0KICAgYWxvbmcgYW55IHBhdGguICBJbnRlcm1lZGlhdGUgcGVyLWZsb3cgc3Rh dGVzIGFyZSBlbGltaW5hdGVkIHRoYW5rcw0KICAgdG8gc291cmNlIHJvdXRpbmcuICBUaGUgaGVh ZGVuZCBub2RlIHN0ZWVycyBhIGZsb3cgaW50byBhbiBTUiBQb2xpY3kuDQogICBUaGUgaGVhZGVy IG9mIGEgcGFja2V0IHN0ZWVyZWQgaW4gYW4gU1IgUG9saWN5IGlzIGF1Z21lbnRlZCB3aXRoIGFu DQogICBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9s aWN5LiAgVGhpcw0KICAgZG9jdW1lbnQgZGV0YWlscyB0aGUgY29uY2VwdHMgb2YgU1IgUG9saWN5 IGFuZCBzdGVlcmluZyBpbnRvIGFuIFNSDQogICBQb2xpY3kuDQoNCg0KVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5Lw0K DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS0wOQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5DQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoN CkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNw cmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCg== --_000_3E1EC6677B1745AC9CDEF121FB75F14Bnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1JTjt9DQpzcGFuLmdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NDI0NDQ1MTI7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUyOTg1MzY4IC0xNDMx MTM4NjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgS2V0YW4sIFBhdmFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29k IGRpc2N1c3Npb24uIEp1c3QgZ29pbmcgdG8gY2hpcCBpbiBzb21lIHRob3VnaHRz4oCmPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgZWxlbWVudHMgSSBwZXJzb25hbGx5IGxpa2Ug b2YgdGhlIFNSIFBvbGljeSBtb2RlbCBpcyB0aGF0IG1hbnkgQ2FuZGlkYXRlIFBhdGhzIG1heSBl eGlzdCwgYnV0IG9ubHkgb25lIG1heSBiZSBhY3RpdmUgYW5kIGEgY2FuZGlkYXRlIHBhdGggY29u dGFpbnMgMSBvciBtYW55IFNJRCBsaXN0cy4gSXTigJlzIGEgc2ltcGxlIHBhcmVudC9jaGlsZCAt IHJvb3QvbGVhZiB0cmVlIHdpdGggdmVyeSBjbGVhcg0KIHJ1bGVzIHdpdGhpbiB0aGUgU1IgcG9s aWN5IGNvbnRleHQgaW5zdGFuY2UuIEZyb20gbXkgcG9pbnQgb2Ygdmlldywgd2hhdCBpcyBiZWlu ZyBwcm9wb3NlZCBpbiB0aGUgLTA5IGRvY3VtZW50IHN0aWxsIGZvbGxvd3MgdGhvc2UgcnVsZXMg YW5kIHRoZSBnZW5lcmFsIHRvcC1kb3duIHRyZWUgYmVoYXZpb3VyLiBEZXNwaXRlIHRoZSBjb21w b3NpdGUgQ1AgcG9pbnRpbmcgdG8gYSBkaWZmZXJlbnQgU1IgUG9saWN5LCB0aGF0IFNSIFBvbGlj eSBzdGlsbA0KIGZvbGxvd3MgYWxsIG9mIHRoZSBzYW1lIHJ1bGVzIHRvcCBkb3duIGluIGl0cyBv d24gaXNvbGF0ZWQgY29udGV4dC4gQ29tcGFyZSB0aGF0IHRvIHNheSwgaGF2aW5nIGEgY2FuZGlk YXRlIHBhdGggY29udGFpbiBhIGNoaWxkIHRoYXQgcG9pbnRzIHRvIG90aGVyIGNhbmRpZGF0ZSBw YXRocyB3aXRoaW4gdGhlIHNhbWUgU1IgUG9saWN5IGNvbnRleHQ6IHdpdGhpbiB0aGUgc2FtZSBj b250ZXh0IGEgY2hpbGQgaXMgcG9pbnRpbmcgdG8gYSBzaWJsaW5nDQogb2YgaXRzIHBhcmVudC4g VGhlIHJ1bGVzIG5vdyBoYXZlIHRvIGJlbmQgc2xpZ2h0bHkuIEFzIG5vdGVkIGJlbG93LCBzb21l IG9mIHRoZSBydWxlcyBhcm91bmQgd2hhdCBpcyBjb25zaWRlcmVkIGFuIGFjdGl2ZSBjYW5kaWRh dGUgcGF0aCB3b3VsZCBuZWVkIHRvIGNoYW5nZSwgc2luY2UgdGhlIGNvbnN0aXR1ZW50cyBlc3Nl bnRpYWxseSBhcmUgYWN0aXZlICh0aGV54oCZcmUgaW5zdGFsbGVkKSBkZXNwaXRlIG5vdCBiZWlu ZyB0aG91Z2h0IG9mIGFzDQogYmVpbmcgYWN0aXZlLiBOb3RlIHRoYXQgdGhlIHByb3Bvc2VkIG5l dyB0ZXh0IGJlbG93IHNheXMg4oCcVGhlIHByZWZlcmVuY2UgaXMgaWdub3JlZCBmb3IgZWFjaCBv ZiB0aGUgdHdvIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRocyZxdW90OyB3aGljaCBpcyBhbHNv IGEgbmV3IHJ1bGUsIGhvd2V2ZXIgb25lIGNvdWxkIHBlcmhhcHMgd29yayBhcm91bmQgdGhhdCBi eSBqdXN0IHJlcXVpcmluZyB0aGUgcHJlZmVyZW5jZSBvbiB0aGUgY29uc3RpdHVlbnRzIGJlDQog bGVzcyBwcmVmZXJyZWQgdGhhbiBhbnkgb3RoZXIgc3RhbmRhcmQgb3IgY29tcG9zaXRlIENQIOKA kyBidXQgdGhhdCByYWlzZXMgaXRzIG93biB0cm91YmxlcyB3aXRoIG11bHRpcGxlIHNvdXJjZXMg b2YgcHJvdmlzaW9uaW5nIOKAkyB3aGljaCBsZWFkcyB0byBhIHJ1bGUgYXNraW5nIHRvIGlnbm9y ZSB0aGUgcHJlZmVyZW5jZS4gSW4gc3VtbWFyeSwgZnJvbSBteSBwLm8udiBuZXcgcnVsZXMgaW4g dGhlIGhpZXJhcmNoeSB3b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZGluZyBzdGVlcmluZyBpbnRvIGFuIFNSIFBvbGljeSwgeWVzLCB5b3Ug YnVybiBjb2xvcnMgaW4gZG9pbmcgdGhpcyAoMzJiaXRzLi4uKSBhbmQgaXQgd291bGQgcmVxdWly ZSBkZXBsb3lpbmcgYW4gZW50aXJlbHkgZGVkaWNhdGVkIFNSIFBvbGljeSBjb25zdHJ1Y3QsIGFu ZCBydW4gdGhlIHJpc2sgb2Ygc3RlZXJpbmcg4oCYb3RoZXLigJkgdHJhZmZpYyBpbnRvIHRoYXQg cG9saWN5LiBJZiB0aGlzIGlzIGEgY29uY2VybiwNCiB3b3VsZCB0aGUgY29tcG9zaXRlIFNSIFBv bGljaWVzIG5vdCBiZSBlbmdpbmVlcmVkIGluIGEgd2F5IHdoZXJlIHRoZSBjb2xvciBibG9jayB1 c2VkIGlzIGRlc2lnbmVkIHRvIG5vdCBiZSB1c2VkIGVsc2V3aGVyZSBpbiB0aGUgbmV0d29yayBm b3Igb3RoZXIgcHVycG9zZXM/IElzIHRoZXJlIG5vdCBhIGRpZmZlcmVudCBidXQga2luZCBvZiBz aW1pbGFyIHByb2JsZW0gd2l0aCBCaW5kaW5nIFNJRHMsIGluIHRoYXQgdGhleeKAmXJlIGVsaWdp YmxlIGZvcg0KIHVzZSBieSBvdGhlciBjb25zdW1lcnMgZXZlbiBpZiBub3QgZGlyZWN0bHkgaW50 ZW5kZWQ/IChhbHRob3VnaCBhdCBsZWFzdCBCU0lEcyBhcmUgb3B0aW9uYWwgYW5kIG5vdCBtYW5k YXRvcnkpLiBJbiBhZGRpdGlvbiB0byB0aGUgc3BsaXQgVEUgY2FzZXMsIGJlaW5nIGFibGUgdG8g aGF2ZSBhbiBTUiBQb2xpY3kgc3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBtaWdodCBhbHNv IGhhdmUgc29tZSB2YWx1ZSBpbiBhIGJhY2t1cCBjYW5kaWRhdGUNCiBzY2VuYXJpbyB3aGVuIG9u ZSBoYXMgbXVsdGlwbGUgU1IgUG9saWNpZXMgd2l0aCB0aGUgc2FtZSBlbmRwb2ludCwgYnV0IGNh biBzaGFyZSBhIGNvbW1vbiBmYWxsYmFjay9iZXN0IGVmZm9ydCBjYW5kaWRhdGUgcGF0aC4gVGhl IGVudGl0eSAoPGk+SSdtIHRoaW5raW5nIFBDRTwvaT4pIG1hbmFnaW5nIHRoYXQgd291bGQgb25s eSBuZWVkIHRvIG1haW50YWluIHRoZSBmYWxsYmFjay9iZXN0IGVmZm9ydCBDUCBTSUQgbGlzdChz KSwgaW5zdGVhZCBvZg0KIG9uZSBmb3IgZWFjaCBOICogQ1BzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Tb21ldGhpbmcgSSBoYXZlbuKAmXQgY29uY2x1ZGVkIHRvIG15c2VsZiB5ZXQgYXJlIHF1 ZXN0aW9ucyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ZG9lcyBoYXZpbmcgYSBjYW5kaWRhdGUgcGF0aCBzdGVl ciBpbnRvIGFub3RoZXIgU1IgUG9saWN5IHNhdGlzZnkgdGhlIGFiaWxpdHkgdG8gZG8gdmFyaW91 cyBzdWItcGF0aCBzcGVjaWZpYyBURS9jb25zdHJhaW50L29iamVjdCBjb21iaW5hdGlvbnMgc3Vm ZmljaWVudGx5PzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPmlzIHRoZSBtb2Rl bCByZWxhdGl2ZWx5IHN0cmFpZ2h0IGZvcndhcmQgdG8gbWFwIGludG8geWFuZy9iZ3AvcGNlcCBl dGMuLj88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5kb2VzIHVzaW5nIGFuIGFk ZGl0aW9uYWwgU1IgUG9saWN5IGNyZWF0ZSB0b28gbXVjaCBvdmVyaGVhZCBvciBzdGF0ZSBidXJu IHRvIGNvbmZpZ3VyZSwgZGVwbG95LCBtYW5hZ2UsIHRyYWNrIGV0Yy4uID88bzpwPjwvbzpwPjwv bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNw cmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtL ZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpJnF1b3Q7ICZsdDtrZXRhbnQ9NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDEwLCAy MDIwIGF0IDEwOjMzIFBNPGJyPg0KPGI+VG86IDwvYj5WaXNobnUgUGF2YW4gQmVlcmFtICZsdDt2 aXNobnVwYXZhbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzcHJpbmdAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ktMDkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIFBhdmFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgY2hl Y2sgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmlzaG51cGF2YW5AZ21haWwuY29t Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDExIE5vdmVtYmVyIDIwMjAgMDA6MjY8YnI+DQo8Yj5U bzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudEBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1w b2xpY3ktMDkudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+S2V0YW4sIEhpITxicj4NCjxicj4NClBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNw b25zZXMgKHByZWZpeGVkIFZQQikuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQotUGF2YW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDEw LCAyMDIwIGF0IDQ6MDQgQU0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkg UGF2YW4sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UgY2hlY2sgaW5saW5lIGJl bG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjpjdXJyZW50 Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFZpc2hudSBQYXZh biBCZWVyYW0gJmx0OzxhIGhyZWY9Im1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj52aXNobnVwYXZhbkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8 L2I+IDEwIE5vdmVtYmVyIDIwMjAgMDA6MDg8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlr YXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+S2V0YW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5NdWNoIFRo YW5rcyBmb3IgdGFraW5nIGEgc3RhYiBhdCBhZGRyZXNzaW5nIHRoZSBjb21wb3NpdGUgY2FuZGlk YXRlIHBhdGggdXNlLWNhc2UhPHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4 Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDtXZSBzZWVtIHRvIGJlIGNvbnZlcmdp bmcuPC9zcGFuPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48aT5bS1RdIFRoYW5rcyBmb3IgdGhhdCBmZWVkYmFjayBhbmQgY29uZmlybWF0aW9uIHRo YXQgdGhlIHByb3Bvc2FsIGluIHRoZSBkcmFmdCBkb2VzIGFkZHJlc3MgdGhlIHVzZS1jYXNlLiBJ IGJlbGlldmUgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIHRoZSBtZWNoYW5pY3Mgb2YgaG93IHRoaXMg aXMgYWNoaWV2ZWQNCiB3aXRoaW4gdGhlIGN1cnJlbnQgU1IgUG9saWN5IGZyYW1ld29yay48L2k+ PC9iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNw OzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ib3dldmVyLCBJIGRvbuKAmXQgdW5k ZXJzdGFuZCB3aHkgeW91IG5lZWQgdG8gdXNlIGFkZGl0aW9uYWwgU1IgcG9saWNpZXMgKGFuZCB1 bm5lY2Vzc2FyaWx5IGJ1cm4gYWRkaXRpb25hbCBjb2xvcnMpIHRvIGFkZHJlc3MgdGhpcy4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+W0tUXSBJ IGRvIG5vdCBmb2xsb3cgd2hhdCB5b3UgbWVhbiBieSDigJxidXJuIGFkZGl0aW9uYWwgY29sb3Jz 4oCdLiBDb2xvciBpcyBqdXN0IGEgMzIgYml0IG51bWJlciB0aGF0IGluZGljYXRlcyB0aGUg4oCc aW50ZW504oCdIGFuZCBpcyBub3QgcmVhbGx5IGEgc2NhcmNlIHJlc291cmNlLiBBc3NpZ25pbmcg YQ0KIGNvbG9yIHRvIOKAnGEgY29tcG9zaXRlIGludGVudOKAnSBzZWVtcyBsaWtlIGEgc2VhbWxl c3Mgd2F5IHRvIGludGVncmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlzbXMgZm9yIFN0ZWVyaW5n IG92ZXIgU1IgUG9saWNpZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmlsaXR5IGZvciBzYXkgc29t ZSBCR1Agc2VydmljZXMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudCBleHBsaWNp dC9keW5hbWljIGludGVudCB3aGlsZSBvdGhlcnMgY2FuIHN0ZWVyDQogb3ZlciBhIGNvbXBvc2l0 ZSBpbnRlbnQgdGhhdCBpbmNsdWRlcyB0aG9zZSBpbmRpdmlkdWFsIGV4cGxpY2l0L2R5bmFtaWMg aW50ZW50cy48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1ZQQl0gVGhlIOKA nGZsZXhpYmlsaXR54oCdIHRoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gaXMgdW5kZXNpcmFibGUg Zm9yIHRoaXMgdXNlLWNhc2UuIEZvciB0aGUgdHJhZmZpYy1zcGxpdCB1c2UtY2FzZSwgd2UgZG9u 4oCZdCB3YW50IGFueSBvdGhlciBzZXJ2aWNlcyB0byBiZSBkaXJlY3RseSBzdGVlcmVkIG92ZXIg dGhlIGNvbnN0aXR1ZW50cyB3aGVuIHRoZXkgYXJlIHBhcnQgb2YgYSBjb21wb3NpdGUgY2FuZGlk YXRlDQogcGF0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bS1RdIEkgYmVsaWV2ZSB0aGUgdXNlLWNhc2UgdGhh dCB5b3UgYXJlIHJlZmVycmluZyB0byB3YXMgZm9yIHNwbGl0dGluZyBzb21lIHRyYWZmaWMgZm9y IGEgc2VydmljZSBvdmVyIGEgYmx1ZSBwbGFuZSBhbmQgdGhlIHJlc3Qgb3ZlciBhIHJlZCBwbGFu ZS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUgbWF5IGJlIG90aGVyIHNlcnZpY2VzIHRoYXQgdXRp bGl6ZQ0KIG9ubHkgYSBzaW5nbGUgcGxhbmUuIFRoZSBmbGV4aWJpbGl0eSB0aGF0IEkgd2FzIHJl ZmVycmluZyB0byB3YXMgdG8gZW5hYmxlL2FsbG93IGZvciBlaXRoZXIgb2YgdGhlIHR3byBzY2Vu YXJpb3MgYW5kIHRoZXJlIG1heSBiZSBvdGhlci9tb3JlIHVzZS1jYXNlcyBmb3Igd2hpY2ggd2Ug bmVlZCBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdvcmsuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHByb3Bvc2FsIGluIHRoZSBkcmFmdCB3b3VsZCBoYXZl IGJlZW4gYWNjZXB0YWJsZSBpZiB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgd2VyZSB1bmNv bG9yZWQg4oCTIGJ1dCB0aGF0IHdvdWxkIHZpb2xhdGUgdGhlIGN1cnJlbnQgcnVsZXMgaW1wb3Nl ZCBieSB0aGUgZHJhZnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPldoeSBjYW7igJl0IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGgganVzdCBiZSBhIGdyb3VwaW5nIG9mIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3Ig ZHluYW1pYyBjYW5kaWRhdGUgcGF0aHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT5bS1RdIFRoaXMgaXMgYmVjYXVzZSBpbiB0aGUgU1IgUG9saWN5 IGZyYW1ld29yaywgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBhY3RpdmUgQ1Ag4oCTIGl0IG1heSBi ZSBleHBsaWNpdCBvciBkeW5hbWljLiBOb3cgd2XigJl2ZSBhZGRlZCBhbm90aGVyIENvbXBvc2l0 ZSBDUCB0eXBlIHRvIGNvdmVyIHRoaXMNCiBzcGVjaWZpYyB1c2UtY2FzZS4gWW91ciBwcm9wb3Nh bCB3aWxsIHJlc3VsdCBpbiAzIGNhbmRpZGF0ZSBwYXRocyBiZWluZyBhY3RpdmUgd2l0aGluIHRo ZSBzYW1lIFNSIFBvbGljeSDigJMgb25lIGVhY2ggb2YgdGhlIGV4cGxpY2l0IGFuZCBkeW5hbWlj IENQIGFuZCB0aGVuIGFkZGl0aW9uYWxseSB0aGUgQ29tcG9zaXRlIENQLiBUaGlzIGJyZWFrcyB0 aGUgZXhpc3RpbmcgcnVsZXMgZm9yIHNlbGVjdGlvbiBvZiBDUCBiYXNlZCBvbiBwcmVmZXJlbmNl DQogYW5kIG1lY2hhbmlzbXMgbGlrZSBmYWxsYmFjayBiZXR3ZWVuIENQcy4gV2hpbGUgdGhlIGN1 cnJlbnQgcHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHByb3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhl IG5ldyB1c2UtY2FzZSB3aXRoIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRo ZSBTUiBQb2xpY3kgZnJhbWV3b3JrLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bVlBCXSBUaGUgcHJvcG9zYWwgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgYmFja3dhcmRzIGNv bXBhdGlibGUgYW5kIGRvZXMgbm90IGludGVuZCB0byBicmVhayBhbnkgZXhpc3RpbmcgcnVsZXMg Zm9yIGRlZW1pbmcgYSBjYW5kaWRhdGUgcGF0aCBhY3RpdmUuIEFzIHBlciB0aGUgcnVsZXMgdGhh dCBhcmUgb3V0bGluZWQgaW4gU2VjdGlvbiAyLjksIG9ubHkgdGhlIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aCBpcw0KIOKAnGFjdGl2ZeKAnSBnaXZlbiBpdHMgcHJlZmVyZW5jZS4gVGhlIGNvbnN0 aXR1ZW50IGNhbmRpZGF0ZSBwYXRocyB3aWxsIG5ldmVyIGJlIGFjdGl2ZSBvbiB0aGVpciBvd24u IElmIGl0IGlzIG5lY2Vzc2FyeSwgd2UgY2FuIGFkZCBhIHN0YXRlbWVudCBpbiBTZWN0aW9uIDIu OSB0byBleHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVjdGlvbiBj cml0ZXJpYSBkb2VzIG5vdCBhcHBseSB0byB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlDQogcGF0 aHMuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPltLVF0gV2hlbiBhIENQIGlzIOKAnGFjdGl2ZeKAnSBp dCBpcyBhY3R1YWxseSB0aGUgb25lIHRoYXQgaXMgYmVpbmcgdXNlZCBmb3IgZm9yd2FyZGluZy48 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj NDQ3MkM0Ij5UaGFua3MsPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+S2V0YW48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+VGhhbmtzLDwvaT48L2I+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPktldGFuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Db25z aWRlciB0aGUgZm9sbG93aW5nIGNoYW5nZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4qKiBTZWN0 aW9uIDIuMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5l ciBmb3IgZ3JvdXBpbmcgb2YgU1I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFBvbGljaWVzLiZuYnNw OyBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGNvbWJpbmF0 aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvZiBTUiBQb2xpY2llcywgZWFjaCB3aXRoIGV4cGxp Y2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg Y2FuZGlkYXRlIHBhdGhzIHdpdGggcG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBv YmplY3RpdmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgY29uc3RyYWludHMsIGZvciBhIGxv YWQtYmFsYW5jZWQgc3RlZXJpbmcgb2YgcGFja2V0IGZsb3dzIG92ZXI8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGl0cyBjb25zdGl0dWVudCBTUiBQb2xpY2llcy4mbmJzcDsgVGhlIGZvbGxvd2luZyBj cml0ZXJpYSBhcHBseSBmb3I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluY2x1c2lvbiBvZiBjb25z dGl0dWVudCBTUiBQb2xpY2llcyB1c2luZyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgdW5kZXIgYSBwYXJlbnQgU1IgUG9saWN5Ojwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGVuZHBvaW50cyBvZiB0aGUgY29u c3RpdHVlbnQgU1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQgU1I8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBvbGljeSBNVVNUIGJlIGlkZW50aWNhbDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGNvbG9ycyBvZiBlYWNoIG9m IHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU1IgUG9saWN5IE1VU1QgYmUgZGlmZmVyZW50PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgY29uc3RpdHVl bnQgU1IgUG9saWNpZXMgTVVTVCBOT1QgdXNlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aHM8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBFYWNoIGNvbnN0aXR1ZW50IFNSIFBv bGljeSBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpczwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3NlcyAo cmVmZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rp b24tMi4xMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5TZWN0 aW9uIDIuMTE8L3NwYW4+PC9hPiBmb3IgZGV0YWlscykuJm5ic3A7IFRoZSBkZWZhdWx0IHdlaWdo dCBpcyAxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3Ig Z3JvdXBpbmcgb2Y8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRo cyBhbmQvb3IgZHluYW1pYyBjYW5kaWRhdGUgcGF0aHMgd2l0aCA8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7cG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVzIGFu ZCBjb25zdHJhaW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBjb21wb3NpdGUgY2FuZGlk YXRlIHBhdGggY29uc3RydWN0IGVuYWJsZXMgbG9hZC1iYWxhbmNlZDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgc3RlZXJpbmcgb2YgcGFja2V0LWZsb3dzIG92ZXIgYSBzZXQgb2YgY29uc3RpdHVlbnQg Y2FuZGlkYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXRocy4gVGhlIGZvbGxvd2luZyBjcml0 ZXJpYSBhcHBseSBmb3IgY29uc3RpdHVlbnQgY2FuZGlkYXRlIDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3Bh dGhzIHVuZGVyIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoOjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgbyZuYnNwOyB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgY29uc3RpdHVlbnQgY2FuZGlk YXRlIHBhdGggTVVTVCBiZSA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpZ25v cmVkLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGNvbnN0aXR1ZW50 IGNhbmRpZGF0ZSBwYXRoIE1VU1QgTk9UIGJlIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSA8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGF0aDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEVhY2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGgg b2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXM8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFz c29jaWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIu MTEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAy LjExPC9zcGFuPjwvYT4gZm9yIGRldGFpbHMpLiZuYnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMg MS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4qKiBTZWN0aW9uIDIuMTE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3 MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XaGVu IGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIGFjdGl2ZSwgdGhlIGZyYWN0aW9uIG9mIGZs b3dzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnN0 ZWVyZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBlcXVhbCB0byB0aGUgcmVs YXRpdmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEz NzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ d2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5LiZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkZ1cnRoZXINCiBsb2FkIGJhbGFuY2luZyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mbG93cyBzdGVlcmVkIGludG8gYSBjb25z dGl0dWVudCBTUiBQb2xpY3kgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53ZWlnaHRzIG9mIHRoZSBTZWdt ZW50LUxpc3Qgb2YgdGhlIGFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiB0aGF0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdt YWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBv bGljeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5k aWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zdGVlcmVkIGludG8gZWFjaCBj b25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUy NjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0IG9mIGVh Y2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGguJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00 NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+RnVydGhlcg0KIGxvYWQgYmFsYW5jaW5nIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZsb3dzIHN0ZWVyZWQgaW50byBhIGNvbnN0aXR1ZW50 IGNhbmRpZGF0ZSBwYXRoIGlzIHBlcmZvcm1lZCBiYXNlZCBvbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aGUgd2VpZ2h0cyBvZiBlYWNoIGFzc29j aWF0ZWQgU2VnbWVudC1MaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDIuMTM8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgaW5mb3JtYXRpb24gbW9kZWwgb2YgU1IgUG9saWN5IFBP TDEwMCBoYXZpbmcgYSBjb21wb3NpdGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Y2FuZGlkYXRlIHBhdGggaXMgdGhlIGZvbGxvd2luZzo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlNSIHBvbGljeSBQT0wxMDAgJmx0O2hlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAs IGVuZHBvaW50ID0gRTEmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRo IENQMSAmbHQ7cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xMDA6MS4xLjEuMSwgZGlzY3Jp bWluYXRvciA9IDEmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlByZWZlcmVuY2UgMjAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPldlaWdodCBXMSwgU1IgcG9saWN5ICZsdDtjb2xvciA9IDEmZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMiwgU1Ig cG9saWN5ICZsdDtjb2xvciA9IDImZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2Mjhn bWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgY29uc3RpdHVlbnQg U1IgUG9saWNpZXMgUE9MMSBhbmQgUE9MMiBoYXZlIGluZm9ybWF0aW9uIG1vZGVsIGFzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlc2NyaWJlZCBh dCB0aGUgc3RhcnQgb2YgdGhpcyBzZWN0aW9uLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlRoZXkNCiBhcmUgcmVmZXJlbmNlZCBvbmx5IGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbG9yIGluIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRl IHBhdGggc2luY2UgdGhlaXIgaGVhZGVuZCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZW5kcG9pbnQgYXJlIGlkZW50aWNhbCB0byB0aGUgUE9M MTAwLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZQ0KIHZhbGlkIFNlZ21lbnQtTGlz dHMgb2YgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiBQT0wxIGFuZCBQT0wyIGFyZSBpbnN0YWxsZWQg aW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PmZvcndhcmRpbmcuJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4 Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHJhZmZpYyBzdGVlcmVk IG9uIFBPTDEwMA0KIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIFBPTDE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2l0aCBhIHJhdGlvIFcxLyhXMStX MikuJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2l0aGluIHRoZQ0KIFBPTDEsIHRoZSBm bG93LWJhc2VkIGhhc2hpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+b3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUgcGVyZm9ybWVkIGFzIGRlc2Ny aWJlZCBlYXJsaWVyIGluIHRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+c2VjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxl PSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhl IGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2aW5nIGEgY29tcG9zaXRl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRp ZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TUiBwb2xpY3kgUE9M MTAwICZsdDtoZWFkZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUxJmd0Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENvbXAtQ1AgJmx0O3Byb3RvY29sLW9yaWdp bg0KID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4xMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDEmZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlByZWZlcmVuY2UgMjAw PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUy NjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcxLCBD YW5kaWRhdGUtcGF0aA0KIENQMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5XZWlnaHQgVzIsIENhbmRpZGF0ZS1wYXRoIENQMiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt bTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5DYW5kaWRhdGUtcGF0aCBDUDEgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5h dG9yID08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMiZn dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3 MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWln aHQgVzExLCBTSUQtTGlzdDENCiAmbHQ7U0lEMTEuLi5TSUQxaSZndDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcxMiwgU0lELUxp c3QyICZsdDtTSUQyMS4uLlNJRDJqJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYW5kaWRhdGUtcGF0aCBDUDIgJmx0O3Byb3RvY29sLW9y aWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDEwMDoxLjEuMS4xLCBk aXNjcmltaW5hdG9yID0gMyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzIxLCBTSUQtTGlzdDMNCiAmbHQ7U0lEMzEuLi5TSUQzaSZn dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEz NzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ V2VpZ2h0IFcyMiwgU0lELUxpc3Q0ICZsdDtTSUQ0MS4uLlNJRDRqJmd0Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ29tcC1DUCBpcyBhIGNvbXBvc2l0ZSBj YW5kaWRhdGUgcGF0aCB3aXRoIHR3byBjb25zdGl0dWVudHMsIENQMTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQgQ1AyLiBUaGUgcHJlZmVyZW5j ZSBpcyBpZ25vcmVkIGZvciBlYWNoIG9mIHRoZSB0d28gY29uc3RpdHVlbnQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgY2FuZGlkYXRlIHBhdGhzLiBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0 aGUgdHdvPHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29uc3RpdHVlbnQNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMgYXJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGlu Zy4mbmJzcDtUcmFmZmljIHN0ZWVyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDtvbg0KPC9zcGFuPkNvbXAtQ1AgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gdG8g Q1AxIGFuZCBDUDIgd2l0aCBhIHJhdGlvIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBX MS8oVzErVzIpIGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGluIGVhY2ggY29uc3Rp dHVlbnQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aCwgdGhlPHNwYW4g Y2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Zmxvdy1iYXNlZA0KIGhhc2hpbmcgb3ZlciBpdHMgU2VnbWVudC1M aXN0cyBhcmUgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHBlcmZvcm1lZCBhczxzcGFuIGNsYXNz PSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPmRlc2NyaWJlZCBlYXJsaWVyDQogaW4gdGhpcyBzZWN0aW9uLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Kio8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioq IFNlY3Rpb24gNS4zPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUy NjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIFBv bGljaWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgdmFs aWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3Bl Y2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBwYXRocy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4gaXQgaGFzIGF0 IGxlYXN0IG9uZSB2YWxpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5jb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LVBhdmFuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBTdW4sIE5vdiAxLCAyMDIwIGF0IDc6MDIgUE0gS2V0YW4gVGFs YXVsaWthciAoa2V0YW50KSAmbHQ7a2V0YW50PTxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KV2UgaGF2ZSBqdXN0IHBvc3RlZCBh biB1cGRhdGUgZm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRoZSBzdW1tYXJ5IG9mIGNo YW5nZXM6PGJyPg0KPGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlk YXRlIFBhdGggY29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUg V0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZF eUZtX01FamlYeVAyd3MvPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS8iIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5n L2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS88L2E+KTxicj4NCjIpIEJhc2VkIG9uIG9mZmxp bmUgZmVlZGJhY2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1 ZGUgb3B0aW9uYWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhlIG5ldyB0eXBl IHRoYXQgd2FzIGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguPGJyPg0KMykgQ2xhcmlmaWNh dGlvbiBvZiBoYW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBi YXNlZCBvbiBvZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLjxicj4NCjQpIENsYXJpZmljYXRpb24g b24gY29uc2lkZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5IGFzIGRpc2N1c3NlZCBp biB0aGUgV0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVz ZDVaZ2tNSEROMEl2Rmh3OWlkNDAvPC9hPik8YnI+DQo8YnI+DQpQbGVhc2UgbGV0IGtub3cgeW91 ciBjb21tZW50cy9mZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW4gKG9uIGJl aGFsZiBvZiBjby1hdXRob3JzKTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9u IEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiAwMiBO b3ZlbWJlciAyMDIwIDA2OjI3PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0K Q2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQo8YnI+DQo8YnI+ DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcgV0cgb2YgdGhlIElFVEYu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFNlZ21lbnQgUm91dGluZyBQb2xpY3kgQXJj aGl0ZWN0dXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyZW5jZSBGaWxzZmlsczxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLZXRhbiBUYWxhdWxpa2FyPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhbmllbCBWb3llcjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGV4IEJvZ2Rhbm92PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhdWwgTWF0dGVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzogMzc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0xMS0wMTxicj4NCjxicj4NCkFic3Ry YWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFk ZW5kIG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgZmxvdzxicj4NCiZuYnNwOyAmbmJzcDthbG9uZyBh bnkgcGF0aC4mbmJzcDsgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRl ZCB0aGFua3M8YnI+DQombmJzcDsgJm5ic3A7dG8gc291cmNlIHJvdXRpbmcuJm5ic3A7IFRoZSBo ZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGljeS48YnI+DQombmJzcDsg Jm5ic3A7VGhlIGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFuIFNSIFBvbGljeSBpcyBh dWdtZW50ZWQgd2l0aCBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVu dHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7 ICZuYnNwO2RvY3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNSIFBvbGljeSBhbmQgc3Rl ZXJpbmcgaW50byBhbiBTUjxicj4NCiZuYnNwOyAmbmJzcDtQb2xpY3kuPGJyPg0KPGJyPg0KPGJy Pg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS0wOTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJy Pg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwv YT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy88L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw cmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_3E1EC6677B1745AC9CDEF121FB75F14Bnokiacom_-- From nobody Wed Nov 11 16:47:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811133A127B; Wed, 11 Nov 2020 16:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 wYT5_4g7RBQc; Wed, 11 Nov 2020 16:47:13 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 C27F43A127C; Wed, 11 Nov 2020 16:47:12 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id z24so2692229pgk.3; Wed, 11 Nov 2020 16:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fRf4AMG2hbQL5qzyjGsJhPkFDQ7hypzEl6ZUyvxOC8c=; b=Mag1YrH+x95/x/YfJPob8+B1HZRQJXFSAvdCGAGBTeR1Rurgp6LLTfBUUQbTMBCxwc nX0xdc7q5HrGjFLC3wsX5RC/ygsR0VII5w1TN0W1Jvb5HPXoCKANcoYRpv/JXkaWsHnm cDmJzdPkL5EVVaOqUR4NcU1DJemcWihhY0MWDUYQ8tajqUEReXLIDe7sbPXwgMLbKT/v aVMV9XOtwRPxeKoQhzcOYJaJcxW654AjouqPxRnvT9Cxw3TUeqQO+vQHIVAlhp9qZbZV tMpRJA8GZ9l8PsaizBEi3fnZgAWpH1/Fq9YhELxPdudWLnIWOupaO2rLFNX/4c3/rfxg rhOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fRf4AMG2hbQL5qzyjGsJhPkFDQ7hypzEl6ZUyvxOC8c=; b=N4kjhE//3/u3HCb+qgvOfEi4DJS4BMOPzkAQNqXFbOAGUUpKIQ88mHIpYjLbi+Uu8w haRHbD4T+7wOwNCEKyEDe7ZWA0EWWXEL5DhWyAIKABzfFmZ1/HU5nwkUDWN4IQDAD6lZ vmE7GKFzY5VQdcksyQsRM4DIPIaHQNFpnA2NXOsen/JEjbJKQ2/vJ8Qc1uYEYE7feWhf wCQoHYuXhCoNPzSc6b3nTI3Y57l8DnzpWVN3qj625Knueio8al/WvzIUgXaZ68PwDL7H 651KKWNkaac0iVRw29yH0D7CbjmWijWwkK9kRLnKKL0pG7lO5+WnOGm4EUdVdf5PZDjC SLhw== X-Gm-Message-State: AOAM533BL8QuDaLb+H21ctJ1Bop2i/YKGuNSaiS5xwpTZA1mIJvZ1xzi WTBbc/Tmsa12hQ6adWPwe7gSMQKUY9daWT1YT2k= X-Google-Smtp-Source: ABdhPJxUu9Gss898bi7o0UuKj2uKP9UhiZ0nMWJbMA783KVusyQx+JtD96GeJeHSrMyfJI/wnRmYmtT0jBQZGICsSok= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr6432781pjx.112.1605142031920; Wed, 11 Nov 2020 16:47:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Wed, 11 Nov 2020 19:47:00 -0500 Message-ID: To: "Zafar Ali (zali)" Cc: James Guichard , "Zafar Ali (zali)" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a0701905b3de40d9" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 00:47:15 -0000 --000000000000a0701905b3de40d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support WG adoption. Thanks Gyan On Mon, Nov 9, 2020 at 11:39 AM Zafar Ali (zali) wrote: > Support! > > > > Thanks > > > > Regards =E2=80=A6 Zafar > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Tuesday, November 3, 2020 at 12:41 PM > *To: *"spring@ietf.org" > *Cc: *"spring-chairs@ietf.org" > *Subject: *[spring] WG Adoption Call for draft-li-spring-srv6-path-segmen= t > > > > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending > November 24th 2020. Please note that this document has several changes > from v-06 that were requested by the SPRING chairs. For this reason, the > chairs have extended the adoption call for an additional week to allow th= e > WG enough time to review these changes before deciding on WG adoption. > > > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a0701905b3de40d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    I support WG adoption. =C2=A0

    Thanks=C2=A0
    =
    Gyan

    <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 9, 2020 at 11:39 AM Zafar = Ali (zali) <zali=3D40cisco= .com@dmarc.ietf.org> wrote:

    Support!

    =C2=A0

    Thanks

    =C2=A0

    Regards =E2=80=A6 Zafar

    =C2=A0

    From: = spring <spring-bounces@ietf.org<= /a>> on behalf of James Guichard <james.n.guichard@futurewei.com>
    Date: Tuesday, November 3, 2020 at 12:41 PM
    To: "sprin= g@ietf.org" <spring@ietf.org>
    Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-seg= ment

    =C2=A0

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-s= egment-07, ending November 24th 2020. Please note that this = document has several changes from v-06 that were requested by the SPRING chairs. For this reason, the chairs have extended the adopti= on call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.

    =C2=A0

    After review of the document pl= ease indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that s= upport (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel=

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --000000000000a0701905b3de40d9-- From nobody Wed Nov 11 16:50:52 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DDB3A127F; Wed, 11 Nov 2020 16:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 uktwQ4zKCALA; Wed, 11 Nov 2020 16:50:49 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 599973A125D; Wed, 11 Nov 2020 16:50:49 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id s2so1881804plr.9; Wed, 11 Nov 2020 16:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eykGwpS+TRjO7Pdkfszb6pB875xDPkHRi+iXN7C6KPw=; b=qv4BhmPboz8WMkpsw/Zj0OMTYOHow7Ykb06/M0gqzbzOci+BCBX0QYa5symgZqfJoi nDN5vD6QXxfV21HaqvNiZBn40GlRloryQCYm75yyrNwDxkteFr4DnoP7a2l8OC+Pc2rj 86wp1H765qTU+a7T/h6WW2Tq3cP+Gsf6ujET8sujJSZmJpVyvkBaaBJcatw62yHokibA TEiVi6YTLZ5s5MgPE9J+lFEd2gkwk9CfR/riedfmYfGtNuzCvBjxeXigbWEzo32B4bn0 2GCf2Z37BCDdT+PzJn55Xw9UAZomK+1NP5ItkGKey/d7dyFh7+pOTCIcSLos6zcLdBhv 6GaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eykGwpS+TRjO7Pdkfszb6pB875xDPkHRi+iXN7C6KPw=; b=IlFZx5hQk59mKxzibDE37xJ37N2zuSeZ36cMRjPZ1NFQysW9X7iBT6yqpVZ+8rOAin 76AOJFb+IRZ7+BjjKdr0yz02liAu4pdo/fa8OdvMyqMXNdYIO8jbz5fepkDhqC8Cqj1Z q/RWmWmg2CkDOLDF4uMMvOGgc7iUUUq6jSN5QEyKqyOUb+PrhqQDcRyVm/y3I1DQiDLH 9dg/DJUcd4GccyOa7Ju5UkqDFZco6qLkmaZOjkDjQsH9GMtwffItlDI+5exAfA2sTzsM oeTrNCP8GEDndW3/0oZrAIGuyGvMc5LYodIknBJGbXZihe7Gp3cJB1Up3iC2NP6kMrsm 1u8A== X-Gm-Message-State: AOAM531G28Bx8LyFqBYUi49We2ObLjGimGsiRLxyDspXpSa978Si4pvP stH7SBReNS06SKj3hjPV+XlaoS/MWoMt+RpLi84gJkNy8F/ndQ== X-Google-Smtp-Source: ABdhPJyfqcrC8zfUIyO7lODVS6ZZaQ0/OYvYizBfi6yqmSEkub3lxKZWXH1U4TyO05swCAo8o2ql9Bf/fYAqkBzh72M= X-Received: by 2002:a17:902:6a84:b029:d8:c8a9:e04d with SMTP id n4-20020a1709026a84b02900d8c8a9e04dmr725166plk.74.1605142248715; Wed, 11 Nov 2020 16:50:48 -0800 (PST) MIME-Version: 1.0 References: <038360BF-72E4-4777-BA0B-B0E4F0316156@cisco.com> In-Reply-To: <038360BF-72E4-4777-BA0B-B0E4F0316156@cisco.com> From: Gyan Mishra Date: Wed, 11 Nov 2020 19:50:38 -0500 Message-ID: To: "Zafar Ali (zali)" Cc: James Guichard , "Zafar Ali (zali)" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008c7a4305b3de4d4d" Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 00:50:51 -0000 --0000000000008c7a4305b3de4d4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support WG adoption. Thanks Gyan On Tue, Oct 27, 2020 at 9:46 AM Zafar Ali (zali) wrote: > Support! > > > > Thanks > > > > Regards =E2=80=A6 Zafar > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Thursday, October 22, 2020 at 8:52 AM > *To: *"spring@ietf.org" > *Cc: *"ippm-chairs@ietf.org" , " > spring-chairs@ietf.org" > *Subject: *[spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 > > > > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending > November 12th 2020. Please note that this document has several changes > from v-02 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for STAMP > Messages*, *Loss Measurement Query Message Extensions*, *Loss > Measurement Response Message Extensions*, *Node Address TLV Extensions= *, > and *Return Path TLV Extensions* were included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and > should be removed from the SPRING document. > - The STAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000008c7a4305b3de4d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    I support WG adoption.

    Thanks=C2=A0
    GIM&= gt;> Whether STAMP test session is in authenticated or unauthenticated m= ode is the matter of configuration (as it is for TWAMP). You can check the = ST= AMP YANG data model draft=C2=A0and TWAMP YANG data model=C2=A0(the la= tter could be useful for *-twamp-srpm drafts).
    As for distinguish= ed of two concurrent sessions between a pair of nodes, in STAMP one can tak= e advantage of the STAMP Session Identifier (SSID) that is defined in Secti= on 3 of draft-ietf-ippm-stamp-option-tlv. If there is only one session, the= n, in my view, the configuration of the STAMP session's mode should suf= fice. Would you agree?
    =

    =

    • Section 4.2.1 refers to Sender Control Code (though it is defined in=C2=A0d= raft-gandhi-ippm-stamp-srpm. Could you explain why it is important to infor= m the Session-Reflector that the reflected test packet be sent out-of-band?= What if only in-band return path is available? Would the Session-Reflector discard test packets in such situat= ion?

    <RG00> Ou= t-of-band is the current behaviour and there is no change in the existing b= ehaviour. We can clarify in the next revision.

    =
    GIM>> I'm confused. An active measu= rement protocol cannot be out-of-band, otherwise, the measured metrics are = meaningless. Thus, an implementation of STAMP must ensure that the test pac= ket is in-band with the monitored flow. So, when you're saying "th= ere is no change in the existing behavior" are you referring to the be= havior of STAMP or to something else? If your intention to use the new prot= ocol out-of-band, that clearly will be a change of STAMP behavior.

    • I got confused by the following in Section 4.2.2

    =C2=A0 =C2=A0In two-way measurement mode, when using= a bidirectional path, the
    =C2=A0 =C2=A0probe response message as defined in Figure 6 is sent back to = the
    =C2=A0 =C2=A0sender node on the congruent path of the data traffic on the s= ame
    =C2=A0 =C2=A0reverse direction Link or associated reverse SR Policy
    =C2=A0 =C2=A0[I-D.ietf-pce-sr-bidir-path].

    If a Path Segment SID associated with the test sessi= on, there seems no need to require the Session-Reflector look for in-band p= ath. Would you agree?

    =C2=A0

    <RG> No. = Existence of Path Segment ID does not mean in-band reply. It may be needed = for RX counter for direct-mode loss measurement.

    GIM>> Can you please clarify the use = case for using the Path Segment SID in the test packet? The text, as quoted= , gives the impression that it is needed for "the probe response messa= ge as defined in Figure 6 is sent back to the sender node on the congruent = path of the data traffic on the same reverse direction Link or associated r= everse SR Policy." I cannot find any text that explains how the Segmen= t Path SID in the test packet may be used by "RX counter for direct-mo= de loss measurement".


    Gyan

    On Tue, Oct 27, 2020 at 9:46 AM Zafar Ali (za= li) <zali=3D40cisco.com@dm= arc.ietf.org> wrote:

    Support!

    =C2=A0

    Thanks

    =C2=A0

    Regards =E2=80=A6 Zafar

    =C2=A0

    From= : spring <spring-bounces@ietf.= org> on behalf of James Guichard <james.n.guichard@futurewei.com>=
    Date: Thursday, October 22, 2020 at 8:52 AM
    To: "sprin= g@ietf.org" <spring@ietf.org>
    Cc: "= ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "spring-chairs@ietf.org" <= ;spring-chairs@= ietf.org>
    Subject: [spring] WG Adoption Call for https://tool= s.ietf.org/html/draft-gandhi-spring-stamp-srpm-03    <= /p>

    =C2=A0

    Dear WG:

    =C2=A0

    This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending N= ovember 12th 2020. Please note that this document has several ch= anges from v-02 that were requested by the SPRING and IPPM chairs. For this= reason, the chairs have extended the adoption call for an additional week to allow the WG enough time to re= view these changes before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0

    =C2=A0

    Several review comments were received previously for= document https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm= -02. The SPRING and IPPM chairs considered those comments, = and upon review of this version of the document, determined the following:<= /span>

    =C2=A0

    • The SPRING document should describe only the proce= dures relevant to SPRING with pointers to non-SPRING document/s that define= any extensions. Several extensions including Control Code Field Extension fo= r STAMP Messages,=C2=A0Loss Measurement Query Message Extensions,=C2=A0Loss Measurement Respons= e Message Extensions,=C2=A0Node Address TLV Extensions, and=C2= =A0Return Path TLV Extensions were inclu= ded in https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 and should be removed from the SPRING document.
    • The STAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 should be described in a new document published in the= IPPM WG. =C2=A0

    =C2=A0

    These conclusions were discusse= d with the authors of https://tools.ietf.org/html/draft-gandhi-spring-sta= mp-srpm-02 the result of which is the publication of the following two = documents:

    =C2=A0

    =C2=A0

    After review of the SPRING docu= ment please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack= thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like to thank the au= thors for their efforts in this matter.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --0000000000008c7a4305b3de4d4d-- From nobody Wed Nov 11 19:59:28 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04443A1391; Wed, 11 Nov 2020 19:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=DCp3u2zj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QCq2F4/k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQCSmROBsCYL; Wed, 11 Nov 2020 19:59:24 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8373A1390; Wed, 11 Nov 2020 19:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21774; q=dns/txt; s=iport; t=1605153564; x=1606363164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sIVtJtm7ZpFeNLSrFCyVkDFlxrsrA238ktB4GAB3tMI=; b=DCp3u2zjmtYQ0uPXonJFki/TUeRpxPdUnQIPe+h8JH6yyvZ4lN9Ttj9i J0pMlNib927qIQHi1xRyXmDJJnoPqWxZKEytjZcZOncLivEPMVztLCHHS jB+Pc7mIKLpZ/uTIVZmGlYdwwqwQFKfm5gnlIjgOrBZpQ7gtm91mSeCuJ U=; X-IPAS-Result: =?us-ascii?q?A0BhCgDZsqxf/4sNJK1iHgEBCxIMQIJyL1EHdFkvLgqHf?= =?us-ascii?q?AONVZkDgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIWAiU4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEcYVhDIVyAQEBBBILIwEBLAsBDwIBCBEDAQEBIQcHMhQJCAEBB?= =?us-ascii?q?AENBQgagwWBflcDLgEOpQcCgTyIaHSBNIMEAQEFgTcCg10YghADBoE4gnOKT?= =?us-ascii?q?BuBQT+BEUOCTz6CXQEBA4EiIBweDQmDFIIsmwOLWTWQG4EDCoJtiQ+SJ4IGg?= =?us-ascii?q?ROKFYhci22GHo0zinyVUwIEAgQFAg4BAQWBayOBV3AVO4JpUBcCDY4fNxiDI?= =?us-ascii?q?oUUhUR0AjYCBgoBAQMJfIw7AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AJToTCBHrfGHLp9tSoHQ6pZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbXZjS9P9FzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX+elTNr3z05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,471,1596499200"; d="scan'208,217";a="579106574" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2020 03:59:19 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AC3xIrK014188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2020 03:59:19 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 21:59:18 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 21:59:17 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 21:59:17 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mBwbal+7OHZocMndcmuuyn9y4ksXivpPrrCW75N5nW+iVkNTHEn0qSgJbRhRB3t9KQzEhNfqEp85BmumdJImBnu2O98gDjV08iTqNF0jBLIVa52Ijo+AoKf46hxN7daWAvT5U+prDxNyC39HW0xTkWsl6trZJ8ZRnF1AO21C2LoCxypjXgKh86m1EQBDPKdXb+X5CZoK/gila6Sy6rk5dKOVvTX6zrhwwaklT2QTHOW6v7ncELqo5yYq6Kh7kDmM/H/COUwsK2x5pRm3NxhEaqHhozBpHi1k8xZ24ZdsBhaX/L0Y6+PgHyKDE2tOVlepNoFTAa4ref0S+UhwNHj+Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o6bmN/3h+AGUDX9syy5BhR5LfzLJpHJPKmrMpfrN4Wo=; b=EJON0MJ+P7GOjouKFJo0VN9WlS3cXUBATfMmJKZf5DTz5i2uuYcW+xvJjcnD9sYbDQ1c/90rqBFwXeBqgJOwSsaInrYfseUgcyqojHIPirUN0xuIH8JUJU5drk0WpOCGidX4YQGKxR4DXKSkXvBJiRXIBhSjCLlWXH3gC5Lq8uHt8mk1wApBo/KocmieMGkeJLecbEw/JG3wFQcUTM1bXy/jT7GTbssQwNToyOJ54wokdzhVnRWnAyEoVExI132PzGe/hkkSbGERJjceKFBmKuOT5Fd2yubJAx2o+P6PiT2Kne7vcyngfUUOWUqWd7SJHQ0Iyn+aJrXWv2WRaUuCMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o6bmN/3h+AGUDX9syy5BhR5LfzLJpHJPKmrMpfrN4Wo=; b=QCq2F4/kXI3tepWf680+y0jy0rIUrWS7noNHTz29x6iSN90u+ZxvIu766N8fKSPJ7+ZVl9X9+Ciy9nvp7XuaOdt8um6lMHRrtuFKcvKKQYo6aIIsEqi/HfVGtX/H6f7YDMRgoCujiN6U1FPEqAWS0z+zzTAWdJx2pi+gnFj8grE= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2617.namprd11.prod.outlook.com (2603:10b6:5:ce::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 03:59:16 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::fdb2:fd4d:1b43:7b36%7]) with mapi id 15.20.3541.024; Thu, 12 Nov 2020 03:59:16 +0000 From: "Rakesh Gandhi (rgandhi)" To: "Xiejingrong (Jingrong)" , James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: Adaobz3858vbu82jQ/ClUjOYTy5CmQIdDJrwAfEmzMs= Date: Thu, 12 Nov 2020 03:59:16 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90c7465d-0e5b-469c-b517-08d886bf5341 x-ms-traffictypediagnostic: DM6PR11MB2617: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2ZmW7H2+sG3H/rNC1KzxJ8AeZwD58YzNv50Xk/jHudtnMr8X0WbJZa23y/ibFqwu00rLM2uUpV0iDUEfNuNllbtOv7ON9NgUm7zl0VW8ZkwkH9H2xl3EB1VAszHPG6eBAxlz/JThT3bjm66BZgT4yZpFdU7Tu+AB/C0AclcTXRSriRR13TYompiqT2aUOTWwTIpZGm1jsGZEs5nl0lpGOR67BWM7+LL/jicW09b/jBaVFe4Tx/V6LssH1l3bbPMWdCthysFE7elJ5QvR91vB6yaYnsHsq6b5CrBqIed/6lSZ+LItF7xgvVJULVDN5YZ3u4XBJjWlO6ksHs+hCm6iEu3eBjKkGlo3KMVjz2RWRivVuKjjSubp7bnYsyR3128+6nUKP6p8WYQDRINzPbTH1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(366004)(39860400002)(396003)(66556008)(53546011)(9686003)(7696005)(2906002)(86362001)(110136005)(52536014)(316002)(5660300002)(26005)(83380400001)(966005)(71200400001)(54906003)(478600001)(186003)(66476007)(64756008)(55016002)(4326008)(66446008)(8936002)(91956017)(6506007)(9326002)(76116006)(66946007)(33656002)(166002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wKgdvNed6e2Jkp1wC2w+XShdZW7IM2fQNifCdtmcX+r6LvCsNpBz5M2Io9JetlMbrXeYhUT0B5aUfr3hBoVG6arzNO9O+hJUsF7nb8W3tXBo7L1ZjxWhe35riBy6/n1u9PeKKcbV4ivygxaNTGf2vXrnokWsVh1iNFfeSMi38NkiI06ra6L/qczU4IjSI1JBGstD+RQ+HF76Ath6iJtVsqkACqlUVa9e4m7Sv+3bgbwuONBjz4j6b/LldXyhJyNJA63vTME0+A/XOWTcSNz3s0Lr5NleGrqhOjwzY15kzro5x/gU/vTvejz62X1UJjh0/7K3gYqI58MAR7ji6HEjtXJSb7yZhI6PAt84Hj9h2YkB8m1m5u1jjq51qjUnEW0zeK3JuF3FWGTA2JKSpeEMu3Xshz11TUKlqdm5XRlEy5UkwmcFuqz082YnUGkkMctTT62hOVQ6pBP6fwa8JZlKlN/Mr4NrjtcVBI4fIsM9fs/GXj4P0QPWH0r0+xC2aglw6FqzQo/250dsMWq0Nb5vdCcczZzk+WGJ/BeFF0q88N9II8mC7E3xO7rBBBd+KPHtKNv4SbI8D4t31qM3rabbT4ey/4fZNCuwD/xy0m3jOzP54iOzM+J5XEj4pKu3DlEgk/ChO2Nws1LTakAHVPNSnZ+X2kwH/LN9H+Hs2Ut5XF8eCvZ0IC6OX2Uo/ICQiQ7y/IzUbNJaFK08vqtQgBex54nLcGNPuVvnnWEGid+s1NF/YjOeCBrDSDnCN6Mri6KjB1kg9ezQjQRbZ5IDDK0Ghd9YETw+c524U6I5aIwip1qq4FBz/F1+6wWXHG8Ws6izkEHoTWc9v35SVw065ppinJKdeeA2XEPZWTacvM7VwVWuUyz+eki85Jqk36AVCtqZzQe8kKNcn7ZF8T24WMeVCw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB311521A9BC78B6AC2AAA39C0BFE70DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90c7465d-0e5b-469c-b517-08d886bf5341 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 03:59:16.5896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 98bWr+aKTfzHaCoV9M/zZIc73BohIKJaU6Md1gxXHEHyk+RqIkCH0GanVk7LcRJW/2n1S+zqBQwgfsNhosFJzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2617 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 03:59:27 -0000 --_000_DM6PR11MB311521A9BC78B6AC2AAA39C0BFE70DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jingrong, Many thanks for your review comments. We will address them in the next upda= tes of the document. Thanks, Rakesh From: spring Date: Monday, November 2, 2020 at 2:04 AM To: James Guichard , spring@ietf.org Cc: ippm-chairs@ietf.org , spring-chairs@ietf.org Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draf= t-gandhi-spring-twamp-srpm-11 Hi working-group: I support the adoption, and I have the following questions: 1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word =93as nee= ded=94 for inner IP Header. Can authors please clarify in which case(s) it= is needed and in which it is not. 2. Section 4.3.1 =93Destination ipv6 address from the ::FFFF:127/104 range= =94, and Section 4.1.4 =93the loopback address ::1/128 for IPv6=94, are the= y different cases or same case ? Thanks Jingrong From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Thursday, October 22, 2020 8:52 PM To: spring@ietf.org Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-11 Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel --_000_DM6PR11MB311521A9BC78B6AC2AAA39C0BFE70DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable --_000_DM6PR11MB311521A9BC78B6AC2AAA39C0BFE70DM6PR11MB3115namp_-- From nobody Wed Nov 11 20:45:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DE93A13E2 for ; Wed, 11 Nov 2020 20:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=aIqX48d3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S6uFSKR0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZljIuEjMBpF1 for ; Wed, 11 Nov 2020 20:45:10 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF9E3A13E1 for ; Wed, 11 Nov 2020 20:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129822; q=dns/txt; s=iport; t=1605156309; x=1606365909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FqJt3KHMVuLz0rR3iYlJ5YMlx4GUIfrYFbcgP6JCfmQ=; b=aIqX48d3JDODTr6kG1/GRDLR9qL3dZRyg6yVvmatyERAL3lPIti/6Mpk a4mA0r61mlemjwPeJjNc098n+NxkataUKL+ezVtH9HcvRXPVYqvIXW2En 8mTXB8DzkGxhbemtGTel2f18dJjK+nBmpb2IorKbVUMfzFgLcPcnan9yh g=; X-IPAS-Result: =?us-ascii?q?A0CCBwBpvaxffYQNJK1iHQEBAQEJARIBBQUBgg+BIy8jL?= =?us-ascii?q?ntZLy4KhDODSQONVYoWjm2BQoERA08FCwEBAQ0BARgBDAgCBAEBhAZEAheBf?= =?us-ascii?q?wIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYYPAQclDIVyAQEBBAEBEAgBC?= =?us-ascii?q?AoTAQEjCQsBCwQCAQgRAQIBAQEhAQYDAgICHwYLFAMGCAIEAQ0FCBqDBYF+V?= =?us-ascii?q?wMuAQ6lBwKBPIhodoEygwQBAQWBMwEDAg5BgwwNC4IQCYE4gnOCZU5CgQaBP?= =?us-ascii?q?oQTG4FBP4ERQ4JPPoIbQgEBAgEBFYEAEQESASMFBxINCQIGglkzgiyQLRmDI?= =?us-ascii?q?IcdjA6QSlQKgm2JD4xyhTWDGYEqiGuBLZBogjSTUYF/iH2Cbo4xhDQCBAIEB?= =?us-ascii?q?QIOAQEFgUEqIWlwcBUaIYI1AQEyCUcXAg2BNIZIhggbDBeDToUUhUR0AjYCB?= =?us-ascii?q?gEJAQEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AhU8GgRC+Gfc4tbctR3i7UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3PWoba4rRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGHsH9ZlSUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,471,1596499200"; d="scan'208,217";a="606079159" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2020 04:45:06 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AC4j2hB005280 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2020 04:45:05 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 22:45:01 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 23:45:01 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 23:45:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hkKoswvgAFqskM3EtpJfJ1A8y38+h9lxvWv0HsKGfPuS+99IgqRLDrtur/vuo/1vcPOdrQRj+0owjWKXjZYDqyP+JADwoDZtljLb63l30mt00yJsIuJ931q7xDs0vTMkfnYF0dtGcOkgJE0BbhpXQ6XLIHvkVMAsHsJsxgqlbwIpK9Jnxv+NKeRRpDmxAdSsoO+rBVyhGi3c3LXxaToIEfbDzlSnq9Djeh5wQ0ICcgz0dBIgz1YdoqDhDMRdmyiOVxaN8aXO5Eg/YPpoZPU6+qAduuW239bB15jOo3IPQ3kURVxYiGf72ArxD3dqorREdUlM0mGDdBdhGTGZRWCMvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FqJt3KHMVuLz0rR3iYlJ5YMlx4GUIfrYFbcgP6JCfmQ=; b=Nm6kH500whWxNLreaKTg7cJ5Td/ISi+4DSO1qia3I3knMqkJCLRj4zanCJeiGKLBWtMKnQA9/PUKswn9Kn/gxlD0fhZLVorf8WIAH7gbSRlFt77MTul2tF85en0HAxX05Ui8X7ry6ZT8DyR325OX89fbK3kuIVFtLIhwPbANSbR3hlGVEUUkJsyfYtFiVQ6ehMFFLPzOSTqDqeAg/oelUZIrgpsD82MQciUmwmfub+2vQP6g636lfgnx+jSqM6yGSzs9JRm+W+vIfxRyKcL5xVy47KMlsTOC1Nsv7x5fjvZNkf6Qo78fFbRXZ7wEFUQjWE/IVa7Tw8CsOsQDVCvxGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FqJt3KHMVuLz0rR3iYlJ5YMlx4GUIfrYFbcgP6JCfmQ=; b=S6uFSKR0bjEkhcvumFs8CRiTM0Y94fMZ88fDtGxUiuMEcMM+oZ/+cBpe9/4yb2oIu+N2pfsEAkRnSO/UQIdOe9rYh+uCrnO0kyviNmEGUWzs5Z/NR6Vu5hWFQaAq+ygk10UWNVqyd3cPwO40teGKDDptj9OWr99sDgHH9Fca9TA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1344.namprd11.prod.outlook.com (2603:10b6:300:23::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 04:44:59 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 04:44:59 +0000 From: "Ketan Talaulikar (ketant)" To: "Stone, Andrew (Nokia - CA/Ottawa)" , "Vishnu Pavan Beeram" CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAwoDICAAP2ogIAAmcsAgACMyMCAAU4HgIAAWSNw Date: Thu, 12 Nov 2020 04:44:58 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> In-Reply-To: <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1199aacc-a802-466a-76b0-08d886c5b5de x-ms-traffictypediagnostic: MWHPR11MB1344: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e/WfjTizdC5S77214j8Wp/sjHPeY503CtP2xUl3bikJvEZt4NSRWchm3uMO5f7aEJ0gTnFbPRvZgFD7AdfpJ8lyuPR2X9My9SWwPyYkETVE+NlO+qZMeCm4ERhbs4IssSstANzRb7dNHN/Da4nrD4OKrR3c7IBgTVFmJScxZC83/HFD8uGnlAD03n0wOBE9UbeP+h5BAqn24g1POYHboPYP6LU0mwWleYjp2Q5vpUUF0DgyNbNnI9v2oNfUN1061W1rl8z7kujeN4/F1/Ddj/dAZK43gfNVi9zBBOLSlMf2EM1lLN89S+sFdvEQinI5r4FSCu14MdekGFyRX0tkETBJmenN6QipPe9MDWlpRPXeY+nWm6A14Pgd39/PKpPCYDicwnYL7ekPbST+XMZ1n1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(376002)(366004)(136003)(346002)(26005)(7696005)(5660300002)(110136005)(16350225007)(86362001)(2906002)(316002)(296002)(55016002)(966005)(478600001)(52536014)(30864003)(8676002)(186003)(8936002)(66574015)(166002)(76116006)(53546011)(66556008)(66946007)(66476007)(64756008)(71200400001)(6506007)(83380400001)(9326002)(66446008)(9686003)(33656002)(4326008)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KnQdTW5J+42AA5ptEVN/VBzOc7TMNbryBgiC+dHcNOL6YBnpFSOFzu5hr1pwI5e6nyDqFmXWWMB91cj2LHpDSDYZ/4E0NhB3/gSsM5JKiueNvQtTUAbxgG42te612F+/ofL8hKigEY4B3JAKgzahUDgdJuU520ZSJCKOVJhf5XJ4T7qyY6iKIKPbniR4UiuCTyBxzftqCbqnae44txIEiF7O8sQhiaVJAd5uAoTtHvp+IGuu85VTx8oQi1M04ZhBSqumHSLClfWHX0X9KniedfwF/iBRB522wBTAxzO8flnX3wgPqYBvkdozgWCLlYX9dBGrYBMEIG1Fl3ub1Ev0ZIdyAMu83hasusnfjF8x+p74Aqe6yfLJdmUQUDTAquWE0N2GQuS3rov9WuN/aptUlKdNRungL6yJIL34u8dsrYm/M3UCBFkhmnk1UuPTwXVC3VXnCkVDS07gAup1z1f7u0Z99+gnEZ6O+qc0kzE5jVbWCGuk4kUUubLUKhuKrb7pii6+lyOKigoZupwOgcQl5j17dgcT4GN6QDE5iw/zTelcE5FJL0AUfumV0TfNlFUsJQGhJOGVFqb7Y9UV6hURuaog+sRLU3RV8JxG615Q6WQQELYQKgx6Fe9/ZqbV/L3M3NGzosZvw6i7KI+Bk9iz6/8TjYTRx1Sm6dH384Y99LEnO2mhokjkk1HGJDU6ELYzd2J8N3VoPYoA8D/ApAVZHMp/6nY4vWyGDj6SJ8ZEkR8FVH1U7deyD25aTz0oKL7UKq4JAk0zFFS++kpGqoh0DhVsz1U5wyNIUnw7+aQABbc2vdj22mzhP/SWKuzw1bo9KkHILR7KcMTYUsvteqa68BaE1M6+poPaZJ2wDRG3s7lykPZv9OPAaY165Htwx9qDgsByvp9D2kINITzS3qizXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570654EEDA8BC76AC8AC3B6C1E70MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1199aacc-a802-466a-76b0-08d886c5b5de X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 04:44:58.9037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qQfvxk7mzqLPggX92H8hIh8gmozDLMl0QjUYh1KWI0yefQoewTa8oXGMmlGDNMJVHvZZs6b3Zd2eJcBJKhPa6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1344 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 04:45:14 -0000 --_000_MW3PR11MB4570654EEDA8BC76AC8AC3B6C1E70MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3LA0KDQpUaGFua3MgZm9yIHlvdXIgaW5wdXRzIGFuZCBmZWVkYmFjay4gUGxlYXNl IGNoZWNrIGlubGluZSBiZWxvdy4NCg0KRnJvbTogU3RvbmUsIEFuZHJldyAoTm9raWEgLSBDQS9P dHRhd2EpIDxhbmRyZXcuc3RvbmVAbm9raWEuY29tPg0KU2VudDogMTIgTm92ZW1iZXIgMjAyMCAw NDo0Ng0KVG86IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb20+OyBW aXNobnUgUGF2YW4gQmVlcmFtIDx2aXNobnVwYXZhbkBnbWFpbC5jb20+DQpDYzogc3ByaW5nQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0KSGkgS2V0YW4sIFBhdmFuLA0KDQpH b29kIGRpc2N1c3Npb24uIEp1c3QgZ29pbmcgdG8gY2hpcCBpbiBzb21lIHRob3VnaHRz4oCmDQoN Ck9uZSBvZiB0aGUgZWxlbWVudHMgSSBwZXJzb25hbGx5IGxpa2Ugb2YgdGhlIFNSIFBvbGljeSBt b2RlbCBpcyB0aGF0IG1hbnkgQ2FuZGlkYXRlIFBhdGhzIG1heSBleGlzdCwgYnV0IG9ubHkgb25l IG1heSBiZSBhY3RpdmUgYW5kIGEgY2FuZGlkYXRlIHBhdGggY29udGFpbnMgMSBvciBtYW55IFNJ RCBsaXN0cy4gSXTigJlzIGEgc2ltcGxlIHBhcmVudC9jaGlsZCAtIHJvb3QvbGVhZiB0cmVlIHdp dGggdmVyeSBjbGVhciBydWxlcyB3aXRoaW4gdGhlIFNSIHBvbGljeSBjb250ZXh0IGluc3RhbmNl LiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHdoYXQgaXMgYmVpbmcgcHJvcG9zZWQgaW4gdGhlIC0w OSBkb2N1bWVudCBzdGlsbCBmb2xsb3dzIHRob3NlIHJ1bGVzIGFuZCB0aGUgZ2VuZXJhbCB0b3At ZG93biB0cmVlIGJlaGF2aW91ci4gRGVzcGl0ZSB0aGUgY29tcG9zaXRlIENQIHBvaW50aW5nIHRv IGEgZGlmZmVyZW50IFNSIFBvbGljeSwgdGhhdCBTUiBQb2xpY3kgc3RpbGwgZm9sbG93cyBhbGwg b2YgdGhlIHNhbWUgcnVsZXMgdG9wIGRvd24gaW4gaXRzIG93biBpc29sYXRlZCBjb250ZXh0LiBD b21wYXJlIHRoYXQgdG8gc2F5LCBoYXZpbmcgYSBjYW5kaWRhdGUgcGF0aCBjb250YWluIGEgY2hp bGQgdGhhdCBwb2ludHMgdG8gb3RoZXIgY2FuZGlkYXRlIHBhdGhzIHdpdGhpbiB0aGUgc2FtZSBT UiBQb2xpY3kgY29udGV4dDogd2l0aGluIHRoZSBzYW1lIGNvbnRleHQgYSBjaGlsZCBpcyBwb2lu dGluZyB0byBhIHNpYmxpbmcgb2YgaXRzIHBhcmVudC4gVGhlIHJ1bGVzIG5vdyBoYXZlIHRvIGJl bmQgc2xpZ2h0bHkuIEFzIG5vdGVkIGJlbG93LCBzb21lIG9mIHRoZSBydWxlcyBhcm91bmQgd2hh dCBpcyBjb25zaWRlcmVkIGFuIGFjdGl2ZSBjYW5kaWRhdGUgcGF0aCB3b3VsZCBuZWVkIHRvIGNo YW5nZSwgc2luY2UgdGhlIGNvbnN0aXR1ZW50cyBlc3NlbnRpYWxseSBhcmUgYWN0aXZlICh0aGV5 4oCZcmUgaW5zdGFsbGVkKSBkZXNwaXRlIG5vdCBiZWluZyB0aG91Z2h0IG9mIGFzIGJlaW5nIGFj dGl2ZS4gTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBuZXcgdGV4dCBiZWxvdyBzYXlzIOKAnFRoZSBw cmVmZXJlbmNlIGlzIGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0dWVudCBjYW5k aWRhdGUgcGF0aHMiIHdoaWNoIGlzIGFsc28gYSBuZXcgcnVsZSwgaG93ZXZlciBvbmUgY291bGQg cGVyaGFwcyB3b3JrIGFyb3VuZCB0aGF0IGJ5IGp1c3QgcmVxdWlyaW5nIHRoZSBwcmVmZXJlbmNl IG9uIHRoZSBjb25zdGl0dWVudHMgYmUgbGVzcyBwcmVmZXJyZWQgdGhhbiBhbnkgb3RoZXIgc3Rh bmRhcmQgb3IgY29tcG9zaXRlIENQIOKAkyBidXQgdGhhdCByYWlzZXMgaXRzIG93biB0cm91Ymxl cyB3aXRoIG11bHRpcGxlIHNvdXJjZXMgb2YgcHJvdmlzaW9uaW5nIOKAkyB3aGljaCBsZWFkcyB0 byBhIHJ1bGUgYXNraW5nIHRvIGlnbm9yZSB0aGUgcHJlZmVyZW5jZS4gSW4gc3VtbWFyeSwgZnJv bSBteSBwLm8udiBuZXcgcnVsZXMgaW4gdGhlIGhpZXJhcmNoeSB3b3VsZCBuZWVkIHRvIGJlIGlu dHJvZHVjZWQuDQpbS1RdIEFncmVlIGFuZCB0aGlzIHdvdWxkIGJlIGEgZmFyIG1vcmUgaW50cnVz aXZlIGFuZCBjaGFuZ2UgdG8gdGhlIG1vZGVsLiBUaGF0IHRvbyBmb3IgYSB2ZXJ5IHNwZWNpZmlj IHVzZS1jYXNlIHdoaWxlIHRoZSBjdXJyZW50IHByb3Bvc2FsIHN1cHBvcnRzIG5vdCBqdXN0IHRo YXQgdXNlLWNhc2UgYnV0IG1hbnkgb3RoZXJzIGFzIHdlbGwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5 Lg0KDQpSZWdhcmRpbmcgc3RlZXJpbmcgaW50byBhbiBTUiBQb2xpY3ksIHllcywgeW91IGJ1cm4g Y29sb3JzIGluIGRvaW5nIHRoaXMgKDMyYml0cy4uLikgYW5kIGl0IHdvdWxkIHJlcXVpcmUgZGVw bG95aW5nIGFuIGVudGlyZWx5IGRlZGljYXRlZCBTUiBQb2xpY3kgY29uc3RydWN0LCBhbmQgcnVu IHRoZSByaXNrIG9mIHN0ZWVyaW5nIOKAmG90aGVy4oCZIHRyYWZmaWMgaW50byB0aGF0IHBvbGlj eS4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHdvdWxkIHRoZSBjb21wb3NpdGUgU1IgUG9saWNpZXMg bm90IGJlIGVuZ2luZWVyZWQgaW4gYSB3YXkgd2hlcmUgdGhlIGNvbG9yIGJsb2NrIHVzZWQgaXMg ZGVzaWduZWQgdG8gbm90IGJlIHVzZWQgZWxzZXdoZXJlIGluIHRoZSBuZXR3b3JrIGZvciBvdGhl ciBwdXJwb3Nlcz8gSXMgdGhlcmUgbm90IGEgZGlmZmVyZW50IGJ1dCBraW5kIG9mIHNpbWlsYXIg cHJvYmxlbSB3aXRoIEJpbmRpbmcgU0lEcywgaW4gdGhhdCB0aGV54oCZcmUgZWxpZ2libGUgZm9y IHVzZSBieSBvdGhlciBjb25zdW1lcnMgZXZlbiBpZiBub3QgZGlyZWN0bHkgaW50ZW5kZWQ/IChh bHRob3VnaCBhdCBsZWFzdCBCU0lEcyBhcmUgb3B0aW9uYWwgYW5kIG5vdCBtYW5kYXRvcnkpLiBJ biBhZGRpdGlvbiB0byB0aGUgc3BsaXQgVEUgY2FzZXMsIGJlaW5nIGFibGUgdG8gaGF2ZSBhbiBT UiBQb2xpY3kgc3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBtaWdodCBhbHNvIGhhdmUgc29t ZSB2YWx1ZSBpbiBhIGJhY2t1cCBjYW5kaWRhdGUgc2NlbmFyaW8gd2hlbiBvbmUgaGFzIG11bHRp cGxlIFNSIFBvbGljaWVzIHdpdGggdGhlIHNhbWUgZW5kcG9pbnQsIGJ1dCBjYW4gc2hhcmUgYSBj b21tb24gZmFsbGJhY2svYmVzdCBlZmZvcnQgY2FuZGlkYXRlIHBhdGguIFRoZSBlbnRpdHkgKEkn bSB0aGlua2luZyBQQ0UpIG1hbmFnaW5nIHRoYXQgd291bGQgb25seSBuZWVkIHRvIG1haW50YWlu IHRoZSBmYWxsYmFjay9iZXN0IGVmZm9ydCBDUCBTSUQgbGlzdChzKSwgaW5zdGVhZCBvZiBvbmUg Zm9yIGVhY2ggTiAqIENQcy4NCltLVF0gVGhpcyB3YXMgZXhhY3RseSBvbmUgdGhlIG1haW4gY29u c2lkZXJhdGlvbnMgZm9yIHRoZSBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgY3VycmVudGx5LiBJbiB0 aGF0IGl0IHByb3ZpZGVzIHRoZSBmbGV4aWJpbGl0eSB0byBzdXBwb3J0IG5vdCBqdXN0IHRoZSB2 ZXJ5IHNwZWNpZmljIHVzZS1jYXNlIGZvciBzcGxpdHRpbmcgc2VydmljZSBmbG93cyB3aXRoIGIv dyBncmFudWxhcml0eSBhY3Jvc3MgZGlmZmVyZW50IHBsYW5lcywgYnV0IGl0IGVuYWJsZXMvYWxs b3dzIG90aGVyIHVzZS1jYXNlcyBsaWtlIHdoYXQgeW91IG1lbnRpb24uIFRoZXJlIGlzIGFsc28g dGhlIHVzZS1jYXNlIHdoZXJlIHRoZXJlIGlzIHJlYWxseSBubyBiL3cgY29uc2lkZXJhdGlvbnMg YnV0IHdoZXJlICBTZXJ2aWNlIFIgbmVlZHMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSByZWQtcGxh bmUsIFNlcnZpY2UgQiBuZWVkcyB0byBiZSBzdGVlcmVkIG92ZXIgdGhlIGJsdWUtcGxhbmUgd2hp bGUgU2VydmljZSBBIG5lZWRzIHRvIGJlIGxvYWQtYmFsYW5jZWQgb3ZlciBib3RoIHJlZCBhbmQg Ymx1ZSBwbGFuZXMuIEhlcmUsIHRoZSBjb2xvcmluZyBvbiB0aGUgc2VydmljZSByb3V0ZSB3aWxs IGRpY3RhdGUgd2hldGhlciB0aGUgcGxhbmVzIGFyZSB0byBiZSB1c2VkIGluZGl2aWR1YWxseSBv ciBub3QuIFRoaXMgaXMganVzdCBvbmUgZXhhbXBsZSB1c2UtY2FzZS4NCg0KU29tZXRoaW5nIEkg aGF2ZW7igJl0IGNvbmNsdWRlZCB0byBteXNlbGYgeWV0IGFyZSBxdWVzdGlvbnMgc3VjaCBhczoN Cg0KDQogICogICBkb2VzIGhhdmluZyBhIGNhbmRpZGF0ZSBwYXRoIHN0ZWVyIGludG8gYW5vdGhl ciBTUiBQb2xpY3kgc2F0aXNmeSB0aGUgYWJpbGl0eSB0byBkbyB2YXJpb3VzIHN1Yi1wYXRoIHNw ZWNpZmljIFRFL2NvbnN0cmFpbnQvb2JqZWN0IGNvbWJpbmF0aW9ucyBzdWZmaWNpZW50bHk/DQog ICogICBpcyB0aGUgbW9kZWwgcmVsYXRpdmVseSBzdHJhaWdodCBmb3J3YXJkIHRvIG1hcCBpbnRv IHlhbmcvYmdwL3BjZXAgZXRjLi4/DQpbS1RdIEkgYmVsaWV2ZSB0aGlzIGlzIHN0cmFpZ2h0Zm9y d2FyZCBhbmQgd2UgY2FuIHdvcmsgdGhlc2UgYXNwZWN0cyBvdXQuDQoNCg0KICAqICAgZG9lcyB1 c2luZyBhbiBhZGRpdGlvbmFsIFNSIFBvbGljeSBjcmVhdGUgdG9vIG11Y2ggb3ZlcmhlYWQgb3Ig c3RhdGUgYnVybiB0byBjb25maWd1cmUsIGRlcGxveSwgbWFuYWdlLCB0cmFjayBldGMuLiA/DQpb S1RdIFRoZSB1bml0IG9mIHNpZ25hbGluZyBiZWluZyB0aGUgQ1AsIEkgZG9u4oCZdCB0aGluayB0 aGlzIG1ha2VzIGEgZGlmZmVyZW5jZSBlaXRoZXIgd2F5Lg0KDQpUaGFua3MsDQpLZXRhbg0KDQpD aGVlcnMNCkFuZHJldw0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiS2V0YW4gVGFsYXVs aWthciAoa2V0YW50KSIgPGtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVt YmVyIDEwLCAyMDIwIGF0IDEwOjMzIFBNDQpUbzogVmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51 cGF2YW5AZ21haWwuY29tPG1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20+Pg0KQ2M6ICJzcHJp bmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4iIDxzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0KSGkgUGF2 YW4sDQoNClBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuDQoNCkZyb206IFZpc2hudSBQYXZhbiBC ZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbTxtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29t Pj4NClNlbnQ6IDExIE5vdmVtYmVyIDIwMjAgMDA6MjYNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChr ZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4NCkNjOiBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3By aW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LTA5LnR4dA0KDQpLZXRhbiwgSGkhDQoNClBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNwb25zZXMg KHByZWZpeGVkIFZQQikuDQoNClJlZ2FyZHMsDQotUGF2YW4NCg0KT24gVHVlLCBOb3YgMTAsIDIw MjAgYXQgNDowNCBBTSBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29t PG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBQYXZhbiwNCg0KUGxlYXNlIGNo ZWNrIGlubGluZSBiZWxvdy4NCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2 YW5AZ21haWwuY29tPG1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20+Pg0KU2VudDogMTAgTm92 ZW1iZXIgMjAyMCAwMDowOA0KVG86IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBj aXNjby5jb208bWFpbHRvOmtldGFudEBjaXNjby5jb20+Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCktldGFu LA0KDQpNdWNoIFRoYW5rcyBmb3IgdGFraW5nIGEgc3RhYiBhdCBhZGRyZXNzaW5nIHRoZSBjb21w b3NpdGUgY2FuZGlkYXRlIHBhdGggdXNlLWNhc2UhIFdlIHNlZW0gdG8gYmUgY29udmVyZ2luZy4N CltLVF0gVGhhbmtzIGZvciB0aGF0IGZlZWRiYWNrIGFuZCBjb25maXJtYXRpb24gdGhhdCB0aGUg cHJvcG9zYWwgaW4gdGhlIGRyYWZ0IGRvZXMgYWRkcmVzcyB0aGUgdXNlLWNhc2UuIEkgYmVsaWV2 ZSB3ZSBhcmUgbm93IGRpc2N1c3NpbmcgdGhlIG1lY2hhbmljcyBvZiBob3cgdGhpcyBpcyBhY2hp ZXZlZCB3aXRoaW4gdGhlIGN1cnJlbnQgU1IgUG9saWN5IGZyYW1ld29yay4NCg0KSG93ZXZlciwg SSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHlvdSBuZWVkIHRvIHVzZSBhZGRpdGlvbmFsIFNSIHBv bGljaWVzIChhbmQgdW5uZWNlc3NhcmlseSBidXJuIGFkZGl0aW9uYWwgY29sb3JzKSB0byBhZGRy ZXNzIHRoaXMuDQpbS1RdIEkgZG8gbm90IGZvbGxvdyB3aGF0IHlvdSBtZWFuIGJ5IOKAnGJ1cm4g YWRkaXRpb25hbCBjb2xvcnPigJ0uIENvbG9yIGlzIGp1c3QgYSAzMiBiaXQgbnVtYmVyIHRoYXQg aW5kaWNhdGVzIHRoZSDigJxpbnRlbnTigJ0gYW5kIGlzIG5vdCByZWFsbHkgYSBzY2FyY2UgcmVz b3VyY2UuIEFzc2lnbmluZyBhIGNvbG9yIHRvIOKAnGEgY29tcG9zaXRlIGludGVudOKAnSBzZWVt cyBsaWtlIGEgc2VhbWxlc3Mgd2F5IHRvIGludGVncmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlz bXMgZm9yIFN0ZWVyaW5nIG92ZXIgU1IgUG9saWNpZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmls aXR5IGZvciBzYXkgc29tZSBCR1Agc2VydmljZXMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25z dGl0dWVudCBleHBsaWNpdC9keW5hbWljIGludGVudCB3aGlsZSBvdGhlcnMgY2FuIHN0ZWVyIG92 ZXIgYSBjb21wb3NpdGUgaW50ZW50IHRoYXQgaW5jbHVkZXMgdGhvc2UgaW5kaXZpZHVhbCBleHBs aWNpdC9keW5hbWljIGludGVudHMuDQoNCltWUEJdIFRoZSDigJxmbGV4aWJpbGl0eeKAnSB0aGF0 IHlvdSBhcmUgcmVmZXJyaW5nIHRvIGlzIHVuZGVzaXJhYmxlIGZvciB0aGlzIHVzZS1jYXNlLiBG b3IgdGhlIHRyYWZmaWMtc3BsaXQgdXNlLWNhc2UsIHdlIGRvbuKAmXQgd2FudCBhbnkgb3RoZXIg c2VydmljZXMgdG8gYmUgZGlyZWN0bHkgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudHMgd2hl biB0aGV5IGFyZSBwYXJ0IG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoLg0KW0tUXSBJIGJl bGlldmUgdGhlIHVzZS1jYXNlIHRoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gd2FzIGZvciBzcGxp dHRpbmcgc29tZSB0cmFmZmljIGZvciBhIHNlcnZpY2Ugb3ZlciBhIGJsdWUgcGxhbmUgYW5kIHRo ZSByZXN0IG92ZXIgYSByZWQgcGxhbmUuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXJlIG1heSBiZSBv dGhlciBzZXJ2aWNlcyB0aGF0IHV0aWxpemUgb25seSBhIHNpbmdsZSBwbGFuZS4gVGhlIGZsZXhp YmlsaXR5IHRoYXQgSSB3YXMgcmVmZXJyaW5nIHRvIHdhcyB0byBlbmFibGUvYWxsb3cgZm9yIGVp dGhlciBvZiB0aGUgdHdvIHNjZW5hcmlvcyBhbmQgdGhlcmUgbWF5IGJlIG90aGVyL21vcmUgdXNl LWNhc2VzIGZvciB3aGljaCB3ZSBuZWVkIGEgbW9yZSBnZW5lcmljIGZyYW1ld29yay4NCg0KVGhl IGN1cnJlbnQgcHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgYmVlbiBhY2NlcHRhYmxl IGlmIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyB3ZXJlIHVuY29sb3JlZCDigJMgYnV0IHRo YXQgd291bGQgdmlvbGF0ZSB0aGUgY3VycmVudCBydWxlcyBpbXBvc2VkIGJ5IHRoZSBkcmFmdC4N Cg0KDQpXaHkgY2Fu4oCZdCB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGp1c3QgYmUgYSBn cm91cGluZyBvZiBleHBsaWNpdCBjYW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMgY2FuZGlk YXRlIHBhdGhzPw0KW0tUXSBUaGlzIGlzIGJlY2F1c2UgaW4gdGhlIFNSIFBvbGljeSBmcmFtZXdv cmssIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgYWN0aXZlIENQIOKAkyBpdCBtYXkgYmUgZXhwbGlj aXQgb3IgZHluYW1pYy4gTm93IHdl4oCZdmUgYWRkZWQgYW5vdGhlciBDb21wb3NpdGUgQ1AgdHlw ZSB0byBjb3ZlciB0aGlzIHNwZWNpZmljIHVzZS1jYXNlLiBZb3VyIHByb3Bvc2FsIHdpbGwgcmVz dWx0IGluIDMgY2FuZGlkYXRlIHBhdGhzIGJlaW5nIGFjdGl2ZSB3aXRoaW4gdGhlIHNhbWUgU1Ig UG9saWN5IOKAkyBvbmUgZWFjaCBvZiB0aGUgZXhwbGljaXQgYW5kIGR5bmFtaWMgQ1AgYW5kIHRo ZW4gYWRkaXRpb25hbGx5IHRoZSBDb21wb3NpdGUgQ1AuIFRoaXMgYnJlYWtzIHRoZSBleGlzdGlu ZyBydWxlcyBmb3Igc2VsZWN0aW9uIG9mIENQIGJhc2VkIG9uIHByZWZlcmVuY2UgYW5kIG1lY2hh bmlzbXMgbGlrZSBmYWxsYmFjayBiZXR3ZWVuIENQcy4gV2hpbGUgdGhlIGN1cnJlbnQgcHJvcG9z YWwgaW4gdGhlIGRyYWZ0IHByb3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIG5ldyB1c2UtY2Fz ZSB3aXRoIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBTUiBQb2xpY3kg ZnJhbWV3b3JrLg0KDQpbVlBCXSBUaGUgcHJvcG9zYWwgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMg YmFja3dhcmRzIGNvbXBhdGlibGUgYW5kIGRvZXMgbm90IGludGVuZCB0byBicmVhayBhbnkgZXhp c3RpbmcgcnVsZXMgZm9yIGRlZW1pbmcgYSBjYW5kaWRhdGUgcGF0aCBhY3RpdmUuIEFzIHBlciB0 aGUgcnVsZXMgdGhhdCBhcmUgb3V0bGluZWQgaW4gU2VjdGlvbiAyLjksIG9ubHkgdGhlIGNvbXBv c2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyDigJxhY3RpdmXigJ0gZ2l2ZW4gaXRzIHByZWZlcmVuY2Uu IFRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMgd2lsbCBuZXZlciBiZSBhY3RpdmUgb24g dGhlaXIgb3duLiBJZiBpdCBpcyBuZWNlc3NhcnksIHdlIGNhbiBhZGQgYSBzdGF0ZW1lbnQgaW4g U2VjdGlvbiAyLjkgdG8gZXhwbGljaXRseSBzdGF0ZSB0aGF0IHRoZSBjYW5kaWRhdGUgcGF0aCBz ZWxlY3Rpb24gY3JpdGVyaWEgZG9lcyBub3QgYXBwbHkgdG8gdGhlIGNvbnN0aXR1ZW50IGNhbmRp ZGF0ZSBwYXRocy4NCltLVF0gV2hlbiBhIENQIGlzIOKAnGFjdGl2ZeKAnSBpdCBpcyBhY3R1YWxs eSB0aGUgb25lIHRoYXQgaXMgYmVpbmcgdXNlZCBmb3IgZm9yd2FyZGluZy4NCg0KVGhhbmtzLA0K S2V0YW4NCg0KDQpUaGFua3MsDQpLZXRhbg0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nIGNoYW5n ZXM6DQoNCioqIFNlY3Rpb24gMi4yDQpPTEQ6DQoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBw YXRoIGFjdHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3VwaW5nIG9mIFNSDQoNCiAgIFBvbGljaWVz LiAgVGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBjb25zdHJ1Y3QgZW5hYmxlcyBjb21iaW5h dGlvbg0KDQogICBvZiBTUiBQb2xpY2llcywgZWFjaCB3aXRoIGV4cGxpY2l0IGNhbmRpZGF0ZSBw YXRocyBhbmQvb3IgZHluYW1pYw0KDQogICBjYW5kaWRhdGUgcGF0aHMgd2l0aCBwb3RlbnRpYWxs eSBkaWZmZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXMNCg0KICAgYW5kIGNvbnN0cmFpbnRz LCBmb3IgYSBsb2FkLWJhbGFuY2VkIHN0ZWVyaW5nIG9mIHBhY2tldCBmbG93cyBvdmVyDQoNCiAg IGl0cyBjb25zdGl0dWVudCBTUiBQb2xpY2llcy4gIFRoZSBmb2xsb3dpbmcgY3JpdGVyaWEgYXBw bHkgZm9yDQoNCiAgIGluY2x1c2lvbiBvZiBjb25zdGl0dWVudCBTUiBQb2xpY2llcyB1c2luZyBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aA0KDQogICB1bmRlciBhIHBhcmVudCBTUiBQb2xpY3k6 DQoNCg0KDQogICBvICB0aGUgZW5kcG9pbnRzIG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2ll cyBhbmQgdGhlIHBhcmVudCBTUg0KDQogICAgICBQb2xpY3kgTVVTVCBiZSBpZGVudGljYWwNCg0K DQoNCiAgIG8gIFRoZSBjb2xvcnMgb2YgZWFjaCBvZiB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNp ZXMgYW5kIHRoZSBwYXJlbnQNCg0KICAgICAgU1IgUG9saWN5IE1VU1QgYmUgZGlmZmVyZW50DQoN Cg0KDQogICBvICB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgTVVTVCBOT1QgdXNlIGNvbXBv c2l0ZSBjYW5kaWRhdGUgcGF0aHMNCg0KDQoNCiAgIEVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5 IG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzDQoNCiAgIGFzc29jaWF0ZWQgd2l0aCBh IHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyDQoNCiAgIFNlY3Rpb24g Mi4xMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTE+IGZvciBkZXRhaWxzKS4gIFRoZSBkZWZh dWx0IHdlaWdodCBpcyAxLg0KDQoNCg0KTkVXOg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUg cGF0aCBhY3RzIGFzIGEgY29udGFpbmVyIGZvciBncm91cGluZyBvZg0KDQogICBleHBsaWNpdCBj YW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMgY2FuZGlkYXRlIHBhdGhzIHdpdGgNCg0KICAg cG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVzIGFuZCBjb25zdHJh aW50cy4NCg0KICAgVGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBjb25zdHJ1Y3QgZW5hYmxl cyBsb2FkLWJhbGFuY2VkDQoNCiAgIHN0ZWVyaW5nIG9mIHBhY2tldC1mbG93cyBvdmVyIGEgc2V0 IG9mIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZQ0KDQogICBwYXRocy4gVGhlIGZvbGxvd2luZyBjcml0 ZXJpYSBhcHBseSBmb3IgY29uc3RpdHVlbnQgY2FuZGlkYXRlDQoNCiAgIHBhdGhzIHVuZGVyIGEg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoOg0KDQoNCg0KICAgbyAgdGhlIHByZWZlcmVuY2Ugb2Yg dGhlIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIE1VU1QgYmUNCg0KICAgICAgaWdub3JlZC4N Cg0KDQoNCiAgIG8gIHRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIE5PVCBiZSBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUNCg0KICAgICAgcGF0aA0KDQoNCg0KICAgRWFjaCBjb25zdGl0 dWVudCBjYW5kaWRhdGUgcGF0aCBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcw0KDQog ICBhc3NvY2lhdGVkIHdpdGggYSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChy ZWZlcg0KDQogICBTZWN0aW9uIDIuMTE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkjc2VjdGlvbi0yLjExPiBmb3Ig ZGV0YWlscykuICBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS4NCg0KDQoNCioqDQoNCg0KDQoqKiBT ZWN0aW9uIDIuMTENCg0KDQoNCk9MRDoNCiAgIFdoZW4gYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGggaXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3MNCiAgIHN0ZWVyZWQgaW50byBlYWNo IGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmUNCiAgIHdlaWdo dCBvZiBlYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeS4gIEZ1cnRoZXIgbG9hZCBiYWxhbmNpbmcg b2YNCiAgIGZsb3dzIHN0ZWVyZWQgaW50byBhIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBwZXJm b3JtZWQgYmFzZWQgb24gdGhlDQogICB3ZWlnaHRzIG9mIHRoZSBTZWdtZW50LUxpc3Qgb2YgdGhl IGFjdGl2ZSBjYW5kaWRhdGUgcGF0aCBvZiB0aGF0DQogICBjb25zdGl0dWVudCBTUiBQb2xpY3ku DQoNCg0KDQpORVc6DQogICBXaGVuIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIGFjdGl2 ZSwgdGhlIGZyYWN0aW9uIG9mIGZsb3dzDQogICBzdGVlcmVkIGludG8gZWFjaCBjb25zdGl0dWVu dCBjYW5kaWRhdGUgcGF0aCBpcyBlcXVhbCB0byB0aGUgcmVsYXRpdmUNCiAgIHdlaWdodCBvZiBl YWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLiAgRnVydGhlciBsb2FkIGJhbGFuY2luZyBv Zg0KICAgZmxvd3Mgc3RlZXJlZCBpbnRvIGEgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggaXMg cGVyZm9ybWVkIGJhc2VkIG9uDQogICB0aGUgd2VpZ2h0cyBvZiBlYWNoIGFzc29jaWF0ZWQgU2Vn bWVudC1MaXN0Lg0KDQoNCioqDQoNCg0KDQoqKiBTZWN0aW9uIDIuMTMNCg0KDQoNCk9MRDoNCiAg IFRoZSBpbmZvcm1hdGlvbiBtb2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBv c2l0ZQ0KICAgY2FuZGlkYXRlIHBhdGggaXMgdGhlIGZvbGxvd2luZzoNCg0KICAgU1IgcG9saWN5 IFBPTDEwMCA8aGVhZGVuZCA9IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9pbnQgPSBFMT4NCiAgICAg ICAgQ2FuZGlkYXRlLXBhdGggQ1AxIDxwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9 DQogICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDE+DQogICAgICAgICAgICBQcmVmZXJl bmNlIDIwMA0KICAgICAgICAgICAgV2VpZ2h0IFcxLCBTUiBwb2xpY3kgPGNvbG9yID0gMT4NCiAg ICAgICAgICAgIFdlaWdodCBXMiwgU1IgcG9saWN5IDxjb2xvciA9IDI+DQoNCiAgIFRoZSBjb25z dGl0dWVudCBTUiBQb2xpY2llcyBQT0wxIGFuZCBQT0wyIGhhdmUgaW5mb3JtYXRpb24gbW9kZWwg YXMNCiAgIGRlc2NyaWJlZCBhdCB0aGUgc3RhcnQgb2YgdGhpcyBzZWN0aW9uLiAgVGhleSBhcmUg cmVmZXJlbmNlZCBvbmx5IGJ5DQogICBjb2xvciBpbiB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBw YXRoIHNpbmNlIHRoZWlyIGhlYWRlbmQgYW5kDQogICBlbmRwb2ludCBhcmUgaWRlbnRpY2FsIHRv IHRoZSBQT0wxMDAuICBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUNCiAgIGFjdGl2ZSBj YW5kaWRhdGUgcGF0aCBvZiBQT0wxIGFuZCBQT0wyIGFyZSBpbnN0YWxsZWQgaW4gdGhlDQogICBm b3J3YXJkaW5nLiAgVHJhZmZpYyBzdGVlcmVkIG9uIFBPTDEwMCBpcyBmbG93LWJhc2VkIGhhc2hl ZCBvbiBQT0wxDQogICB3aXRoIGEgcmF0aW8gVzEvKFcxK1cyKS4gIFdpdGhpbiB0aGUgUE9MMSwg dGhlIGZsb3ctYmFzZWQgaGFzaGluZw0KICAgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUgcGVy Zm9ybWVkIGFzIGRlc2NyaWJlZCBlYXJsaWVyIGluIHRoaXMNCiAgIHNlY3Rpb24uDQoNCg0KDQpO RVc6DQogICBUaGUgaW5mb3JtYXRpb24gbW9kZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZpbmcg YSBjb21wb3NpdGUNCiAgIGNhbmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIFNS IHBvbGljeSBQT0wxMDAgPGhlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0gRTE+ DQogICAgICAgIENhbmRpZGF0ZS1wYXRoIENvbXAtQ1AgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBv cmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMT4NCiAgICAgICAg ICAgIFByZWZlcmVuY2UgMjAwDQogICAgICAgICAgICBXZWlnaHQgVzEsIENhbmRpZGF0ZS1wYXRo IENQMQ0KICAgICAgICAgICAgV2VpZ2h0IFcyLCBDYW5kaWRhdGUtcGF0aCBDUDINCiAgICAgICAg Q2FuZGlkYXRlLXBhdGggQ1AxIDxwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQog ICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDI+DQogICAgICAgICAgICAgV2VpZ2h0IFcx MSwgU0lELUxpc3QxIDxTSUQxMS4uLlNJRDFpPg0KICAgICAgICAgICAgIFdlaWdodCBXMTIsIFNJ RC1MaXN0MiA8U0lEMjEuLi5TSUQyaj4NCiAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ1AyIDxwcm90 b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9DQogICAxMDA6MS4xLjEuMSwgZGlzY3JpbWlu YXRvciA9IDM+DQogICAgICAgICAgICAgV2VpZ2h0IFcyMSwgU0lELUxpc3QzIDxTSUQzMS4uLlNJ RDNpPg0KICAgICAgICAgICAgIFdlaWdodCBXMjIsIFNJRC1MaXN0NCA8U0lENDEuLi5TSUQ0aj4N Cg0KICAgQ29tcC1DUCBpcyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB3aXRoIHR3byBjb25z dGl0dWVudHMsIENQMQ0KICAgYW5kIENQMi4gVGhlIHByZWZlcmVuY2UgaXMgaWdub3JlZCBmb3Ig ZWFjaCBvZiB0aGUgdHdvIGNvbnN0aXR1ZW50DQogICBjYW5kaWRhdGUgcGF0aHMuIFRoZSB2YWxp ZCBTZWdtZW50LUxpc3RzIG9mIHRoZSB0d28gY29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBwYXRo cyBhcmUgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nLiBUcmFmZmljIHN0ZWVyZWQNCiAgIG9u IENvbXAtQ1AgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gdG8gQ1AxIGFuZCBDUDIgd2l0aCBhIHJh dGlvIG9mDQogICBXMS8oVzErVzIpIGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGlu IGVhY2ggY29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBwYXRoLCB0aGUgZmxvdy1iYXNlZCBoYXNo aW5nIG92ZXIgaXRzIFNlZ21lbnQtTGlzdHMgYXJlDQogICBwZXJmb3JtZWQgYXMgZGVzY3JpYmVk IGVhcmxpZXIgaW4gdGhpcyBzZWN0aW9uLg0KDQoNCioqDQoNCg0KDQoqKiBTZWN0aW9uIDUuMw0K DQoNCg0KT0xEOg0KICAgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFz IGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50DQogICBTUiBQb2xpY2llcy4NCg0KICAgQSBjb21w b3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZh bGlkDQogICBjb25zdGl0dWVudCBTUiBQb2xpY3kuDQoNCg0KDQpORVc6DQogICBBIGNvbXBvc2l0 ZSBjYW5kaWRhdGUgcGF0aCBpcyBzcGVjaWZpZWQgYXMgYSBncm91cCBvZiBpdHMgY29uc3RpdHVl bnQNCiAgIGNhbmRpZGF0ZSBwYXRocy4NCg0KICAgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg aXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkDQogICBjb25zdGl0dWVudCBj YW5kaWRhdGUgcGF0aC4NCg0KDQoqKg0KDQoNCg0KUmVnYXJkcywNCg0KLVBhdmFuDQoNCg0KDQpP biBTdW4sIE5vdiAxLCAyMDIwIGF0IDc6MDIgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZz4+IHdyb3RlOg0KSGVsbG8gQWxsLA0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGFu IHVwZGF0ZSBmb3IgdGhlIGRyYWZ0IGFuZCBmb2xsb3dpbmcgaXMgdGhlIHN1bW1hcnkgb2YgY2hh bmdlczoNCg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlkYXRlIFBhdGgg Y29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6 IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2ZFcUU1VE93ZGgy dkV5Rm1fTUVqaVh5UDJ3cy8gYW5kIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS8pDQoyKSBCYXNlZCBvbiBvZmZs aW5lIGZlZWRiYWNrIHJlY2VpdmVkLCB1cGRhdGVkIFNSdjYgc2VnbWVudCB0eXBlcyB0byBpbmNs dWRlIG9wdGlvbmFsIFNSdjYgU0lEIGFuZCBiZWhhdmlvciBpbnN0ZWFkIG9mIHRoZSBuZXcgdHlw ZSB0aGF0IHdhcyBpbnRyb2R1Y2VkIGZvciBpdCBpbiB0aGUgdjA4Lg0KMykgQ2xhcmlmaWNhdGlv biBvZiBoYW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBiYXNl ZCBvbiBvZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLg0KNCkgQ2xhcmlmaWNhdGlvbiBvbiBjb25z aWRlcmF0aW9ucyBmb3IgVEktTEZBIGZvciBTUiBQb2xpY3kgYXMgZGlzY3Vzc2VkIGluIHRoZSBX RyAoUmVmIDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvRVYx eXRVc2Q1WmdrTUhETjBJdkZodzlpZDQwLykNCg0KUGxlYXNlIGxldCBrbm93IHlvdXIgY29tbWVu dHMvZmVlZGJhY2suDQoNClRoYW5rcywNCktldGFuIChvbiBiZWhhbGYgb2YgY28tYXV0aG9ycykN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KU2VudDogMDIgTm92ZW1iZXIgMjAyMCAwNjoyNw0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y ZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0KDQpBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTb3VyY2UgUGFj a2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBTZWdtZW50IFJvdXRpbmcgUG9saWN5IEFyY2hpdGVjdHVyZQ0KICAgICAg ICBBdXRob3JzICAgICAgICAgOiBDbGFyZW5jZSBGaWxzZmlscw0KICAgICAgICAgICAgICAgICAg ICAgICAgICBLZXRhbiBUYWxhdWxpa2FyDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmll bCBWb3llcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbGV4IEJvZ2Rhbm92DQogICAgICAg ICAgICAgICAgICAgICAgICAgIFBhdWwgTWF0dGVzDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQogICAgICAg IFBhZ2VzICAgICAgICAgICA6IDM3DQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMjAtMTEt MDENCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5k IG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgZmxvdw0KICAgYWxvbmcgYW55IHBhdGguICBJbnRlcm1l ZGlhdGUgcGVyLWZsb3cgc3RhdGVzIGFyZSBlbGltaW5hdGVkIHRoYW5rcw0KICAgdG8gc291cmNl IHJvdXRpbmcuICBUaGUgaGVhZGVuZCBub2RlIHN0ZWVycyBhIGZsb3cgaW50byBhbiBTUiBQb2xp Y3kuDQogICBUaGUgaGVhZGVyIG9mIGEgcGFja2V0IHN0ZWVyZWQgaW4gYW4gU1IgUG9saWN5IGlz IGF1Z21lbnRlZCB3aXRoIGFuDQogICBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2NpYXRl ZCB3aXRoIHRoYXQgU1IgUG9saWN5LiAgVGhpcw0KICAgZG9jdW1lbnQgZGV0YWlscyB0aGUgY29u Y2VwdHMgb2YgU1IgUG9saWN5IGFuZCBzdGVlcmluZyBpbnRvIGFuIFNSDQogICBQb2xpY3kuDQoN Cg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5Lw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFp bGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5DQoNCkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5LTA5DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90 b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmlu ZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_MW3PR11MB4570654EEDA8BC76AC8AC3B6C1E70MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tSU47fQ0Kc3Bhbi5n bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTpnbWFpbC1tXzQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTQyNDQ0NTEyOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1Mjk4NTM2OCAtMTQzMTEzODY0IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzgxNjQ3OTA4Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTA3NDU0NDA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFuZHJldyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhhbmtzIGZvciB5b3VyIGlucHV0cyBhbmQgZmVlZGJhY2suIFBsZWFzZSBjaGVjayBp bmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSAmbHQ7YW5kcmV3 LnN0b25lQG5va2lhLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBOb3ZlbWJlciAyMDIw IDA0OjQ2PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRh bnRAY2lzY28uY29tJmd0OzsgVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmlzaG51cGF2YW5AZ21h aWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBLZXRhbiwgUGF2YW4sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj5Hb29kIGRpc2N1c3Npb24uIEp1c3QgZ29pbmcgdG8gY2hpcCBpbiBzb21lIHRo b3VnaHRz4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5PbmUgb2YgdGhlIGVsZW1lbnRzIEkgcGVyc29u YWxseSBsaWtlIG9mIHRoZSBTUiBQb2xpY3kgbW9kZWwgaXMgdGhhdCBtYW55IENhbmRpZGF0ZSBQ YXRocyBtYXkgZXhpc3QsIGJ1dCBvbmx5IG9uZSBtYXkgYmUgYWN0aXZlIGFuZCBhIGNhbmRpZGF0 ZSBwYXRoIGNvbnRhaW5zIDEgb3IgbWFueSBTSUQgbGlzdHMuIEl04oCZcyBhIHNpbXBsZSBwYXJl bnQvY2hpbGQgLSByb290L2xlYWYNCiB0cmVlIHdpdGggdmVyeSBjbGVhciBydWxlcyB3aXRoaW4g dGhlIFNSIHBvbGljeSBjb250ZXh0IGluc3RhbmNlLiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHdo YXQgaXMgYmVpbmcgcHJvcG9zZWQgaW4gdGhlIC0wOSBkb2N1bWVudCBzdGlsbCBmb2xsb3dzIHRo b3NlIHJ1bGVzIGFuZCB0aGUgZ2VuZXJhbCB0b3AtZG93biB0cmVlIGJlaGF2aW91ci4gRGVzcGl0 ZSB0aGUgY29tcG9zaXRlIENQIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IFNSIFBvbGljeSwNCiB0 aGF0IFNSIFBvbGljeSBzdGlsbCBmb2xsb3dzIGFsbCBvZiB0aGUgc2FtZSBydWxlcyB0b3AgZG93 biBpbiBpdHMgb3duIGlzb2xhdGVkIGNvbnRleHQuIENvbXBhcmUgdGhhdCB0byBzYXksIGhhdmlu ZyBhIGNhbmRpZGF0ZSBwYXRoIGNvbnRhaW4gYSBjaGlsZCB0aGF0IHBvaW50cyB0byBvdGhlciBj YW5kaWRhdGUgcGF0aHMgd2l0aGluIHRoZSBzYW1lIFNSIFBvbGljeSBjb250ZXh0OiB3aXRoaW4g dGhlIHNhbWUgY29udGV4dCBhIGNoaWxkIGlzDQogcG9pbnRpbmcgdG8gYSBzaWJsaW5nIG9mIGl0 cyBwYXJlbnQuIFRoZSBydWxlcyBub3cgaGF2ZSB0byBiZW5kIHNsaWdodGx5LiBBcyBub3RlZCBi ZWxvdywgc29tZSBvZiB0aGUgcnVsZXMgYXJvdW5kIHdoYXQgaXMgY29uc2lkZXJlZCBhbiBhY3Rp dmUgY2FuZGlkYXRlIHBhdGggd291bGQgbmVlZCB0byBjaGFuZ2UsIHNpbmNlIHRoZSBjb25zdGl0 dWVudHMgZXNzZW50aWFsbHkgYXJlIGFjdGl2ZSAodGhleeKAmXJlIGluc3RhbGxlZCkgZGVzcGl0 ZSBub3QNCiBiZWluZyB0aG91Z2h0IG9mIGFzIGJlaW5nIGFjdGl2ZS4gTm90ZSB0aGF0IHRoZSBw cm9wb3NlZCBuZXcgdGV4dCBiZWxvdyBzYXlzIOKAnFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9yZWQg Zm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMmcXVvdDsgd2hp Y2ggaXMgYWxzbyBhIG5ldyBydWxlLCBob3dldmVyIG9uZSBjb3VsZCBwZXJoYXBzIHdvcmsgYXJv dW5kIHRoYXQgYnkganVzdCByZXF1aXJpbmcgdGhlIHByZWZlcmVuY2Ugb24NCiB0aGUgY29uc3Rp dHVlbnRzIGJlIGxlc3MgcHJlZmVycmVkIHRoYW4gYW55IG90aGVyIHN0YW5kYXJkIG9yIGNvbXBv c2l0ZSBDUCDigJMgYnV0IHRoYXQgcmFpc2VzIGl0cyBvd24gdHJvdWJsZXMgd2l0aCBtdWx0aXBs ZSBzb3VyY2VzIG9mIHByb3Zpc2lvbmluZyDigJMgd2hpY2ggbGVhZHMgdG8gYSBydWxlIGFza2lu ZyB0byBpZ25vcmUgdGhlIHByZWZlcmVuY2UuIEluIHN1bW1hcnksIGZyb20gbXkgcC5vLnYgbmV3 IHJ1bGVzIGluIHRoZSBoaWVyYXJjaHkNCiB3b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFu Zz0iRU4tQ0EiPltLVF0gQWdyZWUgYW5kIHRoaXMgd291bGQgYmUgYSBmYXIgbW9yZSBpbnRydXNp dmUgYW5kIGNoYW5nZSB0byB0aGUgbW9kZWwuIFRoYXQgdG9vIGZvciBhIHZlcnkgc3BlY2lmaWMg dXNlLWNhc2Ugd2hpbGUgdGhlIGN1cnJlbnQgcHJvcG9zYWwgc3VwcG9ydHMgbm90IGp1c3QgdGhh dCB1c2UtY2FzZSBidXQgbWFueSBvdGhlcnMgYXMgd2VsbCBpbiBhIG1vcmUgZ2VuZXJpYw0KIHdh eS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5S ZWdhcmRpbmcgc3RlZXJpbmcgaW50byBhbiBTUiBQb2xpY3ksIHllcywgeW91IGJ1cm4gY29sb3Jz IGluIGRvaW5nIHRoaXMgKDMyYml0cy4uLikgYW5kIGl0IHdvdWxkIHJlcXVpcmUgZGVwbG95aW5n IGFuIGVudGlyZWx5IGRlZGljYXRlZCBTUiBQb2xpY3kgY29uc3RydWN0LCBhbmQgcnVuIHRoZSBy aXNrIG9mIHN0ZWVyaW5nIOKAmG90aGVy4oCZIHRyYWZmaWMgaW50byB0aGF0IHBvbGljeS4NCiBJ ZiB0aGlzIGlzIGEgY29uY2Vybiwgd291bGQgdGhlIGNvbXBvc2l0ZSBTUiBQb2xpY2llcyBub3Qg YmUgZW5naW5lZXJlZCBpbiBhIHdheSB3aGVyZSB0aGUgY29sb3IgYmxvY2sgdXNlZCBpcyBkZXNp Z25lZCB0byBub3QgYmUgdXNlZCBlbHNld2hlcmUgaW4gdGhlIG5ldHdvcmsgZm9yIG90aGVyIHB1 cnBvc2VzPyBJcyB0aGVyZSBub3QgYSBkaWZmZXJlbnQgYnV0IGtpbmQgb2Ygc2ltaWxhciBwcm9i bGVtIHdpdGggQmluZGluZyBTSURzLCBpbiB0aGF0DQogdGhleeKAmXJlIGVsaWdpYmxlIGZvciB1 c2UgYnkgb3RoZXIgY29uc3VtZXJzIGV2ZW4gaWYgbm90IGRpcmVjdGx5IGludGVuZGVkPyAoYWx0 aG91Z2ggYXQgbGVhc3QgQlNJRHMgYXJlIG9wdGlvbmFsIGFuZCBub3QgbWFuZGF0b3J5KS4gSW4g YWRkaXRpb24gdG8gdGhlIHNwbGl0IFRFIGNhc2VzLCBiZWluZyBhYmxlIHRvIGhhdmUgYW4gU1Ig UG9saWN5IHN0ZWVyIGludG8gYW5vdGhlciBTUiBQb2xpY3kgbWlnaHQgYWxzbyBoYXZlIHNvbWUg dmFsdWUNCiBpbiBhIGJhY2t1cCBjYW5kaWRhdGUgc2NlbmFyaW8gd2hlbiBvbmUgaGFzIG11bHRp cGxlIFNSIFBvbGljaWVzIHdpdGggdGhlIHNhbWUgZW5kcG9pbnQsIGJ1dCBjYW4gc2hhcmUgYSBj b21tb24gZmFsbGJhY2svYmVzdCBlZmZvcnQgY2FuZGlkYXRlIHBhdGguIFRoZSBlbnRpdHkgKDxp PkknbSB0aGlua2luZyBQQ0U8L2k+KSBtYW5hZ2luZyB0aGF0IHdvdWxkIG9ubHkgbmVlZCB0byBt YWludGFpbiB0aGUgZmFsbGJhY2svYmVzdCBlZmZvcnQgQ1ANCiBTSUQgbGlzdChzKSwgaW5zdGVh ZCBvZiBvbmUgZm9yIGVhY2ggTiAqIENQcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSI+W0tUXSBUaGlzIHdhcyBleGFj dGx5IG9uZSB0aGUgbWFpbiBjb25zaWRlcmF0aW9ucyBmb3IgdGhlIHByb3Bvc2FsIGluIHRoZSBk cmFmdCBjdXJyZW50bHkuIEluIHRoYXQgaXQgcHJvdmlkZXMgdGhlIGZsZXhpYmlsaXR5IHRvIHN1 cHBvcnQgbm90IGp1c3QgdGhlIHZlcnkgc3BlY2lmaWMgdXNlLWNhc2UgZm9yIHNwbGl0dGluZyBz ZXJ2aWNlIGZsb3dzIHdpdGggYi93DQogZ3JhbnVsYXJpdHkgYWNyb3NzIGRpZmZlcmVudCBwbGFu ZXMsIGJ1dCBpdCBlbmFibGVzL2FsbG93cyBvdGhlciB1c2UtY2FzZXMgbGlrZSB3aGF0IHlvdSBt ZW50aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSB1c2UtY2FzZSB3aGVyZSB0aGVyZSBpcyByZWFsbHkg bm8gYi93IGNvbnNpZGVyYXRpb25zIGJ1dCB3aGVyZSAmbmJzcDtTZXJ2aWNlIFIgbmVlZHMgdG8g YmUgc3RlZXJlZCBvdmVyIHRoZSByZWQtcGxhbmUsIFNlcnZpY2UgQiBuZWVkcyB0byBiZSBzdGVl cmVkDQogb3ZlciB0aGUgYmx1ZS1wbGFuZSB3aGlsZSBTZXJ2aWNlIEEgbmVlZHMgdG8gYmUgbG9h ZC1iYWxhbmNlZCBvdmVyIGJvdGggcmVkIGFuZCBibHVlIHBsYW5lcy4gSGVyZSwgdGhlIGNvbG9y aW5nIG9uIHRoZSBzZXJ2aWNlIHJvdXRlIHdpbGwgZGljdGF0ZSB3aGV0aGVyIHRoZSBwbGFuZXMg YXJlIHRvIGJlIHVzZWQgaW5kaXZpZHVhbGx5IG9yIG5vdC4gVGhpcyBpcyBqdXN0IG9uZSBleGFt cGxlIHVzZS1jYXNlLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPlNvbWV0aGluZyBJIGhhdmVu4oCZdCBjb25jbHVkZWQgdG8gbXlzZWxmIHlldCBh cmUgcXVlc3Rpb25zIHN1Y2ggYXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBs Zm8zIj48c3BhbiBsYW5nPSJFTi1DQSI+ZG9lcyBoYXZpbmcgYSBjYW5kaWRhdGUgcGF0aCBzdGVl ciBpbnRvIGFub3RoZXIgU1IgUG9saWN5IHNhdGlzZnkgdGhlIGFiaWxpdHkgdG8gZG8gdmFyaW91 cyBzdWItcGF0aCBzcGVjaWZpYyBURS9jb25zdHJhaW50L29iamVjdCBjb21iaW5hdGlvbnMgc3Vm ZmljaWVudGx5PzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3Bh biBsYW5nPSJFTi1DQSI+aXMgdGhlIG1vZGVsIHJlbGF0aXZlbHkgc3RyYWlnaHQgZm9yd2FyZCB0 byBtYXAgaW50byB5YW5nL2JncC9wY2VwIGV0Yy4uPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj5bS1RdIEkg YmVsaWV2ZSB0aGlzIGlzIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgd2UgY2FuIHdvcmsgdGhlc2UgYXNw ZWN0cyBvdXQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi PjxzcGFuIGxhbmc9IkVOLUNBIj5kb2VzIHVzaW5nIGFuIGFkZGl0aW9uYWwgU1IgUG9saWN5IGNy ZWF0ZSB0b28gbXVjaCBvdmVyaGVhZCBvciBzdGF0ZSBidXJuIHRvIGNvbmZpZ3VyZSwgZGVwbG95 LCBtYW5hZ2UsIHRyYWNrIGV0Yy4uID88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSI+W0tUXSBUaGUgdW5pdCBv ZiBzaWduYWxpbmcgYmVpbmcgdGhlIENQLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBtYWtlcyBhIGRp ZmZlcmVuY2UgZWl0aGVyIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLUNBIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSI+S2V0YW48L3NwYW4+PC9pPjwv Yj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5DaGVlcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QW5k cmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJpbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7S2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudD00MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZyI+a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMTAsIDIwMjAgYXQgMTA6MzMgUE08YnI+ DQo8Yj5UbzogPC9iPlZpc2hudSBQYXZhbiBCZWVyYW0gJmx0OzxhIGhyZWY9Im1haWx0bzp2aXNo bnVwYXZhbkBnbWFpbC5jb20iPnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NwcmluZ10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SGkgUGF2YW4sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj5QbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpc2hu dXBhdmFuQGdtYWlsLmNvbSI+dmlzaG51cGF2YW5AZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiAxMSBOb3ZlbWJlciAyMDIwIDAwOjI2PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBU YWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNvbSI+ a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5LTA5LnR4dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+S2V0YW4sIEhpITxicj4NCjxicj4NClBsZWFzZSBz ZWUgaW5saW5lIGZvciByZXNwb25zZXMgKHByZWZpeGVkIFZQQikuPGJyPg0KPGJyPg0KUmVnYXJk cyw8YnI+DQotUGF2YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5P biBUdWUsIE5vdiAxMCwgMjAyMCBhdCA0OjA0IEFNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIj5rZXRhbnRAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+SGkgUGF2YW4sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1DQSI+UGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29s b3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBW aXNobnUgUGF2YW4gQmVlcmFtICZsdDs8YSBocmVmPSJtYWlsdG86dmlzaG51cGF2YW5AZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dmlzaG51cGF2YW5AZ21haWwuY29tPC9hPiZndDsNCjxicj4N CjxiPlNlbnQ6PC9iPiAxMCBOb3ZlbWJlciAyMDIwIDAwOjA4PGJyPg0KPGI+VG86PC9iPiBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmlu Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+S2V0YW4sPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5NdWNoIFRoYW5rcyBmb3IgdGFraW5nIGEg c3RhYiBhdCBhZGRyZXNzaW5nIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggdXNlLWNhc2Uh PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDtXZSBzZWVtIHRvIGJlIGNvbnZlcmdpbmcuPC9zcGFuPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj5bS1RdIFRoYW5rcyBmb3IgdGhhdCBm ZWVkYmFjayBhbmQgY29uZmlybWF0aW9uIHRoYXQgdGhlIHByb3Bvc2FsIGluIHRoZSBkcmFmdCBk b2VzIGFkZHJlc3MgdGhlIHVzZS1jYXNlLiBJIGJlbGlldmUgd2UgYXJlIG5vdyBkaXNjdXNzaW5n IHRoZSBtZWNoYW5pY3Mgb2YNCiBob3cgdGhpcyBpcyBhY2hpZXZlZCB3aXRoaW4gdGhlIGN1cnJl bnQgU1IgUG9saWN5IGZyYW1ld29yay48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhvd2V2ZXIsIEkg ZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB5b3UgbmVlZCB0byB1c2UgYWRkaXRpb25hbCBTUiBwb2xp Y2llcyAoYW5kIHVubmVjZXNzYXJpbHkgYnVybiBhZGRpdGlvbmFsIGNvbG9ycykgdG8gYWRkcmVz cw0KIHRoaXMuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSI+W0tUXSBJ IGRvIG5vdCBmb2xsb3cgd2hhdCB5b3UgbWVhbiBieSDigJxidXJuIGFkZGl0aW9uYWwgY29sb3Jz 4oCdLiBDb2xvciBpcyBqdXN0IGEgMzIgYml0IG51bWJlciB0aGF0IGluZGljYXRlcyB0aGUg4oCc aW50ZW504oCdIGFuZCBpcyBub3QgcmVhbGx5IGEgc2NhcmNlIHJlc291cmNlLg0KIEFzc2lnbmlu ZyBhIGNvbG9yIHRvIOKAnGEgY29tcG9zaXRlIGludGVudOKAnSBzZWVtcyBsaWtlIGEgc2VhbWxl c3Mgd2F5IHRvIGludGVncmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlzbXMgZm9yIFN0ZWVyaW5n IG92ZXIgU1IgUG9saWNpZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmlsaXR5IGZvciBzYXkgc29t ZSBCR1Agc2VydmljZXMgdG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudCBleHBsaWNp dC9keW5hbWljIGludGVudCB3aGlsZSBvdGhlcnMNCiBjYW4gc3RlZXIgb3ZlciBhIGNvbXBvc2l0 ZSBpbnRlbnQgdGhhdCBpbmNsdWRlcyB0aG9zZSBpbmRpdmlkdWFsIGV4cGxpY2l0L2R5bmFtaWMg aW50ZW50cy48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+W1ZQQl0gVGhlIOKAnGZsZXhpYmlsaXR54oCdIHRoYXQgeW91IGFyZSByZWZlcnJp bmcgdG8gaXMgdW5kZXNpcmFibGUgZm9yIHRoaXMgdXNlLWNhc2UuIEZvciB0aGUgdHJhZmZpYy1z cGxpdCB1c2UtY2FzZSwgd2UgZG9u4oCZdCB3YW50IGFueSBvdGhlciBzZXJ2aWNlcyB0byBiZSBk aXJlY3RseSBzdGVlcmVkIG92ZXIgdGhlIGNvbnN0aXR1ZW50cyB3aGVuIHRoZXkgYXJlIHBhcnQg b2YgYQ0KIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OiM0NDcyQzQiPltLVF0gSSBiZWxpZXZlIHRoZSB1c2UtY2FzZSB0aGF0IHlvdSBhcmUgcmVmZXJy aW5nIHRvIHdhcyBmb3Igc3BsaXR0aW5nIHNvbWUgdHJhZmZpYyBmb3IgYSBzZXJ2aWNlIG92ZXIg YSBibHVlIHBsYW5lIGFuZCB0aGUgcmVzdCBvdmVyIGEgcmVkIHBsYW5lLiBBdCB0aGUgc2FtZSB0 aW1lLCB0aGVyZSBtYXkgYmUgb3RoZXIgc2VydmljZXMNCiB0aGF0IHV0aWxpemUgb25seSBhIHNp bmdsZSBwbGFuZS4gVGhlIGZsZXhpYmlsaXR5IHRoYXQgSSB3YXMgcmVmZXJyaW5nIHRvIHdhcyB0 byBlbmFibGUvYWxsb3cgZm9yIGVpdGhlciBvZiB0aGUgdHdvIHNjZW5hcmlvcyBhbmQgdGhlcmUg bWF5IGJlIG90aGVyL21vcmUgdXNlLWNhc2VzIGZvciB3aGljaCB3ZSBuZWVkIGEgbW9yZSBnZW5l cmljIGZyYW1ld29yay48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj5UaGUgY3VycmVudCBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgd291bGQgaGF2ZSBi ZWVuIGFjY2VwdGFibGUgaWYgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIHdlcmUgdW5jb2xv cmVkIOKAkyBidXQgdGhhdCB3b3VsZCB2aW9sYXRlIHRoZSBjdXJyZW50IHJ1bGVzIGltcG9zZWQg YnkgdGhlIGRyYWZ0LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PldoeSBjYW7igJl0IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgganVzdCBiZSBhIGdyb3Vw aW5nIG9mIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYyBjYW5kaWRhdGUg cGF0aHM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj5bS1RdIFRoaXMg aXMgYmVjYXVzZSBpbiB0aGUgU1IgUG9saWN5IGZyYW1ld29yaywgdGhlcmUgaXMgb25seSBhIHNp bmdsZSBhY3RpdmUgQ1Ag4oCTIGl0IG1heSBiZSBleHBsaWNpdCBvciBkeW5hbWljLiBOb3cgd2Xi gJl2ZSBhZGRlZCBhbm90aGVyIENvbXBvc2l0ZSBDUA0KIHR5cGUgdG8gY292ZXIgdGhpcyBzcGVj aWZpYyB1c2UtY2FzZS4gWW91ciBwcm9wb3NhbCB3aWxsIHJlc3VsdCBpbiAzIGNhbmRpZGF0ZSBw YXRocyBiZWluZyBhY3RpdmUgd2l0aGluIHRoZSBzYW1lIFNSIFBvbGljeSDigJMgb25lIGVhY2gg b2YgdGhlIGV4cGxpY2l0IGFuZCBkeW5hbWljIENQIGFuZCB0aGVuIGFkZGl0aW9uYWxseSB0aGUg Q29tcG9zaXRlIENQLiBUaGlzIGJyZWFrcyB0aGUgZXhpc3RpbmcgcnVsZXMgZm9yIHNlbGVjdGlv biBvZiBDUA0KIGJhc2VkIG9uIHByZWZlcmVuY2UgYW5kIG1lY2hhbmlzbXMgbGlrZSBmYWxsYmFj ayBiZXR3ZWVuIENQcy4gV2hpbGUgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHBy b3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIG5ldyB1c2UtY2FzZSB3aXRoIGEgYmFja3dhcmRz IGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBTUiBQb2xpY3kgZnJhbWV3b3JrLjwvc3Bhbj48 L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bVlBCXSBU aGUgcHJvcG9zYWwgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgYmFja3dhcmRzIGNvbXBhdGlibGUg YW5kIGRvZXMgbm90IGludGVuZCB0byBicmVhayBhbnkgZXhpc3RpbmcgcnVsZXMgZm9yIGRlZW1p bmcgYSBjYW5kaWRhdGUgcGF0aCBhY3RpdmUuIEFzIHBlciB0aGUgcnVsZXMgdGhhdCBhcmUgb3V0 bGluZWQgaW4gU2VjdGlvbiAyLjksIG9ubHkgdGhlIGNvbXBvc2l0ZQ0KIGNhbmRpZGF0ZSBwYXRo IGlzIOKAnGFjdGl2ZeKAnSBnaXZlbiBpdHMgcHJlZmVyZW5jZS4gVGhlIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRocyB3aWxsIG5ldmVyIGJlIGFjdGl2ZSBvbiB0aGVpciBvd24uIElmIGl0IGlz IG5lY2Vzc2FyeSwgd2UgY2FuIGFkZCBhIHN0YXRlbWVudCBpbiBTZWN0aW9uIDIuOSB0byBleHBs aWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVjdGlvbiBjcml0ZXJpYSBk b2VzIG5vdCBhcHBseSB0byB0aGUNCiBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMuJm5ic3A7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+W0tUXSBXaGVuIGEgQ1AgaXMg4oCc YWN0aXZl4oCdIGl0IGlzIGFjdHVhbGx5IHRoZSBvbmUgdGhhdCBpcyBiZWluZyB1c2VkIGZvciBm b3J3YXJkaW5nLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOiM0NDcyQzQiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM0NDcyQzQiPlRoYW5rcyw8L3NwYW4+PC9p PjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNDQ3MkM0 Ij5LZXRhbjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwv c3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGFua3MsPC9z cGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiPktldGFuPC9zcGFu PjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Q29uc2lkZXIgdGhlIGZv bGxvd2luZyBjaGFuZ2VzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+KiogU2VjdGlvbiAyLjI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0xEOjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgY29tcG9zaXRlIGNh bmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3VwaW5nIG9mIFNSPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBQ b2xpY2llcy4mbmJzcDsgVGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBjb25zdHJ1Y3QgZW5h YmxlcyBjb21iaW5hdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgb2YgU1IgUG9saWNpZXMsIGVhY2ggd2l0aCBleHBsaWNpdCBj YW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNhbmRpZGF0ZSBwYXRocyB3aXRoIHBv dGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24gb2JqZWN0aXZlczwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIGNvbnN0 cmFpbnRzLCBmb3IgYSBsb2FkLWJhbGFuY2VkIHN0ZWVyaW5nIG9mIHBhY2tldCBmbG93cyBvdmVy PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBpdHMgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMuJm5ic3A7IFRoZSBmb2xsb3dpbmcgY3Jp dGVyaWEgYXBwbHkgZm9yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBpbmNsdXNpb24gb2YgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMg dXNpbmcgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVuZGVyIGEgcGFyZW50IFNSIFBv bGljeTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBvJm5ic3A7IHRoZSBlbmRwb2ludHMgb2YgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGlj aWVzIGFuZCB0aGUgcGFyZW50IFNSPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQb2xpY3kgTVVTVCBi ZSBpZGVudGljYWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBjb2xvcnMgb2YgZWFjaCBvZiB0aGUgY29uc3RpdHVl bnQgU1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSIFBv bGljeSBNVVNUIGJlIGRpZmZlcmVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGlj aWVzIE1VU1QgTk9UIHVzZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGhzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRWFjaCBjb25zdGl0 dWVudCBTUiBQb2xpY3kgb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXM8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFzc29j aWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTEiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAyLjExPC9zcGFuPjwvYT4gZm9yIGRl dGFpbHMpLiZuYnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5FVzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoIGFjdHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3VwaW5nIG9mPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBleHBsaWNp dCBjYW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMgY2FuZGlkYXRlIHBhdGhzIHdpdGggPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwO3BvdGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24gb2JqZWN0aXZlcyBhbmQg Y29uc3RyYWludHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBl bmFibGVzIGxvYWQtYmFsYW5jZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0ZWVyaW5nIG9mIHBhY2tldC1mbG93cyBvdmVyIGEg c2V0IG9mIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGF0aHMuIFRoZSBmb2xsb3dpbmcgY3Jp dGVyaWEgYXBwbHkgZm9yIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSA8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtwYXRocyB1bmRlciBhIGNvbXBv c2l0ZSBjYW5kaWRhdGUgcGF0aDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIHByZWZlcmVuY2Ugb2YgdGhlIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRoIE1VU1QgYmUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aWdub3JlZC4gPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IHRoZSBjb25z dGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIE5PVCBiZSBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUg PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhdGg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBFYWNoIGNvbnN0aXR1ZW50IGNhbmRp ZGF0ZSBwYXRoIG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVk IHdpdGggYSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChyZWZlcjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDkjc2VjdGlvbi0yLjExIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPlNlY3Rpb24gMi4xMTwvc3Bhbj48L2E+IGZvciBkZXRhaWxz KS4mbmJzcDsgVGhlIGRlZmF1bHQgd2VpZ2h0IGlzIDEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+KiogU2VjdGlvbiAyLjExPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBhY3RpdmUs IHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5z dGVlcmVkIGludG8gZWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kgaXMgZXF1YWwgdG8gdGhlIHJl bGF0aXZlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdt YWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndlaWdodCBvZiBlYWNoIGNv bnN0aXR1ZW50IFNSIFBvbGljeS4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEw MTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GdXJ0aGVy DQogbG9hZCBiYWxhbmNpbmcgb2Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Zmxv d3Mgc3RlZXJlZCBpbnRvIGEgY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIHBlcmZvcm1lZCBiYXNl ZCBvbiB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4 Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0cyBvZiB0aGUg U2VnbWVudC1MaXN0IG9mIHRoZSBhY3RpdmUgY2FuZGlkYXRlIHBhdGggb2YgdGhhdDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25zdGl0dWVudCBTUiBQb2xpY3kuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldoZW4gYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg aXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+c3RlZXJlZCBpbnRvIGVhY2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggaXMg ZXF1YWwgdG8gdGhlIHJlbGF0aXZlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndl aWdodCBvZiBlYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLiZuYnNwOzxzcGFuIGNsYXNz PSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkZ1cnRoZXINCiBsb2FkIGJhbGFuY2luZyBvZjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5mbG93cyBzdGVlcmVkIGludG8gYSBjb25zdGl0dWVudCBjYW5kaWRh dGUgcGF0aCBpcyBwZXJmb3JtZWQgYmFzZWQgb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWls LW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+dGhlIHdlaWdodHMgb2YgZWFjaCBhc3NvY2lhdGVkIFNlZ21lbnQtTGlzdC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxl PSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+KiogU2VjdGlvbiAy LjEzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5P TEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIGluZm9ybWF0aW9uIG1v ZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2aW5nIGEgY29tcG9zaXRlPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TUiBwb2xpY3kgUE9MMTAwICZsdDtoZWFk ZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUxJmd0Ozwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5kaWRhdGUt cGF0aCBDUDEgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAxJmd0 Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QcmVmZXJlbmNlIDIwMDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzEsIFNSIHBvbGljeSAmbHQ7Y29sb3IgPSAxJmd0 Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzIsIFNSIHBvbGljeSAmbHQ7 Y29sb3IgPSAyJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzEx MDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIGNv bnN0aXR1ZW50IFNSIFBvbGljaWVzIFBPTDEgYW5kIFBPTDIgaGF2ZSBpbmZvcm1hdGlvbiBtb2Rl bCBhczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kZXNjcmliZWQgYXQgdGhlIHN0 YXJ0IG9mIHRoaXMgc2VjdGlvbi4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEw MTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGV5DQog YXJlIHJlZmVyZW5jZWQgb25seSBieTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5j b2xvciBpbiB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHNpbmNlIHRoZWlyIGhlYWRlbmQg YW5kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmVuZHBvaW50IGFyZSBpZGVudGlj YWwgdG8gdGhlIFBPTDEwMC4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUNCiB2YWxp ZCBTZWdtZW50LUxpc3RzIG9mIHRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5h Y3RpdmUgY2FuZGlkYXRlIHBhdGggb2YgUE9MMSBhbmQgUE9MMiBhcmUgaW5zdGFsbGVkIGluIHRo ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mb3J3YXJkaW5nLiZuYnNwOzxzcGFu IGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlRyYWZmaWMgc3RlZXJlZA0KIG9uIFBPTDEwMCBpcyBmbG93LWJh c2VkIGhhc2hlZCBvbiBQT0wxPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpdGgg YSByYXRpbyBXMS8oVzErVzIpLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAx Mzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpdGhpbg0K IHRoZSBQT0wxLCB0aGUgZmxvdy1iYXNlZCBoYXNoaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPm92ZXIgaXRzIFNlZ21lbnQtTGlzdHMgYXJlIHBlcmZvcm1lZCBhcyBkZXNjcmli ZWQgZWFybGllciBpbiB0aGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNlY3Rp b24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl IHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVX Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZSBpbmZvcm1hdGlvbiBtb2Rl bCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5jYW5kaWRhdGUgcGF0aCBpcyB0aGUgZm9sbG93aW5nOjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U1IgcG9saWN5IFBPTDEwMCAmbHQ7aGVhZGVu ZCA9IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9pbnQgPSBFMSZndDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2Mjhn bWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5kaWRhdGUtcGF0aA0K IENvbXAtQ1AgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAxJmd0 Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QcmVmZXJlbmNlIDIwMDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMSwNCiBDYW5kaWRhdGUtcGF0aCBDUDE8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcyLCBDYW5kaWRhdGUtcGF0aCBDUDImbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2Fu ZGlkYXRlLXBhdGggQ1AxICZsdDtwcm90b2NvbC1vcmlnaW4gPSAyMCwgb3JpZ2luYXRvciA9PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAyJmd0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodA0KIFcxMSwgU0lELUxpc3QxICZsdDtTSUQxMS4u LlNJRDFpJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzEy LCBTSUQtTGlzdDIgJmx0O1NJRDIxLi4uU0lEMmomZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENhbmRpZGF0ZS1wYXRoIENQMiAmbHQ7cHJvdG9jb2wtb3JpZ2luID0gMjAs IG9yaWdpbmF0b3IgPTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0g MyZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQNCiBXMjEsIFNJRC1M aXN0MyAmbHQ7U0lEMzEuLi5TSUQzaSZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWls LW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+V2VpZ2h0IFcyMiwgU0lELUxpc3Q0ICZsdDtTSUQ0MS4uLlNJRDRqJmd0Ozwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgQ29tcC1DUCBpcyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB3aXRoIHR3byBjb25zdGl0 dWVudHMsIENQMTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQgQ1AyLiBUaGUg cHJlZmVyZW5jZSBpcyBpZ25vcmVkIGZvciBlYWNoIG9mIHRoZSB0d28gY29uc3RpdHVlbnQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgY2FuZGlkYXRlIHBhdGhzLiBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUgdHdvPHNw YW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29uc3RpdHVlbnQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMg YXJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZy4mbmJzcDtUcmFmZmljIHN0ZWVyZWQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDtvbg0KPC9zcGFuPkNvbXAtQ1AgaXMgZmxvdy1iYXNlZCBo YXNoZWQgb24gdG8gQ1AxIGFuZCBDUDIgd2l0aCBhIHJhdGlvIG9mPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXMS8oVzEr VzIpIGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGluIGVhY2ggY29uc3RpdHVlbnQN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBjYW5kaWRhdGUgcGF0aCwgdGhlPHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzEx MDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Zmxvdy1i YXNlZA0KIGhhc2hpbmcgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUgPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHBlcmZvcm1l ZCBhczxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlc2NyaWJlZA0KIGVhcmxpZXIgaW4gdGhpcyBz ZWN0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Kio8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioq IFNlY3Rpb24gNS4zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEz OTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3Np dGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1 ZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIFBvbGljaWVzLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg aXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFz IGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmNhbmRpZGF0ZSBwYXRocy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PkEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4gaXQgaGFzIGF0IGxlYXN0 IG9uZSB2YWxpZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25zdGl0dWVudCBj YW5kaWRhdGUgcGF0aC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LVBhdmFuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+T24gU3VuLCBOb3YgMSwgMjAy MCBhdCA3OjAyIFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudD08YSBocmVm PSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3Ig cmdiKDIwNCwyMDQsMjA0KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUNBIj5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KV2UgaGF2ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGUg Zm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRoZSBzdW1tYXJ5IG9mIGNoYW5nZXM6PGJy Pg0KPGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBDb21wb3NpdGUgQ2FuZGlkYXRlIFBhdGgg Y29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNvbW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6 DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9m RXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlY eVAyd3MvPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdw MGpDRXhSeDBTWHlCWTBDeXFYVS88L2E+KTxicj4NCjIpIEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJh Y2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9u YWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhlIG5ldyB0eXBlIHRoYXQgd2Fz IGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguPGJyPg0KMykgQ2xhcmlmaWNhdGlvbiBvZiBo YW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1wYXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBv ZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLjxicj4NCjQpIENsYXJpZmljYXRpb24gb24gY29uc2lk ZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5IGFzIGRpc2N1c3NlZCBpbiB0aGUgV0cg KFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nw cmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSERO MEl2Rmh3OWlkNDAvPC9hPik8YnI+DQo8YnI+DQpQbGVhc2UgbGV0IGtub3cgeW91ciBjb21tZW50 cy9mZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW4gKG9uIGJlaGFsZiBvZiBj by1hdXRob3JzKTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBP Zg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiAwMiBOb3ZlbWJlciAy MDIwIDA2OjI3PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PGJyPg0KU3ViamVjdDogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU291 cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IFNlZ21lbnQgUm91dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJl PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyZW5jZSBGaWxzZmlsczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBLZXRhbiBUYWxhdWxpa2FyPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERhbmllbCBWb3llcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBbGV4IEJvZ2Rhbm92PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFBhdWwgTWF0dGVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZp bGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMzc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0xMS0wMTxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUg dG8gc3RlZXIgYSBwYWNrZXQgZmxvdzxicj4NCiZuYnNwOyAmbmJzcDthbG9uZyBhbnkgcGF0aC4m bmJzcDsgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3M8 YnI+DQombmJzcDsgJm5ic3A7dG8gc291cmNlIHJvdXRpbmcuJm5ic3A7IFRoZSBoZWFkZW5kIG5v ZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGljeS48YnI+DQombmJzcDsgJm5ic3A7VGhl IGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFuIFNSIFBvbGljeSBpcyBhdWdtZW50ZWQg d2l0aCBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2Np YXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO2Rv Y3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNSIFBvbGljeSBhbmQgc3RlZXJpbmcgaW50 byBhbiBTUjxicj4NCiZuYnNwOyAmbmJzcDtQb2xpY3kuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5Lzwv YT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS0wOTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJyPg0KQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4uPGJyPg0K PGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0 YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJy Pg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MW3PR11MB4570654EEDA8BC76AC8AC3B6C1E70MW3PR11MB4570namp_-- From nobody Thu Nov 12 01:06:07 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D373A1521; Thu, 12 Nov 2020 01:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r9wjnylBuF4d; Thu, 12 Nov 2020 01:06:02 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 606253A1520; Thu, 12 Nov 2020 01:06:00 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65facfae99a0-3d234; Thu, 12 Nov 2020 17:05:45 +0800 (CST) X-RM-TRANSID: 2ee65facfae99a0-3d234 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.130]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee85facfae856a-40df7; Thu, 12 Nov 2020 17:05:45 +0800 (CST) X-RM-TRANSID: 2ee85facfae856a-40df7 From: "Weiqiang Cheng" To: Cc: "'srcomp'" , Date: Thu, 12 Nov 2020 17:05:44 +0800 Message-ID: <08c001d6b8d3$010d08d0$03271a70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Adaw8qWMM8NXBKsVRSCF3jBwduJ55QH3lL/w Content-Language: zh-cn Archived-At: Subject: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 09:06:06 -0000 Hi Group, As you know, the SPRING Working Group set up an SR compression design = team prior to IETF108. The design team is to produce (rough) consensus (of the DT) outputs to = the WG on two related topics: 1) What are the requirements for solutions to compressing segment = routing information for use over IPv6; 2) A comparison of proposed approaches to compressing segment routing = information for use over IPv6. With great effort of design team members, DT have finished the version = -00 of the requirements document and have submitted it to datatracker. Please review it and let's know your comments. B.R. Weiqiang Cheng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 = 16:32 =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang = Cheng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-srcompdt-spring-compression-requirement-00.txt A new version of I-D, = draft-srcompdt-spring-compression-requirement-00.txt has been successfully submitted by Weiqiang Cheng and posted to the IETF repository. Name: draft-srcompdt-spring-compression-requirement Revision: 00 Title: Compressed SRv6 SID List Requirements Document date: 2020-10-30 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-00.txt Status: = https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ Htmlized: = https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement Htmlized: = https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -00 Abstract: This document specifies requirements for solutions to compress SRv6 SID lists. = =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 Thu Nov 12 05:14:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AE63A0E2D; Thu, 12 Nov 2020 05:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VBr2I9pvsMJA; Thu, 12 Nov 2020 05:14:10 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1F3A0E23; Thu, 12 Nov 2020 05:14:07 -0800 (PST) HMM_SOURCE_IP: 172.18.0.92:10470.1149907680 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-14.25.156.69?logid-06af63eb6960473698378617e5d715c6 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 03E232800C3; Thu, 12 Nov 2020 21:13:58 +0800 (CST) X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id 06af63eb6960473698378617e5d715c6 for james.n.guichard@futurewei.com; Thu Nov 12 21:14:02 2020 X-Transaction-ID: 06af63eb6960473698378617e5d715c6 X-filter-score: filter<0> X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: zhuyq8@chinatelecom.cn From: To: "'James Guichard'" , Cc: References: In-Reply-To: Date: Thu, 12 Nov 2020 21:13:56 +0800 Message-ID: <00dc01d6b8f5$b07b57a0$117206e0$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01D6B938.BE9F8200" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ3ch36/eVqyc5sHb/ZLFmT7LdzyKiDBrMQ Content-Language: zh-cn Archived-At: Subject: [spring] =?gb2312?b?u9i4tDogIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0?= =?gb2312?b?LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudA==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 13:14:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DD_01D6B938.BE9F8200 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable It=A1=AFs useful for us to deploy SR Protection. Support. Thanks. B.R. Zhu Yongqing =20 =B7=A2=BC=FE=C8=CB: spring =B4=FA=B1=ED James = Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 1:39 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call for = draft-li-spring-srv6-path-segment =20 Dear WG: =20 This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending November 24th 2020. Please note that this document has several changes = from v-06 that were requested by the SPRING chairs. For this reason, the = chairs have extended the adoption call for an additional week to allow the WG enough time to review these changes before deciding on WG adoption.=20 =20 After review of the document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as consent. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 =20 =20 =20 ------=_NextPart_000_00DD_01D6B938.BE9F8200 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Jingrong,

    Many thanks for your review comments. We will addres= s them in the next updates of the document.

     

    Thanks,

    Rakesh

     

     

    From: spring <spring-b= ounces@ietf.org>
    Date: Monday, November 2, 2020 at 2:04 AM
    To: James Guichard <james.n.guichard@futurewei.com>, spring@ie= tf.org <spring@ietf.org>
    Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs= @ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11

    Hi working-group:

     

    I support the adoption, and I have the following questions:

     

    1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word= =93as needed=94 for inner IP Header.  Can authors please clarify in w= hich case(s) it is needed and in which it is not.

    2. Section 4.3.1 =93Destination ipv6 address from the ::FFFF:127/= 104 range=94, and Section 4.1.4 =93the loopback address ::1/128 for IPv6=94= , are they different cases or same case ?

     

    Thanks

    Jingrong

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Thursday, October 22, 2020 8:52 PM
    To: spring@ietf.org
    Cc: ippm-chairs@ietf.org; spring-chairs@ietf.org
    Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/d= raft-gandhi-spring-twamp-srpm-11

     

    Dear WG:

     

    This message starts a 3 week WG= adoption call for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending Nov= ember 12th 2020. Please note that this document has several chan= ges from v-10 that were requested by the SPRING and IPPM chairs. For this reason, the chairs have extended t= he adoption call for an additional week to allow the WG enough time to revi= ew these changes before deciding on WG adoption.

     

    Some background:  <= o:p>

     

    Several review comments were re= ceived previously for document h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

     

    • The SPRING docume= nt should describe only the procedures relevant to SPRING with pointers to = non-SPRING document/s that define any extensions. Several extensions includ= ing Control Code Field Extension for TWAMP Light Messages,&= nbsp;Loss Measurement Query Message Extensions, and Loss Mea= surement Response Message Extensions were included in https://tools.ietf.org/html= /draft-gandhi-spring-twamp-srpm-10 and should be removed from the SPRIN= G document.
    • The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-s= rpm-10 should be described in a new document published in the IPPM WG. &nbs= p;

     

    These conclusions were discussed with the authors of=  https://tools.ietf.org/html/draft-gandhi-spring-= twamp-srpm-10 the result of which is the publication of the following two documents:

     

     

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.=

     

    Finally, the chairs would like = to thank the authors for their efforts in this matter.

     

    Thanks!

     

    Jim, Bruno, & Joel

     

     

     

     

     

    It=A1=AFs useful for us = to deploy SR Protection. Support. Thanks.

    B.R.

    Zhu = Yongqing

     <= /p>

    =B7=A2=BC=FE=C8=CB: spring <spring-bounces@ietf.org> = =B4=FA=B1=ED = James = Guichard
    =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C24=C8=D5 1:39
    =CA=D5=BC=FE=C8=CB: = spring@ietf.org
    =B3=AD=CB=CD: = spring-chairs@ietf.org
    =D6=F7=CC=E2: [spring] WG Adoption Call = for = draft-li-spring-srv6-path-segment

     

    Dear WG:

     

    This message starts a 3 week WG = adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, = ending November 24th 2020. Please note that this document has = several changes from v-06 that were requested by the SPRING chairs. For = this reason, the chairs have extended the adoption call for an = additional week to allow the WG enough time to review these changes = before deciding on WG adoption.

     

    After review of the document please = indicate support (or not) for WG adoption to the mailing list. Please = also provide comments/reasons for that support (or lack thereof) as = silence will not be considered as consent.

     

    Thanks!

     

    Jim, Bruno & = Joel

     

     

     

     

     

    ------=_NextPart_000_00DD_01D6B938.BE9F8200-- From nobody Thu Nov 12 08:51:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D23A13E7; Thu, 12 Nov 2020 08:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=comcast.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 lKLHw5GQn075; Thu, 12 Nov 2020 08:51:21 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 4AAD13A13FB; Thu, 12 Nov 2020 08:51:21 -0800 (PST) Received: from pps.filterd (m0184892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ACGhca8015135; Thu, 12 Nov 2020 11:51:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=vRkEhvCYlfb18HAZv0YXTNUOg3rhc5QotXVv/OjLODs=; b=E1qCumev0voPq1uLG/hosDnnEXQsJZZ0vHgTvV39jCl2xWRUVflCgc7zVLtY0KE16WYW WTPIlFgRYA5nxKxGeEgXCkt1+D8CTlq5S5LQXkoWcLOsQ+Go23OxHYzqwBtGGW84rlN+ 84sqvAdNmPJeytC9eoA1rK5WIHi20Vso004JPhn7dpCfGjGu7wFc/mQhtVdfrBe5NsAN mSBFPuJscw7qQGA6AQvKWMzgFijJp4vZxbdXdOpYrN1vjtxgA4OJjVkhjuFuqru68a9D aQLcx0//yQJKKdb0MNRbZgKB6Ceav5X2lVTnSqHB7iOP2nQ6Y0w4uxmxbpuecVeIFE0m 0A== Received: from pacdcex51.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 34rpc5wwx7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 11:51:18 -0500 Received: from PACDCEX56.cable.comcast.com (24.40.2.155) by PACDCEX51.cable.comcast.com (24.40.2.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Nov 2020 11:51:16 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX56.cable.comcast.com (24.40.2.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Nov 2020 11:51:16 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.51) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Nov 2020 11:51:11 -0500 Received: from MN2PR11MB4334.namprd11.prod.outlook.com (2603:10b6:208:18e::33) by MN2PR11MB4461.namprd11.prod.outlook.com (2603:10b6:208:192::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Thu, 12 Nov 2020 16:51:09 +0000 Received: from MN2PR11MB4334.namprd11.prod.outlook.com ([fe80::b174:741b:185:fbbf]) by MN2PR11MB4334.namprd11.prod.outlook.com ([fe80::b174:741b:185:fbbf%4]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 16:51:09 +0000 From: "Wen, Bin" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AQHWuRQFm0XeFBuzUUWIOzcXqWparQ== Date: Thu, 12 Nov 2020 16:51:09 +0000 Message-ID: <09EB8FBF-3D80-4C34-8BF3-9A3F3A570307@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [71.58.36.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1585388-cedc-46fd-62e8-08d8872b27d0 x-ms-traffictypediagnostic: MN2PR11MB4461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PmGazCJmEFCzdlrkCq48kA9k3jPU7YuYC+KcLkWMxCuf4OC8ucwFBrYaS+9vqegMmshIKKMSy8FKT9IuT5fP3JXDIKH3ABTEG95RkqGCtEIsHxkKmT1O+fQ1b3nZAv1YSSzhpU3Oyu7nOyAybei9lstIVImsP6Tdmehl9KWms14pl6B4Ryix/xTiLzQx5imDZwUTwKzQxrdQKF23M3HonASXV43o4Rhv+yIyvTnfp5Dg+1ykQWQMXQcUyOIQVk+oDW2hk2nGl18me1FUT7Sg91hOdUmayC3FIEfIZ5+wAHpMHy98YFyloUQLP6O64v6BGYjRu/H0QLiKp4JdcD8BLIEDHqGACvCz3GKHpnWDRMr8t8gdddoTy3FDrcFn5g5SAcDHhWoiknVTMAQarDypbg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4334.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(86362001)(66476007)(33656002)(83380400001)(110136005)(26005)(6486002)(8936002)(71200400001)(316002)(66556008)(2616005)(966005)(6512007)(166002)(478600001)(2906002)(66446008)(64756008)(54906003)(186003)(8676002)(66946007)(4326008)(76116006)(5660300002)(53546011)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RlA8yIV5zo/WpPmdNyCCYOdEILn90VH7zIdrDU04b8zPR0wHTSE4znQ/XK1seLkwACEZ7Zwk0IsRdAPRGLUxE7GAkFJoRTyzOxLqT16gMsYvhfF+BMat489T8+2tYG7HunUHdvaHhfSzsMZH5XTXipIsX5F1J95Ug692AGqsURJRNfl88uwBb87MIvykW228qj4S9ww3tOIOLxkcsj29oZ1h5b97ONcSqGDKMtbsv3RpD7mOToPgBMrmiop40g5Q07LYgLiHE94N+fqsD/z4zTO23/K7hPVynmA95LHecSFiLT2w4f5tUwU4NDkzbV2hmqjj/pTaeAseilUkNjNZ6a/rzFcCjLIi2IgDydx9ewXLdphrAcgvxJPHZGZC+V4xiBVEOy1gfaAaypWzriD1TjOpVsKOxY5hRT1RJxpHUW0YLK6pzSa0bt0GIbgD4GD2iUab3jb0p5c0RmrRnXrmMKNGnBW3MJfmtKp40QFZR2G+5kDQM/l6kYuhBwVwd9wrufTeVlmAT6wbmaP66RCz3r4olkveQIQfgTBkNdraFag0wSdfR2XTA4BmPUAVNpUcMADbyZjaLsrkYJoEOAddfauhqblaAbh4EC39DC//TdqjgCm2M5bTDho3j2wcHzJZPol0AqGUDvhzNLjzqo86yw== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uf7KvZWXGneyRGMqIwjzNZrBVs99F/vxEGfx5ypn+EEd826mpNb+ko1p027/4gm7yBHxYXQH7Ov1VreEyg5K3B+SsYVuJtTUN+mXe/Tgmcl84hqj5wiCC39O7Ft14/OjxKmu73DwhZDyfwS7SPxphEBfyCUGDCQu+K3+2q6W6eVXsUZNGTlC9zMdFb+AG8aSi77D0b4kgArcVlOu/SyteopBfvoBxDbCwhD9M317FWVdq+HvQlj5q5GsT6OH87UAz0x6sJUOrzWDP1aou6qRjyk1Ha8drE9/UJlwYsiZ9JZ+d2wZwptQmtEImV4W1lxA+SQHITrwJDa49s8lzDW5eA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Id05Pom4XOYuS377p6OVtdqzmmZBFFtip2LJn9zhypI=; b=J9MTTfT7+4zfffuck0dsvxCQDl3sBP1++PmjQcuwgtSG+7jckQ3c6ZYDfbSkJcE2NnLC+sF3JsCkB046pR6CIspDABz73egepGbh9PDS5HBnKn1jAKpZV8Ike54uzFvsYoymB7fRIhOm0GYlWe6Hocs7Bf6ZwCykn/G67ZvsdTmZe/IzZi+wXuOvod9nBT+lVwfe25zKveDmgBgHB6WoPQCYY1B5Pu4aYtr898tpugft92RLPaxJm9opq8wsk63AOretz+n09HGIhny9HWKS6vD1lpBeaj9uaWZwyY9T2Itk9Ei3hVgA4Iwd3ipZytjIjeqwayb7nCBH8fIRdaYTkA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4334.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: f1585388-cedc-46fd-62e8-08d8872b27d0 x-ms-exchange-crosstenant-originalarrivaltime: 12 Nov 2020 16:51:09.3897 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: p0T/2SA/J/ouNd2Io4Mtb3Y71w32fCMs6JBkU2IeWKnj8OnGskiTEbkmjKQUxb6qW0Mk+KxrgdotE6Z9ub9Dv7rY+B1RNu01OHQqWQbE3eo= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4461 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_09EB8FBF3D804C348BF39A3F3A570307cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-12_07:2020-11-12, 2020-11-12 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 16:51:23 -0000 --_000_09EB8FBF3D804C348BF39A3F3A570307cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRywNCg0KSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCB0aGUgV0cg YWRvcHRpb24uDQoNClJlZ2FyZHMsDQoNCg0KRnJvbTogSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4u Z3VpY2hhcmRAZnV0dXJld2VpLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIw IGF0IDk6NTIgQU0NClRvOiAic3ByaW5nQGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KQ2M6 ICJpcHBtLWNoYWlyc0BpZXRmLm9yZyIgPGlwcG0tY2hhaXJzQGlldGYub3JnPiwgInNwcmluZy1j aGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogW3Nwcmlu Z10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMw0KDQpEZWFyIFdHOg0KDQpUaGlzIG1lc3NhZ2Ug c3RhcnRzIGEgMyB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMsIGVuZGluZyBOb3ZlbWJl ciAxMnRoIDIwMjAuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2ZXJhbCBj aGFuZ2VzIGZyb20gdi0wMiB0aGF0IHdlcmUgcmVxdWVzdGVkIGJ5IHRoZSBTUFJJTkcgYW5kIElQ UE0gY2hhaXJzLiBGb3IgdGhpcyByZWFzb24sIHRoZSBjaGFpcnMgaGF2ZSBleHRlbmRlZCB0aGUg YWRvcHRpb24gY2FsbCBmb3IgYW4gYWRkaXRpb25hbCB3ZWVrIHRvIGFsbG93IHRoZSBXRyBlbm91 Z2ggdGltZSB0byByZXZpZXcgdGhlc2UgY2hhbmdlcyBiZWZvcmUgZGVjaWRpbmcgb24gV0cgYWRv cHRpb24uDQoNClNvbWUgYmFja2dyb3VuZDoNCg0KU2V2ZXJhbCByZXZpZXcgY29tbWVudHMgd2Vy ZSByZWNlaXZlZCBwcmV2aW91c2x5IGZvciBkb2N1bWVudCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyLiBUaGUgU1BSSU5HIGFuZCBJ UFBNIGNoYWlycyBjb25zaWRlcmVkIHRob3NlIGNvbW1lbnRzLCBhbmQgdXBvbiByZXZpZXcgb2Yg dGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCwgZGV0ZXJtaW5lZCB0aGUgZm9sbG93aW5nOg0K DQoNCiAgKiAgIFRoZSBTUFJJTkcgZG9jdW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHBy b2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BSSU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBk b2N1bWVudC9zIHRoYXQgZGVmaW5lIGFueSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMg aW5jbHVkaW5nIENvbnRyb2wgQ29kZSBGaWVsZCBFeHRlbnNpb24gZm9yIFNUQU1QIE1lc3NhZ2Vz LCBMb3NzIE1lYXN1cmVtZW50IFF1ZXJ5IE1lc3NhZ2UgRXh0ZW5zaW9ucywgTG9zcyBNZWFzdXJl bWVudCBSZXNwb25zZSBNZXNzYWdlIEV4dGVuc2lvbnMsIE5vZGUgQWRkcmVzcyBUTFYgRXh0ZW5z aW9ucywgYW5kIFJldHVybiBQYXRoIFRMViBFeHRlbnNpb25zIHdlcmUgaW5jbHVkZWQgaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0w MiBhbmQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgU1BSSU5HIGRvY3VtZW50Lg0KICAqICAg VGhlIFNUQU1QIGV4dGVuc2lvbnMgaW5jbHVkZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiBzaG91bGQgYmUgZGVzY3JpYmVk IGluIGEgbmV3IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUgSVBQTSBXRy4NCg0KVGhlc2UgY29u Y2x1c2lvbnMgd2VyZSBkaXNjdXNzZWQgd2l0aCB0aGUgYXV0aG9ycyBvZiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIHRoZSByZXN1 bHQgb2Ygd2hpY2ggaXMgdGhlIHB1YmxpY2F0aW9uIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGRvY3Vt ZW50czoNCg0KDQogICogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhp LXNwcmluZy1zdGFtcC1zcnBtLTAzLiBUaGUgc3ViamVjdCBvZiB0aGlzIFdHIGFkb3B0aW9uIGNh bGwuDQogICogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0t c3RhbXAtc3JwbS0wMC4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIHByb2dyZXNzZWQgKGlmIGRldGVy bWluZWQgYnkgdGhlIFdHKSB3aXRoaW4gdGhlIElQUE0gV0cuDQoNCkFmdGVyIHJldmlldyBvZiB0 aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFzZSBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBX RyBhZG9wdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0LiBQbGVhc2UgYWxzbyBwcm92aWRlIGNvbW1l bnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0aGVyZW9mKSBhcyBzaWxlbmNl IHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2VudC4NCg0KRmluYWxseSwgdGhlIGNoYWly cyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZvciB0aGVpciBlZmZvcnRzIGluIHRo aXMgbWF0dGVyLg0KDQpUaGFua3MhDQoNCkppbSwgQnJ1bm8sICYgSm9lbA0K --_000_09EB8FBF3D804C348BF39A3F3A570307cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <1545A8BB8CE98840BCEF9B801ECD4BA2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlh bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjgxODIyOTkxMDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTEwNDMxOTM3ODg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxMjc2NzE0MjUyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4Mzg1MDcwODA7fQ0KQGxpc3Qg bDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNDQwODMzMzQ0Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzI1NDMwMzA0IDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE5MzMzOTQ3Mzg7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg4MDIwOTQzMCA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCB0aGUgV0cgYWRv cHRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdl aS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIwIGF0 IDk6NTIgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7 c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7aXBwbS1jaGFpcnNAaWV0 Zi5vcmcmcXVvdDsgJmx0O2lwcG0tY2hhaXJzQGlldGYub3JnJmd0OywgJnF1b3Q7c3ByaW5nLWNo YWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+W3NwcmluZ10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIFdHOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgMyB3ZWVrIFdHIGFk b3B0aW9uIGNhbGwgZm9yIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMzwvYT4sIGVuZGluZyBOb3ZlbWJl ciAxMjxzdXA+dGg8L3N1cD4gMjAyMC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhh cyBzZXZlcmFsIGNoYW5nZXMgZnJvbSB2LTAyIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQ UklORyBhbmQgSVBQTSBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4 dGVuZGVkDQogdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxv dyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lk aW5nIG9uIFdHIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIGJhY2tncm91 bmQ6ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXZlcmFsIHJldmlldyBjb21tZW50 cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50DQo8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBt LTAyPC9hPi4NCjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgU1BSSU5HIGFuZCBJUFBNIGNoYWlycyBj b25zaWRlcmVkIHRob3NlIGNvbW1lbnRzLCBhbmQgdXBvbiByZXZpZXcgb2YgdGhpcyB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudCwgZGV0ZXJtaW5lZCB0aGUgZm9sbG93aW5nOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBTUFJJTkcg ZG9jdW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8g U1BSSU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5l IGFueSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMNCiBpbmNsdWRpbmc8L3NwYW4+PGI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiBDb250cm9sIENvZGUgRmllbGQg RXh0ZW5zaW9uIGZvciBTVEFNUCBNZXNzYWdlczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr O2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8Yj5Mb3NzDQogTWVhc3VyZW1lbnQgUXVlcnkgTWVz c2FnZSBFeHRlbnNpb25zPC9iPiwmbmJzcDs8Yj5Mb3NzIE1lYXN1cmVtZW50IFJlc3BvbnNlIE1l c3NhZ2UgRXh0ZW5zaW9uczwvYj4sJm5ic3A7PGI+Tm9kZSBBZGRyZXNzIFRMViBFeHRlbnNpb25z PC9iPiwgYW5kJm5ic3A7PGI+UmV0dXJuIFBhdGggVExWIEV4dGVuc2lvbnM8L2I+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj4gd2VyZSBpbmNsdWRlZCBpbg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDIi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNy cG0tMDI8L2E+IGFuZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcgZG9jdW1lbnQu PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRo ZSBTVEFNUCBleHRlbnNpb25zIGluY2x1ZGVkIGluDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0w MjwvYT4NCjxzcGFuIGxhbmc9IkVOLUNBIj5zaG91bGQgYmUgZGVzY3JpYmVkIGluIGEgbmV3IGRv Y3VtZW50IHB1Ymxpc2hlZCBpbiB0aGUgSVBQTSBXRy4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIj5UaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3Jz IG9mDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdh bmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMjwvYT4gdGhlIHJlc3VsdCBvZiB3aGljaCBp cyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZvbGxvd2luZyB0d28gZG9jdW1lbnRzOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmct c3RhbXAtc3JwbS0wMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1z cHJpbmctc3RhbXAtc3JwbS0wMzwvYT4uIFRoZSBzdWJqZWN0IG9mIHRoaXMgV0cgYWRvcHRpb24g Y2FsbC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0tc3RhbXAtc3JwbS0wMCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXN0YW1wLXNycG0tMDA8 L2E+LiBUaGlzIGRvY3VtZW50IHdpbGwgYmUgcHJvZ3Jlc3NlZCAoaWYgZGV0ZXJtaW5lZA0KIGJ5 IHRoZSBXRykgd2l0aGluIHRoZSBJUFBNIFdHLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSI+QWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcgZG9jdW1lbnQg cGxlYXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBt YWlsaW5nIGxpc3QuDQo8L3NwYW4+UGxlYXNlIGFsc28gcHJvdmlkZSBjb21tZW50cy9yZWFzb25z IGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMgc2lsZW5jZSB3aWxsIG5vdCBi ZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbmFsbHks IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgYXV0aG9ycyBmb3IgdGhlaXIgZWZm b3J0cyBpbiB0aGlzIG1hdHRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhhbmtzITwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSI+SmltLCBCcnVubywgJmFtcDsgSm9lbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_09EB8FBF3D804C348BF39A3F3A570307cablecomcastcom_-- From nobody Thu Nov 12 08:51:58 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1B53A13E7; Thu, 12 Nov 2020 08:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=comcast.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 Ykav2jhMsTxH; Thu, 12 Nov 2020 08:51:54 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 EF82C3A13FB; Thu, 12 Nov 2020 08:51:53 -0800 (PST) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ACGiX9d018032; Thu, 12 Nov 2020 11:51:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=eS4E6vxEsmokO1Dc7a6QcGEv2BGwqlwtgjTlITWW4sg=; b=diYBYojYLtxNrepwqkiutF5BktaIejJHqb8dW96a+UU98cLjRaCU3PgpZHXNS5d/GQOh T4+4xrqnwtkUjcSUqNEyFv72L6fPa8MB9HSyU4gDclRvh9kQ5UoMn52sf0H2J1kw4qMf rYotMhSP3NYrQRdOHGvWP+e3rzeiZgqU8mVphK7HnpctqFHo9sdxg80IymbD8TDSCrzj srAhWKMgq+JYSqq+I6nDZyTjSuFNDoXYYJYil1zFlGh6NLFufTZ3LqzK7mkwbGguYA74 wON2OhnKxGBYwSoc7STZd/brQyPpR6UiY6QN1t6Dw4pkurvifjU8P8Sga/a/9bu4xzKP cA== Received: from pacdcex47.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 34ns5rrht8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 11:51:52 -0500 Received: from PACDCEX47.cable.comcast.com (24.40.2.146) by pacdcex47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Nov 2020 11:51:50 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Nov 2020 11:51:50 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.47) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Nov 2020 11:51:43 -0500 Received: from MN2PR11MB4334.namprd11.prod.outlook.com (2603:10b6:208:18e::33) by BL0PR11MB2883.namprd11.prod.outlook.com (2603:10b6:208:7b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 16:51:42 +0000 Received: from MN2PR11MB4334.namprd11.prod.outlook.com ([fe80::b174:741b:185:fbbf]) by MN2PR11MB4334.namprd11.prod.outlook.com ([fe80::b174:741b:185:fbbf%4]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 16:51:42 +0000 From: "Wen, Bin" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWuRQYWwn0NuMiD06CM/KBqL5Izg== Date: Thu, 12 Nov 2020 16:51:42 +0000 Message-ID: <3F015E1D-DB06-47C7-89CF-2122725591C9@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [71.58.36.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de026870-a49f-4b2c-b4a5-08d8872b3b44 x-ms-traffictypediagnostic: BL0PR11MB2883: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uZWxnxbZekFPKOlEQkm9zVbIpRiouKXAP7CA0NTMvSg45t9G3BqVXqf3u6AuCqhfb+EtEkEuqp2pd3lb1vYKijaxdlDAPoQ6fs9Pcq2qEWGV4fU/GZnJ/KVN7zQUiLc0QukZaMO3PJnisBLkruxkAJWrVKUe45+ld5sYD9ckAo1GHEDqLSDSHB4KpzcKaZoV2xvoV/G4JWDN7nuLhRpsjX0zCuoEofZeoPr3B0VFcXVhPHZYyYzIsB29Ml+J1ZIuR+H70p0qeyg5pG4l47PpT+4cHvXgmT0rROE4Xp/TIpq3GKEMRCVJuaXAlVCvASOYJe9a8hB/hHcYWwTebuqgG4ErBTcBv7ywNT0sgbOOjVppVXM0LbF0SKEW3LZn3T1nIzKHsjeDbgXubNbRMAlT2A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4334.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(8936002)(76116006)(6506007)(71200400001)(2616005)(53546011)(478600001)(8676002)(26005)(83380400001)(186003)(86362001)(6486002)(5660300002)(166002)(316002)(6512007)(66446008)(64756008)(66476007)(2906002)(66556008)(66946007)(54906003)(110136005)(33656002)(966005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ScskTADl18GBpi5hcCS2q1C2FBUthjMgV2C4FLP7d6nTmvQT+Z36oFR/AGaIF1Zf481bcjwli9CicyCrjuG1jtmc2uVhpw136LjwgCTD+y5KA6n4UOhnIXdnZa1MishFTaGrD1xn0XnxvhpDtpFUlbTP1vtfRFrbz3HKzAZOiWMkFypTE88Sd/15brAWqF2jaRrc8hUDS9000zYZP/PIj/4fbVLkMG0kgvj2qDYEOK6peyaP2yosK/9GEmArfJpeq3OxDw00uKDfXhyBBwBj2Dj6Q7S5znBszM3EIPU8xJ5l73maG5FY7Gt3cqF9u0yeGm4tKktvmFLPR+HvcZr4ukjoi070CZ9Dj1m2nC/p0LT4w3g61pBboCbAkZShV8Ry5qddfLp0JBBWZi3E15S0BYTn2FYN7A52VrSNwPxooLBIMk19vCzHuSda6V/nyqR+glAsq3vRj97INKlx7g/LdOafqBLpj0Ho4b4oJg98fG0ObYUNJFB2t6oktpceyGvTMLPWtgWVBCqJxUTK958nufnDmlUV6Yu5fo9P/nkhGd2fhwLumsN5bx0yrHd3bL2jnIWkcxKJcI6rY98ROKwP3RewqiQxk72HKaLY8Aydles/0zyLAKUOEq1t0hPujh6AoStHLXszq5SwHALmX0eHVA== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QeNhsCA3TLpry5D7cADkHrCAS+b11wqrIXU/1oDI4qzWQgiszzaAob1uFlhf4uZA8n2ok4xtrtRNcTJHQgBRcp4atRRnUbtZ0QWl1xjhtsCcPfxPaloZ6IRTw868rsQVoksi+3I8SQz5iJxIMxb3igGC+nJGHlnWy0hmX+wt4yBfI8F+mcHf4/8ZI2rnxZDqplEalnn6lpvl/taMjIajA6Q/Pkq5wRfE8pW9IETujkGCVtscCvT4Zd/YEVAd32RSKwW4UER/ZXI7m4FpuXQdRHQP0wln30Zxm9yfXtPmwrbnxqpH5nUJwQlTyNRsx1RIHIFqVtTahrDhHLiXN92pFg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=92mA4miM6E/m7yKyUjKjd8HFQxT18xGAo9U/RIUm0lo=; b=nsMFRPqBhQu5Gwcj83Sz33+ILSFzNc0LnWPdQNOwRGKJzg7bwP0L2zj70BgIVPcWoZty8qFhaIes+eD3iYrWBjaZYTRJfLitKR1FLgXnen7m8fdrQ9mI74p7eH56QOVotxx7J/AZVE3hlQcu16wbs1iXSSS5M5m7b7imtpQfv3ImgizQJXl1UhvPsZctv1Kip0ZY61S8wfxqLM1NMyCzRB5bKz4umxG1ugkre3VXcvrSLJYsT5suMjBcyYPhU7kynfGX4sXE9rnuBqHXyPfhN19aA3mal836RqePSXB+tC1moImgWkWxrhxXW6D0yGM+F11nbq/X1VTPXM1XeXxtvw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4334.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: de026870-a49f-4b2c-b4a5-08d8872b3b44 x-ms-exchange-crosstenant-originalarrivaltime: 12 Nov 2020 16:51:42.0297 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: WDc8mbh/QtnCF0EjTyCAkTQ1JronjEAIehQvzmJUyOF4XnH7a9+8Ys/TzaliZN80lnSUw0Ge71GJtW+cW/ELROpDiG9f63tAfo9GAdnqam8= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB2883 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_3F015E1DDB0647C789CF2122725591C9cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWS X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-12_07:2020-11-12, 2020-11-12 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 16:51:56 -0000 --_000_3F015E1DDB0647C789CF2122725591C9cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZWFyIFdHLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBzdXBwb3J0IHRoZSBX RyBhZG9wdGlvbi4NCg0KUmVnYXJkcywNCg0KDQpGcm9tOiBKYW1lcyBHdWljaGFyZCA8amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIw MjAgYXQgOTo1MiBBTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpD YzogImlwcG0tY2hhaXJzQGlldGYub3JnIiA8aXBwbS1jaGFpcnNAaWV0Zi5vcmc+LCAic3ByaW5n LWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3By aW5nXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExDQoNCkRlYXIgV0c6DQoNClRoaXMgbWVzc2Fn ZSBzdGFydHMgYSAzIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgZG9jdW1lbnQgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMSBlbmRp bmcgTm92ZW1iZXIgMTJ0aCAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaGFz IHNldmVyYWwgY2hhbmdlcyBmcm9tIHYtMTAgdGhhdCB3ZXJlIHJlcXVlc3RlZCBieSB0aGUgU1BS SU5HIGFuZCBJUFBNIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUgY2hhaXJzIGhhdmUgZXh0 ZW5kZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0 aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5n IG9uIFdHIGFkb3B0aW9uLg0KDQpTb21lIGJhY2tncm91bmQ6DQoNClNldmVyYWwgcmV2aWV3IGNv bW1lbnRzIHdlcmUgcmVjZWl2ZWQgcHJldmlvdXNseSBmb3IgZG9jdW1lbnQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMC4gVGhlIFNQ UklORyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9zZSBjb21tZW50cywgYW5kIHVwb24g cmV2aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGRldGVybWluZWQgdGhlIGZv bGxvd2luZzoNCg0KDQogICogICBUaGUgU1BSSU5HIGRvY3VtZW50IHNob3VsZCBkZXNjcmliZSBv bmx5IHRoZSBwcm9jZWR1cmVzIHJlbGV2YW50IHRvIFNQUklORyB3aXRoIHBvaW50ZXJzIHRvIG5v bi1TUFJJTkcgZG9jdW1lbnQvcyB0aGF0IGRlZmluZSBhbnkgZXh0ZW5zaW9ucy4gU2V2ZXJhbCBl eHRlbnNpb25zIGluY2x1ZGluZyBDb250cm9sIENvZGUgRmllbGQgRXh0ZW5zaW9uIGZvciBUV0FN UCBMaWdodCBNZXNzYWdlcywgTG9zcyBNZWFzdXJlbWVudCBRdWVyeSBNZXNzYWdlIEV4dGVuc2lv bnMsIGFuZCBMb3NzIE1lYXN1cmVtZW50IFJlc3BvbnNlIE1lc3NhZ2UgRXh0ZW5zaW9ucyB3ZXJl IGluY2x1ZGVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3By aW5nLXR3YW1wLXNycG0tMTAgYW5kIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFNQUklORyBk b2N1bWVudC4NCiAgKiAgIFRoZSBUV0FNUCBleHRlbnNpb25zIGluY2x1ZGVkIGluIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAgc2hv dWxkIGJlIGRlc2NyaWJlZCBpbiBhIG5ldyBkb2N1bWVudCBwdWJsaXNoZWQgaW4gdGhlIElQUE0g V0cuDQoNClRoZXNlIGNvbmNsdXNpb25zIHdlcmUgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhvcnMg b2YgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1w LXNycG0tMTAgdGhlIHJlc3VsdCBvZiB3aGljaCBpcyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZv bGxvd2luZyB0d28gZG9jdW1lbnRzOg0KDQoNCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEuIFRoZSBzdWJqZWN0IG9mIHRo aXMgV0cgYWRvcHRpb24gY2FsbC4NCiAgKiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwLiBUaGlzIGRvY3VtZW50IHdpbGwgYmUgcHJv Z3Jlc3NlZCAoaWYgZGV0ZXJtaW5lZCBieSB0aGUgV0cpIHdpdGhpbiB0aGUgSVBQTSBXRy4NCg0K QWZ0ZXIgcmV2aWV3IG9mIHRoZSBTUFJJTkcgZG9jdW1lbnQgcGxlYXNlIGluZGljYXRlIHN1cHBv cnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuIFBsZWFzZSBh bHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBwb3J0IChvciBsYWNrIHRo ZXJlb2YpIGFzIHNpbGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyBjb25zZW50Lg0KDQpG aW5hbGx5LCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRo ZWlyIGVmZm9ydHMgaW4gdGhpcyBtYXR0ZXIuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubywgJiBK b2VsDQoNCg0KDQoNCg== --_000_3F015E1DDB0647C789CF2122725591C9cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlh bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYz QzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEzNDU1MjEwNzk7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi02ODQxOTQxMDI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxMzc1MzQ4MjkzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTcxNzY1MjQzMjt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE0NDA4MzMzNDQ7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMjU0MzAzMDQgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTkzMzM5NDczODsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODgwMjA5NDMwIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgV0csPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIHN1cHBvcnQgdGhlIFdHIGFkb3B0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5KYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciAyMiwgMjAyMCBhdCA5OjUyIEFNPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDtzcHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2lwcG0tY2hhaXJzQGlldGYub3JnJnF1b3Q7 ICZsdDtpcHBtLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5v cmcmcXVvdDsgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPltzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxs IGZvciBkb2N1bWVudCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTE8L2E+IGVuZGluZyBOb3ZlbWJlciAx MjxzdXA+dGg8L3N1cD4gMjAyMC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBz ZXZlcmFsIGNoYW5nZXMgZnJvbSB2LTEwIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQUklO RyBhbmQgSVBQTSBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4dGVu ZGVkDQogdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0 aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5n IG9uIFdHIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIGJhY2tncm91bmQ6 ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXZlcmFsIHJldmlldyBjb21tZW50cyB3 ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50DQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEw PC9hPi4NCjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgU1BSSU5HIGFuZCBJUFBNIGNoYWlycyBjb25z aWRlcmVkIHRob3NlIGNvbW1lbnRzLCBhbmQgdXBvbiByZXZpZXcgb2YgdGhpcyB2ZXJzaW9uIG9m IHRoZSBkb2N1bWVudCwgZGV0ZXJtaW5lZCB0aGUgZm9sbG93aW5nOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBTUFJJTkcgZG9j dW1lbnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BS SU5HIHdpdGggcG9pbnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5lIGFu eSBleHRlbnNpb25zLiBTZXZlcmFsIGV4dGVuc2lvbnMNCiBpbmNsdWRpbmc8L3NwYW4+PGI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiBDb250cm9sIENvZGUgRmllbGQgRXh0 ZW5zaW9uIGZvciBUV0FNUCBMaWdodCBNZXNzYWdlczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8Yj5Mb3NzDQogTWVhc3VyZW1lbnQgUXVlcnkg TWVzc2FnZSBFeHRlbnNpb25zPC9iPiwgYW5kJm5ic3A7PGI+TG9zcyBNZWFzdXJlbWVudCBSZXNw b25zZSBNZXNzYWdlIEV4dGVuc2lvbnMNCjwvYj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPndl cmUgaW5jbHVkZWQgaW4gPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTA8L2E+IGFuZCBzaG91bGQg YmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcgZG9jdW1lbnQuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBUV0FNUCBleHRlbnNpb25zIGlu Y2x1ZGVkIGluDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMDwvYT4NCjxzcGFuIGxhbmc9IkVO LUNBIj5zaG91bGQgYmUgZGVzY3JpYmVkIGluIGEgbmV3IGRvY3VtZW50IHB1Ymxpc2hlZCBpbiB0 aGUgSVBQTSBXRy4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGVzZSBjb25jbHVz aW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3JzIG9mICZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2Ft cC1zcnBtLTEwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmlu Zy10d2FtcC1zcnBtLTEwPC9hPiB0aGUgcmVzdWx0IG9mIHdoaWNoDQogaXMgdGhlIHB1YmxpY2F0 aW9uIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGRvY3VtZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNy cG0tMTE8L2E+LiBUaGUgc3ViamVjdCBvZiB0aGlzIFdHIGFkb3B0aW9uIGNhbGwuPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXR3YW1wLXNycG0tMDAiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwPC9hPi4gVGhpcyBkb2N1 bWVudCB3aWxsIGJlIHByb2dyZXNzZWQgKGlmIGRldGVybWluZWQNCiBieSB0aGUgV0cpIHdpdGhp biB0aGUgSVBQTSBXRy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiPkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFzZSBpbmRpY2F0 ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0Lg0K PC9zcGFuPlBsZWFzZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBw b3J0IChvciBsYWNrIHRoZXJlb2YpIGFzIHNpbGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJlZCBh cyBjb25zZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5hbGx5LCB0aGUgY2hhaXJzIHdv dWxkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRoZWlyIGVmZm9ydHMgaW4gdGhpcyBt YXR0ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPlRoYW5rcyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkppbSwgQnJ1bm8s ICZhbXA7IEpvZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_3F015E1DDB0647C789CF2122725591C9cablecomcastcom_-- From nobody Thu Nov 12 11:22:14 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1033A0062 for ; Thu, 12 Nov 2020 11:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mJq1-9MuCzEI for ; Thu, 12 Nov 2020 11:22:09 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 B62483A0061 for ; Thu, 12 Nov 2020 11:22:08 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id n15so6694512otl.8 for ; Thu, 12 Nov 2020 11:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=EF7raEQFJq58Pq8JW7yQmxtaH7uaBhBKomk2ZXJsKEc=; b=gBpWQevzQ7CMj7E8Fr0Cuuq4owvfqGl7vI9LAxZLpQc5FAWZFSprLZSlmqGxiG0NrN kEoA6mJ5hVKghXvoYW3Kfxun4kbQ42YDWy/5wjUL+ETAAZIy6VWpX8i7ALQnvu71fs3P CdaLnZyPoa5mAP4RJXjUFFfJvaWl7mvNLAshGT4bDWDgmgQm2LiPbFa0UEvIjMYYwvbt UiMZGHdGSF5OLEjUkSccyM6raJxbekAAnSya959F8U8C2BFECA5b4RVx/FOAWMQGC4Fb RliKH8iDnKgwl3yvRnSVpon++ldGM5Ngc+/GEtF3hfT1yRgroEi8rcRf5yvFQJ/H+yTi CVbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=EF7raEQFJq58Pq8JW7yQmxtaH7uaBhBKomk2ZXJsKEc=; b=m+o3QbM7nIJR5FXKsbugn8HEW5vpTxT8a3OV/HZx50ovXcozV/TTp86ZdfQn9IBkqw AFgbdHLBvCOmlN3rUCAgskGq0ejHyW86ZLSbzYO4uES2Dn4h+sD14GlMHWDql8RjqXIz D0FUmAo6hm+dE0O+YsjoC9RbhpBWaGenV9vuU/z5DLEMP4Ra2vl5tUZa5I4dHgJ3u3Y+ ZNMPjBLReEja9sCNhw1LPylxNrUzy/1rNcUc/7n3Z6tJiiHgQ1Zzze2KMbtRhKVT56Io cca753qot7g7bHylmCWCzEG2v0Mzbom6irAJ0YglLL+NCWCR1KyMw3vseS6uKOxAkZLP a12g== X-Gm-Message-State: AOAM53234xz1XTrWEymbQtaEhzC3PctayFHF4vgmN91PgQ6eb+BgUgBH VRQ7YWhYgOHp+qq1sVBZ9bI= X-Google-Smtp-Source: ABdhPJxg2aYlI3qxrhgbfXqfN/GEYHjmRePUn9SOwGq1NaYtwG834GPh6pRIbK7yRhJ/UXMQwOz6ZA== X-Received: by 2002:a9d:4b14:: with SMTP id q20mr494955otf.269.1605208927873; Thu, 12 Nov 2020 11:22:07 -0800 (PST) Received: from SN6PR1901MB2158.namprd19.prod.outlook.com ([2603:1036:805:3::5]) by smtp.gmail.com with ESMTPSA id 64sm1422098otq.26.2020.11.12.11.22.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2020 11:22:06 -0800 (PST) From: Tarek Saad To: "Stone, Andrew (Nokia - CA/Ottawa)" , "Ketan Talaulikar (ketant)" , Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: ATAwMzc2qfPqQNapuJZk9Cc0Tdn5c80BAToAgAwnQYCAAQLIAIAAlKsAgACQY4CAAUptgIABUQja X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 12 Nov 2020 19:22:05 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> In-Reply-To: <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_SN6PR1901MB2158E62ACC8F0645A3AE283BFCE70SN6PR1901MB2158_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 19:22:13 -0000 --_000_SN6PR1901MB2158E62ACC8F0645A3AE283BFCE70SN6PR1901MB2158_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, See inline for some comments.. From: spring on behalf of "Stone, Andrew (Nokia -= CA/Ottawa)" Date: Wednesday, November 11, 2020 at 6:16 PM To: "Ketan Talaulikar (ketant)" , Vish= nu Pavan Beeram Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Ketan, Pavan, Good discussion. Just going to chip in some thoughts=85 One of the elements I personally like of the SR Policy model is that many C= andidate Paths may exist, but only one may be active and a candidate path c= ontains 1 or many SID lists. It=92s a simple parent/child - root/leaf tree = with very clear rules within the SR policy context instance. From my point = of view, what is being proposed in the -09 document still follows those rul= es and the general top-down tree behaviour. Despite the composite CP pointi= ng to a different SR Policy, that SR Policy still follows all of the same r= ules top down in its own isolated context. Compare that to say, having a ca= ndidate path contain a child that points to other candidate paths within th= e same SR Policy context: within the same context a child is pointing to a = sibling of its parent. The rules now have to bend slightly. As noted below,= some of the rules around what is considered an active candidate path would= need to change, since the constituents essentially are active (they=92re i= nstalled) despite not being thought of as being active. Note that the propo= sed new text below says =93The preference is ignored for each of the two co= nstituent candidate paths" which is also a new rule, however one could perh= aps work around that by just requiring the preference on the constituents b= e less preferred than any other standard or composite CP =96 but that raise= s its own troubles with multiple sources of provisioning =96 which leads to= a rule asking to ignore the preference. In summary, from my p.o.v new rule= s in the hierarchy would need to be introduced. Regarding steering into an SR Policy, yes, you burn colors in doing this (3= 2bits...) and it would require deploying an entirely dedicated SR Policy co= nstruct, and run the risk of steering =91other=92 traffic into that policy.= If this is a concern, would the composite SR Policies not be engineered in= a way where the color block used is designed to not be used elsewhere in t= he network for other purposes? [TS]: Today colors of SR Policies that are instantiated =93on-demand=94 or = instantiated via PCEP from a PCE are derived from the intent/service. With = the hierarchical SR policies proposal, a PCE may need to instantiate the co= lored child SR policies on-demand too, but it is not clear where the colors= of those child SR policies would be derived from. As Andrew suggests, a bl= ock of colors could be carved from every headend=92s space -- specifically = for this purpose and be managed by the PCE. Alternatively, one could consid= er creating such SR Policies with a special/reserved color that would simpl= ify their creation. My understanding is that there are other cases where SR= Policies may be instantiated (e.g. for tactical TE =96 e.g. on P nodes) th= at would not require color resolution, and creation of those could benefit = from a reserved color too. Regards, Tarek Is there not a different but kind of similar problem with Binding SIDs, in = that they=92re eligible for use by other consumers even if not directly int= ended? (although at least BSIDs are optional and not mandatory). In additio= n to the split TE cases, being able to have an SR Policy steer into another= SR Policy might also have some value in a backup candidate scenario when o= ne has multiple SR Policies with the same endpoint, but can share a common = fallback/best effort candidate path. The entity (I'm thinking PCE) managing= that would only need to maintain the fallback/best effort CP SID list(s), = instead of one for each N * CPs. Something I haven=92t concluded to myself yet are questions such as: 1. does having a candidate path steer into another SR Policy satisfy = the ability to do various sub-path specific TE/constraint/object combinatio= ns sufficiently? 2. is the model relatively straight forward to map into yang/bgp/pcep= etc..? 3. does using an additional SR Policy create too much overhead or sta= te burn to configure, deploy, manage, track etc.. ? Cheers Andrew From: spring on behalf of "Ketan Talaulikar (keta= nt)" Date: Tuesday, November 10, 2020 at 10:33 PM To: Vishnu Pavan Beeram Cc: "spring@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Pavan, Please check inline below. From: Vishnu Pavan Beeram Sent: 11 November 2020 00:26 To: Ketan Talaulikar (ketant) Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Ketan, Hi! Please see inline for responses (prefixed VPB). Regards, -Pavan On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) > wrote: Hi Pavan, Please check inline below. From: Vishnu Pavan Beeram > Sent: 10 November 2020 00:08 To: Ketan Talaulikar (ketant) > Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Ketan, Much Thanks for taking a stab at addressing the composite candidate path us= e-case! We seem to be converging. [KT] Thanks for that feedback and confirmation that the proposal in the dra= ft does address the use-case. I believe we are now discussing the mechanics= of how this is achieved within the current SR Policy framework. However, I don=92t understand why you need to use additional SR policies (a= nd unnecessarily burn additional colors) to address this. [KT] I do not follow what you mean by =93burn additional colors=94. Color i= s just a 32 bit number that indicates the =93intent=94 and is not really a = scarce resource. Assigning a color to =93a composite intent=94 seems like a= seamless way to integrate with existing mechanisms for Steering over SR Po= licies. This gives the flexibility for say some BGP services to be steered = over the constituent explicit/dynamic intent while others can steer over a = composite intent that includes those individual explicit/dynamic intents. [VPB] The =93flexibility=94 that you are referring to is undesirable for th= is use-case. For the traffic-split use-case, we don=92t want any other serv= ices to be directly steered over the constituents when they are part of a c= omposite candidate path. [KT] I believe the use-case that you are referring to was for splitting som= e traffic for a service over a blue plane and the rest over a red plane. At= the same time, there may be other services that utilize only a single plan= e. The flexibility that I was referring to was to enable/allow for either o= f the two scenarios and there may be other/more use-cases for which we need= a more generic framework. The current proposal in the draft would have been acceptable if the constit= uent SR Policies were uncolored =96 but that would violate the current rule= s imposed by the draft. Why can=92t the composite candidate path just be a grouping of explicit can= didate paths and/or dynamic candidate paths? [KT] This is because in the SR Policy framework, there is only a single act= ive CP =96 it may be explicit or dynamic. Now we=92ve added another Composi= te CP type to cover this specific use-case. Your proposal will result in 3 = candidate paths being active within the same SR Policy =96 one each of the = explicit and dynamic CP and then additionally the Composite CP. This breaks= the existing rules for selection of CP based on preference and mechanisms = like fallback between CPs. While the current proposal in the draft provides= a way to address the new use-case with a backwards compatible extension to= the SR Policy framework. [VPB] The proposal in my previous email is backwards compatible and does no= t intend to break any existing rules for deeming a candidate path active. A= s per the rules that are outlined in Section 2.9, only the composite candid= ate path is =93active=94 given its preference. The constituent candidate pa= ths will never be active on their own. If it is necessary, we can add a sta= tement in Section 2.9 to explicitly state that the candidate path selection= criteria does not apply to the constituent candidate paths. [KT] When a CP is =93active=94 it is actually the one that is being used fo= r forwarding. Thanks, Ketan Thanks, Ketan Consider the following changes: ** Section 2.2 OLD: A composite candidate path acts as a container for grouping of SR Policies. The composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies. The following criteria apply for inclusion of constituent SR Policies using a composite candidate path under a parent SR Policy: o the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical o The colors of each of the constituent SR Policies and the parent SR Policy MUST be different o the constituent SR Policies MUST NOT use composite candidate paths Each constituent SR Policy of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. NEW: A composite candidate path acts as a container for grouping of explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints. The composite candidate path construct enables load-balanced steering of packet-flows over a set of constituent candidate paths. The following criteria apply for constituent candidate paths under a composite candidate path: o the preference of the constituent candidate path MUST be ignored. o the constituent candidate path MUST NOT be a composite candidate path Each constituent candidate path of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. ** ** Section 2.11 OLD: When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load balancing of flows steered into a constituent SR Policy is performed based on the weights of the Segment-List of the active candidate path of that constituent SR Policy. NEW: When a composite candidate path is active, the fraction of flows steered into each constituent candidate path is equal to the relative weight of each constituent candidate path. Further load balancing of flows steered into a constituent candidate path is performed based on the weights of each associated Segment-List. ** ** Section 2.13 OLD: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path CP1 Preference 200 Weight W1, SR policy Weight W2, SR policy The constituent SR Policies POL1 and POL2 have information model as described at the start of this section. They are referenced only by color in the composite candidate path since their headend and endpoint are identical to the POL100. The valid Segment-Lists of the active candidate path of POL1 and POL2 are installed in the forwarding. Traffic steered on POL100 is flow-based hashed on POL1 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. NEW: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path Comp-CP Preference 200 Weight W1, Candidate-path CP1 Weight W2, Candidate-path CP2 Candidate-path CP1 Weight W11, SID-List1 Weight W12, SID-List2 Candidate-path CP2 Weight W21, SID-List3 Weight W22, SID-List4 Comp-CP is a composite candidate path with two constituents, CP1 and CP2. The preference is ignored for each of the two constituent candidate paths. The valid Segment-Lists of the two constituent candidate paths are installed in the forwarding. Traffic steered on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent candidate path, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. ** ** Section 5.3 OLD: A composite candidate path is specified as a group of its constituent SR Policies. A composite candidate path is valid when it has at least one valid constituent SR Policy. NEW: A composite candidate path is specified as a group of its constituent candidate paths. A composite candidate path is valid when it has at least one valid constituent candidate path. ** Regards, -Pavan On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) > wrote: Hello All, We have just posted an update for the draft and following is the summary of= changes: 1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring= /fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spr= ing/d9oSSbgp0jCExRx0SXyBY0CyqXU/) 2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08. 3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received. 4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHD= N0IvFhw9id40/) Please let know your comments/feedback. Thanks, Ketan (on behalf of co-authors) -----Original Message----- From: spring > On B= ehalf Of internet-drafts@ietf.org Sent: 02 November 2020 06:27 To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking WG of = the IETF. Title : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-09.txt Pages : 37 Date : 2020-11-01 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-polic= y-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_SN6PR1901MB2158E62ACC8F0645A3AE283BFCE70SN6PR1901MB2158_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi all,<= /span>

     

    See inline for some= comments..

     

    From: spring <spring-b= ounces@ietf.org> on behalf of "Stone, Andrew (Nokia - CA/Ottawa)&qu= ot; <andrew.stone@nokia.com>
    Date: Wednesday, November 11, 2020 at 6:16 PM
    To: "Ketan Talaulikar (ketant)" <ketant=3D40cisco.com@d= marc.ietf.org>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Cc: "spring@ietf.org" <spring@ietf.org>
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Hi Ketan, Pavan,

     

    Good discussion. Just goi= ng to chip in some thoughts=85

     

    One of the elements I per= sonally like of the SR Policy model is that many Candidate Paths may exist,= but only one may be active and a candidate path contains 1 or many SID lis= ts. It=92s a simple parent/child - root/leaf tree with very clear rules within the SR policy context instance. From my = point of view, what is being proposed in the -09 document still follows tho= se rules and the general top-down tree behaviour. Despite the composite CP = pointing to a different SR Policy, that SR Policy still follows all of the same rules top down in its own iso= lated context. Compare that to say, having a candidate path contain a child= that points to other candidate paths within the same SR Policy context: wi= thin the same context a child is pointing to a sibling of its parent. The rules now have to bend slightly. = As noted below, some of the rules around what is considered an active candi= date path would need to change, since the constituents essentially are acti= ve (they=92re installed) despite not being thought of as being active. Note that the proposed new text below sa= ys =93The preference is ignored for each of the two constituent candidate p= aths" which is also a new rule, however one could perhaps work around = that by just requiring the preference on the constituents be less preferred than any other standard or composite CP= =96 but that raises its own troubles with multiple sources of provisioning= =96 which leads to a rule asking to ignore the preference. In summary, fro= m my p.o.v new rules in the hierarchy would need to be introduced.

     

    Regarding steering into a= n SR Policy, yes, you burn colors in doing this (32bits...) and it would re= quire deploying an entirely dedicated SR Policy construct, and run the risk= of steering =91other=92 traffic into that policy. If this is a concern, would the composite SR Policies not be engin= eered in a way where the color block used is designed to not be used elsewh= ere in the network for other purposes?

    [TS]: Today colors = of SR Policies that are instantiated =93on-demand=94 or instantiated via PC= EP from a PCE are derived from the intent/service. With the hierarchical SR= policies proposal, a PCE may need to instantiate the colored child SR policies on-demand too, but it is not clear where the= colors of those child SR policies would be derived from. As Andrew suggest= s, a block of colors could be carved from every headend=92s space -- specif= ically for this purpose and be managed by the PCE. Alternatively, one could consider creating such SR Policies wi= th a special/reserved color that would simplify their creation. My understa= nding is that there are other cases where SR Policies may be instantiated (= e.g. for tactical TE =96 e.g. on P nodes) that would not require color resolution, and creation of those coul= d benefit from a reserved color too.

     

    Regards,=

    Tarek

     

     

     

    Is there not a different = but kind of similar problem with Binding SIDs, in that they=92re eligible f= or use by other consumers even if not directly intended? (although at least= BSIDs are optional and not mandatory). In addition to the split TE cases, being able to have an SR Policy steer i= nto another SR Policy might also have some value in a backup candidate scen= ario when one has multiple SR Policies with the same endpoint, but can shar= e a common fallback/best effort candidate path. The entity (I'm thinking PCE) managing that would o= nly need to maintain the fallback/best effort CP SID list(s), instead of on= e for each N * CPs.

     

    Something I haven=92t con= cluded to myself yet are questions such as:

     

    1.       does having a candidate path steer into another SR = Policy satisfy the ability to do various sub-path specific TE/constraint/ob= ject combinations sufficiently?

    2.       is the model relatively straight forward to map int= o yang/bgp/pcep etc..?

    3.       does using an additional SR Policy create too much = overhead or state burn to configure, deploy, manage, track etc.. ?

     

    Cheers

    Andrew

     

    From: spring <spring-b= ounces@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <= ketant=3D40cisco.com@dmarc.ietf.org>
    Date: Tuesday, November 10, 2020 at 10:33 PM
    To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Cc: "spring@ietf.org" <spring@ietf.org>
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Hi Pavan,

     

    Please check inline below= .

     

    From: Vishnu Pavan= Beeram <vishnupavan@gmail.com>
    Sent: 11 November 2020 00:26
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf.org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Ketan, Hi!

    Please see inline for responses (prefixed VPB).

    Regards,
    -Pavan

     

    On Tue, Nov 10, 2020 at 4= :04 AM Ketan Talaulikar (ketant) <ke= tant@cisco.com> wrote:

    Hi Pavan,

     

    Please check inline below= .

     

    From: Vishnu Pavan= Beeram <vish= nupavan@gmail.com>
    Sent: 10 November 2020 00:08
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf= .org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Ketan,

     

    Much Thanks for taking a stab = at addressing the composite candidate path use-case! We seem to be convergi= ng.

    [KT] Thanks for tha= t feedback and confirmation that the proposal in the draft does address the= use-case. I believe we are now discussing the mechanics of how this is ach= ieved within the current SR Policy framework. 

     =

    However, I don=92t understand why you need to use addit= ional SR policies (and unnecessarily burn additional colors) to address thi= s.

    [KT] I do not follo= w what you mean by =93burn additional colors=94. Color is just a 32 bit num= ber that indicates the =93intent=94 and is not really a scarce resource. As= signing a color to =93a composite intent=94 seems like a seamless way to integrate with existing mechanisms for Steering ove= r SR Policies. This gives the flexibility for say some BGP services to be s= teered over the constituent explicit/dynamic intent while others can steer = over a composite intent that includes those individual explicit/dynamic intents.

     

    [VPB] The =93flexibility= =94 that you are referring to is undesirable for this use-case. For the tra= ffic-split use-case, we don=92t want any other services to be directly stee= red over the constituents when they are part of a composite candidate path.

    [KT] I believe the use-case that you are referring to was for sp= litting some traffic for a service over a blue plane and the rest over a re= d plane. At the same time, there may be other services that utilize only a single plane. The flexibility that I wa= s referring to was to enable/allow for either of the two scenarios and ther= e may be other/more use-cases for which we need a more generic framework.

     

    The current proposal in t= he draft would have been acceptable if the constituent SR Policies were unc= olored =96 but that would violate the current rules imposed by the draft.&n= bsp;

     

     =

    Why can=92t the composite candidate path just be a grou= ping of explicit candidate paths and/or dynamic candidate paths?

    [KT] This is becaus= e in the SR Policy framework, there is only a single active CP =96 it may b= e explicit or dynamic. Now we=92ve added another Composite CP type to cover= this specific use-case. Your proposal will result in 3 candidate paths being active within the same SR Policy =96 one= each of the explicit and dynamic CP and then additionally the Composite CP= . This breaks the existing rules for selection of CP based on preference an= d mechanisms like fallback between CPs. While the current proposal in the draft provides a way to address the= new use-case with a backwards compatible extension to the SR Policy framew= ork.

     

    [VPB] The proposal in my = previous email is backwards compatible and does not intend to break any exi= sting rules for deeming a candidate path active. As per the rules that are = outlined in Section 2.9, only the composite candidate path is =93active=94 given its preference. The constituent candi= date paths will never be active on their own. If it is necessary, we can ad= d a statement in Section 2.9 to explicitly state that the candidate path se= lection criteria does not apply to the constituent candidate paths. 

    [KT] When a CP is =93active=94 it is actually the one that is be= ing used for forwarding.

     

    Thanks,

    Ketan

     

     =

    Thanks,

    Ketan<= /o:p>

     

    Consider the following changes= :

     

    ** Section 2.2

    OLD:

       A composite candid=
ate path acts as a container for grouping of SR
       Policies.  Th=
e composite candidate path construct enables combination<=
/pre>

       of SR Policies, ea=
ch with explicit candidate paths and/or dynamic
    

       candidate paths wi=
th potentially different optimization objectives
    

       and constraints, f=
or a load-balanced steering of packet flows over
    

       its constituent SR=
 Policies.  The following criteria apply for
    

       inclusion of const=
ituent SR Policies using a composite candidate path
    

       under a parent SR =
Policy:
    

     
    

       o  the endpoi=
nts of the constituent SR Policies and the parent SR

          =
Policy MUST be identical
    

     
    

       o  The colors=
 of each of the constituent SR Policies and the parent

          =
SR Policy MUST be different
    

     
    

       o  the consti=
tuent SR Policies MUST NOT use composite candidate paths<=
/pre>

     
    

       Each constituent S=
R Policy of a composite candidate path is
    

       associated with a =
weight for load-balancing purposes (refer
    

       Section 2.11=
 for details).  The default weight is 1.
    

     
    

    NEW:
    

       A composite candid=
ate path acts as a container for grouping of
    

       explicit candidate=
 paths and/or dynamic candidate paths with 
    

       potentially d=
ifferent optimization objectives and constraints.
    

       The composite cand=
idate path construct enables load-balanced
    

       steering of packet=
-flows over a set of constituent candidate
    

       paths. The followi=
ng criteria apply for constituent candidate 
    

      &nb=
sp;paths under a composite candidate path:
    

     
    

       o  the prefer=
ence of the constituent candidate path MUST be 
    

      &nb=
sp;   ignored. 
    

     
    

       o  the consti=
tuent candidate path MUST NOT be a composite candidate 

         &=
nbsp;path
    

     
    

       Each constituent c=
andidate path of a composite candidate path is
    

       associated with a =
weight for load-balancing purposes (refer
    

       Section 2.11=
 for details).  The default weight is 1.
    

     
    

    **
    

     
    

    ** Section 2.11
    

     
    

    OLD:
    

    
   When a composite candidate path is active, the fr=
action of flows
    

    
   steered into each constituent SR Policy is equal =
to the relative
    

    
   weight of each constituent SR Policy.  Further
 load balancing of
    

    
   flows steered into a constituent SR Policy is per=
formed based on the
    

    
   weights of the Segment-List of the active candida=
te path of that
    

    
   constituent SR Policy.
    

     
    

    NEW:
    

    
   When a composite candidate path is active, the fr=
action of flows
    

    
   steered into each constituent candidate path is e=
qual to the relative
    

    
   weight of each constituent candidate path. <=
span class=3D"gmail-m4413790711013952628gmail-apple-converted-space"> =
Further
 load balancing of
    

    
   flows steered into a constituent candidate path i=
s performed based on
    

    
   the weights of each associated Segment-List.
    

    
 
    

    **
    

     
    

    ** Section 2.13
    

     
    

    OLD:
    

    
   The information model of SR Policy POL100 having =
a composite
    

    
   candidate path is the following:
    

    
 
    

    
   SR policy POL100 <headend =3D H1, color =3D 10=
0, endpoint =3D E1>
    

    
        Candidate-path CP1 =
<protocol-origin =3D 20, originator =3D
    

    
   100:1.1.1.1, discriminator =3D 1><=
/o:p>
    

    
            Preference 200
    

    
            Weight W1, SR policy <color =3D 1>
    

    
            Weight W2, SR policy <color =3D 2>
    

    
 
    

    
   The constituent SR Policies POL1 and POL2 have in=
formation model as
    

    
   described at the start of this section.  They
 are referenced only by
    

    
   color in the composite candidate path since their=
 headend and
    

    
   endpoint are identical to the POL100.  The
 valid Segment-Lists of the
    

    
   active candidate path of POL1 and POL2 are instal=
led in the
    

    
   forwarding.  Traffic steered on POL10=
0
 is flow-based hashed on POL1
    

    
   with a ratio W1/(W1+W2).  Within the
 POL1, the flow-based hashing
    

    
   over its Segment-Lists are performed as described=
 earlier in this
    

    
   section.
    

     
    

    NEW:
    

    
   The information model of SR Policy POL100 having =
a composite
    

    
   candidate path is the following:
    

    
 
    

    
   SR policy POL100 <headend =3D H1, color =3D 10=
0, endpoint =3D E1>
    

       &=
nbsp;    Candidate-path Comp-CP <protocol-origin =
=3D 20, originator =3D
    

    
   100:1.1.1.1, discriminator =3D 1><=
/o:p>
    

    
            Preference 200
    

       &=
nbsp;        Weight W1, Candidate=
-path CP1
    

    
            Weight W2, Candidate-path CP2      
    

    
        Candidate-path CP1 =
<protocol-origin =3D 20, originator =3D

    

       100:1.=
1.1.1, discriminator =3D 2>
    

       &=
nbsp;         Weight W11, SI=
D-List1 <SID11...SID1i>
    

    
           &nb=
sp;&n=
bsp;Weight W12, SID-List2 <SID21...SID2j>

       &=
nbsp;    Candidate-path CP2 <protocol-origin =3D 20, orig=
inator =3D

    

       100:1.=
1.1.1, discriminator =3D 3>
    

       &=
nbsp;         Weight W21, SI=
D-List3 <SID31...SID3i>
    

    
           &nb=
sp;&n=
bsp;Weight W22, SID-List4 <SID41...SID4j>

    
 
    

       Comp-C=
P is a composite candidate path with two constituents, CP1
    

    
   and CP2. The preference is ignored for each of th=
e two constituent
    

       candid=
ate paths. The valid Segment-Lists of the two constituent

    

       candid=
ate paths are installed in the forwarding. Traffic steered=

    

    
   on
Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of
    

    
   W1/(W1+W2) and W2/(W1+W2) respectively. Within each cons=
tituent

    

       candid=
ate path, the flow-based hashing over its Segment-Lists are

    

       perfor=
med as described earlier in this section.
    

     <=
/o:p>
    

    **
    

     
    

    ** Section 5.3
    

     
    

    OLD:
    

    
   A composite candidate path is specified as a grou=
p of its constituent
    

    
   SR Policies.
    

    
 
    

    
   A composite candidate path is valid when it has a=
t least one valid
    

    
   constituent SR Policy.
    

     
    

    NEW:
    

    
   A composite candidate path is specified as a grou=
p of its constituent
    

    
   candidate paths.
    

    
 
    

    
   A composite candidate path is valid when it has a=
t least one valid
    

    
   constituent candidate path.
    

     
    

    
**
    

     
    

    Regards,
    

    -Pavan
    

    
 
    

     

     

    On Sun, Nov 1, 2020 at 7:= 02 PM Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org> wrote:=

    Hello All,

    We have just posted an update for the draft and following is the summary of= changes:

    1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
    2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08.
    3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received.
    4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref :     https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

    Please let know your comments/feedback.

    Thanks,
    Ketan (on behalf of co-authors)

    -----Original Message-----
    From: spring <    spring-bounces@ietf.org> On Behalf Of internet-draf= ts@ietf.org
    Sent: 02 November 2020 06:27
    To: i-d-announce= @ietf.org
    Cc: spring@ietf.org
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

            Title           := Segment Routing Policy Architecture
            Authors         : Clar= ence Filsfils
                         = ;     Ketan Talaulikar
                         = ;     Daniel Voyer
                         = ;     Alex Bogdanov
                         = ;     Paul Mattes
            Filename        : draft-iet= f-spring-segment-routing-policy-09.txt
            Pages           := 37
            Date            := 2020-11-01

    Abstract:
       Segment Routing (SR) allows a headend node to steer a packet f= low
       along any path.  Intermediate per-flow states are elimina= ted thanks
       to source routing.  The headend node steers a flow into a= n SR Policy.
       The header of a packet steered in an SR Policy is augmented wi= th an
       ordered list of segments associated with that SR Policy. = This
       document details the concepts of SR Policy and steering into a= n SR
       Policy.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-spring-se= gment-routing-policy-09
    https://datatracker.ietf.org/doc/html/= draft-ietf-spring-segment-routing-policy-09

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-spring-segment-routing-policy-09


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

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


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

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

    --_000_SN6PR1901MB2158E62ACC8F0645A3AE283BFCE70SN6PR1901MB2158_-- From nobody Thu Nov 12 13:02:10 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77113A0880 for ; Thu, 12 Nov 2020 13:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH4238MAGQ-3 for ; Thu, 12 Nov 2020 13:02:05 -0800 (PST) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3C33A0879 for ; Thu, 12 Nov 2020 13:02:04 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp2056.outbound.protection.outlook.com [104.47.10.56]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-137-UeXSqTPJMCC9OSPpDoVsNw-1; Thu, 12 Nov 2020 21:01:57 +0000 X-MC-Unique: UeXSqTPJMCC9OSPpDoVsNw-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB4143.eurprd03.prod.outlook.com (2603:10a6:803:73::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Thu, 12 Nov 2020 21:01:55 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::fd6d:5942:84f5:3812]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::fd6d:5942:84f5:3812%3]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 21:01:54 +0000 From: Andrew Alston To: Weiqiang Cheng , "spring@ietf.org" CC: 'srcomp' , "spring-chairs@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt Thread-Index: Adaw8qWMM8NXBKsVRSCF3jBwduJ55QH3lL/wABjpqnk= Date: Thu, 12 Nov 2020 21:01:54 +0000 Message-ID: References: <08c001d6b8d3$010d08d0$03271a70$@com> In-Reply-To: <08c001d6b8d3$010d08d0$03271a70$@com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [152.108.254.20] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 481b3a79-0e9e-477b-b36c-08d8874e2fa6 x-ms-traffictypediagnostic: VI1PR03MB4143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: fBgDxWs0UZ/squO7lHO0G+YSNqMNdlWAzrxEyR2/Pe4qmGW6YR3lgtlTkeSGnIVmsEr3zxAFrfQEIMJfOw0KFxfVFU5m+BgAa6zvbYzKUGNEOb/kjcbXWDJ9cBApQ/Hded+N83MAOoSHYgFMDVxEVgd2TZC12DAj+kISTAGcdJgAOeNWZcw1LD6ydR+PoaTE/bwW9kvXlSh1kIQvbdMpAWE6G+NYy4QHNiicqWqYVjObyHM/pjKWII2WSAEUdjZUlALIx0kQcGq7TuMy8ewxssVUidtm7UFk7aWCb5Y4ucxtcHnaI5Nyv1s4/xYdb4H7j+wDI0klSk2788sJ9oyYS8qjNiV3NYRwhkPPvo14cLZsC77T80kfymGDmrmDP+Tf1zLywzOWFwIPnC6/vV7X5A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(346002)(376002)(136003)(8676002)(66574015)(4001150100001)(53546011)(54906003)(6506007)(55016002)(110136005)(2906002)(15650500001)(8936002)(33656002)(9686003)(83380400001)(5660300002)(52536014)(186003)(86362001)(91956017)(316002)(166002)(4326008)(64756008)(71200400001)(66946007)(966005)(478600001)(26005)(7696005)(66446008)(66476007)(66556008)(76116006); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata: vQaQqQj2o5GPbJrz7XVVOlb8Wyuj3dr9RILlAhGb9FRYluqiKzvPnajhSRmV5WpGJIHrIwptFiYfP6iIZoN0GfKPms+H2JPrmJpZ5q7VwJkObKhHcuq0MUlmmOsiW4VzQup9KVOrqVKfG66UO9RhMyjNiyaEUv9C0b7X5UE6c9M8ugpUXvRZ1glQnrUtvZcrcsbgKcBb5G4QM+Oc3GwMnzX4MLnAItXjMQ/SKqmD8YUnSfB0L/cvOYjJEPf82fQGSB//4JeArOEWeedEYvzE/uTKLgK/Nl/WC+siooTtrRI3aPbJuEx/YOWz+JARHR9Va0/iiDVKn18V+MCabVwHwpzQsWBOi5LZpx2omb17luYDRaF2f90KOxlQSh19KReg2kn6+ue9aQhVo3/3dSGu/qoziGmRPwt7wxbVIxV5iCpeS7xoZszDK86WBUkWd9Iy1pb4YHAfdKTPs26Q9F/cZXJFszrsXJUrtqem10qxJs8++HrGOdTkbAqDwCPFTeQjxDqKoXcZ7CWXTR1nYxw5XUSvqbf9wDpvwnePeSHTXhFFnJzczJ1FzzqUkX8KKBOd0ShAVgN4oS46CI43iTvQZWVm58UWxO+7F/u0KycBxiZHhYr+Zbh+a5lOVOesJt5QPz0cRLkIUj7kbyGiX8JD+sQh81iOhdqHuXX9gmAq4vI1LXp3lAE0vhVvQMpoe1IQ+GEsvJoO9q8lyXigdXoSWaxkomTceGsC0Tms8iz8697LogAgQb6dXsoVa6Vilap/D6jgWBrB+3HmCe3TqFlk2D1nbGCJnawoz2DYde6mhmpG6HM5qyWApu0pL5kMUSI0Rijq6SdLgGoelbl3a8rhnnStUuZZOIRgF0ocqoOfV7THJJL5Vy4s2VQz7kGsIPisbDzWZB9tHSTRIoAWoP4SlA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 481b3a79-0e9e-477b-b36c-08d8874e2fa6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 21:01:54.7179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZxPfypfs4pohLppmPkQkOI4drsN0a0x0e3pRlGtYyiiYtGJ7dG1pIYDFfyQGXz32X4N4dEta6+Jlzdq05OC7CrQ9qibD22mJwqqoRPAwDZM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4143 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056546242C4F37B521403BAEEE70VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:02:09 -0000 --_000_VI1PR03MB5056546242C4F37B521403BAEEE70VI1PR03MB5056eurp_ Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 RXJtLA0KDQpPayCoQyBzbyCoQyB3ZSBoYXZlIHdhaXRlZCA2IG1vbnRocyBmb3IgYSBkb2N1bWVu dCCoQyB0aGF0IHdlIHdpbGwgZ28gaW50byBTUFJJTkcgYW5kIDZtYW4gdG8gZGlzY3VzcyCoQyBh bmQgd2hhdCB3ZSBoYXZlIGhlcmUgaW4gbXkgdmlldyCoQyBpcyBhIGRvY3VtZW50IHRoYXQgc2F5 cyBwcmVjaXNlbHkgbm90aGluZy4NCg0KSaGvbSBnb2luZyB0byB0YWtlIHRoaXMgc2VjdGlvbiBi eSBzZWN0aW9uIKhDIGFuZCBJIHdvdWxkIGhhdmUgaG9wZWQgc2VuZGluZyBhbiBlbWFpbCBsaWtl IHRoaXMgqEMgdGhhdCBpdCB3b3VsZCBiZSBhIGxvdCBsb25nZXIgdGhhbiBpdCBpcyBnb2luZyB0 byBiZSCoQyBidXQgqEMgc2luY2UgdGhlcmUgaXMgc28gbGl0dGxlIGhlcmUgqEMgaXQgcHJvYmFi bHkgd29uoa90IGJlIGFsbCB0aGF0IGxvbmcuDQoNClNvIGxldKGvcyBzdGFydCBhdCBzZWN0aW9u IDMgqEMNCg0KU2VjdGlvbiAzLjEuMSBpcyB3ZWxsLCBqdXN0IHByZXR0eSBvYnZpb3VzIGFuZCBn b2VzIHdpdGhvdXQgc3RhdGluZw0KU2VjdGlvbiAzLjEuMiBhZ2FpbiwgcHJldHR5IG9idmlvdXMg dGhhdCBmb3J3YXJkaW5nIGVmZmljaWVuY3kgaXMgaW1wb3J0YW50DQpTZWN0aW9uIDMuMS4zIGFn YWluLCBkb26hr3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcgbXVjaCB0byBjb21tZW50IG9uIGhl cmUgqEMgaXRzIHN0YXRpbmcgdGhlIG9idmlvdXMNCg0KVGhlbiB3ZSBnZXQgdG8gU2VjdGlvbiA0 Lg0KNC4xLjEgU1J2NiBCYXNlZCCoQyBJIGRvbqGvdCBiZWxpZXZlIGlzIHdpdGhpbiB0aGUgc2Nv cGUgb2YgdGhlIGNoYXJ0ZXIgqEMgdGhlIGNoYXJ0ZXIgZG9lcyBub3Qgc2F5IKhDIGRlc2lnbiBh IHNvbHV0aW9uIKhDIGl0IHNheXMgqEMgc3RhdGUgdGhlIHJlcXVpcmVtZW50cyBvZiBhIHNvbHV0 aW9uIGZvciBjb21wcmVzc2lvbiBvZiBzZWdtZW50IHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIHVz ZSBvdmVyIGlwdjYuICBOb3doZXJlIGRvZXMgaXQgc2F5IGZvciB0aGUgZGVzaWduIHRlYW0gdG8g ZGVjaWRlIGlmIHRoYXQgaXMgdGllZCB0byBvbmUgcHJvdG9jb2wgb3IgYW5vdGhlci4NCjQuMS4y IFNlZSBhYm92ZSBjb21tZW50DQo0LjEuMyBObyBpc3N1ZXMNCjQuMS40IERvbqGvdCBoYXZlIGEg bWFqb3IgcHJvYmxlbSB3aXRoIHRoaXMNCjQuMS41IFBsZWFzZSBleHBsYWluIGhvdyB5b3Ugd291 bGQgYWNoaWV2ZSBjcm9zc2luZyBib3VuZGFyaWVzIHVzaW5nIHNvbWV0aGluZyBsaWtlIGEgYmlu ZGluZyBTSUQgb3Igc29tZXRoaW5nIHRvIHRoYXQgZWZmZWN0IHdoaWxlIGJlaW5nIGNvbXBsaWFu dCB3aXRoIHRoaXMgc2VjdGlvbg0KDQpTZWN0aW9uIDUNCkkgaGF2ZSBhIG1ham9yIGlzc3VlIHdp dGggZXhwbGljaXRseSBzdGF0aW5nIHlvdSBuZWVkIHRvIHN1cHBvcnQgdGhlIGJlaGF2aW9ycyBp biBuZXR3b3JrIHByb2dyYW1taW5nIKhDIHRoYXQgaXMgZW50aXJlbHkgb3V0c2lkZSBvZiB0aGUg Y2hhcnRlci4gICBBZ2FpbiwgdGhlIGNoYXJ0ZXIgc3RhdGVzIKhDIGEgc29sdXRpb24gZm9yIGNv bXByZXNzaW9uIG9mIHNlZ21lbnQgcm91dGluZyBpbmZvcm1hdGlvbiBmb3IgdXNlIG92ZXIgaXB2 Ni4gIFRoZXJlIG1heSB3ZWxsIGJlIHNvbHV0aW9ucyB3aXRoaW4gdGhpcyB0aGF0IHNjb3BlIHRo YXQgZG8gY29uZm9ybSB0byB0aGUgYmVoYXZpb3JzIG9mIG5ldHdvcmsgcHJvZ3JhbW1pbmcgqEMg YnV0IHRoZXJlIG1heSBiZSBzb2x1dGlvbnMgd2hlcmUgc3VjaCBjb21wcmVzc2lvbiBpcyB1c2Vk IGZvciBwdXJwb3NlcyBlbnRpcmVseSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBkZXNjcmliZWQgaW4g bmV0d29yayBwcm9ncmFtbWluZyCoQyBhbmQgaGF2ZSBubyByZWxhdGlvbiB0byBuZXR3b3JrIHBy b2dyYW1taW5nIGF0IGFsbC4NCg0KTm93IGxldHMgbG9vayBhdCB3aGF0IGVsc2UgdGhlIGNoYXJ0 ZXIgc2F5cy4NCg0KVGhlIGNoYXJ0ZXIgc3RhdGVzIHRoYXQgdGhlcmUgd291bGQgYmUgYSBjb21w YXJpc29uIG9mIGFwcHJvYWNoZXMgYW5kIG1ldGhvZHMgcmVsYXRlZCB0byBjb21wcmVzc2lvbiCo QyB0aGF0IGlzIG5vdCBpbiB0aGlzIGRvY3VtZW50IGF0IGFsbCCoQyBpdCBpcyBlbnRpcmVseSBh YnNlbnQuIEl0IHN0YXRlcyB0aGF0IHRoZSBkZXNpZ24gdGVhbSB3b3VsZCBsb29rIGludG8gdGhl IGN1cnJlbnQgc29sdXRpb25zIGFuZCBzdGF0ZSBpZiB0aGV5IGFncmVlZCBpZiB0aGVyZSB3YXMg c3BhY2UgZm9yIG1vcmUgdGhhbiBvbmUgc29sdXRpb24gb3Igbm90IKhDIGFuZCBpZiB0aGV5IHdl cmUgaW4gYWdyZWVtZW50IKhDIHRoYXQgaXMgZW50aXJlbHkgbWlzc2luZyBmcm9tIHRoaXMgZG9j dW1lbnQuDQoNClRoZSBhYm92ZSBwb2ludHMgZm9ybSBlZmZlY3RpdmVseSBoYWxmIHRoZSBjaGFy dGVyLg0KDQpTbyCoQyB3aXRoIGFsbCB0aGlzIHNhaWQgqEMgSSBjYW4gb25seSBjb25jbHVkZSBi YXNlZCBvbiB3aGF0IGlzIGhlcmUgqEMgdGhhdCB0aGUgZGVzaWduIHRlYW0gaGFzIGZhaWxlZCB0 byBkYXRlIGluIGl0cyBtYW5kYXRlIKhDIGJlY2F1c2UgdGhpcyBkb2N1bWVudCBwcmV0dHkgbXVj aCBzdGF0ZXMgdGhlIG9idmlvdXMgd2hpbGUgaWdub3JpbmcgdGhlIGVudGlyZSBzZWNvbmQgaGFs ZiBvZiB0aGUgY2hhcnRlci4gIEFuZCB0aGlzIGlzIHdoYXQgd2UgaGF2ZSB3YWl0ZWQgNiBsb25n IG1vbnRocyBmb3KhrSBiYXNlZCBvbiBhIGNvbW1pdG1lbnQgdGhhdCB0aGUgZGVzaWduIHRlYW0g d291bGQgY29tZSB3aXRoIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGF0IElFVEYgMTA5LiAgV2Vs bCCoQyB0aGlzIKhDIGhhcmRseSBjdXRzIGl0IGFzIGEgZGVzaWduIGRvY3VtZW50Lg0KDQpEaXNh cHBvaW50ZWQgqEMgdG8gc2F5IHRoZSBsZWFzdA0KDQpBbmRyZXcNCg0KRnJvbTogc3ByaW5nIDxz cHJpbmctYm91bmNlc0BpZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCAxMiBOb3ZlbWJlciAyMDIw IGF0IDEyOjA2DQpUbzogc3ByaW5nQGlldGYub3JnIDxzcHJpbmdAaWV0Zi5vcmc+DQpDYzogJ3Ny Y29tcCcgPHNyY29tcEBpZXRmLm9yZz4sIHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcgPHNwcmluZy1j aGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQt MDAudHh0DQpIaSBHcm91cCwNCkFzIHlvdSBrbm93LCB0aGUgU1BSSU5HIFdvcmtpbmcgR3JvdXAg c2V0IHVwIGFuIFNSIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIHByaW9yIHRvIElFVEYxMDguDQpU aGUgZGVzaWduIHRlYW0gaXMgdG8gcHJvZHVjZSAocm91Z2gpIGNvbnNlbnN1cyAob2YgdGhlIERU KSBvdXRwdXRzIHRvIHRoZSBXRyBvbiB0d28gcmVsYXRlZCB0b3BpY3M6DQoxKSBXaGF0IGFyZSB0 aGUgcmVxdWlyZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3Npbmcgc2VnbWVudCByb3V0 aW5nIGluZm9ybWF0aW9uIGZvciB1c2Ugb3ZlciBJUHY2Ow0KMikgQSBjb21wYXJpc29uIG9mIHBy b3Bvc2VkIGFwcHJvYWNoZXMgdG8gY29tcHJlc3Npbmcgc2VnbWVudCByb3V0aW5nIGluZm9ybWF0 aW9uIGZvciB1c2Ugb3ZlciBJUHY2Lg0KDQpXaXRoIGdyZWF0IGVmZm9ydCBvZiBkZXNpZ24gdGVh bSBtZW1iZXJzLCBEVCBoYXZlIGZpbmlzaGVkIHRoZSB2ZXJzaW9uIC0wMCBvZiB0aGUgcmVxdWly ZW1lbnRzIGRvY3VtZW50IGFuZCBoYXZlIHN1Ym1pdHRlZCBpdCB0byBkYXRhdHJhY2tlci4NCg0K UGxlYXNlIHJldmlldyBpdCBhbmQgbGV0J3Mga25vdyB5b3VyIGNvbW1lbnRzLg0KDQpCLlIuDQpX ZWlxaWFuZyBDaGVuZw0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3osvNyrG8 5DogMjAyMMTqMTHUwjLI1SAxNjozMg0KytW8/sjLOiBTYW5kZXIgU3RlZmZhbm47IFNKTSBTdGVm ZmFubjsgV2VpcWlhbmcgQ2hlbmcNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24t cmVxdWlyZW1lbnQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdl aXFpYW5nIENoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudA0KUmV2aXNpb246 IDAwDQpUaXRsZTogQ29tcHJlc3NlZCBTUnY2IFNJRCBMaXN0IFJlcXVpcmVtZW50cw0KRG9jdW1l bnQgZGF0ZTogMjAyMC0xMC0zMA0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 IDEwDQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQt c3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwLnR4dDxodHRwczovL3d3dy5pZXRmLm9y Zy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVu dC0wMC50eHQ+DQpTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC88aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50Pg0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNz aW9uLXJlcXVpcmVtZW50Pg0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDA8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudC0wMD4NCg0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVp cmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzIFNSdjYNClNJRCBsaXN0cy4NCg0KDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZz4NCg== --_000_VI1PR03MB5056546242C4F37B521403BAEEE70VI1PR03MB5056eurp_ Content-Type: text/html; charset=GBK Content-Transfer-Encoding: quoted-printable

    Erm,

     

    Ok =A8C so =A8C we have waited 6 months for a document =A8C that we w= ill go into SPRING and 6man to discuss =A8C and what we have here in my vie= w =A8C is a document that says precisely nothing.

     

    I=A1=AFm going to take this section by section =A8C and I would have = hoped sending an email like this =A8C that it would be a lot longer than it= is going to be =A8C but =A8C since there is so little here =A8C it probably won=A1=AFt be all that long.

     

    So let=A1=AFs start at section 3 =A8C

     

    Section 3.1.1 is well, just pretty obvious and goes without stating

    Section 3.1.2 again, pretty obvious that forwarding efficiency is imp= ortant

    Section 3.1.3 again, don=A1=AFt think there is anything much to comme= nt on here =A8C its stating the obvious

     

    Then we get to Section 4.

    4.1.1 SRv6 Based =A8C I don=A1=AFt believe is within the scope of the= charter =A8C the charter does not say =A8C design a solution =A8C it says = =A8C state the requirements of a solution for compression of segment routing information for use over ipv6.  Nowhere does it sa= y for the design team to decide if that is tied to one protocol or another.

    4.1.2 See above comment

    4.1.3 No issues

    4.1.4 Don=A1=AFt have a major problem with this

    4.1.5 Please explain how you would achieve crossing boundaries using = something like a binding SID or something to that effect while being compli= ant with this section

     

    Section 5

    I have a major issue with explicitly stating you need to support the = behaviors in network programming =A8C that is entirely outside of the chart= er.   Again, the charter states =A8C a solution for compression of segment routing information for use over ipv6.  Th= ere may well be solutions within this that scope that do conform to the beh= aviors of network programming =A8C but there may be solutions where such co= mpression is used for purposes entirely different from those described in network programming =A8C and have no rel= ation to network programming at all. 

     

    Now lets look at what else the charter says.

     

    The charter states that there would be a comparison of approaches and= methods related to compression =A8C that is not in this document at all = =A8C it is entirely absent. It states that the design team would look into the current solutions and state if they agreed= if there was space for more than one solution or not =A8C and if they were= in agreement =A8C that is entirely missing from this document. 

     

    The above points form effectively half the charter.=

     

    So =A8C with all this said =A8C I can only conclude based on what is = here =A8C that the design team has failed to date in its mandate =A8C becau= se this document pretty much states the obvious while ignoring the entire second half of the charter.  And this is what we = have waited 6 long months for=A1=AD based on a commitment that the design t= eam would come with a requirements document at IETF 109.  Well =A8C th= is =A8C hardly cuts it as a design document.

     

    Disappointed =A8C to say the least

     

    Andrew

    &nbs= p;

    From: spring <spring-b= ounces@ietf.org>
    Date: Thursday, 12 November 2020 at 12:06
    To: spring@ietf.org <spring@ietf.org>
    Cc: 'srcomp' <srcomp@ietf.org>, spring-chairs@ietf.org <spr= ing-chairs@ietf.org>
    Subject: [spring] FW: New Version Notification for draft-srcompdt-sp= ring-compression-requirement-00.txt

    Hi Group,
    As you know, the SPRING Working Group set up an SR compression design team = prior to IETF108.
    The design team is to produce (rough) consensus (of the DT) outputs to the = WG on two related topics:
    1) What are the requirements for solutions to compressing segment routing i= nformation for use over IPv6;
    2) A comparison of proposed approaches to compressing segment routing infor= mation for use over IPv6.

    With great effort of design team members, DT have finished the version -00 = of the requirements document and have submitted it to datatracker.

    Please review it and let's know your comments.

    B.R.
    Weiqiang Cheng


    -----=D3=CA=BC=FE=D4=AD=BC=FE-----
    =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts= @ietf.org]
    =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C22=C8=D5 16:32
    =CA=D5=BC= =FE=C8=CB: Sander Steffann; SJM Steffann; Weiqiang Cheng
    =D6=F7=CC=E2: New Version Notification for draft-srcompdt-spring-com= pression-requirement-00.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt<= br> has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 00
    Title: Compressed SRv6 SID List Requirements
    Document date: 2020-10-30
    Group: Individual Submission
    Pages: 10
    URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requireme= nt-00.txt
    Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirem= ent/
    Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-req= uirement
    Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-0= 0


    Abstract:
    This document specifies requirements for solutions to compress SRv6
    SID lists.




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

    The IETF Secretariat





    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/spring

    --_000_VI1PR03MB5056546242C4F37B521403BAEEE70VI1PR03MB5056eurp_-- From nobody Thu Nov 12 15:12:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56A3A0EC5 for ; Thu, 12 Nov 2020 15:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 yrt2bpV0TvgO for ; Thu, 12 Nov 2020 15:12:11 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2110.outbound.protection.outlook.com [40.107.236.110]) (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 0A7593A0EC3 for ; Thu, 12 Nov 2020 15:12:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dvO0DfTLlW2Zsu3DkVOcGzxxQ7o9WXQZisSr9LPIXH5EWEd4LiuAb5ceUk1jn+2eZsOQRijSTPGsD2Pfk9eZrClK057eQw5q3bxc9Kk7Tq/b/sMx2cKcYd81xZagh8V41iDVbZHA7JxGrhFao2oUbQ+kyHmnA8T52RDIM3DQNdM8xDv2O6X0vRdXDuSKTpjGKLSq5DKKDj9mckqWSdtIJG1YJ7a7uZykySD9OobNkaWIoBg4VAxN6UN3McF4JBYEWLV9bBKkHuMHETpAeHrsY00UplFb4d5q7xPT33p5nODQEjxTOK/4QCRIQXO1Dypd9hF1ArbNZ9Wdpls9oxZylA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2bNRsl2uvjxNMxuuIrbfckcHjF5Lnqe8PbspjimKA3E=; b=WYLlKAUiftptJCXzfjNU19XlHMWbBDASVKufdqyRicaRHEjWWpff/JnqlcCzl/1gg85e79NZj+1lSrhXiwmhkDQA3yAfSAnz0h9ritLisiFoW42KuNhdFgoqcgAF+fqWjm9H++8MLadx5voE9YmAe/6IffYl66lBvihNxRm9W676Et/YD/941gbPGEB3chqc9aYnINdlvmSM2A7qcVaKrHVZnes+qlE47+jLdQviLQUU1GhSqHxJeMplDsJ6tIFn85ka+M1m/36Whe66H0MInbl+f0oHxeYI7PF42E//sg6IVfX+mCVDu6lp12oadE0uEPDM3W5vH4XHFFnEmI4NeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2bNRsl2uvjxNMxuuIrbfckcHjF5Lnqe8PbspjimKA3E=; b=tS+8s0V2/tLiz4J7IYlYJ8EhDMvCoXj1FLyUmT88I9UHVGGPOgdZ7XRL2HGTeeNYPNpn+yLv/Vm43spPI6Sx13aQGjw8frC6e5iwPDAQa4KiTgej/43jSQtO7RkcNQgyf5FOlTrCaxuzx643/2H/cHEs1ta33n11AvpR/lS5GX0= Received: from DM6PR08MB4393.namprd08.prod.outlook.com (2603:10b6:5:a2::21) by DM6PR08MB6170.namprd08.prod.outlook.com (2603:10b6:5:159::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Thu, 12 Nov 2020 23:12:07 +0000 Received: from DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424]) by DM6PR08MB4393.namprd08.prod.outlook.com ([fe80::755b:419f:e52f:c424%6]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 23:12:07 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Tarek Saad , "Ketan Talaulikar (ketant)" , Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLM70syLdU1bpku3yUTxttqV3Km0BkEAgAwnQoCAAQLIAIAAlKsAgACQY4CAAPaaAIABpNyA///scgA= Date: Thu, 12 Nov 2020 23:12:07 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: af9d8072-14e3-4021-f41d-08d887606048 x-ms-traffictypediagnostic: DM6PR08MB6170: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c3+mnaX5R+MHDO39v8QzAc4ogfLKcUXy/vhwS1mwZ/6r9b85ZBjB+V9Rq5e6xd1VK2jqoCu2LxeB0BD2IQZCRBDSFGyKgqiX88eSUucphn070/DSACT6DSeFEyi6FjSX5KBkjiAW29WIRGMZ39cyGStg3GJLiOqelZGBcrB9kmdl6NyH71xoIwSTl08obdF7PQpQnIo8AfErJZWrk9VzGgc0E2oAY9I3n+IgshRrv6GJ3WAzotVbvbySFjZ1/FeV02xpL/HtCpSNdByZN6+sXRNQNuflWS0tladcbZB3M54NqqcRV5SK+tLPtUuDznsdEC9/s84g2zbF29A07HPAcKW3THREiNekdfmA2l9Zw+F1jcNlhaiaokh3PQ229hT2+q/JnpsyhKb6vW7YsURwvg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4393.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(316002)(2906002)(966005)(8676002)(110136005)(16350225007)(478600001)(71200400001)(4326008)(6486002)(36756003)(6506007)(76116006)(8936002)(53546011)(6512007)(9326002)(33656002)(86362001)(30864003)(91956017)(83380400001)(2616005)(66574015)(5660300002)(66446008)(64756008)(66556008)(166002)(186003)(26005)(66476007)(66946007)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: yCm7fX1xQ3tTP0GHCLwUkFTOC4+z0gcDmP6KmirS+Ehz4NfJIJ/rbq3M+oCZuM6FkktjBl8zwyE4oQD7PEEUr2ak3VjBKyMBAvpPUJ5THwYeLFlJjlbuyZwfog900BA8cHxJfeJSVLFsptvkzM4ojlfhoHNLgT2iF/w5QKRzh6HMqgmGHDwKhZzuFdhs3lokAgLIJrfWfR+Z4WJj7mRKC0spFLZ4JDUOrR+X3gOg/D10Uo70qUsDgCrNYcSePCRUJ0jcwcTXh1wVFFjClzGztmm+lD7cDO6ayXbAnUgpdatuRaXCscpdlubbmx5w+oAsZK6SilrKpq1mBxp2Otp7CtvTm55ivXmCrsooeMJQQT+YBkVTpeZv/Jd9Xd7X8zJIZ9YKbxJRnThtIiZgw4FkgVc2PRmIGfLWVCemBVtpQO/pXzec6kci1l1wzxOLUxKS52Rl5J93WzCuAZZzl0ZB9Ttg6JByqmmh57ihKkzyznDZm4VEpzWvR45bgE1Ulmud3fGDi3eFhzP65sTCBNv4hJcieKugpN5Z+wMCeDnTGRzk8pwvxveAXr5nCmofQ74algAHGjUsg9V8sFKv+QdqUyQquEO1/h2yWQQg5vsMeU0LoTYqqJO/efpv2UoT0Ab5clv1NkEiaLO3ueC/HNFJ/A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F4D9D63A369142C2AB693FEE278B808Enokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB4393.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: af9d8072-14e3-4021-f41d-08d887606048 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 23:12:07.3909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EdvKbb1LBBZmrmH0Oc9/u9CThEB7iPGyJLeFd5aQFQ2HZTdlhjRY9seTzQ+UMToOhBDUPgDGQXhA1RilErzcRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6170 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 23:12:16 -0000 --_000_F4D9D63A369142C2AB693FEE278B808Enokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGFyZWssDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBTbWFsbCByZXBseSBiZWxvdy4N Cg0KVGhhbmtzDQpBbmRyZXcNCg0KRnJvbTogVGFyZWsgU2FhZCA8dHNhYWQubmV0QGdtYWlsLmNv bT4NCkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAyMCBhdCAyOjIyIFBNDQpUbzogIlN0 b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSIgPGFuZHJldy5zdG9uZUBub2tpYS5jb20+ LCAiS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSIgPGtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZz4sIFZpc2hudSBQYXZhbiBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbT4NCkNj OiAic3ByaW5nQGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJp bmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDkudHh0DQoNCkhpIGFsbCwNCg0KU2VlIGlubGluZSBmb3Igc29tZSBjb21tZW50cy4uDQoNCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiU3RvbmUs IEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpIiA8YW5kcmV3LnN0b25lQG5va2lhLmNvbT4NCkRh dGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTEsIDIwMjAgYXQgNjoxNiBQTQ0KVG86ICJLZXRhbiBU YWxhdWxpa2FyIChrZXRhbnQpIiA8a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiwg VmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2YW5AZ21haWwuY29tPg0KQ2M6ICJzcHJpbmdA aWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQNCg0K SGkgS2V0YW4sIFBhdmFuLA0KDQpHb29kIGRpc2N1c3Npb24uIEp1c3QgZ29pbmcgdG8gY2hpcCBp biBzb21lIHRob3VnaHRz4oCmDQoNCk9uZSBvZiB0aGUgZWxlbWVudHMgSSBwZXJzb25hbGx5IGxp a2Ugb2YgdGhlIFNSIFBvbGljeSBtb2RlbCBpcyB0aGF0IG1hbnkgQ2FuZGlkYXRlIFBhdGhzIG1h eSBleGlzdCwgYnV0IG9ubHkgb25lIG1heSBiZSBhY3RpdmUgYW5kIGEgY2FuZGlkYXRlIHBhdGgg Y29udGFpbnMgMSBvciBtYW55IFNJRCBsaXN0cy4gSXTigJlzIGEgc2ltcGxlIHBhcmVudC9jaGls ZCAtIHJvb3QvbGVhZiB0cmVlIHdpdGggdmVyeSBjbGVhciBydWxlcyB3aXRoaW4gdGhlIFNSIHBv bGljeSBjb250ZXh0IGluc3RhbmNlLiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHdoYXQgaXMgYmVp bmcgcHJvcG9zZWQgaW4gdGhlIC0wOSBkb2N1bWVudCBzdGlsbCBmb2xsb3dzIHRob3NlIHJ1bGVz IGFuZCB0aGUgZ2VuZXJhbCB0b3AtZG93biB0cmVlIGJlaGF2aW91ci4gRGVzcGl0ZSB0aGUgY29t cG9zaXRlIENQIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IFNSIFBvbGljeSwgdGhhdCBTUiBQb2xp Y3kgc3RpbGwgZm9sbG93cyBhbGwgb2YgdGhlIHNhbWUgcnVsZXMgdG9wIGRvd24gaW4gaXRzIG93 biBpc29sYXRlZCBjb250ZXh0LiBDb21wYXJlIHRoYXQgdG8gc2F5LCBoYXZpbmcgYSBjYW5kaWRh dGUgcGF0aCBjb250YWluIGEgY2hpbGQgdGhhdCBwb2ludHMgdG8gb3RoZXIgY2FuZGlkYXRlIHBh dGhzIHdpdGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kgY29udGV4dDogd2l0aGluIHRoZSBzYW1lIGNv bnRleHQgYSBjaGlsZCBpcyBwb2ludGluZyB0byBhIHNpYmxpbmcgb2YgaXRzIHBhcmVudC4gVGhl IHJ1bGVzIG5vdyBoYXZlIHRvIGJlbmQgc2xpZ2h0bHkuIEFzIG5vdGVkIGJlbG93LCBzb21lIG9m IHRoZSBydWxlcyBhcm91bmQgd2hhdCBpcyBjb25zaWRlcmVkIGFuIGFjdGl2ZSBjYW5kaWRhdGUg cGF0aCB3b3VsZCBuZWVkIHRvIGNoYW5nZSwgc2luY2UgdGhlIGNvbnN0aXR1ZW50cyBlc3NlbnRp YWxseSBhcmUgYWN0aXZlICh0aGV54oCZcmUgaW5zdGFsbGVkKSBkZXNwaXRlIG5vdCBiZWluZyB0 aG91Z2h0IG9mIGFzIGJlaW5nIGFjdGl2ZS4gTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBuZXcgdGV4 dCBiZWxvdyBzYXlzIOKAnFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhl IHR3byBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMiIHdoaWNoIGlzIGFsc28gYSBuZXcgcnVs ZSwgaG93ZXZlciBvbmUgY291bGQgcGVyaGFwcyB3b3JrIGFyb3VuZCB0aGF0IGJ5IGp1c3QgcmVx dWlyaW5nIHRoZSBwcmVmZXJlbmNlIG9uIHRoZSBjb25zdGl0dWVudHMgYmUgbGVzcyBwcmVmZXJy ZWQgdGhhbiBhbnkgb3RoZXIgc3RhbmRhcmQgb3IgY29tcG9zaXRlIENQIOKAkyBidXQgdGhhdCBy YWlzZXMgaXRzIG93biB0cm91YmxlcyB3aXRoIG11bHRpcGxlIHNvdXJjZXMgb2YgcHJvdmlzaW9u aW5nIOKAkyB3aGljaCBsZWFkcyB0byBhIHJ1bGUgYXNraW5nIHRvIGlnbm9yZSB0aGUgcHJlZmVy ZW5jZS4gSW4gc3VtbWFyeSwgZnJvbSBteSBwLm8udiBuZXcgcnVsZXMgaW4gdGhlIGhpZXJhcmNo eSB3b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQuDQoNClJlZ2FyZGluZyBzdGVlcmluZyBpbnRv IGFuIFNSIFBvbGljeSwgeWVzLCB5b3UgYnVybiBjb2xvcnMgaW4gZG9pbmcgdGhpcyAoMzJiaXRz Li4uKSBhbmQgaXQgd291bGQgcmVxdWlyZSBkZXBsb3lpbmcgYW4gZW50aXJlbHkgZGVkaWNhdGVk IFNSIFBvbGljeSBjb25zdHJ1Y3QsIGFuZCBydW4gdGhlIHJpc2sgb2Ygc3RlZXJpbmcg4oCYb3Ro ZXLigJkgdHJhZmZpYyBpbnRvIHRoYXQgcG9saWN5LiBJZiB0aGlzIGlzIGEgY29uY2Vybiwgd291 bGQgdGhlIGNvbXBvc2l0ZSBTUiBQb2xpY2llcyBub3QgYmUgZW5naW5lZXJlZCBpbiBhIHdheSB3 aGVyZSB0aGUgY29sb3IgYmxvY2sgdXNlZCBpcyBkZXNpZ25lZCB0byBub3QgYmUgdXNlZCBlbHNl d2hlcmUgaW4gdGhlIG5ldHdvcmsgZm9yIG90aGVyIHB1cnBvc2VzPw0KW1RTXTogVG9kYXkgY29s b3JzIG9mIFNSIFBvbGljaWVzIHRoYXQgYXJlIGluc3RhbnRpYXRlZCDigJxvbi1kZW1hbmTigJ0g b3IgaW5zdGFudGlhdGVkIHZpYSBQQ0VQIGZyb20gYSBQQ0UgYXJlIGRlcml2ZWQgZnJvbSB0aGUg aW50ZW50L3NlcnZpY2UuIFdpdGggdGhlIGhpZXJhcmNoaWNhbCBTUiBwb2xpY2llcyBwcm9wb3Nh bCwgYSBQQ0UgbWF5IG5lZWQgdG8gaW5zdGFudGlhdGUgdGhlIGNvbG9yZWQgY2hpbGQgU1IgcG9s aWNpZXMgb24tZGVtYW5kIHRvbywgYnV0IGl0IGlzIG5vdCBjbGVhciB3aGVyZSB0aGUgY29sb3Jz IG9mIHRob3NlIGNoaWxkIFNSIHBvbGljaWVzIHdvdWxkIGJlIGRlcml2ZWQgZnJvbS4gQXMgQW5k cmV3IHN1Z2dlc3RzLCBhIGJsb2NrIG9mIGNvbG9ycyBjb3VsZCBiZSBjYXJ2ZWQgZnJvbSBldmVy eSBoZWFkZW5k4oCZcyBzcGFjZSAtLSBzcGVjaWZpY2FsbHkgZm9yIHRoaXMgcHVycG9zZSBhbmQg YmUgbWFuYWdlZCBieSB0aGUgUENFLiBBbHRlcm5hdGl2ZWx5LCBvbmUgY291bGQgY29uc2lkZXIg Y3JlYXRpbmcgc3VjaCBTUiBQb2xpY2llcyB3aXRoIGEgc3BlY2lhbC9yZXNlcnZlZCBjb2xvciB0 aGF0IHdvdWxkIHNpbXBsaWZ5IHRoZWlyIGNyZWF0aW9uLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRo YXQgdGhlcmUgYXJlIG90aGVyIGNhc2VzIHdoZXJlIFNSIFBvbGljaWVzIG1heSBiZSBpbnN0YW50 aWF0ZWQgKGUuZy4gZm9yIHRhY3RpY2FsIFRFIOKAkyBlLmcuIG9uIFAgbm9kZXMpIHRoYXQgd291 bGQgbm90IHJlcXVpcmUgY29sb3IgcmVzb2x1dGlvbiwgYW5kIGNyZWF0aW9uIG9mIHRob3NlIGNv dWxkIGJlbmVmaXQgZnJvbSBhIHJlc2VydmVkIGNvbG9yIHRvby4NCg0KDQpbQW5kcmV3XSBHb29k IHBvaW50IGluZGVlZC4gVGhlIFAgbm9kZSBpcyB3aGF0IEkgd2FzIHBvaW50aW5nIGF0IHdpdGgg dGhlIEJTSUQgZXhhbXBsZSwgd2hlcmUsIGZvciBleGFtcGxlLCB3ZeKAmWxsIGhhdmUgdG8gYnVy biBhIGNvbG9yIHRvIGRlcGxveSBhIFNSIFBvbGljeSBvbiBhIHRyYW5zaXQgbm9kZSB3aGVuIHRo ZSBjb25zdW1lciBpbnRlbnQgaXMgc2ltcGx5IGZvciB0aGUgQlNJRC4gVGhhdCBjb2xvciBzZWxl Y3Rpb24gd291bGQgbmVlZCB0byBiZSBjb25zaWRlcmVkIOKAmHNwZWNpYWzigJkgYW5kIHRha2Vu IGZyb20gYSB1bmlxdWUgYmxvY2sgaWYgb25lIHdhbnRzIHRvIGF2b2lkIHVzaW5nIGl0IGZvciBo ZWFkLWVuZCBzdGVlcmluZyBvbiB0aGF0IFAgbm9kZS4gIE5vdGluZyB0aGF0IGNvbG9yIGlzIHBh cnQgb2Ygd2hhdCB1bmlxdWVuZXNzLCB0byBkZWZpbmUgdGhlIOKAnG5vdCBmb3Igc3RlZXJpbmfi gJ0gYmVoYXZpb3VyLCBpdCB3b3VsZCBuZWVkIHRvIGJlIGEgcmVzZXJ2ZWQgYmxvY2sgb3IgYml0 IGVuY29kZWQgaW4gY29sb3IgYXMgb3Bwb3NlZCB0byBhIHNpbmdsZSBzcGVjaWFsIHZhbHVlLiBJ 4oCZbSBub3Qgc3VyZSBhIHNwZWNpYWwgcmFuZ2UgbmVlZHMgdG8gYmUgSUVURiBzdGFuZGFyZGl6 ZWQgb3Igc2ltcGx5IGxlZnQgdG8gaW1wbGVtZW50YXRpb25zL1BDRSAvIG5ldHdvcmsgZGVzaWdu IHRvIGFsbG9jYXRlIGFuZCBlbmZvcmNlLiBJdCBzZWVtcyB0aGF0IHRoZSBtb2RlbCB0byBzdGVl ciBhbiBTUiBQb2xpY3kgY2FuZGlkYXRlIHBhdGggaW50byBhbm90aGVyIFNSIFBvbGljeSB3aXRo IGVpdGhlciBjb2xvciBvciB0aGUgY29uY2VwdCBvZiBhIHNwZWNpYWwgY29sb3Igc3RpbGwgc2Vl bXMgZmVhc2libGUgaW4gdGhlIHByZXNlbnQgZG9jdW1lbnQuIEl0IG1pZ2h0IGJlIHdvcnRoIGhh dmluZyB0ZXh0IGRlc2NyaWJpbmcgdGhhdCBhIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIG1h eSBiZSB1c2VkIGZvciBzdGVlcmluZyBvbiB0aGUgaGVhZGVuZCwgYW5kIGlmIGludGVudGlvbiBp cyB0byBhdm9pZCB0aGF0IHRoZW4gdGhlIHVzZXIvcGNlL25ldHdvcmsgZGVzaWduIHNob3VsZCBh bGxvY2F0ZSBhIGJsb2NrIG9mIHZhbHVlcyBmb3IgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGhz IGFuZCBzZWxlY3Qgb25seSBmcm9tIHRoYXQgYmxvY2ssIG5vdCB0byBiZSB1c2VkIG9uIGFueSBv dGhlciByb3V0ZXMgaW4gdGhlIG5ldHdvcmsuDQoNCg0KUmVnYXJkcywNClRhcmVrDQoNCg0KDQpJ cyB0aGVyZSBub3QgYSBkaWZmZXJlbnQgYnV0IGtpbmQgb2Ygc2ltaWxhciBwcm9ibGVtIHdpdGgg QmluZGluZyBTSURzLCBpbiB0aGF0IHRoZXnigJlyZSBlbGlnaWJsZSBmb3IgdXNlIGJ5IG90aGVy IGNvbnN1bWVycyBldmVuIGlmIG5vdCBkaXJlY3RseSBpbnRlbmRlZD8gKGFsdGhvdWdoIGF0IGxl YXN0IEJTSURzIGFyZSBvcHRpb25hbCBhbmQgbm90IG1hbmRhdG9yeSkuIEluIGFkZGl0aW9uIHRv IHRoZSBzcGxpdCBURSBjYXNlcywgYmVpbmcgYWJsZSB0byBoYXZlIGFuIFNSIFBvbGljeSBzdGVl ciBpbnRvIGFub3RoZXIgU1IgUG9saWN5IG1pZ2h0IGFsc28gaGF2ZSBzb21lIHZhbHVlIGluIGEg YmFja3VwIGNhbmRpZGF0ZSBzY2VuYXJpbyB3aGVuIG9uZSBoYXMgbXVsdGlwbGUgU1IgUG9saWNp ZXMgd2l0aCB0aGUgc2FtZSBlbmRwb2ludCwgYnV0IGNhbiBzaGFyZSBhIGNvbW1vbiBmYWxsYmFj ay9iZXN0IGVmZm9ydCBjYW5kaWRhdGUgcGF0aC4gVGhlIGVudGl0eSAoSSdtIHRoaW5raW5nIFBD RSkgbWFuYWdpbmcgdGhhdCB3b3VsZCBvbmx5IG5lZWQgdG8gbWFpbnRhaW4gdGhlIGZhbGxiYWNr L2Jlc3QgZWZmb3J0IENQIFNJRCBsaXN0KHMpLCBpbnN0ZWFkIG9mIG9uZSBmb3IgZWFjaCBOICog Q1BzLg0KDQpTb21ldGhpbmcgSSBoYXZlbuKAmXQgY29uY2x1ZGVkIHRvIG15c2VsZiB5ZXQgYXJl IHF1ZXN0aW9ucyBzdWNoIGFzOg0KDQoNCjEuICAgICAgIGRvZXMgaGF2aW5nIGEgY2FuZGlkYXRl IHBhdGggc3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBzYXRpc2Z5IHRoZSBhYmlsaXR5IHRv IGRvIHZhcmlvdXMgc3ViLXBhdGggc3BlY2lmaWMgVEUvY29uc3RyYWludC9vYmplY3QgY29tYmlu YXRpb25zIHN1ZmZpY2llbnRseT8NCg0KMi4gICAgICAgaXMgdGhlIG1vZGVsIHJlbGF0aXZlbHkg c3RyYWlnaHQgZm9yd2FyZCB0byBtYXAgaW50byB5YW5nL2JncC9wY2VwIGV0Yy4uPw0KDQozLiAg ICAgICBkb2VzIHVzaW5nIGFuIGFkZGl0aW9uYWwgU1IgUG9saWN5IGNyZWF0ZSB0b28gbXVjaCBv dmVyaGVhZCBvciBzdGF0ZSBidXJuIHRvIGNvbmZpZ3VyZSwgZGVwbG95LCBtYW5hZ2UsIHRyYWNr IGV0Yy4uID8NCg0KQ2hlZXJzDQpBbmRyZXcNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIiA8a2V0 YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIg MTAsIDIwMjAgYXQgMTA6MzMgUE0NClRvOiBWaXNobnUgUGF2YW4gQmVlcmFtIDx2aXNobnVwYXZh bkBnbWFpbC5jb20+DQpDYzogInNwcmluZ0BpZXRmLm9yZyIgPHNwcmluZ0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQpIaSBQYXZhbiwNCg0KUGxlYXNlIGNoZWNrIGlubGlu ZSBiZWxvdy4NCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2YW5AZ21haWwu Y29tPg0KU2VudDogMTEgTm92ZW1iZXIgMjAyMCAwMDoyNg0KVG86IEtldGFuIFRhbGF1bGlrYXIg KGtldGFudCkgPGtldGFudEBjaXNjby5jb20+DQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLXBvbGljeS0wOS50eHQNCg0KS2V0YW4sIEhpIQ0KDQpQbGVhc2Ugc2VlIGlubGluZSBmb3Ig cmVzcG9uc2VzIChwcmVmaXhlZCBWUEIpLg0KDQpSZWdhcmRzLA0KLVBhdmFuDQoNCk9uIFR1ZSwg Tm92IDEwLCAyMDIwIGF0IDQ6MDQgQU0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50 QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgUGF2YW4sDQoN ClBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuDQoNCkZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0g PHZpc2hudXBhdmFuQGdtYWlsLmNvbTxtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tPj4NClNl bnQ6IDEwIE5vdmVtYmVyIDIwMjAgMDA6MDgNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQp IDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4NCkNjOiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4 dA0KDQpLZXRhbiwNCg0KTXVjaCBUaGFua3MgZm9yIHRha2luZyBhIHN0YWIgYXQgYWRkcmVzc2lu ZyB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHVzZS1jYXNlISBXZSBzZWVtIHRvIGJlIGNv bnZlcmdpbmcuDQpbS1RdIFRoYW5rcyBmb3IgdGhhdCBmZWVkYmFjayBhbmQgY29uZmlybWF0aW9u IHRoYXQgdGhlIHByb3Bvc2FsIGluIHRoZSBkcmFmdCBkb2VzIGFkZHJlc3MgdGhlIHVzZS1jYXNl LiBJIGJlbGlldmUgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIHRoZSBtZWNoYW5pY3Mgb2YgaG93IHRo aXMgaXMgYWNoaWV2ZWQgd2l0aGluIHRoZSBjdXJyZW50IFNSIFBvbGljeSBmcmFtZXdvcmsuDQoN Ckhvd2V2ZXIsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB5b3UgbmVlZCB0byB1c2UgYWRkaXRp b25hbCBTUiBwb2xpY2llcyAoYW5kIHVubmVjZXNzYXJpbHkgYnVybiBhZGRpdGlvbmFsIGNvbG9y cykgdG8gYWRkcmVzcyB0aGlzLg0KW0tUXSBJIGRvIG5vdCBmb2xsb3cgd2hhdCB5b3UgbWVhbiBi eSDigJxidXJuIGFkZGl0aW9uYWwgY29sb3Jz4oCdLiBDb2xvciBpcyBqdXN0IGEgMzIgYml0IG51 bWJlciB0aGF0IGluZGljYXRlcyB0aGUg4oCcaW50ZW504oCdIGFuZCBpcyBub3QgcmVhbGx5IGEg c2NhcmNlIHJlc291cmNlLiBBc3NpZ25pbmcgYSBjb2xvciB0byDigJxhIGNvbXBvc2l0ZSBpbnRl bnTigJ0gc2VlbXMgbGlrZSBhIHNlYW1sZXNzIHdheSB0byBpbnRlZ3JhdGUgd2l0aCBleGlzdGlu ZyBtZWNoYW5pc21zIGZvciBTdGVlcmluZyBvdmVyIFNSIFBvbGljaWVzLiBUaGlzIGdpdmVzIHRo ZSBmbGV4aWJpbGl0eSBmb3Igc2F5IHNvbWUgQkdQIHNlcnZpY2VzIHRvIGJlIHN0ZWVyZWQgb3Zl ciB0aGUgY29uc3RpdHVlbnQgZXhwbGljaXQvZHluYW1pYyBpbnRlbnQgd2hpbGUgb3RoZXJzIGNh biBzdGVlciBvdmVyIGEgY29tcG9zaXRlIGludGVudCB0aGF0IGluY2x1ZGVzIHRob3NlIGluZGl2 aWR1YWwgZXhwbGljaXQvZHluYW1pYyBpbnRlbnRzLg0KDQpbVlBCXSBUaGUg4oCcZmxleGliaWxp dHnigJ0gdGhhdCB5b3UgYXJlIHJlZmVycmluZyB0byBpcyB1bmRlc2lyYWJsZSBmb3IgdGhpcyB1 c2UtY2FzZS4gRm9yIHRoZSB0cmFmZmljLXNwbGl0IHVzZS1jYXNlLCB3ZSBkb27igJl0IHdhbnQg YW55IG90aGVyIHNlcnZpY2VzIHRvIGJlIGRpcmVjdGx5IHN0ZWVyZWQgb3ZlciB0aGUgY29uc3Rp dHVlbnRzIHdoZW4gdGhleSBhcmUgcGFydCBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aC4N CltLVF0gSSBiZWxpZXZlIHRoZSB1c2UtY2FzZSB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHdh cyBmb3Igc3BsaXR0aW5nIHNvbWUgdHJhZmZpYyBmb3IgYSBzZXJ2aWNlIG92ZXIgYSBibHVlIHBs YW5lIGFuZCB0aGUgcmVzdCBvdmVyIGEgcmVkIHBsYW5lLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGVy ZSBtYXkgYmUgb3RoZXIgc2VydmljZXMgdGhhdCB1dGlsaXplIG9ubHkgYSBzaW5nbGUgcGxhbmUu IFRoZSBmbGV4aWJpbGl0eSB0aGF0IEkgd2FzIHJlZmVycmluZyB0byB3YXMgdG8gZW5hYmxlL2Fs bG93IGZvciBlaXRoZXIgb2YgdGhlIHR3byBzY2VuYXJpb3MgYW5kIHRoZXJlIG1heSBiZSBvdGhl ci9tb3JlIHVzZS1jYXNlcyBmb3Igd2hpY2ggd2UgbmVlZCBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdv cmsuDQoNClRoZSBjdXJyZW50IHByb3Bvc2FsIGluIHRoZSBkcmFmdCB3b3VsZCBoYXZlIGJlZW4g YWNjZXB0YWJsZSBpZiB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgd2VyZSB1bmNvbG9yZWQg 4oCTIGJ1dCB0aGF0IHdvdWxkIHZpb2xhdGUgdGhlIGN1cnJlbnQgcnVsZXMgaW1wb3NlZCBieSB0 aGUgZHJhZnQuDQoNCg0KV2h5IGNhbuKAmXQgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBq dXN0IGJlIGEgZ3JvdXBpbmcgb2YgZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5h bWljIGNhbmRpZGF0ZSBwYXRocz8NCltLVF0gVGhpcyBpcyBiZWNhdXNlIGluIHRoZSBTUiBQb2xp Y3kgZnJhbWV3b3JrLCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIGFjdGl2ZSBDUCDigJMgaXQgbWF5 IGJlIGV4cGxpY2l0IG9yIGR5bmFtaWMuIE5vdyB3ZeKAmXZlIGFkZGVkIGFub3RoZXIgQ29tcG9z aXRlIENQIHR5cGUgdG8gY292ZXIgdGhpcyBzcGVjaWZpYyB1c2UtY2FzZS4gWW91ciBwcm9wb3Nh bCB3aWxsIHJlc3VsdCBpbiAzIGNhbmRpZGF0ZSBwYXRocyBiZWluZyBhY3RpdmUgd2l0aGluIHRo ZSBzYW1lIFNSIFBvbGljeSDigJMgb25lIGVhY2ggb2YgdGhlIGV4cGxpY2l0IGFuZCBkeW5hbWlj IENQIGFuZCB0aGVuIGFkZGl0aW9uYWxseSB0aGUgQ29tcG9zaXRlIENQLiBUaGlzIGJyZWFrcyB0 aGUgZXhpc3RpbmcgcnVsZXMgZm9yIHNlbGVjdGlvbiBvZiBDUCBiYXNlZCBvbiBwcmVmZXJlbmNl IGFuZCBtZWNoYW5pc21zIGxpa2UgZmFsbGJhY2sgYmV0d2VlbiBDUHMuIFdoaWxlIHRoZSBjdXJy ZW50IHByb3Bvc2FsIGluIHRoZSBkcmFmdCBwcm92aWRlcyBhIHdheSB0byBhZGRyZXNzIHRoZSBu ZXcgdXNlLWNhc2Ugd2l0aCBhIGJhY2t3YXJkcyBjb21wYXRpYmxlIGV4dGVuc2lvbiB0byB0aGUg U1IgUG9saWN5IGZyYW1ld29yay4NCg0KW1ZQQl0gVGhlIHByb3Bvc2FsIGluIG15IHByZXZpb3Vz IGVtYWlsIGlzIGJhY2t3YXJkcyBjb21wYXRpYmxlIGFuZCBkb2VzIG5vdCBpbnRlbmQgdG8gYnJl YWsgYW55IGV4aXN0aW5nIHJ1bGVzIGZvciBkZWVtaW5nIGEgY2FuZGlkYXRlIHBhdGggYWN0aXZl LiBBcyBwZXIgdGhlIHJ1bGVzIHRoYXQgYXJlIG91dGxpbmVkIGluIFNlY3Rpb24gMi45LCBvbmx5 IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMg4oCcYWN0aXZl4oCdIGdpdmVuIGl0cyBw cmVmZXJlbmNlLiBUaGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGhzIHdpbGwgbmV2ZXIgYmUg YWN0aXZlIG9uIHRoZWlyIG93bi4gSWYgaXQgaXMgbmVjZXNzYXJ5LCB3ZSBjYW4gYWRkIGEgc3Rh dGVtZW50IGluIFNlY3Rpb24gMi45IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUgY2FuZGlk YXRlIHBhdGggc2VsZWN0aW9uIGNyaXRlcmlhIGRvZXMgbm90IGFwcGx5IHRvIHRoZSBjb25zdGl0 dWVudCBjYW5kaWRhdGUgcGF0aHMuDQpbS1RdIFdoZW4gYSBDUCBpcyDigJxhY3RpdmXigJ0gaXQg aXMgYWN0dWFsbHkgdGhlIG9uZSB0aGF0IGlzIGJlaW5nIHVzZWQgZm9yIGZvcndhcmRpbmcuDQoN ClRoYW5rcywNCktldGFuDQoNCg0KVGhhbmtzLA0KS2V0YW4NCg0KQ29uc2lkZXIgdGhlIGZvbGxv d2luZyBjaGFuZ2VzOg0KDQoqKiBTZWN0aW9uIDIuMg0KT0xEOg0KDQogICBBIGNvbXBvc2l0ZSBj YW5kaWRhdGUgcGF0aCBhY3RzIGFzIGEgY29udGFpbmVyIGZvciBncm91cGluZyBvZiBTUg0KDQog ICBQb2xpY2llcy4gIFRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggY29uc3RydWN0IGVuYWJs ZXMgY29tYmluYXRpb24NCg0KICAgb2YgU1IgUG9saWNpZXMsIGVhY2ggd2l0aCBleHBsaWNpdCBj YW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWMNCg0KICAgY2FuZGlkYXRlIHBhdGhzIHdpdGgg cG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVzDQoNCiAgIGFuZCBj b25zdHJhaW50cywgZm9yIGEgbG9hZC1iYWxhbmNlZCBzdGVlcmluZyBvZiBwYWNrZXQgZmxvd3Mg b3Zlcg0KDQogICBpdHMgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMuICBUaGUgZm9sbG93aW5nIGNy aXRlcmlhIGFwcGx5IGZvcg0KDQogICBpbmNsdXNpb24gb2YgY29uc3RpdHVlbnQgU1IgUG9saWNp ZXMgdXNpbmcgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgNCg0KICAgdW5kZXIgYSBwYXJlbnQg U1IgUG9saWN5Og0KDQoNCg0KICAgbyAgdGhlIGVuZHBvaW50cyBvZiB0aGUgY29uc3RpdHVlbnQg U1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQgU1INCg0KICAgICAgUG9saWN5IE1VU1QgYmUgaWRl bnRpY2FsDQoNCg0KDQogICBvICBUaGUgY29sb3JzIG9mIGVhY2ggb2YgdGhlIGNvbnN0aXR1ZW50 IFNSIFBvbGljaWVzIGFuZCB0aGUgcGFyZW50DQoNCiAgICAgIFNSIFBvbGljeSBNVVNUIGJlIGRp ZmZlcmVudA0KDQoNCg0KICAgbyAgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIE1VU1QgTk9U IHVzZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGhzDQoNCg0KDQogICBFYWNoIGNvbnN0aXR1ZW50 IFNSIFBvbGljeSBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcw0KDQogICBhc3NvY2lh dGVkIHdpdGggYSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChyZWZlcg0KDQog ICBTZWN0aW9uIDIuMTE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkjc2VjdGlvbi0yLjExPiBmb3IgZGV0YWlscyku ICBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS4NCg0KDQoNCk5FVzoNCg0KICAgQSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3JvdXBpbmcgb2YNCg0KICAg ZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWljIGNhbmRpZGF0ZSBwYXRocyB3 aXRoDQoNCiAgIHBvdGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24gb2JqZWN0aXZlcyBh bmQgY29uc3RyYWludHMuDQoNCiAgIFRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggY29uc3Ry dWN0IGVuYWJsZXMgbG9hZC1iYWxhbmNlZA0KDQogICBzdGVlcmluZyBvZiBwYWNrZXQtZmxvd3Mg b3ZlciBhIHNldCBvZiBjb25zdGl0dWVudCBjYW5kaWRhdGUNCg0KICAgcGF0aHMuIFRoZSBmb2xs b3dpbmcgY3JpdGVyaWEgYXBwbHkgZm9yIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZQ0KDQogICBwYXRo cyB1bmRlciBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aDoNCg0KDQoNCiAgIG8gIHRoZSBwcmVm ZXJlbmNlIG9mIHRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIGJlDQoNCiAgICAg IGlnbm9yZWQuDQoNCg0KDQogICBvICB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggTVVT VCBOT1QgYmUgYSBjb21wb3NpdGUgY2FuZGlkYXRlDQoNCiAgICAgIHBhdGgNCg0KDQoNCiAgIEVh Y2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBh dGggaXMNCg0KICAgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBw dXJwb3NlcyAocmVmZXINCg0KICAgU2VjdGlvbiAyLjExPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rpb24t Mi4xMT4gZm9yIGRldGFpbHMpLiAgVGhlIGRlZmF1bHQgd2VpZ2h0IGlzIDEuDQoNCg0KDQoqKg0K DQoNCg0KKiogU2VjdGlvbiAyLjExDQoNCg0KDQpPTEQ6DQogICBXaGVuIGEgY29tcG9zaXRlIGNh bmRpZGF0ZSBwYXRoIGlzIGFjdGl2ZSwgdGhlIGZyYWN0aW9uIG9mIGZsb3dzDQogICBzdGVlcmVk IGludG8gZWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kgaXMgZXF1YWwgdG8gdGhlIHJlbGF0aXZl DQogICB3ZWlnaHQgb2YgZWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kuICBGdXJ0aGVyIGxvYWQg YmFsYW5jaW5nIG9mDQogICBmbG93cyBzdGVlcmVkIGludG8gYSBjb25zdGl0dWVudCBTUiBQb2xp Y3kgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZQ0KICAgd2VpZ2h0cyBvZiB0aGUgU2VnbWVudC1M aXN0IG9mIHRoZSBhY3RpdmUgY2FuZGlkYXRlIHBhdGggb2YgdGhhdA0KICAgY29uc3RpdHVlbnQg U1IgUG9saWN5Lg0KDQoNCg0KTkVXOg0KICAgV2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93cw0KICAgc3RlZXJlZCBpbnRvIGVhY2gg Y29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggaXMgZXF1YWwgdG8gdGhlIHJlbGF0aXZlDQogICB3 ZWlnaHQgb2YgZWFjaCBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aC4gIEZ1cnRoZXIgbG9hZCBi YWxhbmNpbmcgb2YNCiAgIGZsb3dzIHN0ZWVyZWQgaW50byBhIGNvbnN0aXR1ZW50IGNhbmRpZGF0 ZSBwYXRoIGlzIHBlcmZvcm1lZCBiYXNlZCBvbg0KICAgdGhlIHdlaWdodHMgb2YgZWFjaCBhc3Nv Y2lhdGVkIFNlZ21lbnQtTGlzdC4NCg0KDQoqKg0KDQoNCg0KKiogU2VjdGlvbiAyLjEzDQoNCg0K DQpPTEQ6DQogICBUaGUgaW5mb3JtYXRpb24gbW9kZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZp bmcgYSBjb21wb3NpdGUNCiAgIGNhbmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAg IFNSIHBvbGljeSBQT0wxMDAgPGhlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0g RTE+DQogICAgICAgIENhbmRpZGF0ZS1wYXRoIENQMSA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9y aWdpbmF0b3IgPQ0KICAgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAxPg0KICAgICAgICAg ICAgUHJlZmVyZW5jZSAyMDANCiAgICAgICAgICAgIFdlaWdodCBXMSwgU1IgcG9saWN5IDxjb2xv ciA9IDE+DQogICAgICAgICAgICBXZWlnaHQgVzIsIFNSIHBvbGljeSA8Y29sb3IgPSAyPg0KDQog ICBUaGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgUE9MMSBhbmQgUE9MMiBoYXZlIGluZm9ybWF0 aW9uIG1vZGVsIGFzDQogICBkZXNjcmliZWQgYXQgdGhlIHN0YXJ0IG9mIHRoaXMgc2VjdGlvbi4g IFRoZXkgYXJlIHJlZmVyZW5jZWQgb25seSBieQ0KICAgY29sb3IgaW4gdGhlIGNvbXBvc2l0ZSBj YW5kaWRhdGUgcGF0aCBzaW5jZSB0aGVpciBoZWFkZW5kIGFuZA0KICAgZW5kcG9pbnQgYXJlIGlk ZW50aWNhbCB0byB0aGUgUE9MMTAwLiAgVGhlIHZhbGlkIFNlZ21lbnQtTGlzdHMgb2YgdGhlDQog ICBhY3RpdmUgY2FuZGlkYXRlIHBhdGggb2YgUE9MMSBhbmQgUE9MMiBhcmUgaW5zdGFsbGVkIGlu IHRoZQ0KICAgZm9yd2FyZGluZy4gIFRyYWZmaWMgc3RlZXJlZCBvbiBQT0wxMDAgaXMgZmxvdy1i YXNlZCBoYXNoZWQgb24gUE9MMQ0KICAgd2l0aCBhIHJhdGlvIFcxLyhXMStXMikuICBXaXRoaW4g dGhlIFBPTDEsIHRoZSBmbG93LWJhc2VkIGhhc2hpbmcNCiAgIG92ZXIgaXRzIFNlZ21lbnQtTGlz dHMgYXJlIHBlcmZvcm1lZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzDQogICBzZWN0aW9u Lg0KDQoNCg0KTkVXOg0KICAgVGhlIGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wx MDAgaGF2aW5nIGEgY29tcG9zaXRlDQogICBjYW5kaWRhdGUgcGF0aCBpcyB0aGUgZm9sbG93aW5n Og0KDQogICBTUiBwb2xpY3kgUE9MMTAwIDxoZWFkZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRw b2ludCA9IEUxPg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBDb21wLUNQIDxwcm90b2NvbC1vcmln aW4gPSAyMCwgb3JpZ2luYXRvciA9DQogICAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDE+ DQogICAgICAgICAgICBQcmVmZXJlbmNlIDIwMA0KICAgICAgICAgICAgV2VpZ2h0IFcxLCBDYW5k aWRhdGUtcGF0aCBDUDENCiAgICAgICAgICAgIFdlaWdodCBXMiwgQ2FuZGlkYXRlLXBhdGggQ1Ay DQogICAgICAgIENhbmRpZGF0ZS1wYXRoIENQMSA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdp bmF0b3IgPQ0KICAgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAyPg0KICAgICAgICAgICAg IFdlaWdodCBXMTEsIFNJRC1MaXN0MSA8U0lEMTEuLi5TSUQxaT4NCiAgICAgICAgICAgICBXZWln aHQgVzEyLCBTSUQtTGlzdDIgPFNJRDIxLi4uU0lEMmo+DQogICAgICAgIENhbmRpZGF0ZS1wYXRo IENQMiA8cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPQ0KICAgMTAwOjEuMS4xLjEs IGRpc2NyaW1pbmF0b3IgPSAzPg0KICAgICAgICAgICAgIFdlaWdodCBXMjEsIFNJRC1MaXN0MyA8 U0lEMzEuLi5TSUQzaT4NCiAgICAgICAgICAgICBXZWlnaHQgVzIyLCBTSUQtTGlzdDQgPFNJRDQx Li4uU0lENGo+DQoNCiAgIENvbXAtQ1AgaXMgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggd2l0 aCB0d28gY29uc3RpdHVlbnRzLCBDUDENCiAgIGFuZCBDUDIuIFRoZSBwcmVmZXJlbmNlIGlzIGln bm9yZWQgZm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBhdGhz LiBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUgdHdvIGNvbnN0aXR1ZW50DQogICBjYW5k aWRhdGUgcGF0aHMgYXJlIGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZy4gVHJhZmZpYyBzdGVl cmVkDQogICBvbiBDb21wLUNQIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIHRvIENQMSBhbmQgQ1Ay IHdpdGggYSByYXRpbyBvZg0KICAgVzEvKFcxK1cyKSBhbmQgVzIvKFcxK1cyKSByZXNwZWN0aXZl bHkuIFdpdGhpbiBlYWNoIGNvbnN0aXR1ZW50DQogICBjYW5kaWRhdGUgcGF0aCwgdGhlIGZsb3ct YmFzZWQgaGFzaGluZyBvdmVyIGl0cyBTZWdtZW50LUxpc3RzIGFyZQ0KICAgcGVyZm9ybWVkIGFz IGRlc2NyaWJlZCBlYXJsaWVyIGluIHRoaXMgc2VjdGlvbi4NCg0KDQoqKg0KDQoNCg0KKiogU2Vj dGlvbiA1LjMNCg0KDQoNCk9MRDoNCiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHNw ZWNpZmllZCBhcyBhIGdyb3VwIG9mIGl0cyBjb25zdGl0dWVudA0KICAgU1IgUG9saWNpZXMuDQoN CiAgIEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4gaXQgaGFzIGF0IGxl YXN0IG9uZSB2YWxpZA0KICAgY29uc3RpdHVlbnQgU1IgUG9saWN5Lg0KDQoNCg0KTkVXOg0KICAg QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgc3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRz IGNvbnN0aXR1ZW50DQogICBjYW5kaWRhdGUgcGF0aHMuDQoNCiAgIEEgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4gaXQgaGFzIGF0IGxlYXN0IG9uZSB2YWxpZA0KICAgY29u c3RpdHVlbnQgY2FuZGlkYXRlIHBhdGguDQoNCg0KKioNCg0KDQoNClJlZ2FyZHMsDQoNCi1QYXZh bg0KDQoNCg0KT24gU3VuLCBOb3YgMSwgMjAyMCBhdCA3OjAyIFBNIEtldGFuIFRhbGF1bGlrYXIg KGtldGFudCkgPGtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhlbGxvIEFsbCwNCg0KV2UgaGF2ZSBqdXN0 IHBvc3RlZCBhbiB1cGRhdGUgZm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRoZSBzdW1t YXJ5IG9mIGNoYW5nZXM6DQoNCjEpIEludHJvZHVjdGlvbiBvZiB0aGUgQ29tcG9zaXRlIENhbmRp ZGF0ZSBQYXRoIGNvbnN0cnVjdCB0byBhZGRyZXNzIGEgcGVuZGluZyBjb21tZW50IGZyb20gdGhl IFdHIChSZWYgOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9m RXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIGFuZCBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NwcmluZy9kOW9TU2JncDBqQ0V4UngwU1h5QlkwQ3lxWFUvKQ0KMikgQmFz ZWQgb24gb2ZmbGluZSBmZWVkYmFjayByZWNlaXZlZCwgdXBkYXRlZCBTUnY2IHNlZ21lbnQgdHlw ZXMgdG8gaW5jbHVkZSBvcHRpb25hbCBTUnY2IFNJRCBhbmQgYmVoYXZpb3IgaW5zdGVhZCBvZiB0 aGUgbmV3IHR5cGUgdGhhdCB3YXMgaW50cm9kdWNlZCBmb3IgaXQgaW4gdGhlIHYwOC4NCjMpIENs YXJpZmljYXRpb24gb2YgaGFuZGxpbmcgb2YgY29sb3JzIGFuZCBCR1AgbXVsdGktcGF0aCBzY2Vu YXJpb3MgYmFzZWQgb24gb2ZmbGluZSBmZWVkYmFjayByZWNlaXZlZC4NCjQpIENsYXJpZmljYXRp b24gb24gY29uc2lkZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5IGFzIGRpc2N1c3Nl ZCBpbiB0aGUgV0cgKFJlZiA6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv c3ByaW5nL0VWMXl0VXNkNVpna01IRE4wSXZGaHc5aWQ0MC8pDQoNClBsZWFzZSBsZXQga25vdyB5 b3VyIGNvbW1lbnRzL2ZlZWRiYWNrLg0KDQpUaGFua3MsDQpLZXRhbiAob24gYmVoYWxmIG9mIGNv LWF1dGhvcnMpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNw cmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9u IEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NClNlbnQ6IDAyIE5vdmVtYmVyIDIwMjAgMDY6MjcNClRvOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiBzcHJpbmdAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg U291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcgV0cgb2YgdGhlIElFVEYuDQoNCiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogU2VnbWVudCBSb3V0aW5nIFBvbGljeSBBcmNoaXRlY3R1 cmUNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQ2xhcmVuY2UgRmlsc2ZpbHMNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgS2V0YW4gVGFsYXVsaWthcg0KICAgICAgICAgICAgICAgICAgICAg ICAgICBEYW5pZWwgVm95ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgQWxleCBCb2dkYW5v dg0KICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsIE1hdHRlcw0KICAgICAgICBGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4 dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiAzNw0KICAgICAgICBEYXRlICAgICAgICAgICAg OiAyMDIwLTExLTAxDQoNCkFic3RyYWN0Og0KICAgU2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dz IGEgaGVhZGVuZCBub2RlIHRvIHN0ZWVyIGEgcGFja2V0IGZsb3cNCiAgIGFsb25nIGFueSBwYXRo LiAgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3MNCiAg IHRvIHNvdXJjZSByb3V0aW5nLiAgVGhlIGhlYWRlbmQgbm9kZSBzdGVlcnMgYSBmbG93IGludG8g YW4gU1IgUG9saWN5Lg0KICAgVGhlIGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFuIFNS IFBvbGljeSBpcyBhdWdtZW50ZWQgd2l0aCBhbg0KICAgb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRz IGFzc29jaWF0ZWQgd2l0aCB0aGF0IFNSIFBvbGljeS4gIFRoaXMNCiAgIGRvY3VtZW50IGRldGFp bHMgdGhlIGNvbmNlcHRzIG9mIFNSIFBvbGljeSBhbmQgc3RlZXJpbmcgaW50byBhbiBTUg0KICAg UG9saWN5Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eS0wOQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y ZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcg bWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo= --_000_F4D9D63A369142C2AB693FEE278B808Enokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <571526D9DD636844B8C1B379DBD33CE7@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2lu LWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5nbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdt YWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5 bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDYy MDUxMjA1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjE2MTcyNTc0O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgVGFyZWssPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGNvbW1l bnRzLiBTbWFsbCByZXBseSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZXc8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRhcmVrIFNhYWQgJmx0O3RzYWFkLm5ldEBnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAyMCBh dCAyOjIyIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENB L090dGF3YSkmcXVvdDsgJmx0O2FuZHJldy5zdG9uZUBub2tpYS5jb20mZ3Q7LCAmcXVvdDtLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpJnF1b3Q7ICZsdDtrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmcmZ3Q7LCBWaXNobnUgUGF2YW4gQmVlcmFtICZsdDt2aXNobnVwYXZhbkBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzcHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3Nw cmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzcHJpbmddIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5TZWUgaW5saW5lIGZvciBzb21lIGNvbW1lbnRzLi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJp bmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7U3Rv bmUsIEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpJnF1b3Q7ICZsdDthbmRyZXcuc3RvbmVAbm9r aWEuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE5vdmVtYmVyIDExLCAyMDIw IGF0IDY6MTYgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0tldGFuIFRhbGF1bGlrYXIgKGtldGFu dCkmcXVvdDsgJmx0O2tldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDssIFZpc2hu dSBQYXZhbiBCZWVyYW0gJmx0O3Zpc2hudXBhdmFuQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIEtldGFuLCBQYXZhbiw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+R29vZCBkaXNjdXNzaW9uLiBKdXN0IGdvaW5nIHRvIGNoaXAgaW4g c29tZSB0aG91Z2h0c+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbmUgb2YgdGhlIGVsZW1lbnRz IEkgcGVyc29uYWxseSBsaWtlIG9mIHRoZSBTUiBQb2xpY3kgbW9kZWwgaXMgdGhhdCBtYW55IENh bmRpZGF0ZSBQYXRocyBtYXkgZXhpc3QsIGJ1dCBvbmx5IG9uZSBtYXkgYmUgYWN0aXZlIGFuZCBh IGNhbmRpZGF0ZSBwYXRoIGNvbnRhaW5zIDEgb3IgbWFueSBTSUQgbGlzdHMuIEl04oCZcyBhIHNp bXBsZSBwYXJlbnQvY2hpbGQgLSByb290L2xlYWYNCiB0cmVlIHdpdGggdmVyeSBjbGVhciBydWxl cyB3aXRoaW4gdGhlIFNSIHBvbGljeSBjb250ZXh0IGluc3RhbmNlLiBGcm9tIG15IHBvaW50IG9m IHZpZXcsIHdoYXQgaXMgYmVpbmcgcHJvcG9zZWQgaW4gdGhlIC0wOSBkb2N1bWVudCBzdGlsbCBm b2xsb3dzIHRob3NlIHJ1bGVzIGFuZCB0aGUgZ2VuZXJhbCB0b3AtZG93biB0cmVlIGJlaGF2aW91 ci4gRGVzcGl0ZSB0aGUgY29tcG9zaXRlIENQIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IFNSIFBv bGljeSwNCiB0aGF0IFNSIFBvbGljeSBzdGlsbCBmb2xsb3dzIGFsbCBvZiB0aGUgc2FtZSBydWxl cyB0b3AgZG93biBpbiBpdHMgb3duIGlzb2xhdGVkIGNvbnRleHQuIENvbXBhcmUgdGhhdCB0byBz YXksIGhhdmluZyBhIGNhbmRpZGF0ZSBwYXRoIGNvbnRhaW4gYSBjaGlsZCB0aGF0IHBvaW50cyB0 byBvdGhlciBjYW5kaWRhdGUgcGF0aHMgd2l0aGluIHRoZSBzYW1lIFNSIFBvbGljeSBjb250ZXh0 OiB3aXRoaW4gdGhlIHNhbWUgY29udGV4dCBhIGNoaWxkIGlzDQogcG9pbnRpbmcgdG8gYSBzaWJs aW5nIG9mIGl0cyBwYXJlbnQuIFRoZSBydWxlcyBub3cgaGF2ZSB0byBiZW5kIHNsaWdodGx5LiBB cyBub3RlZCBiZWxvdywgc29tZSBvZiB0aGUgcnVsZXMgYXJvdW5kIHdoYXQgaXMgY29uc2lkZXJl ZCBhbiBhY3RpdmUgY2FuZGlkYXRlIHBhdGggd291bGQgbmVlZCB0byBjaGFuZ2UsIHNpbmNlIHRo ZSBjb25zdGl0dWVudHMgZXNzZW50aWFsbHkgYXJlIGFjdGl2ZSAodGhleeKAmXJlIGluc3RhbGxl ZCkgZGVzcGl0ZSBub3QNCiBiZWluZyB0aG91Z2h0IG9mIGFzIGJlaW5nIGFjdGl2ZS4gTm90ZSB0 aGF0IHRoZSBwcm9wb3NlZCBuZXcgdGV4dCBiZWxvdyBzYXlzIOKAnFRoZSBwcmVmZXJlbmNlIGlz IGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMm cXVvdDsgd2hpY2ggaXMgYWxzbyBhIG5ldyBydWxlLCBob3dldmVyIG9uZSBjb3VsZCBwZXJoYXBz IHdvcmsgYXJvdW5kIHRoYXQgYnkganVzdCByZXF1aXJpbmcgdGhlIHByZWZlcmVuY2Ugb24NCiB0 aGUgY29uc3RpdHVlbnRzIGJlIGxlc3MgcHJlZmVycmVkIHRoYW4gYW55IG90aGVyIHN0YW5kYXJk IG9yIGNvbXBvc2l0ZSBDUCDigJMgYnV0IHRoYXQgcmFpc2VzIGl0cyBvd24gdHJvdWJsZXMgd2l0 aCBtdWx0aXBsZSBzb3VyY2VzIG9mIHByb3Zpc2lvbmluZyDigJMgd2hpY2ggbGVhZHMgdG8gYSBy dWxlIGFza2luZyB0byBpZ25vcmUgdGhlIHByZWZlcmVuY2UuIEluIHN1bW1hcnksIGZyb20gbXkg cC5vLnYgbmV3IHJ1bGVzIGluIHRoZSBoaWVyYXJjaHkNCiB3b3VsZCBuZWVkIHRvIGJlIGludHJv ZHVjZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZGluZyBzdGVlcmluZyBpbnRvIGFuIFNS IFBvbGljeSwgeWVzLCB5b3UgYnVybiBjb2xvcnMgaW4gZG9pbmcgdGhpcyAoMzJiaXRzLi4uKSBh bmQgaXQgd291bGQgcmVxdWlyZSBkZXBsb3lpbmcgYW4gZW50aXJlbHkgZGVkaWNhdGVkIFNSIFBv bGljeSBjb25zdHJ1Y3QsIGFuZCBydW4gdGhlIHJpc2sgb2Ygc3RlZXJpbmcg4oCYb3RoZXLigJkg dHJhZmZpYyBpbnRvDQogdGhhdCBwb2xpY3kuIElmIHRoaXMgaXMgYSBjb25jZXJuLCB3b3VsZCB0 aGUgY29tcG9zaXRlIFNSIFBvbGljaWVzIG5vdCBiZSBlbmdpbmVlcmVkIGluIGEgd2F5IHdoZXJl IHRoZSBjb2xvciBibG9jayB1c2VkIGlzIGRlc2lnbmVkIHRvIG5vdCBiZSB1c2VkIGVsc2V3aGVy ZSBpbiB0aGUgbmV0d29yayBmb3Igb3RoZXIgcHVycG9zZXM/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+W1RTXTogVG9k YXkgY29sb3JzIG9mIFNSIFBvbGljaWVzIHRoYXQgYXJlIGluc3RhbnRpYXRlZCDigJxvbi1kZW1h bmTigJ0gb3IgaW5zdGFudGlhdGVkIHZpYSBQQ0VQIGZyb20gYSBQQ0UgYXJlIGRlcml2ZWQgZnJv bSB0aGUgaW50ZW50L3NlcnZpY2UuIFdpdGggdGhlIGhpZXJhcmNoaWNhbCBTUiBwb2xpY2llcyBw cm9wb3NhbCwgYSBQQ0UgbWF5IG5lZWQgdG8gaW5zdGFudGlhdGUNCiB0aGUgY29sb3JlZCBjaGls ZCBTUiBwb2xpY2llcyBvbi1kZW1hbmQgdG9vLCBidXQgaXQgaXMgbm90IGNsZWFyIHdoZXJlIHRo ZSBjb2xvcnMgb2YgdGhvc2UgY2hpbGQgU1IgcG9saWNpZXMgd291bGQgYmUgZGVyaXZlZCBmcm9t LiBBcyBBbmRyZXcgc3VnZ2VzdHMsIGEgYmxvY2sgb2YgY29sb3JzIGNvdWxkIGJlIGNhcnZlZCBm cm9tIGV2ZXJ5IGhlYWRlbmTigJlzIHNwYWNlIC0tIHNwZWNpZmljYWxseSBmb3IgdGhpcyBwdXJw b3NlIGFuZCBiZSBtYW5hZ2VkDQogYnkgdGhlIFBDRS4gQWx0ZXJuYXRpdmVseSwgb25lIGNvdWxk IGNvbnNpZGVyIGNyZWF0aW5nIHN1Y2ggU1IgUG9saWNpZXMgd2l0aCBhIHNwZWNpYWwvcmVzZXJ2 ZWQgY29sb3IgdGhhdCB3b3VsZCBzaW1wbGlmeSB0aGVpciBjcmVhdGlvbi4gTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSBTUiBQb2xpY2llcyBtYXkg YmUgaW5zdGFudGlhdGVkIChlLmcuIGZvciB0YWN0aWNhbCBURSDigJMgZS5nLiBvbiBQDQogbm9k ZXMpIHRoYXQgd291bGQgbm90IHJlcXVpcmUgY29sb3IgcmVzb2x1dGlvbiwgYW5kIGNyZWF0aW9u IG9mIHRob3NlIGNvdWxkIGJlbmVmaXQgZnJvbSBhIHJlc2VydmVkIGNvbG9yIHRvby48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQW5kcmV3 XSBHb29kIHBvaW50IGluZGVlZC4gVGhlIFAgbm9kZSBpcyB3aGF0IEkgd2FzIHBvaW50aW5nIGF0 IHdpdGggdGhlIEJTSUQgZXhhbXBsZSwgd2hlcmUsIGZvciBleGFtcGxlLCB3ZeKAmWxsIGhhdmUg dG8gYnVybiBhIGNvbG9yIHRvIGRlcGxveSBhIFNSIFBvbGljeSBvbiBhIHRyYW5zaXQgbm9kZSB3 aGVuIHRoZSBjb25zdW1lciBpbnRlbnQgaXMgc2ltcGx5IGZvciB0aGUgQlNJRC4gVGhhdCBjb2xv ciBzZWxlY3Rpb24NCiB3b3VsZCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQg4oCYc3BlY2lhbOKAmSBh bmQgdGFrZW4gZnJvbSBhIHVuaXF1ZSBibG9jayBpZiBvbmUgd2FudHMgdG8gYXZvaWQgdXNpbmcg aXQgZm9yIGhlYWQtZW5kIHN0ZWVyaW5nIG9uIHRoYXQgUCBub2RlLiAmbmJzcDtOb3RpbmcgdGhh dCBjb2xvciBpcyBwYXJ0IG9mIHdoYXQgdW5pcXVlbmVzcywgdG8gZGVmaW5lIHRoZSDigJxub3Qg Zm9yIHN0ZWVyaW5n4oCdIGJlaGF2aW91ciwgaXQgd291bGQgbmVlZCB0byBiZSBhIHJlc2VydmVk DQogYmxvY2sgb3IgYml0IGVuY29kZWQgaW4gY29sb3IgYXMgb3Bwb3NlZCB0byBhIHNpbmdsZSBz cGVjaWFsIHZhbHVlLiBJ4oCZbSBub3Qgc3VyZSBhIHNwZWNpYWwgcmFuZ2UgbmVlZHMgdG8gYmUg SUVURiBzdGFuZGFyZGl6ZWQgb3Igc2ltcGx5IGxlZnQgdG8gaW1wbGVtZW50YXRpb25zL1BDRSAv IG5ldHdvcmsgZGVzaWduIHRvIGFsbG9jYXRlIGFuZCBlbmZvcmNlLiBJdCBzZWVtcyB0aGF0IHRo ZSBtb2RlbCB0byBzdGVlciBhbiBTUiBQb2xpY3kgY2FuZGlkYXRlDQogcGF0aCBpbnRvIGFub3Ro ZXIgU1IgUG9saWN5IHdpdGggZWl0aGVyIGNvbG9yIG9yIHRoZSBjb25jZXB0IG9mIGEgc3BlY2lh bCBjb2xvciBzdGlsbCBzZWVtcyBmZWFzaWJsZSBpbiB0aGUgcHJlc2VudCBkb2N1bWVudC4gSXQg bWlnaHQgYmUgd29ydGggaGF2aW5nIHRleHQgZGVzY3JpYmluZyB0aGF0IGEgY29uc3RpdHVlbnQg Y2FuZGlkYXRlIHBhdGggbWF5IGJlIHVzZWQgZm9yIHN0ZWVyaW5nIG9uIHRoZSBoZWFkZW5kLCBh bmQgaWYgaW50ZW50aW9uDQogaXMgdG8gYXZvaWQgdGhhdCB0aGVuIHRoZSB1c2VyL3BjZS9uZXR3 b3JrIGRlc2lnbiBzaG91bGQgYWxsb2NhdGUgYSBibG9jayBvZiB2YWx1ZXMgZm9yIGNvbnN0aXR1 ZW50IGNhbmRpZGF0ZSBwYXRocyBhbmQgc2VsZWN0IG9ubHkgZnJvbSB0aGF0IGJsb2NrLCBub3Qg dG8gYmUgdXNlZCBvbiBhbnkgb3RoZXIgcm91dGVzIGluIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRhcmVrPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SXMgdGhlcmUgbm90IGEgZGlmZmVyZW50IGJ1dCBraW5kIG9m IHNpbWlsYXIgcHJvYmxlbSB3aXRoIEJpbmRpbmcgU0lEcywgaW4gdGhhdCB0aGV54oCZcmUgZWxp Z2libGUgZm9yIHVzZSBieSBvdGhlciBjb25zdW1lcnMgZXZlbiBpZiBub3QgZGlyZWN0bHkgaW50 ZW5kZWQ/IChhbHRob3VnaCBhdCBsZWFzdCBCU0lEcyBhcmUgb3B0aW9uYWwgYW5kIG5vdCBtYW5k YXRvcnkpLg0KIEluIGFkZGl0aW9uIHRvIHRoZSBzcGxpdCBURSBjYXNlcywgYmVpbmcgYWJsZSB0 byBoYXZlIGFuIFNSIFBvbGljeSBzdGVlciBpbnRvIGFub3RoZXIgU1IgUG9saWN5IG1pZ2h0IGFs c28gaGF2ZSBzb21lIHZhbHVlIGluIGEgYmFja3VwIGNhbmRpZGF0ZSBzY2VuYXJpbyB3aGVuIG9u ZSBoYXMgbXVsdGlwbGUgU1IgUG9saWNpZXMgd2l0aCB0aGUgc2FtZSBlbmRwb2ludCwgYnV0IGNh biBzaGFyZSBhIGNvbW1vbiBmYWxsYmFjay9iZXN0IGVmZm9ydA0KIGNhbmRpZGF0ZSBwYXRoLiBU aGUgZW50aXR5ICg8aT5JJ20gdGhpbmtpbmcgUENFPC9pPikgbWFuYWdpbmcgdGhhdCB3b3VsZCBv bmx5IG5lZWQgdG8gbWFpbnRhaW4gdGhlIGZhbGxiYWNrL2Jlc3QgZWZmb3J0IENQIFNJRCBsaXN0 KHMpLCBpbnN0ZWFkIG9mIG9uZSBmb3IgZWFjaCBOICogQ1BzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5Tb21ldGhpbmcgSSBoYXZlbuKAmXQgY29uY2x1ZGVkIHRvIG15c2VsZiB5ZXQgYXJlIHF1ZXN0 aW9ucyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmRvZXMgaGF2aW5nIGEgY2FuZGlkYXRlIHBhdGgg c3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBzYXRpc2Z5IHRoZSBhYmlsaXR5IHRvIGRvIHZh cmlvdXMgc3ViLXBhdGggc3BlY2lmaWMgVEUvY29uc3RyYWludC9vYmplY3QgY29tYmluYXRpb25z IHN1ZmZpY2llbnRseT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+aXMgdGhlIG1vZGVsIHJlbGF0aXZlbHkgc3RyYWlnaHQgZm9yd2FyZCB0 byBtYXAgaW50byB5YW5nL2JncC9wY2VwIGV0Yy4uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5kb2VzIHVzaW5nIGFuIGFkZGl0aW9uYWwg U1IgUG9saWN5IGNyZWF0ZSB0b28gbXVjaCBvdmVyaGVhZCBvciBzdGF0ZSBidXJuIHRvIGNvbmZp Z3VyZSwgZGVwbG95LCBtYW5hZ2UsIHRyYWNrIGV0Yy4uID88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Q2hlZXJzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5BbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg JnF1b3Q7S2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSZxdW90OyAmbHQ7a2V0YW50PTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBOb3ZlbWJl ciAxMCwgMjAyMCBhdCAxMDozMyBQTTxicj4NCjxiPlRvOiA8L2I+VmlzaG51IFBhdmFuIEJlZXJh bSAmbHQ7dmlzaG51cGF2YW5AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c3By aW5nQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA5LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5IaSBQYXZhbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UGxlYXNlIGNo ZWNrIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+RnJvbTo8L2I+IFZpc2hudSBQYXZhbiBCZWVyYW0gJmx0O3Zpc2hudXBhdmFu QGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxMSBOb3ZlbWJlciAyMDIwIDAwOjI2 PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRhbnRAY2lz Y28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA5LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+S2V0YW4sIEhpITxicj4NCjxicj4NClBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNw b25zZXMgKHByZWZpeGVkIFZQQikuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQotUGF2YW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1ZSwgTm92IDEwLCAy MDIwIGF0IDQ6MDQgQU0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkhpIFBhdmFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5QbGVhc2Ug Y2hlY2sgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj5G cm9tOjwvYj4gVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpc2hudXBh dmFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT4m Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgTm92ZW1iZXIgMjAyMCAwMDowODxicj4NCjxiPlRv OjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFu dEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXRhbnRAY2lzY28uY29tPC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5n XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5 LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+S2V0YW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk11Y2ggVGhh bmtzIGZvciB0YWtpbmcgYSBzdGFiIGF0IGFkZHJlc3NpbmcgdGhlIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aCB1c2UtY2FzZSE8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2Mjhn bWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwO1dlIHNlZW0gdG8gYmUgY29udmVyZ2lu Zy48L3NwYW4+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT5bS1RdIFRoYW5rcyBmb3IgdGhhdCBmZWVk YmFjayBhbmQgY29uZmlybWF0aW9uIHRoYXQgdGhlIHByb3Bvc2FsIGluIHRoZSBkcmFmdCBkb2Vz IGFkZHJlc3MgdGhlIHVzZS1jYXNlLiBJIGJlbGlldmUgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIHRo ZSBtZWNoYW5pY3Mgb2YgaG93IHRoaXMgaXMgYWNoaWV2ZWQgd2l0aGluIHRoZSBjdXJyZW50IFNS IFBvbGljeQ0KIGZyYW1ld29yay48L2k+PC9iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT4mbmJzcDs8L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhvd2V2 ZXIsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB5b3UgbmVlZCB0byB1c2UgYWRkaXRpb25hbCBT UiBwb2xpY2llcyAoYW5kIHVubmVjZXNzYXJpbHkgYnVybiBhZGRpdGlvbmFsIGNvbG9ycykgdG8g YWRkcmVzcyB0aGlzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+W0tUXSBJIGRvIG5vdCBmb2xsb3cg d2hhdCB5b3UgbWVhbiBieSDigJxidXJuIGFkZGl0aW9uYWwgY29sb3Jz4oCdLiBDb2xvciBpcyBq dXN0IGEgMzIgYml0IG51bWJlciB0aGF0IGluZGljYXRlcyB0aGUg4oCcaW50ZW504oCdIGFuZCBp cyBub3QgcmVhbGx5IGEgc2NhcmNlIHJlc291cmNlLiBBc3NpZ25pbmcgYSBjb2xvciB0byDigJxh IGNvbXBvc2l0ZSBpbnRlbnTigJ0gc2VlbXMNCiBsaWtlIGEgc2VhbWxlc3Mgd2F5IHRvIGludGVn cmF0ZSB3aXRoIGV4aXN0aW5nIG1lY2hhbmlzbXMgZm9yIFN0ZWVyaW5nIG92ZXIgU1IgUG9saWNp ZXMuIFRoaXMgZ2l2ZXMgdGhlIGZsZXhpYmlsaXR5IGZvciBzYXkgc29tZSBCR1Agc2VydmljZXMg dG8gYmUgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0dWVudCBleHBsaWNpdC9keW5hbWljIGludGVu dCB3aGlsZSBvdGhlcnMgY2FuIHN0ZWVyIG92ZXIgYSBjb21wb3NpdGUgaW50ZW50IHRoYXQgaW5j bHVkZXMNCiB0aG9zZSBpbmRpdmlkdWFsIGV4cGxpY2l0L2R5bmFtaWMgaW50ZW50cy48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W1ZQQl0gVGhlIOKAnGZsZXhpYmlsaXR54oCdIHRo YXQgeW91IGFyZSByZWZlcnJpbmcgdG8gaXMgdW5kZXNpcmFibGUgZm9yIHRoaXMgdXNlLWNhc2Uu IEZvciB0aGUgdHJhZmZpYy1zcGxpdCB1c2UtY2FzZSwgd2UgZG9u4oCZdCB3YW50IGFueSBvdGhl ciBzZXJ2aWNlcyB0byBiZSBkaXJlY3RseSBzdGVlcmVkIG92ZXIgdGhlIGNvbnN0aXR1ZW50cyB3 aGVuIHRoZXkgYXJlIHBhcnQNCiBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bS1RdIEkgYmVsaWV2ZSB0aGUgdXNl LWNhc2UgdGhhdCB5b3UgYXJlIHJlZmVycmluZyB0byB3YXMgZm9yIHNwbGl0dGluZyBzb21lIHRy YWZmaWMgZm9yIGEgc2VydmljZSBvdmVyIGEgYmx1ZSBwbGFuZSBhbmQgdGhlIHJlc3Qgb3ZlciBh IHJlZCBwbGFuZS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUgbWF5DQogYmUgb3RoZXIgc2Vydmlj ZXMgdGhhdCB1dGlsaXplIG9ubHkgYSBzaW5nbGUgcGxhbmUuIFRoZSBmbGV4aWJpbGl0eSB0aGF0 IEkgd2FzIHJlZmVycmluZyB0byB3YXMgdG8gZW5hYmxlL2FsbG93IGZvciBlaXRoZXIgb2YgdGhl IHR3byBzY2VuYXJpb3MgYW5kIHRoZXJlIG1heSBiZSBvdGhlci9tb3JlIHVzZS1jYXNlcyBmb3Ig d2hpY2ggd2UgbmVlZCBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdvcmsuPC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPlRoZSBjdXJyZW50IHByb3Bvc2FsIGluIHRoZSBkcmFmdCB3b3Vs ZCBoYXZlIGJlZW4gYWNjZXB0YWJsZSBpZiB0aGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgd2Vy ZSB1bmNvbG9yZWQg4oCTIGJ1dCB0aGF0IHdvdWxkIHZpb2xhdGUgdGhlIGN1cnJlbnQgcnVsZXMg aW1wb3NlZCBieSB0aGUgZHJhZnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+V2h5IGNhbuKAmXQg dGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBqdXN0IGJlIGEgZ3JvdXBpbmcgb2YgZXhwbGlj aXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWljIGNhbmRpZGF0ZSBwYXRocz88L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48Yj48aT5bS1RdIFRoaXMgaXMgYmVjYXVzZSBpbiB0aGUgU1IgUG9saWN5IGZyYW1l d29yaywgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBhY3RpdmUgQ1Ag4oCTIGl0IG1heSBiZSBleHBs aWNpdCBvciBkeW5hbWljLiBOb3cgd2XigJl2ZSBhZGRlZCBhbm90aGVyIENvbXBvc2l0ZSBDUCB0 eXBlIHRvIGNvdmVyIHRoaXMgc3BlY2lmaWMgdXNlLWNhc2UuIFlvdXIgcHJvcG9zYWwNCiB3aWxs IHJlc3VsdCBpbiAzIGNhbmRpZGF0ZSBwYXRocyBiZWluZyBhY3RpdmUgd2l0aGluIHRoZSBzYW1l IFNSIFBvbGljeSDigJMgb25lIGVhY2ggb2YgdGhlIGV4cGxpY2l0IGFuZCBkeW5hbWljIENQIGFu ZCB0aGVuIGFkZGl0aW9uYWxseSB0aGUgQ29tcG9zaXRlIENQLiBUaGlzIGJyZWFrcyB0aGUgZXhp c3RpbmcgcnVsZXMgZm9yIHNlbGVjdGlvbiBvZiBDUCBiYXNlZCBvbiBwcmVmZXJlbmNlIGFuZCBt ZWNoYW5pc21zIGxpa2UgZmFsbGJhY2sgYmV0d2Vlbg0KIENQcy4gV2hpbGUgdGhlIGN1cnJlbnQg cHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHByb3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIG5ldyB1 c2UtY2FzZSB3aXRoIGEgYmFja3dhcmRzIGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBTUiBQ b2xpY3kgZnJhbWV3b3JrLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bVlBCXSBU aGUgcHJvcG9zYWwgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgYmFja3dhcmRzIGNvbXBhdGlibGUg YW5kIGRvZXMgbm90IGludGVuZCB0byBicmVhayBhbnkgZXhpc3RpbmcgcnVsZXMgZm9yIGRlZW1p bmcgYSBjYW5kaWRhdGUgcGF0aCBhY3RpdmUuIEFzIHBlciB0aGUgcnVsZXMgdGhhdCBhcmUgb3V0 bGluZWQgaW4gU2VjdGlvbiAyLjksIG9ubHkgdGhlDQogY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRo IGlzIOKAnGFjdGl2ZeKAnSBnaXZlbiBpdHMgcHJlZmVyZW5jZS4gVGhlIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRocyB3aWxsIG5ldmVyIGJlIGFjdGl2ZSBvbiB0aGVpciBvd24uIElmIGl0IGlz IG5lY2Vzc2FyeSwgd2UgY2FuIGFkZCBhIHN0YXRlbWVudCBpbiBTZWN0aW9uIDIuOSB0byBleHBs aWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNhbmRpZGF0ZSBwYXRoIHNlbGVjdGlvbiBjcml0ZXJpYSBk b2VzIG5vdA0KIGFwcGx5IHRvIHRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMuJm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPltLVF0gV2hlbiBhIENQ IGlzIOKAnGFjdGl2ZeKAnSBpdCBpcyBhY3R1YWxseSB0aGUgb25lIHRoYXQgaXMgYmVpbmcgdXNl ZCBmb3IgZm9yd2FyZGluZy48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojNDQ3MkM0Ij4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5UaGFua3MsPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+S2V0YW48L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxp PiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT5UaGFua3MsPC9pPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxp PktldGFuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgY2hhbmdlczo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+KiogU2VjdGlvbiAyLjI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgQSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRh aW5lciBmb3IgZ3JvdXBpbmcgb2YgU1I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBQb2xpY2llcy4mbmJzcDsgVGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBjb25z dHJ1Y3QgZW5hYmxlcyBjb21iaW5hdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IG9mIFNSIFBvbGljaWVzLCBlYWNoIHdpdGggZXhwbGljaXQgY2FuZGlkYXRlIHBh dGhzIGFuZC9vciBkeW5hbWljPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgY2FuZGlkYXRlIHBhdGhzIHdpdGggcG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlv biBvYmplY3RpdmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5k IGNvbnN0cmFpbnRzLCBmb3IgYSBsb2FkLWJhbGFuY2VkIHN0ZWVyaW5nIG9mIHBhY2tldCBmbG93 cyBvdmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaXRzIGNvbnN0 aXR1ZW50IFNSIFBvbGljaWVzLiZuYnNwOyBUaGUgZm9sbG93aW5nIGNyaXRlcmlhIGFwcGx5IGZv cjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluY2x1c2lvbiBvZiBj b25zdGl0dWVudCBTUiBQb2xpY2llcyB1c2luZyBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aDwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVuZGVyIGEgcGFyZW50IFNS IFBvbGljeTo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIGVuZHBvaW50cyBvZiB0aGUg Y29uc3RpdHVlbnQgU1IgUG9saWNpZXMgYW5kIHRoZSBwYXJlbnQgU1I8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQb2xpY3kgTVVTVCBi ZSBpZGVudGljYWw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGNvbG9ycyBvZiBlYWNo IG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSIFBvbGlj eSBNVVNUIGJlIGRpZmZlcmVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgY29uc3Rp dHVlbnQgU1IgUG9saWNpZXMgTVVTVCBOT1QgdXNlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aHM8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IG9mIGEgY29tcG9z aXRlIGNhbmRpZGF0ZSBwYXRoIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3Nl cyAocmVmZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAyLjExPC9zcGFuPjwvYT4gZm9yIGRldGFpbHMpLiZu YnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGFj dHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3VwaW5nIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgZXhwbGljaXQgY2FuZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWlj IGNhbmRpZGF0ZSBwYXRocyB3aXRoIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7cG90ZW50aWFsbHkgZGlmZmVyZW50IG9wdGltaXphdGlvbiBvYmplY3RpdmVz IGFuZCBjb25zdHJhaW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVzIGxvYWQtYmFs YW5jZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzdGVlcmluZyBv ZiBwYWNrZXQtZmxvd3Mgb3ZlciBhIHNldCBvZiBjb25zdGl0dWVudCBjYW5kaWRhdGU8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXRocy4gVGhlIGZvbGxvd2luZyBj cml0ZXJpYSBhcHBseSBmb3IgY29uc3RpdHVlbnQgY2FuZGlkYXRlIDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3BhdGhzIHVuZGVyIGEgY29tcG9zaXRlIGNhbmRp ZGF0ZSBwYXRoOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgdGhlIHByZWZlcmVuY2Ugb2YgdGhl IGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIE1VU1QgYmUgPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aWdub3JlZC4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggTVVTVCBO T1QgYmUgYSBjb21wb3NpdGUgY2FuZGlkYXRlIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGF0aDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgRWFjaCBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBvZiBhIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQt c3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFzc29j aWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXMgKHJlZmVyPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xp Y3ktMDkjc2VjdGlvbi0yLjExIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 NTRGNzIiPlNlY3Rpb24gMi4xMTwvc3Bhbj48L2E+IGZvciBkZXRhaWxzKS4mbmJzcDsgVGhlIGRl ZmF1bHQgd2VpZ2h0IGlzIDEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqIFNlY3Rpb24gMi4xMTwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldoZW4gYSBjb21wb3NpdGUgY2Fu ZGlkYXRlIHBhdGggaXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3M8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPnN0ZWVyZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IFNSIFBvbGljeSBpcyBlcXVhbCB0 byB0aGUgcmVsYXRpdmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndlaWdodCBvZiBlYWNoIGNvbnN0aXR1 ZW50IFNSIFBvbGljeS4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GdXJ0aGVyDQogbG9h ZCBiYWxhbmNpbmcgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZsb3dzIHN0ZWVyZWQgaW50byBhIGNv bnN0aXR1ZW50IFNSIFBvbGljeSBpcyBwZXJmb3JtZWQgYmFzZWQgb24gdGhlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21h aWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj53ZWlnaHRzIG9mIHRoZSBTZWdtZW50LUxpc3Qgb2YgdGhlIGFjdGl2ZSBjYW5kaWRh dGUgcGF0aCBvZiB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25zdGl0dWVudCBTUiBQb2xpY3ku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldoZW4gYSBjb21wb3NpdGUgY2Fu ZGlkYXRlIHBhdGggaXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3M8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPnN0ZWVyZWQgaW50byBlYWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIGlzIGVx dWFsIHRvIHRoZSByZWxhdGl2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2VpZ2h0IG9mIGVhY2ggY29u c3RpdHVlbnQgY2FuZGlkYXRlIHBhdGguJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnVy dGhlcg0KIGxvYWQgYmFsYW5jaW5nIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mbG93cyBzdGVlcmVk IGludG8gYSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBpcyBwZXJmb3JtZWQgYmFzZWQgb248 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPnRoZSB3ZWlnaHRzIG9mIGVhY2ggYXNzb2NpYXRlZCBTZWdtZW50 LUxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDIuMTM8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+T0xEOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgaW5mb3JtYXRpb24gbW9k ZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZpbmcgYSBjb21wb3NpdGU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmNhbmRpZGF0ZSBwYXRoIGlzIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIHBvbGljeSBQ T0wxMDAgJmx0O2hlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0gRTEmZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5kaWRhdGUt cGF0aCBDUDEgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMSZndDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlByZWZlcmVuY2UgMjAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzEsIFNSIHBvbGljeSAm bHQ7Y29sb3IgPSAxJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcyLCBTUiBwb2xpY3kgJmx0 O2NvbG9yID0gMiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIFBPTDEg YW5kIFBPTDIgaGF2ZSBpbmZvcm1hdGlvbiBtb2RlbCBhczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGVz Y3JpYmVkIGF0IHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uJm5ic3A7PHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VGhleQ0KIGFyZSByZWZlcmVuY2VkIG9ubHkgYnk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQx Mzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PmNvbG9yIGluIHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggc2luY2UgdGhlaXIgaGVhZGVu ZCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmVuZHBvaW50IGFyZSBpZGVudGljYWwgdG8gdGhlIFBP TDEwMC4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUNCiB2YWxpZCBTZWdtZW50LUxp c3RzIG9mIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9mIFBP TDEgYW5kIFBPTDIgYXJlIGluc3RhbGxlZCBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZvcndh cmRpbmcuJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHJhZmZpYyBzdGVlcmVkIG9uIFBP TDEwMA0KIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIFBPTDE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndp dGggYSByYXRpbyBXMS8oVzErVzIpLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpdGhp biB0aGUNCiBQT0wxLCB0aGUgZmxvdy1iYXNlZCBoYXNoaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5v dmVyIGl0cyBTZWdtZW50LUxpc3RzIGFyZSBwZXJmb3JtZWQgYXMgZGVzY3JpYmVkIGVhcmxpZXIg aW4gdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+c2VjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5FVzo8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+VGhlIGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAg aGF2aW5nIGEgY29tcG9zaXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jYW5kaWRhdGUgcGF0aCBpcyB0 aGUgZm9sbG93aW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TUiBwb2xpY3kgUE9MMTAwICZsdDtoZWFkZW5kID0gSDEs IGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUxJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5kaWRhdGUtcGF0aCBDb21wLUNQICZsdDtwcm90b2NvbC1v cmlnaW4gPSAyMCwgb3JpZ2luYXRvcg0KID08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjEwMDoxLjEuMS4x LCBkaXNjcmltaW5hdG9yID0gMSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdt YWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlByZWZlcmVuY2UgMjAwPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPldlaWdodCBXMSwgQ2FuZGlkYXRlLXBhdGggQ1AxPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5X ZWlnaHQgVzIsIENhbmRpZGF0ZS1wYXRoIENQMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Q2FuZGlkYXRlLXBhdGggQ1AxICZsdDtwcm90b2NvbC1vcmlnaW4g PSAyMCwgb3JpZ2luYXRvciA9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAyJmd0Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0 MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5XZWlnaHQgVzExLCBTSUQtTGlzdDEgJmx0O1NJRDExLi4uU0lEMWkmZ3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5XZWlnaHQgVzEyLCBTSUQtTGlzdDIgJmx0O1NJRDIxLi4uU0lEMmomZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBDYW5kaWRhdGUtcGF0aCBDUDIgJmx0O3Byb3RvY29sLW9yaWdp biA9IDIwLCBvcmlnaW5hdG9yID08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyAxMDA6MS4xLjEuMSwgZGlzY3JpbWluYXRvciA9IDMmZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPldlaWdodCBXMjEsIFNJRC1MaXN0MyAmbHQ7U0lEMzEuLi5TSUQzaSZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPldlaWdodCBXMjIsIFNJRC1MaXN0NCAmbHQ7U0lENDEuLi5TSUQ0aiZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ29tcC1DUCBpcyBhIGNvbXBv c2l0ZSBjYW5kaWRhdGUgcGF0aCB3aXRoIHR3byBjb25zdGl0dWVudHMsIENQMTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Imdt YWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+YW5kIENQMi4gVGhlIHByZWZlcmVuY2UgaXMgaWdub3JlZCBmb3IgZWFjaCBvZiB0 aGUgdHdvIGNvbnN0aXR1ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMuIFRoZSB2YWxpZCBTZWdtZW50LUxpc3RzIG9mIHRo ZSB0d288c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25zdGl0dWVudA0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMgYXJlIGlu c3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZy4mbmJzcDtUcmFmZmljIHN0ZWVyZWQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7b24NCjwvc3Bhbj5Db21wLUNQIGlzIGZsb3ctYmFzZWQgaGFzaGVkIG9uIHRvIENQMSBhbmQg Q1AyIHdpdGggYSByYXRpbyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IFcxLyhXMStXMikgYW5kIFcyLyhXMStXMikgcmVzcGVjdGl2ZWx5LiBX aXRoaW4gZWFjaCBjb25zdGl0dWVudA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aCwgdGhlPHNwYW4gY2xhc3M9ImdtYWlsLW00 NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Zmxvdy1iYXNlZCBoYXNoaW5nIG92ZXIgaXRzIFNlZ21lbnQtTGlzdHMNCiBhcmUgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwZXJmb3JtZWQgYXM8 c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kZXNjcmliZWQgZWFybGllciBpbiB0aGlzIHNlY3Rpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqIFNlY3Rpb24gNS4zPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pk9MRDo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMg c3BlY2lmaWVkIGFzIGEgZ3JvdXAgb2YgaXRzIGNvbnN0aXR1ZW50PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0 MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5TUiBQb2xpY2llcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMgdmFs aWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3 MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25z dGl0dWVudCBTUiBQb2xpY3kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkEg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHNwZWNpZmllZCBhcyBhIGdyb3VwIG9mIGl0cyBj b25zdGl0dWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y2FuZGlkYXRlIHBhdGhzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5B IGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyB2YWxpZCB3aGVuIGl0IGhhcyBhdCBsZWFzdCBv bmUgdmFsaWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4qKjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVn YXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi1QYXZhbjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPk9uIFN1biwgTm92IDEsIDIwMjAgYXQgNzowMiBQTSBLZXRhbiBUYWxhdWxpa2FyIChr ZXRhbnQpICZsdDtrZXRhbnQ9PGEgaHJlZj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KV2UgaGF2 ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGUgZm9yIHRoZSBkcmFmdCBhbmQgZm9sbG93aW5nIGlzIHRo ZSBzdW1tYXJ5IG9mIGNoYW5nZXM6PGJyPg0KPGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIHRoZSBD b21wb3NpdGUgQ2FuZGlkYXRlIFBhdGggY29uc3RydWN0IHRvIGFkZHJlc3MgYSBwZW5kaW5nIGNv bW1lbnQgZnJvbSB0aGUgV0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NwcmluZy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nwcmlu Zy9mRXFFNVRPd2RoMnZFeUZtX01FamlYeVAyd3MvPC9hPiBhbmQNCjxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlC WTBDeXFYVS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvc3ByaW5nL2Q5b1NTYmdwMGpDRXhSeDBTWHlCWTBDeXFYVS88L2E+KTxicj4NCjIp IEJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50 IHR5cGVzIHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQg b2YgdGhlIG5ldyB0eXBlIHRoYXQgd2FzIGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguPGJy Pg0KMykgQ2xhcmlmaWNhdGlvbiBvZiBoYW5kbGluZyBvZiBjb2xvcnMgYW5kIEJHUCBtdWx0aS1w YXRoIHNjZW5hcmlvcyBiYXNlZCBvbiBvZmZsaW5lIGZlZWRiYWNrIHJlY2VpdmVkLjxicj4NCjQp IENsYXJpZmljYXRpb24gb24gY29uc2lkZXJhdGlvbnMgZm9yIFRJLUxGQSBmb3IgU1IgUG9saWN5 IGFzIGRpc2N1c3NlZCBpbiB0aGUgV0cgKFJlZiA6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAv IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3NwcmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvPC9hPik8YnI+DQo8YnI+DQpQbGVh c2UgbGV0IGtub3cgeW91ciBjb21tZW50cy9mZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KS2V0YW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKTxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48 YnI+DQpTZW50OiAwMiBOb3ZlbWJlciAyMDIwIDA2OjI3PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0 bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0 Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW3NwcmluZ10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8 YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcg V0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRp dGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFNlZ21lbnQgUm91 dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyZW5jZSBGaWxz Zmlsczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLZXRhbiBUYWxhdWxp a2FyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhbmllbCBWb3llcjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGV4IEJvZ2Rhbm92PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhdWwgTWF0dGVzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogMzc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0 ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0xMS0wMTxi cj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRpbmcgKFNS KSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgZmxvdzxicj4NCiZuYnNw OyAmbmJzcDthbG9uZyBhbnkgcGF0aC4mbmJzcDsgSW50ZXJtZWRpYXRlIHBlci1mbG93IHN0YXRl cyBhcmUgZWxpbWluYXRlZCB0aGFua3M8YnI+DQombmJzcDsgJm5ic3A7dG8gc291cmNlIHJvdXRp bmcuJm5ic3A7IFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFuIFNSIFBvbGlj eS48YnI+DQombmJzcDsgJm5ic3A7VGhlIGhlYWRlciBvZiBhIHBhY2tldCBzdGVlcmVkIGluIGFu IFNSIFBvbGljeSBpcyBhdWdtZW50ZWQgd2l0aCBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlcmVk IGxpc3Qgb2Ygc2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBU aGlzPGJyPg0KJm5ic3A7ICZuYnNwO2RvY3VtZW50IGRldGFpbHMgdGhlIGNvbmNlcHRzIG9mIFNS IFBvbGljeSBhbmQgc3RlZXJpbmcgaW50byBhbiBTUjxicj4NCiZuYnNwOyAmbmJzcDtQb2xpY3ku PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDki IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOTwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDk8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50 b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmlu Z0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F4D9D63A369142C2AB693FEE278B808Enokiacom_-- From nobody Thu Nov 12 17:54:37 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB83A1380; Thu, 12 Nov 2020 17:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 64VgA30V8ppA; Thu, 12 Nov 2020 17:54:32 -0800 (PST) Received: from sendh.mailex.chinaunicom.cn (sendh.mailex.chinaunicom.cn [210.53.66.231]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6793A1383; Thu, 12 Nov 2020 17:54:28 -0800 (PST) X-AuditID: 0a000f37-647ff7000000bf52-43-5fade751c71d Received: from M10-HQ-MLCEN01.cnc.intra (Unknown_Domain [10.249.212.31]) by sendh.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 97.B5.48978.157EDAF5; Fri, 13 Nov 2020 09:54:25 +0800 (HKT) Received: from M10-HQ-ML03.hq.cnc.intra (10.249.213.73) by M10-HQ-MLCEN01.cnc.intra (10.249.212.31) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 09:54:24 +0800 Received: from M10-HQ-ML02.hq.cnc.intra (10.249.213.72) by M10-HQ-ML03.hq.cnc.intra (10.249.213.73) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 09:54:19 +0800 Received: from M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250]) by M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250%20]) with mapi id 15.00.1497.006; Fri, 13 Nov 2020 09:54:18 +0800 From: =?gb2312?B?UmFuIFBhbmcowarNqLyvzcXW0Ln6warNqNHQvr/Uui2xvrK/KQ==?= To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment Thread-Index: AQHWuV8t5udZPXlkrka99K6shDPe0A== Date: Fri, 13 Nov 2020 01:54:18 +0000 Message-ID: <750e919ca514406ab274485914aaffa2@M10-HQ-ML02.hq.cnc.intra> References: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.203.1] Content-Type: multipart/alternative; boundary="_000_750e919ca514406ab274485914aaffa2M10HQML02hqcncintra_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsXC9fOKvG7g87XxBlu+sVnsvLOKxeL0ql52 i+MXfjM6MHtsXufmsWTJT6YApigum5TUnMyy1CJ9uwSujKdfrrEVPPes+DZNqIFxjXMXIyeH hICJxJXDsxi7GLk4hATOM0p0X+1ihXB2MEr87n/HDOdce/UGKrOfUaJrwys2kH42gSSJhf+/ g9kiAlES6xunMoLYzAKmEndm/QezhQV8JBqmtzBB1PhKzOzshKrXkzj9YwtYDYuAqsSlxSvB bF4Bd4krfz6D1QsJxEi07GsBizMKyEpMe3SfCWK+uMTcabNYIX4QkFiy5zwzhC0q8fLxP6i4 gcTWpftYIGwFieU996Buy5ZofzeRBWKXoMTJmU9YIHYpSzQfn846gVF8FpIVs5C0zELSAhHX kpjX8JsJwlaUmNL9kB3C1pS4MvkQlK0tsWzha+YFjOyrGCWDfd0tjC0MdP1N9ZIzMvMSS/My k/Nz9ZLzNjGCYpaB33wH489bH/QOMTJxMB5ilOBgVhLhVXZYEy/Em5JYWZValB9fVJqTWnyI UZqDRUmc181kVZyQQHpiSWp2ampBahFMlomDU6qBybrNvjdq5R/rf9Nkd/75I6u59pnZC3UX zYerds7mDDhyifmGmMKxYuWi6LolXx6cfvfrhtTkp1231oatPLQj5Ydj2L0nPyfIepZ5bNm0 UjXjoIk04w1V7yNKeQ81PhkrNfJZ3ZNeoWWg7iFzn/NwwuXwU12ewV/LDz5IvP6Cse/FKXdr 36ab3mknXCf9bg/JMg+q31V3q2eL68zvDo0a8U5KeUueCX09bdNknDiLcZ7tK5d72y8ssZ8e aLvpeUPM7dfubXzyWokvdly7v/pbSZOpSJxw4gz/ZzZvZ8SlJHOKct7dsW/z/FlxOw1YHrnf O+Q3+czGh7aPzguoie8sSbg6UWLW9wXWxi1reMyffFViKc5INNRiLipOBAA3nv0qSAMAAA== Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 01:54:36 -0000 --_000_750e919ca514406ab274485914aaffa2M10HQML02hqcncintra_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFdHLA0KDQogICAgU3VwcG9ydCB0aGUgV0cgQWRvcHRpb24gb2YgdGhlIGRyYWZ0LiBJdCB3 aWxsIGJlIHVzZWZ1bCBpbiBPQU0gYW5kIHByb3RlY3Rpb24uDQoNCkJlc3QgcmVnYXJkcywNClBh bmcgUmFuDQoNCkZyb206IEphbWVzIEd1aWNoYXJkPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb20+DQpEYXRlOiAyMDIwLTExLTA0IDAxOjM5DQpUbzogc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpDQzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIFdHIEFkb3B0aW9u IENhbGwgZm9yIGRyYWZ0LWxpLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudA0KRGVhciBXRzoNCg0K VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50LTA3 LCBlbmRpbmcgTm92ZW1iZXIgMjR0aCAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9jdW1l bnQgaGFzIHNldmVyYWwgY2hhbmdlcyBmcm9tIHYtMDYgdGhhdCB3ZXJlIHJlcXVlc3RlZCBieSB0 aGUgU1BSSU5HIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUgY2hhaXJzIGhhdmUgZXh0ZW5k ZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0aGUg V0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5nIG9u IFdHIGFkb3B0aW9uLg0KDQpBZnRlciByZXZpZXcgb2YgdGhlIGRvY3VtZW50IHBsZWFzZSBpbmRp Y2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0 LiBQbGVhc2UgYWxzbyBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAo b3IgbGFjayB0aGVyZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29u c2VudC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg0KDQoNCsjnufvE+rTt zvO908rVwcu4w9PKvP6jrMfrzai5/bXn19PTyrz+waK8tM2o1qrO0sPHoaPH67vYuLTTyrz+tb0g aHFzLXNwbWNAY2hpbmF1bmljb20uY26jrLy0v8nS1M3Ltqm0y9PKvP6ho87Sw8e9q8GivLS9q8T6 tcTQxc+itNPO0sPHtcS3osvNxL/CvNbQyb6z/aGjIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBs ZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNvbS5jbiAseW91IGNhbiB1bnN1YnNjcmli ZSBmcm9tIHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91ciBpbmZvcm1h dGlvbiBmcm9tIHNlbmQgY2F0YWxvZ3VlIG9mIG91ci4NCg== --_000_750e919ca514406ab274485914aaffa2M10HQML02hqcncintra_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Hi, WG,

        Support the = WG Adoption of the draft. It will be useful in OAM and protection.

    Best regards,
    Pang Ran
     

    Dear WG:

     

    This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, endin= g November 24th 2020. Please note that this document has several= changes from v-06 that were requested by the SPRING chairs. For this reaso= n, the chairs have extended the adoption call for an additional week to allow the WG enough time to review= these changes before deciding on WG adoption.

     

    After review of the document please indicate support (= or not) for WG adoption to the mailing list. Please als= o provide comments/reasons for that support (or lack thereof) as silence wi= ll not be considered as consent.

     =

    Thanks!

     =

    Jim, Bruno & = Joel

     

     

     

     

     

    =C8=E7=B9=FB=C4=FA=B4=ED=CE=F3=BD=D3=CA=D5=C1=CB=B8=C3=D3=CA=BC=FE=A3=AC=C7= =EB=CD=A8=B9=FD=B5=E7=D7=D3=D3=CA=BC=FE=C1=A2=BC=B4=CD=A8=D6=AA=CE=D2=C3=C7= =A1=A3=C7=EB=BB=D8=B8=B4=D3=CA=BC=FE=B5=BD hqs-spmc@chinaunicom.cn=A3= =AC=BC=B4=BF=C9=D2=D4=CD=CB=B6=A9=B4=CB=D3=CA=BC=FE=A1=A3=CE=D2=C3=C7=BD=AB= =C1=A2=BC=B4=BD=AB=C4=FA=B5=C4=D0=C5=CF=A2=B4=D3=CE=D2=C3=C7=B5=C4=B7=A2=CB= =CD=C4=BF=C2=BC=D6=D0=C9=BE=B3=FD=A1=A3 If you have received this email in = error please notify us immediately by e-mail. Please reply to hqs-spmc= @chinaunicom.cn ,you can unsubscribe from this mail. We will immediate= ly remove your information from send catalogue of our. --_000_750e919ca514406ab274485914aaffa2M10HQML02hqcncintra_-- From nobody Thu Nov 12 18:50:36 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F883A13AF; Thu, 12 Nov 2020 18:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 UJ0FyR6X06Az; Thu, 12 Nov 2020 18:50:29 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 B4F713A130B; Thu, 12 Nov 2020 18:50:29 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id d17so2321429plr.5; Thu, 12 Nov 2020 18:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fV9mb83M+LfikOtYyczT1K+ivl/NzoEMKl2UEfBETCc=; b=WESPtGypy2gzlfab8EyAFo/EpUIfzx1Pud9MnqVBSuBT/cIzrAdlMUZpsCiRlbFhaJ XWTD90sF+0bbyKSTmH9j16xmsqgFykF8W1Ej1ujnisbQvBulIaJnq8/Ocw6xxPzSUBCS a9JJt7HLa/BO8EbFdpFkQzbeM/OobT3WEzZ2t2OSvpYTjaB/4m3FSzWTeZ7/fXkRf97S VMG0znmINJCuEjuB9uN4jiXVHYYbcTY/SXkM8RUsAkZRwIo6xr0DA5Id3e4P9cx3MVfH 1ELoZchyHuKjG3o1+lOM0fxzCM5tlUvW9nObwcNP8QOG9hD8OpazVfUaD4PrdmpbRmLP RwdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fV9mb83M+LfikOtYyczT1K+ivl/NzoEMKl2UEfBETCc=; b=dIhc1wKysP7flBzeFIv8NPbQzW6cDFpfYJCOGbNPhTMKS0wy/3LiIQs+B32EHGykMT BvYhMQyTpxDiCAFpZKQBX+xyqINuWH2QtGS30GNWPe27yptv//7fzpyeAiu2v/6kZb/9 fcjY9bxlTkauNcX0YS3t7hOPJQC5hF0Wd4EA5PrvPyEl3gH7qa+3LJBN4slhnW4zAPAW xDtyOOZ/iYYAuwvo7k+mQEtMdiWmuP1hrMNx+7yz0eqIIgxV2Py/k8m1KGkQmskrOIlB UXj29J+VFeNaBbybCF+Ckn0hHUNWjUXwsr31XYlU7Qb2zxx3H6+cJqMVMaVVCwcYwg7v rLcg== X-Gm-Message-State: AOAM532DDtpI1ixA6yQVKrT1asa0DyW326n0bqwV4qjt+tNlZJ+w7Vmh nDho/jaCeNdUt6/Oqzquzv142y8vppQ+pDjJO00j1RrpxRdCGA== X-Google-Smtp-Source: ABdhPJxdOpY3sINHKFlO+XIF822dqlmWBuFYenAzHUYlaDbNIoM08Qs/S1VjU2sv8n1nY03XEG8//H7gxu7KR8yDFjk= X-Received: by 2002:a17:902:bc83:b029:d6:ab18:1079 with SMTP id bb3-20020a170902bc83b02900d6ab181079mr332693plb.22.1605235829048; Thu, 12 Nov 2020 18:50:29 -0800 (PST) MIME-Version: 1.0 References: <00dc01d6b8f5$b07b57a0$117206e0$@chinatelecom.cn> In-Reply-To: <00dc01d6b8f5$b07b57a0$117206e0$@chinatelecom.cn> From: Gyan Mishra Date: Thu, 12 Nov 2020 21:50:18 -0500 Message-ID: To: zhuyq8@chinatelecom.cn Cc: James Guichard , spring@ietf.org, spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005f0ba805b3f417a8" Archived-At: Subject: Re: [spring] =?utf-8?b?5Zue5aSNOiBXRyBBZG9wdGlvbiBDYWxsIGZvciBkcmFm?= =?utf-8?q?t-li-spring-srv6-path-segment?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 02:50:34 -0000 --0000000000005f0ba805b3f417a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support WG adoption. This is an important draft for binding bidirectional paths for PCE and PM and possibly other cases. I noticed this draft which seems to be identical defining this new SRv6 path segment. https://tools.ietf.org/html/draft-li-6man-srv6-path-segment-encap-04 Thanks Gyan On Thu, Nov 12, 2020 at 8:14 AM wrote: > It=E2=80=99s useful for us to deploy SR Protection. Support. Thanks. > > B.R. > > Zhu Yongqing > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* spring *=E4=BB= =A3=E8=A1=A8 *James Guichard > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2020=E5=B9=B411=E6=9C=884=E6=97= =A5 1:39 > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* spring@ietf.org > *=E6=8A=84=E9=80=81:* spring-chairs@ietf.org > *=E4=B8=BB=E9=A2=98:* [spring] WG Adoption Call for draft-li-spring-srv6-= path-segment > > > > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, ending > November 24th 2020. Please note that this document has several changes > from v-06 that were requested by the SPRING chairs. For this reason, the > chairs have extended the adoption call for an additional week to allow th= e > WG enough time to review these changes before deciding on WG adoption. > > > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for th= at > support (or lack thereof) as silence will not be considered as consent. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000005f0ba805b3f417a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    I support WG adoption.

    This is an important draft for binding bidi= rectional paths for PCE and PM and possibly other cases.

    I noticed this draft which seems to be ide= ntical defining this new SRv6 path segment.

    Gyan
    --
    --0000000000005f0ba805b3f417a8-- From nobody Thu Nov 12 23:49:14 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C533A160B; Thu, 12 Nov 2020 23:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 whzSpCo8SG3R; Thu, 12 Nov 2020 23:49:09 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id EA68B3A14FC; Thu, 12 Nov 2020 23:49:03 -0800 (PST) HMM_SOURCE_IP: 172.18.0.218:21972.1890132224 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.77?logid-ee470a783ec245d484c06ba3cfbd3c39 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 5D2372800DC; Fri, 13 Nov 2020 15:48:51 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id ee470a783ec245d484c06ba3cfbd3c39 for james.n.guichard@futurewei.com; Fri Nov 13 15:48:54 2020 X-Transaction-ID: ee470a783ec245d484c06ba3cfbd3c39 X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: xiechf@chinatelecom.cn Date: Fri, 13 Nov 2020 15:48:49 +0800 From: "xiechf@chinatelecom.cn" To: "James Guichard" , List Cc: spring-chairs References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <2020111315484948987215@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart025452643450_=----" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 07:49:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart025452643450_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQpIZWxsbywNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCwgZm9yIHRo ZSBhcHByb2FjaCBkZWZpbmVkIGluIGl0IGlzIHZlcnkgdXNlZnVsIGZvciBTUnY2IG5ldHdvcmsg b3BlcmF0aW9uIGFuZCBzZXJ2aWNlIHByb3Zpc2lvbmluZywgaW4gYWRkaXRpb24gaXQgYWxzbyBo YXMgZ29vZCBkb2N1bWVudCBxdWFsaXR5Lg0KQmVzdCByZWdhcmRzDQpDaG9uZ2ZlbmcNCkZyb206 IEphbWVzIEd1aWNoYXJkDQpEYXRlOiAyMDIwLTExLTA0IDAxOjM5DQpUbzogc3ByaW5nQGlldGYu b3JnDQpDQzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogW3NwcmluZ10gV0cgQWRv cHRpb24gQ2FsbCBmb3IgZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50DQpEZWFyIFdH Og0KIA0KVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdt ZW50LTA3LCBlbmRpbmcgTm92ZW1iZXIgMjR0aCAyMDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg ZG9jdW1lbnQgaGFzIHNldmVyYWwgY2hhbmdlcyBmcm9tIHYtMDYgdGhhdCB3ZXJlIHJlcXVlc3Rl ZCBieSB0aGUgU1BSSU5HIGNoYWlycy4gRm9yIHRoaXMgcmVhc29uLCB0aGUgY2hhaXJzIGhhdmUg ZXh0ZW5kZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxv dyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lk aW5nIG9uIFdHIGFkb3B0aW9uLiANCiANCkFmdGVyIHJldmlldyBvZiB0aGUgZG9jdW1lbnQgcGxl YXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWls aW5nIGxpc3QuIFBsZWFzZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBz dXBwb3J0IChvciBsYWNrIHRoZXJlb2YpIGFzIHNpbGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJl ZCBhcyBjb25zZW50Lg0KIA0KVGhhbmtzIQ0KIA0KSmltLCBCcnVubyAmIEpvZWwNCiANCiANCiAN CiANCiANCg== ------=_001_NextPart025452643450_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0A

    =
    =0A
    Hello,
    I support the adoption of = this document, for the approach defined in it is very useful for SRv6 netw= ork operation and service provisioning, in addition it also has good docum= ent quality.
    Best= regards
    Chongfeng
    =0A ------=_001_NextPart025452643450_=------ From nobody Fri Nov 13 00:24:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C003A1633; Fri, 13 Nov 2020 00:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 i3ErOTcHSu0e; Fri, 13 Nov 2020 00:24:39 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id D353B3A1630; Fri, 13 Nov 2020 00:24:35 -0800 (PST) HMM_SOURCE_IP: 172.18.0.92:21583.361073821 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.78?logid-c17fd97f59e34d71a7a864d55f9c3710 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 74F7C2800DA; Fri, 13 Nov 2020 16:24:29 +0800 (CST) X-189-SAVE-TO-SEND: 71080549@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id c17fd97f59e34d71a7a864d55f9c3710 for james.n.guichard@futurewei.com; Fri Nov 13 16:24:32 2020 X-Transaction-ID: c17fd97f59e34d71a7a864d55f9c3710 X-filter-score: filter<0> X-Real-From: licong@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: licong@chinatelecom.cn Date: Fri, 13 Nov 2020 16:24:28 +0800 From: "licong@chinatelecom.cn" To: "James Guichard" , spring Cc: "spring-chairs@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <2020111316220476608511@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart773252251577_=----" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 08:24:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart773252251577_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQWxs77yMDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyB3b3JrLg0KDQpCZXN0 IFJlZ2FyZHMsDQpDb25nIExpDQoNCkZyb206IEphbWVzIEd1aWNoYXJkDQpEYXRlOiAyMDIwLTEx LTA0IDAxOjM5DQpUbzogc3ByaW5nQGlldGYub3JnDQpDQzogc3ByaW5nLWNoYWlyc0BpZXRmLm9y Zw0KU3ViamVjdDogW3NwcmluZ10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtbGktc3ByaW5n LXNydjYtcGF0aC1zZWdtZW50DQpEZWFyIFdHOg0KIA0KVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMg d2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbGktc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50LTA3LCBlbmRpbmcgTm92ZW1iZXIgMjR0aCAy MDIwLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIHNldmVyYWwgY2hhbmdlcyBm cm9tIHYtMDYgdGhhdCB3ZXJlIHJlcXVlc3RlZCBieSB0aGUgU1BSSU5HIGNoYWlycy4gRm9yIHRo aXMgcmVhc29uLCB0aGUgY2hhaXJzIGhhdmUgZXh0ZW5kZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9y IGFuIGFkZGl0aW9uYWwgd2VlayB0byBhbGxvdyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3 IHRoZXNlIGNoYW5nZXMgYmVmb3JlIGRlY2lkaW5nIG9uIFdHIGFkb3B0aW9uLiANCiANCkFmdGVy IHJldmlldyBvZiB0aGUgZG9jdW1lbnQgcGxlYXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkg Zm9yIFdHIGFkb3B0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuIFBsZWFzZSBhbHNvIHByb3ZpZGUg Y29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBwb3J0IChvciBsYWNrIHRoZXJlb2YpIGFzIHNp bGVuY2Ugd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyBjb25zZW50Lg0KIA0KVGhhbmtzIQ0KIA0K SmltLCBCcnVubyAmIEpvZWwNCiANCiANCiANCiANCiANCg== ------=_001_NextPart773252251577_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = =0A=0A
    Hi= All=EF=BC=8C

    I support the adoption of this work.<= /div>

    Best Regards,
    Cong Li
    =0A
    <= div>
    Date: 2= 020-11-04 01:39
    Subject: [spring] WG Adopti= on Call for draft-li-spring-srv6-path-segment
    =0A=0A=0A=0A
    =0A

    Dear WG:=

    =0A

     

    =0A

    This message starts a 3 week WG adoption c= all for=0Ahttps://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07, end= ing November 24th 2020. Please note that this document has seve= ral changes from v-06 that were requested=0A by the SPRING chairs. For thi= s reason, the chairs have extended the adoption call for an additional wee= k to allow the WG enough time to review these changes before deciding on W= G adoption.=0A

    =0A

    &nb= sp;

    =0A

    After revi= ew of the document please indicate support (or not) for WG adoption to the= mailing list.=0APlease also provide comments/reasons for that support (or lack the= reof) as silence will not be considered as consent.

    = =0A

     

    =0A

    <= span lang=3D"EN-CA" style=3D"mso-fareast-language:ZH-CN">Thanks!

    =0A

     

    =0A

    Jim, B= runo & Joel

    =0A

     

    =0A

    <= o:p> 

    =0A

     

    =0A=

     

    =0A

     

    =0A
    =0A
    =0A ------=_001_NextPart773252251577_=------ From nobody Fri Nov 13 00:44:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1573A1663 for ; Fri, 13 Nov 2020 00:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=HCPL5uWO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mxt/9tg2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cft5dT7yx95I for ; Fri, 13 Nov 2020 00:43:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126273A1645 for ; Fri, 13 Nov 2020 00:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=136628; q=dns/txt; s=iport; t=1605257039; x=1606466639; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wuuOKnzUsiXol8fDczwKEWtoSyIv2SfqktvpPl+owoo=; b=HCPL5uWOKt+qQMsGljbsxiaTO2C4JyfMJUPxAFPS4G9IglJRmPs+NWKw 87iGs6WFtLXpoJmJYDl7wxRySnkLJG9/PBcBZJPPwGzIWMJnLLRfZg8vd 9zKqBi5Nw16wEqYgsA/sAztgSoV8kp6s0hIzaW4BS7DbaMfrDf8PQyeUw Y=; X-IPAS-Result: =?us-ascii?q?A0A0BQC5Rq5ffZRdJa1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4EjLyMue1kvLgqEM4NJA41XihaObYFCgREDTwULAQEBDQEBGAEMCAIEAQGEB?= =?us-ascii?q?kQCF4IEAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBhg8BByUMhXIBAQEBA?= =?us-ascii?q?wEBEAgBCAoTAQEjCQsBCwQCAQgRAQIBAQEhAQYDAgICHwYLFAMGCAIEAQ0FC?= =?us-ascii?q?BqDBYF+VwMuAQ6kXwKBPIhodoEygwQBAQWBMwEDAg5BgwENC4IQCYE4gnOCZ?= =?us-ascii?q?k5CgQaBPoQTG4FBP4ERQ4JPPoIbQgEBAgEBFYEAEQESASMFBxINCQIGglkzg?= =?us-ascii?q?iyQHRIZK4J1hx6MDpASOFQKgm2JD4xzhTWDGYEqiGyBLZBpgjSTUoIAiH2Cb?= =?us-ascii?q?o4yhDYCBAIEBQIOAQEFgUEqIWlwcBUaIYI1AQEyCUcXAg2BNIZIhggbDBeDT?= =?us-ascii?q?oRZO4VEdAI2AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A2v2IHx/arGnLxP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN4/JujVaPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHe8MklcXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,475,1596499200"; d="scan'208,217";a="625201561" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Nov 2020 08:43:57 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AD8hvKj017051 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2020 08:43:57 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 02:43:56 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 02:43:56 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 13 Nov 2020 03:43:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gj0t7kRpnmwAn4xwHtMnbKc2uNzZRawDkVKN5QjWiSxYuKI32g2o3FpNyubwJPnF6sPPxBCuTlPqci1jwW7LocQ2hsjVPY1O8hIv1sYbmuDpPEq/LwcUOgS6Qpe/ZzWR3efpfASG5L7haIuiA8waH+qE/8X2U29zW9sUndpsWg5AXclxXlDZBmgaMOvbtvdDV3O8bMwLVi3g4iFrHW/2OioDT53uca06/bf1ibcFFwvtvi8hA79ZxnRNCDrr2JJn+o1mqukStGr9pg84ZzSr8BuT/avsI3+CnIHZR0GwVPEdHij0SBy6ZaZXCYXLGqZTZ4o6YC6mWTuWHegtT5+iCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wuuOKnzUsiXol8fDczwKEWtoSyIv2SfqktvpPl+owoo=; b=gZzKAQ+H1SCcApEvAD2SaB3SNkJltIGfOYTqpzKbtiuPXbqEB5Kh1Bl7DZebngvdSCji+gk34RkntrvZGTH6ZmARYt8YgYSNBRb0fPUvvi79qT58xGthajaRJXsBFLKPkYoDDC+OXFAPwNb8bwbxmcn56xmPoKiSi40okSl29STaTogK1TB0HHPJVNp5gsv1wzE80bVkIe3YWodorL4csKElK82W93A4qIpAWxAcTNWdESYqG44rs3icGF5QfciVukQ71of+Diz7f8D1+Nec9hBGGCvcx1U2H/t/d0WO2MeG1RSRPrxqpnvJ/xwPZXiV7/Go0zDk/c3BtpQTUYf0lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wuuOKnzUsiXol8fDczwKEWtoSyIv2SfqktvpPl+owoo=; b=mxt/9tg2C9lQwfq303kLhNUy1hzBpfTnSPNdSk4OS+d11ugz4Wxp75UvD2mHTpY0pvfa19cumilkLAnOGLdt1suOuI0nsTNYtxv8YatQVWZRlZ0Uh0lXxK6Q/C8Lg2bmNNUqcP82jVwhgo97tfJhDhaq0hzqXl3FePPm88t7MbA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB4930.namprd11.prod.outlook.com (2603:10b6:303:9b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Fri, 13 Nov 2020 08:43:54 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Fri, 13 Nov 2020 08:43:54 +0000 From: "Ketan Talaulikar (ketant)" To: "Stone, Andrew (Nokia - CA/Ottawa)" , Tarek Saad , Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAwoDICAAP2ogIAAmcsAgACMyMCAAU4HgIABUQqAgABARYCAAJ6g4A== Date: Fri, 13 Nov 2020 08:43:54 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efb296da-a6bd-452f-c952-08d887b040c0 x-ms-traffictypediagnostic: CO1PR11MB4930: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OYCebm/qf5j/EgwKVvkHR1cWJSnQ3KbzhlEeyfdeSFo6FO25qbJQ3LUKrYgTcjB/v2RCwgbyCAy+g6MDLNjeXIKty13uqLBj4jJOA7Mmqt98N6fjjxBUjglTPp7KzT/N1+0PL0dak6guqfqd/oxMLmu0871CXelWWUPCwx7cmmJsB8i5zf7XeiEd41fINqNLDSRYV8JLHg1M9bqt4ZREo8YSszmu+r1aT3Rui40VSSqxYq6WB+usOUkO5IqVI/y/bV6wKnbsy47k5NGQaz55jFby5ClaspkmNS7wVzvPD129XGS4jHrj7LS2zq1lgmMx966l/pAK8rEJxHqdWlQb+GyVmtW03ZzOuVYIcDpEWFoOWRYsnQoaDUXX1hbDdhBQY/iSrCmCX2d+1pBe6ng8sQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(366004)(136003)(39860400002)(5660300002)(26005)(52536014)(66476007)(166002)(71200400001)(66574015)(66556008)(2906002)(8676002)(110136005)(4326008)(316002)(8936002)(64756008)(33656002)(478600001)(966005)(66446008)(186003)(6506007)(9686003)(86362001)(66946007)(296002)(76116006)(55016002)(16350225007)(30864003)(53546011)(7696005)(83380400001)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FnOZUBREUNcmwVdxkLicd3IRFznCWQRkZ0Ar2Kjgkp5FN4di/6kchF4FnOP4TtUKyBnb+NsKoTdzWc72sMLzXQuFstL8Z4ynAk6FORVCsPGjHH5V50VbQOCzWg1AQXoxppGm8xUVfQEg4/MkUYZk4RLXeY4+JYH1n2ZZwjsBUyWDKvCZyPg5wpEfuQaetIyQ/jQLiRxx+QYYewtll9G9m6Oau1mXNd9rB1Q7z+0yiICf/VlDM3anIHjVnOP8Hlw6LQyulJpW0PH+agd6VtZ9nQjUrYE+KYcUfVAvPLsqSoFeHtL4FQ7LtEDe0nzAgZQLZAXVVHWF1wxU3hVeXzSbGewdXbbCvAf2D+KrPDaefYCtO8oz+mhlE1LMJ3OVEmwhu/AnMPrkZikwn3NbdR7kR5kGmK7O19LeW9thTblwYNoUTMhn80vwq76I+BQJWKpTLPNjdEZWcaf7x7lUOVs0QrWHq79/pIaEUCW9Nq8uZVgyhQB/VIMEBnyttiNDajCAJZiYgvswdes20lsZHtgnQawAR6EGfCmJb/StYPABSKewwHT0HLFlrD8m2zN7sypESNtn7whIQ3vNuNu/HQFA/ahPCZmijEJYJXHO8WF+XWvn3p5Q1ayV8593N23v7lRHDq0GIk9QHKnB70Es5+ZtfTBdgCZOjcDQ3tMRWo4p9UlES71A5M8cuTpjNG7NvRaTv6S+ofIkoA0qUwm4NhXjoC2VaYrI7Tn8+fbPHs5/M+HnKU5TK5Y+wZDBM8kdZATvoImAM1UiVI5LI8gYEAOakADFJ5sfzJiwcEkq9obdD6BaBssmoi5Vp1LUURszVfro58liQcs+jmluvX4VHf+ESwUVWDnbZDhQW2F58C53Rq61EXUY0Yz4/Ncv1m4oLH4mDhv7cOjk4FIuh41bddnSeg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570A2FB66F1BBDC7D2412EAC1E60MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: efb296da-a6bd-452f-c952-08d887b040c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 08:43:54.2887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pjlQZmci6LpLlZHL3wNRbOMSMcyANFuijbL7Sf4IW2byVStHL0f9hhwlX8EAsBWqR8CplEjDZ84dvZJ7TbMJWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4930 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 08:44:03 -0000 --_000_MW3PR11MB4570A2FB66F1BBDC7D2412EAC1E60MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3L1RhcmVrLA0KDQpUaGFua3MgYWdhaW4gZm9yIHRoaXMgZGlzY3Vzc2lvbiBhbmQg eW91ciBpbnB1dHMuDQoNCkkgY29uY3VyIHdpdGggQW5kcmV3IHRoYXQgY29sb3IgaXMgc29tZXRo aW5nIHRoYXQgaXMgbGVmdCB0byB0aGUgb3BlcmF0b3IgYXMgcGFydCBvZiB0aGVpciBuZXR3b3Jr IGRlc2lnbiBhbmQgbm90IHNvbWV0aGluZyB0byByZXNlcnZlIG9yIGRlZmluZSBhIHNwZWNpYWwg cmFuZ2UgZm9yLiBUaGlzIGlzIHdoYXQgd291bGQgZ2l2ZSB0aGUgb3BlcmF0b3IgdG8gY2hvb3Nl IHRoZSB2YXJpb3VzIHN0ZWVyaW5nIG1lY2hhbmlzbXMgYW5kIGhvdyBhbmQgd2hlcmUgdG8gdXNl IHRoZW0gaW4gdGhlaXIgbmV0d29ya3MuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IFN0b25l LCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSA8YW5kcmV3LnN0b25lQG5va2lhLmNvbT4NClNl bnQ6IDEzIE5vdmVtYmVyIDIwMjAgMDQ6NDINClRvOiBUYXJlayBTYWFkIDx0c2FhZC5uZXRAZ21h aWwuY29tPjsgS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbT47IFZp c2hudSBQYXZhbiBCZWVyYW0gPHZpc2hudXBhdmFuQGdtYWlsLmNvbT4NCkNjOiBzcHJpbmdAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQpIaSBUYXJlaywNCg0KVGhhbmtzIGZv ciB0aGUgY29tbWVudHMuIFNtYWxsIHJlcGx5IGJlbG93Lg0KDQpUaGFua3MNCkFuZHJldw0KDQpG cm9tOiBUYXJlayBTYWFkIDx0c2FhZC5uZXRAZ21haWwuY29tPG1haWx0bzp0c2FhZC5uZXRAZ21h aWwuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAyMCBhdCAyOjIyIFBNDQpU bzogIlN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSIgPGFuZHJldy5zdG9uZUBub2tp YS5jb208bWFpbHRvOmFuZHJldy5zdG9uZUBub2tpYS5jb20+PiwgIktldGFuIFRhbGF1bGlrYXIg KGtldGFudCkiIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmtldGFu dD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+LCBWaXNobnUgUGF2YW4gQmVlcmFtIDx2aXNo bnVwYXZhbkBnbWFpbC5jb208bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+DQpDYzogInNw cmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQpIaSBh bGwsDQoNClNlZSBpbmxpbmUgZm9yIHNvbWUgY29tbWVudHMuLg0KDQpGcm9tOiBzcHJpbmcgPHNw cmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiAiU3RvbmUsIEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpIiA8YW5kcmV3LnN0 b25lQG5va2lhLmNvbTxtYWlsdG86YW5kcmV3LnN0b25lQG5va2lhLmNvbT4+DQpEYXRlOiBXZWRu ZXNkYXksIE5vdmVtYmVyIDExLCAyMDIwIGF0IDY6MTYgUE0NClRvOiAiS2V0YW4gVGFsYXVsaWth ciAoa2V0YW50KSIgPGtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86a2V0 YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4sIFZpc2hudSBQYXZhbiBCZWVyYW0gPHZp c2hudXBhdmFuQGdtYWlsLmNvbTxtYWlsdG86dmlzaG51cGF2YW5AZ21haWwuY29tPj4NCkNjOiAi c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IiA8c3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0DQoNCkhp IEtldGFuLCBQYXZhbiwNCg0KR29vZCBkaXNjdXNzaW9uLiBKdXN0IGdvaW5nIHRvIGNoaXAgaW4g c29tZSB0aG91Z2h0c+KApg0KDQpPbmUgb2YgdGhlIGVsZW1lbnRzIEkgcGVyc29uYWxseSBsaWtl IG9mIHRoZSBTUiBQb2xpY3kgbW9kZWwgaXMgdGhhdCBtYW55IENhbmRpZGF0ZSBQYXRocyBtYXkg ZXhpc3QsIGJ1dCBvbmx5IG9uZSBtYXkgYmUgYWN0aXZlIGFuZCBhIGNhbmRpZGF0ZSBwYXRoIGNv bnRhaW5zIDEgb3IgbWFueSBTSUQgbGlzdHMuIEl04oCZcyBhIHNpbXBsZSBwYXJlbnQvY2hpbGQg LSByb290L2xlYWYgdHJlZSB3aXRoIHZlcnkgY2xlYXIgcnVsZXMgd2l0aGluIHRoZSBTUiBwb2xp Y3kgY29udGV4dCBpbnN0YW5jZS4gRnJvbSBteSBwb2ludCBvZiB2aWV3LCB3aGF0IGlzIGJlaW5n IHByb3Bvc2VkIGluIHRoZSAtMDkgZG9jdW1lbnQgc3RpbGwgZm9sbG93cyB0aG9zZSBydWxlcyBh bmQgdGhlIGdlbmVyYWwgdG9wLWRvd24gdHJlZSBiZWhhdmlvdXIuIERlc3BpdGUgdGhlIGNvbXBv c2l0ZSBDUCBwb2ludGluZyB0byBhIGRpZmZlcmVudCBTUiBQb2xpY3ksIHRoYXQgU1IgUG9saWN5 IHN0aWxsIGZvbGxvd3MgYWxsIG9mIHRoZSBzYW1lIHJ1bGVzIHRvcCBkb3duIGluIGl0cyBvd24g aXNvbGF0ZWQgY29udGV4dC4gQ29tcGFyZSB0aGF0IHRvIHNheSwgaGF2aW5nIGEgY2FuZGlkYXRl IHBhdGggY29udGFpbiBhIGNoaWxkIHRoYXQgcG9pbnRzIHRvIG90aGVyIGNhbmRpZGF0ZSBwYXRo cyB3aXRoaW4gdGhlIHNhbWUgU1IgUG9saWN5IGNvbnRleHQ6IHdpdGhpbiB0aGUgc2FtZSBjb250 ZXh0IGEgY2hpbGQgaXMgcG9pbnRpbmcgdG8gYSBzaWJsaW5nIG9mIGl0cyBwYXJlbnQuIFRoZSBy dWxlcyBub3cgaGF2ZSB0byBiZW5kIHNsaWdodGx5LiBBcyBub3RlZCBiZWxvdywgc29tZSBvZiB0 aGUgcnVsZXMgYXJvdW5kIHdoYXQgaXMgY29uc2lkZXJlZCBhbiBhY3RpdmUgY2FuZGlkYXRlIHBh dGggd291bGQgbmVlZCB0byBjaGFuZ2UsIHNpbmNlIHRoZSBjb25zdGl0dWVudHMgZXNzZW50aWFs bHkgYXJlIGFjdGl2ZSAodGhleeKAmXJlIGluc3RhbGxlZCkgZGVzcGl0ZSBub3QgYmVpbmcgdGhv dWdodCBvZiBhcyBiZWluZyBhY3RpdmUuIE5vdGUgdGhhdCB0aGUgcHJvcG9zZWQgbmV3IHRleHQg YmVsb3cgc2F5cyDigJxUaGUgcHJlZmVyZW5jZSBpcyBpZ25vcmVkIGZvciBlYWNoIG9mIHRoZSB0 d28gY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGhzIiB3aGljaCBpcyBhbHNvIGEgbmV3IHJ1bGUs IGhvd2V2ZXIgb25lIGNvdWxkIHBlcmhhcHMgd29yayBhcm91bmQgdGhhdCBieSBqdXN0IHJlcXVp cmluZyB0aGUgcHJlZmVyZW5jZSBvbiB0aGUgY29uc3RpdHVlbnRzIGJlIGxlc3MgcHJlZmVycmVk IHRoYW4gYW55IG90aGVyIHN0YW5kYXJkIG9yIGNvbXBvc2l0ZSBDUCDigJMgYnV0IHRoYXQgcmFp c2VzIGl0cyBvd24gdHJvdWJsZXMgd2l0aCBtdWx0aXBsZSBzb3VyY2VzIG9mIHByb3Zpc2lvbmlu ZyDigJMgd2hpY2ggbGVhZHMgdG8gYSBydWxlIGFza2luZyB0byBpZ25vcmUgdGhlIHByZWZlcmVu Y2UuIEluIHN1bW1hcnksIGZyb20gbXkgcC5vLnYgbmV3IHJ1bGVzIGluIHRoZSBoaWVyYXJjaHkg d291bGQgbmVlZCB0byBiZSBpbnRyb2R1Y2VkLg0KDQpSZWdhcmRpbmcgc3RlZXJpbmcgaW50byBh biBTUiBQb2xpY3ksIHllcywgeW91IGJ1cm4gY29sb3JzIGluIGRvaW5nIHRoaXMgKDMyYml0cy4u LikgYW5kIGl0IHdvdWxkIHJlcXVpcmUgZGVwbG95aW5nIGFuIGVudGlyZWx5IGRlZGljYXRlZCBT UiBQb2xpY3kgY29uc3RydWN0LCBhbmQgcnVuIHRoZSByaXNrIG9mIHN0ZWVyaW5nIOKAmG90aGVy 4oCZIHRyYWZmaWMgaW50byB0aGF0IHBvbGljeS4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHdvdWxk IHRoZSBjb21wb3NpdGUgU1IgUG9saWNpZXMgbm90IGJlIGVuZ2luZWVyZWQgaW4gYSB3YXkgd2hl cmUgdGhlIGNvbG9yIGJsb2NrIHVzZWQgaXMgZGVzaWduZWQgdG8gbm90IGJlIHVzZWQgZWxzZXdo ZXJlIGluIHRoZSBuZXR3b3JrIGZvciBvdGhlciBwdXJwb3Nlcz8NCltUU106IFRvZGF5IGNvbG9y cyBvZiBTUiBQb2xpY2llcyB0aGF0IGFyZSBpbnN0YW50aWF0ZWQg4oCcb24tZGVtYW5k4oCdIG9y IGluc3RhbnRpYXRlZCB2aWEgUENFUCBmcm9tIGEgUENFIGFyZSBkZXJpdmVkIGZyb20gdGhlIGlu dGVudC9zZXJ2aWNlLiBXaXRoIHRoZSBoaWVyYXJjaGljYWwgU1IgcG9saWNpZXMgcHJvcG9zYWws IGEgUENFIG1heSBuZWVkIHRvIGluc3RhbnRpYXRlIHRoZSBjb2xvcmVkIGNoaWxkIFNSIHBvbGlj aWVzIG9uLWRlbWFuZCB0b28sIGJ1dCBpdCBpcyBub3QgY2xlYXIgd2hlcmUgdGhlIGNvbG9ycyBv ZiB0aG9zZSBjaGlsZCBTUiBwb2xpY2llcyB3b3VsZCBiZSBkZXJpdmVkIGZyb20uIEFzIEFuZHJl dyBzdWdnZXN0cywgYSBibG9jayBvZiBjb2xvcnMgY291bGQgYmUgY2FydmVkIGZyb20gZXZlcnkg aGVhZGVuZOKAmXMgc3BhY2UgLS0gc3BlY2lmaWNhbGx5IGZvciB0aGlzIHB1cnBvc2UgYW5kIGJl IG1hbmFnZWQgYnkgdGhlIFBDRS4gQWx0ZXJuYXRpdmVseSwgb25lIGNvdWxkIGNvbnNpZGVyIGNy ZWF0aW5nIHN1Y2ggU1IgUG9saWNpZXMgd2l0aCBhIHNwZWNpYWwvcmVzZXJ2ZWQgY29sb3IgdGhh dCB3b3VsZCBzaW1wbGlmeSB0aGVpciBjcmVhdGlvbi4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSBTUiBQb2xpY2llcyBtYXkgYmUgaW5zdGFudGlh dGVkIChlLmcuIGZvciB0YWN0aWNhbCBURSDigJMgZS5nLiBvbiBQIG5vZGVzKSB0aGF0IHdvdWxk IG5vdCByZXF1aXJlIGNvbG9yIHJlc29sdXRpb24sIGFuZCBjcmVhdGlvbiBvZiB0aG9zZSBjb3Vs ZCBiZW5lZml0IGZyb20gYSByZXNlcnZlZCBjb2xvciB0b28uDQoNCg0KW0FuZHJld10gR29vZCBw b2ludCBpbmRlZWQuIFRoZSBQIG5vZGUgaXMgd2hhdCBJIHdhcyBwb2ludGluZyBhdCB3aXRoIHRo ZSBCU0lEIGV4YW1wbGUsIHdoZXJlLCBmb3IgZXhhbXBsZSwgd2XigJlsbCBoYXZlIHRvIGJ1cm4g YSBjb2xvciB0byBkZXBsb3kgYSBTUiBQb2xpY3kgb24gYSB0cmFuc2l0IG5vZGUgd2hlbiB0aGUg Y29uc3VtZXIgaW50ZW50IGlzIHNpbXBseSBmb3IgdGhlIEJTSUQuIFRoYXQgY29sb3Igc2VsZWN0 aW9uIHdvdWxkIG5lZWQgdG8gYmUgY29uc2lkZXJlZCDigJhzcGVjaWFs4oCZIGFuZCB0YWtlbiBm cm9tIGEgdW5pcXVlIGJsb2NrIGlmIG9uZSB3YW50cyB0byBhdm9pZCB1c2luZyBpdCBmb3IgaGVh ZC1lbmQgc3RlZXJpbmcgb24gdGhhdCBQIG5vZGUuICBOb3RpbmcgdGhhdCBjb2xvciBpcyBwYXJ0 IG9mIHdoYXQgdW5pcXVlbmVzcywgdG8gZGVmaW5lIHRoZSDigJxub3QgZm9yIHN0ZWVyaW5n4oCd IGJlaGF2aW91ciwgaXQgd291bGQgbmVlZCB0byBiZSBhIHJlc2VydmVkIGJsb2NrIG9yIGJpdCBl bmNvZGVkIGluIGNvbG9yIGFzIG9wcG9zZWQgdG8gYSBzaW5nbGUgc3BlY2lhbCB2YWx1ZS4gSeKA mW0gbm90IHN1cmUgYSBzcGVjaWFsIHJhbmdlIG5lZWRzIHRvIGJlIElFVEYgc3RhbmRhcmRpemVk IG9yIHNpbXBseSBsZWZ0IHRvIGltcGxlbWVudGF0aW9ucy9QQ0UgLyBuZXR3b3JrIGRlc2lnbiB0 byBhbGxvY2F0ZSBhbmQgZW5mb3JjZS4gSXQgc2VlbXMgdGhhdCB0aGUgbW9kZWwgdG8gc3RlZXIg YW4gU1IgUG9saWN5IGNhbmRpZGF0ZSBwYXRoIGludG8gYW5vdGhlciBTUiBQb2xpY3kgd2l0aCBl aXRoZXIgY29sb3Igb3IgdGhlIGNvbmNlcHQgb2YgYSBzcGVjaWFsIGNvbG9yIHN0aWxsIHNlZW1z IGZlYXNpYmxlIGluIHRoZSBwcmVzZW50IGRvY3VtZW50LiBJdCBtaWdodCBiZSB3b3J0aCBoYXZp bmcgdGV4dCBkZXNjcmliaW5nIHRoYXQgYSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBtYXkg YmUgdXNlZCBmb3Igc3RlZXJpbmcgb24gdGhlIGhlYWRlbmQsIGFuZCBpZiBpbnRlbnRpb24gaXMg dG8gYXZvaWQgdGhhdCB0aGVuIHRoZSB1c2VyL3BjZS9uZXR3b3JrIGRlc2lnbiBzaG91bGQgYWxs b2NhdGUgYSBibG9jayBvZiB2YWx1ZXMgZm9yIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRocyBh bmQgc2VsZWN0IG9ubHkgZnJvbSB0aGF0IGJsb2NrLCBub3QgdG8gYmUgdXNlZCBvbiBhbnkgb3Ro ZXIgcm91dGVzIGluIHRoZSBuZXR3b3JrLg0KDQoNClJlZ2FyZHMsDQpUYXJlaw0KDQoNCg0KSXMg dGhlcmUgbm90IGEgZGlmZmVyZW50IGJ1dCBraW5kIG9mIHNpbWlsYXIgcHJvYmxlbSB3aXRoIEJp bmRpbmcgU0lEcywgaW4gdGhhdCB0aGV54oCZcmUgZWxpZ2libGUgZm9yIHVzZSBieSBvdGhlciBj b25zdW1lcnMgZXZlbiBpZiBub3QgZGlyZWN0bHkgaW50ZW5kZWQ/IChhbHRob3VnaCBhdCBsZWFz dCBCU0lEcyBhcmUgb3B0aW9uYWwgYW5kIG5vdCBtYW5kYXRvcnkpLiBJbiBhZGRpdGlvbiB0byB0 aGUgc3BsaXQgVEUgY2FzZXMsIGJlaW5nIGFibGUgdG8gaGF2ZSBhbiBTUiBQb2xpY3kgc3RlZXIg aW50byBhbm90aGVyIFNSIFBvbGljeSBtaWdodCBhbHNvIGhhdmUgc29tZSB2YWx1ZSBpbiBhIGJh Y2t1cCBjYW5kaWRhdGUgc2NlbmFyaW8gd2hlbiBvbmUgaGFzIG11bHRpcGxlIFNSIFBvbGljaWVz IHdpdGggdGhlIHNhbWUgZW5kcG9pbnQsIGJ1dCBjYW4gc2hhcmUgYSBjb21tb24gZmFsbGJhY2sv YmVzdCBlZmZvcnQgY2FuZGlkYXRlIHBhdGguIFRoZSBlbnRpdHkgKEknbSB0aGlua2luZyBQQ0Up IG1hbmFnaW5nIHRoYXQgd291bGQgb25seSBuZWVkIHRvIG1haW50YWluIHRoZSBmYWxsYmFjay9i ZXN0IGVmZm9ydCBDUCBTSUQgbGlzdChzKSwgaW5zdGVhZCBvZiBvbmUgZm9yIGVhY2ggTiAqIENQ cy4NCg0KU29tZXRoaW5nIEkgaGF2ZW7igJl0IGNvbmNsdWRlZCB0byBteXNlbGYgeWV0IGFyZSBx dWVzdGlvbnMgc3VjaCBhczoNCg0KDQoxLiAgICAgIGRvZXMgaGF2aW5nIGEgY2FuZGlkYXRlIHBh dGggc3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBzYXRpc2Z5IHRoZSBhYmlsaXR5IHRvIGRv IHZhcmlvdXMgc3ViLXBhdGggc3BlY2lmaWMgVEUvY29uc3RyYWludC9vYmplY3QgY29tYmluYXRp b25zIHN1ZmZpY2llbnRseT8NCg0KMi4gICAgICBpcyB0aGUgbW9kZWwgcmVsYXRpdmVseSBzdHJh aWdodCBmb3J3YXJkIHRvIG1hcCBpbnRvIHlhbmcvYmdwL3BjZXAgZXRjLi4/DQoNCjMuICAgICAg ZG9lcyB1c2luZyBhbiBhZGRpdGlvbmFsIFNSIFBvbGljeSBjcmVhdGUgdG9vIG11Y2ggb3Zlcmhl YWQgb3Igc3RhdGUgYnVybiB0byBjb25maWd1cmUsIGRlcGxveSwgbWFuYWdlLCB0cmFjayBldGMu LiA/DQoNCkNoZWVycw0KQW5kcmV3DQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpIiA8a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzprZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlc2Rh eSwgTm92ZW1iZXIgMTAsIDIwMjAgYXQgMTA6MzMgUE0NClRvOiBWaXNobnUgUGF2YW4gQmVlcmFt IDx2aXNobnVwYXZhbkBnbWFpbC5jb208bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+DQpD YzogInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRm Lm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0K DQpIaSBQYXZhbiwNCg0KUGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdy4NCg0KRnJvbTogVmlzaG51 IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2YW5AZ21haWwuY29tPG1haWx0bzp2aXNobnVwYXZhbkBn bWFpbC5jb20+Pg0KU2VudDogMTEgTm92ZW1iZXIgMjAyMCAwMDoyNg0KVG86IEtldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFudEBjaXNjby5jb20+ Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ktMDkudHh0DQoNCktldGFuLCBIaSENCg0KUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHJl c3BvbnNlcyAocHJlZml4ZWQgVlBCKS4NCg0KUmVnYXJkcywNCi1QYXZhbg0KDQpPbiBUdWUsIE5v diAxMCwgMjAyMCBhdCA0OjA0IEFNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBj aXNjby5jb208bWFpbHRvOmtldGFudEBjaXNjby5jb20+PiB3cm90ZToNCkhpIFBhdmFuLA0KDQpQ bGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBWaXNobnUgUGF2YW4gQmVlcmFtIDx2 aXNobnVwYXZhbkBnbWFpbC5jb208bWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbT4+DQpTZW50 OiAxMCBOb3ZlbWJlciAyMDIwIDAwOjA4DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+DQpDYzogc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQN Cg0KS2V0YW4sDQoNCk11Y2ggVGhhbmtzIGZvciB0YWtpbmcgYSBzdGFiIGF0IGFkZHJlc3Npbmcg dGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCB1c2UtY2FzZSEgV2Ugc2VlbSB0byBiZSBjb252 ZXJnaW5nLg0KW0tUXSBUaGFua3MgZm9yIHRoYXQgZmVlZGJhY2sgYW5kIGNvbmZpcm1hdGlvbiB0 aGF0IHRoZSBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgZG9lcyBhZGRyZXNzIHRoZSB1c2UtY2FzZS4g SSBiZWxpZXZlIHdlIGFyZSBub3cgZGlzY3Vzc2luZyB0aGUgbWVjaGFuaWNzIG9mIGhvdyB0aGlz IGlzIGFjaGlldmVkIHdpdGhpbiB0aGUgY3VycmVudCBTUiBQb2xpY3kgZnJhbWV3b3JrLg0KDQpI b3dldmVyLCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgeW91IG5lZWQgdG8gdXNlIGFkZGl0aW9u YWwgU1IgcG9saWNpZXMgKGFuZCB1bm5lY2Vzc2FyaWx5IGJ1cm4gYWRkaXRpb25hbCBjb2xvcnMp IHRvIGFkZHJlc3MgdGhpcy4NCltLVF0gSSBkbyBub3QgZm9sbG93IHdoYXQgeW91IG1lYW4gYnkg 4oCcYnVybiBhZGRpdGlvbmFsIGNvbG9yc+KAnS4gQ29sb3IgaXMganVzdCBhIDMyIGJpdCBudW1i ZXIgdGhhdCBpbmRpY2F0ZXMgdGhlIOKAnGludGVudOKAnSBhbmQgaXMgbm90IHJlYWxseSBhIHNj YXJjZSByZXNvdXJjZS4gQXNzaWduaW5nIGEgY29sb3IgdG8g4oCcYSBjb21wb3NpdGUgaW50ZW50 4oCdIHNlZW1zIGxpa2UgYSBzZWFtbGVzcyB3YXkgdG8gaW50ZWdyYXRlIHdpdGggZXhpc3Rpbmcg bWVjaGFuaXNtcyBmb3IgU3RlZXJpbmcgb3ZlciBTUiBQb2xpY2llcy4gVGhpcyBnaXZlcyB0aGUg ZmxleGliaWxpdHkgZm9yIHNheSBzb21lIEJHUCBzZXJ2aWNlcyB0byBiZSBzdGVlcmVkIG92ZXIg dGhlIGNvbnN0aXR1ZW50IGV4cGxpY2l0L2R5bmFtaWMgaW50ZW50IHdoaWxlIG90aGVycyBjYW4g c3RlZXIgb3ZlciBhIGNvbXBvc2l0ZSBpbnRlbnQgdGhhdCBpbmNsdWRlcyB0aG9zZSBpbmRpdmlk dWFsIGV4cGxpY2l0L2R5bmFtaWMgaW50ZW50cy4NCg0KW1ZQQl0gVGhlIOKAnGZsZXhpYmlsaXR5 4oCdIHRoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gaXMgdW5kZXNpcmFibGUgZm9yIHRoaXMgdXNl LWNhc2UuIEZvciB0aGUgdHJhZmZpYy1zcGxpdCB1c2UtY2FzZSwgd2UgZG9u4oCZdCB3YW50IGFu eSBvdGhlciBzZXJ2aWNlcyB0byBiZSBkaXJlY3RseSBzdGVlcmVkIG92ZXIgdGhlIGNvbnN0aXR1 ZW50cyB3aGVuIHRoZXkgYXJlIHBhcnQgb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGguDQpb S1RdIEkgYmVsaWV2ZSB0aGUgdXNlLWNhc2UgdGhhdCB5b3UgYXJlIHJlZmVycmluZyB0byB3YXMg Zm9yIHNwbGl0dGluZyBzb21lIHRyYWZmaWMgZm9yIGEgc2VydmljZSBvdmVyIGEgYmx1ZSBwbGFu ZSBhbmQgdGhlIHJlc3Qgb3ZlciBhIHJlZCBwbGFuZS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUg bWF5IGJlIG90aGVyIHNlcnZpY2VzIHRoYXQgdXRpbGl6ZSBvbmx5IGEgc2luZ2xlIHBsYW5lLiBU aGUgZmxleGliaWxpdHkgdGhhdCBJIHdhcyByZWZlcnJpbmcgdG8gd2FzIHRvIGVuYWJsZS9hbGxv dyBmb3IgZWl0aGVyIG9mIHRoZSB0d28gc2NlbmFyaW9zIGFuZCB0aGVyZSBtYXkgYmUgb3RoZXIv bW9yZSB1c2UtY2FzZXMgZm9yIHdoaWNoIHdlIG5lZWQgYSBtb3JlIGdlbmVyaWMgZnJhbWV3b3Jr Lg0KDQpUaGUgY3VycmVudCBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgd291bGQgaGF2ZSBiZWVuIGFj Y2VwdGFibGUgaWYgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIHdlcmUgdW5jb2xvcmVkIOKA kyBidXQgdGhhdCB3b3VsZCB2aW9sYXRlIHRoZSBjdXJyZW50IHJ1bGVzIGltcG9zZWQgYnkgdGhl IGRyYWZ0Lg0KDQoNCldoeSBjYW7igJl0IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgganVz dCBiZSBhIGdyb3VwaW5nIG9mIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1p YyBjYW5kaWRhdGUgcGF0aHM/DQpbS1RdIFRoaXMgaXMgYmVjYXVzZSBpbiB0aGUgU1IgUG9saWN5 IGZyYW1ld29yaywgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBhY3RpdmUgQ1Ag4oCTIGl0IG1heSBi ZSBleHBsaWNpdCBvciBkeW5hbWljLiBOb3cgd2XigJl2ZSBhZGRlZCBhbm90aGVyIENvbXBvc2l0 ZSBDUCB0eXBlIHRvIGNvdmVyIHRoaXMgc3BlY2lmaWMgdXNlLWNhc2UuIFlvdXIgcHJvcG9zYWwg d2lsbCByZXN1bHQgaW4gMyBjYW5kaWRhdGUgcGF0aHMgYmVpbmcgYWN0aXZlIHdpdGhpbiB0aGUg c2FtZSBTUiBQb2xpY3kg4oCTIG9uZSBlYWNoIG9mIHRoZSBleHBsaWNpdCBhbmQgZHluYW1pYyBD UCBhbmQgdGhlbiBhZGRpdGlvbmFsbHkgdGhlIENvbXBvc2l0ZSBDUC4gVGhpcyBicmVha3MgdGhl IGV4aXN0aW5nIHJ1bGVzIGZvciBzZWxlY3Rpb24gb2YgQ1AgYmFzZWQgb24gcHJlZmVyZW5jZSBh bmQgbWVjaGFuaXNtcyBsaWtlIGZhbGxiYWNrIGJldHdlZW4gQ1BzLiBXaGlsZSB0aGUgY3VycmVu dCBwcm9wb3NhbCBpbiB0aGUgZHJhZnQgcHJvdmlkZXMgYSB3YXkgdG8gYWRkcmVzcyB0aGUgbmV3 IHVzZS1jYXNlIHdpdGggYSBiYWNrd2FyZHMgY29tcGF0aWJsZSBleHRlbnNpb24gdG8gdGhlIFNS IFBvbGljeSBmcmFtZXdvcmsuDQoNCltWUEJdIFRoZSBwcm9wb3NhbCBpbiBteSBwcmV2aW91cyBl bWFpbCBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZSBhbmQgZG9lcyBub3QgaW50ZW5kIHRvIGJyZWFr IGFueSBleGlzdGluZyBydWxlcyBmb3IgZGVlbWluZyBhIGNhbmRpZGF0ZSBwYXRoIGFjdGl2ZS4g QXMgcGVyIHRoZSBydWxlcyB0aGF0IGFyZSBvdXRsaW5lZCBpbiBTZWN0aW9uIDIuOSwgb25seSB0 aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIOKAnGFjdGl2ZeKAnSBnaXZlbiBpdHMgcHJl ZmVyZW5jZS4gVGhlIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRocyB3aWxsIG5ldmVyIGJlIGFj dGl2ZSBvbiB0aGVpciBvd24uIElmIGl0IGlzIG5lY2Vzc2FyeSwgd2UgY2FuIGFkZCBhIHN0YXRl bWVudCBpbiBTZWN0aW9uIDIuOSB0byBleHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNhbmRpZGF0 ZSBwYXRoIHNlbGVjdGlvbiBjcml0ZXJpYSBkb2VzIG5vdCBhcHBseSB0byB0aGUgY29uc3RpdHVl bnQgY2FuZGlkYXRlIHBhdGhzLg0KW0tUXSBXaGVuIGEgQ1AgaXMg4oCcYWN0aXZl4oCdIGl0IGlz IGFjdHVhbGx5IHRoZSBvbmUgdGhhdCBpcyBiZWluZyB1c2VkIGZvciBmb3J3YXJkaW5nLg0KDQpU aGFua3MsDQpLZXRhbg0KDQoNClRoYW5rcywNCktldGFuDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dp bmcgY2hhbmdlczoNCg0KKiogU2VjdGlvbiAyLjINCk9MRDoNCg0KICAgQSBjb21wb3NpdGUgY2Fu ZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3JvdXBpbmcgb2YgU1INCg0KICAg UG9saWNpZXMuICBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVjdCBlbmFibGVz IGNvbWJpbmF0aW9uDQoNCiAgIG9mIFNSIFBvbGljaWVzLCBlYWNoIHdpdGggZXhwbGljaXQgY2Fu ZGlkYXRlIHBhdGhzIGFuZC9vciBkeW5hbWljDQoNCiAgIGNhbmRpZGF0ZSBwYXRocyB3aXRoIHBv dGVudGlhbGx5IGRpZmZlcmVudCBvcHRpbWl6YXRpb24gb2JqZWN0aXZlcw0KDQogICBhbmQgY29u c3RyYWludHMsIGZvciBhIGxvYWQtYmFsYW5jZWQgc3RlZXJpbmcgb2YgcGFja2V0IGZsb3dzIG92 ZXINCg0KICAgaXRzIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzLiAgVGhlIGZvbGxvd2luZyBjcml0 ZXJpYSBhcHBseSBmb3INCg0KICAgaW5jbHVzaW9uIG9mIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVz IHVzaW5nIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoDQoNCiAgIHVuZGVyIGEgcGFyZW50IFNS IFBvbGljeToNCg0KDQoNCiAgIG8gIHRoZSBlbmRwb2ludHMgb2YgdGhlIGNvbnN0aXR1ZW50IFNS IFBvbGljaWVzIGFuZCB0aGUgcGFyZW50IFNSDQoNCiAgICAgIFBvbGljeSBNVVNUIGJlIGlkZW50 aWNhbA0KDQoNCg0KICAgbyAgVGhlIGNvbG9ycyBvZiBlYWNoIG9mIHRoZSBjb25zdGl0dWVudCBT UiBQb2xpY2llcyBhbmQgdGhlIHBhcmVudA0KDQogICAgICBTUiBQb2xpY3kgTVVTVCBiZSBkaWZm ZXJlbnQNCg0KDQoNCiAgIG8gIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBNVVNUIE5PVCB1 c2UgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRocw0KDQoNCg0KICAgRWFjaCBjb25zdGl0dWVudCBT UiBQb2xpY3kgb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggaXMNCg0KICAgYXNzb2NpYXRl ZCB3aXRoIGEgd2VpZ2h0IGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3NlcyAocmVmZXINCg0KICAg U2VjdGlvbiAyLjExPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rpb24tMi4xMT4gZm9yIGRldGFpbHMpLiAg VGhlIGRlZmF1bHQgd2VpZ2h0IGlzIDEuDQoNCg0KDQpORVc6DQoNCiAgIEEgY29tcG9zaXRlIGNh bmRpZGF0ZSBwYXRoIGFjdHMgYXMgYSBjb250YWluZXIgZm9yIGdyb3VwaW5nIG9mDQoNCiAgIGV4 cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1pYyBjYW5kaWRhdGUgcGF0aHMgd2l0 aA0KDQogICBwb3RlbnRpYWxseSBkaWZmZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXMgYW5k IGNvbnN0cmFpbnRzLg0KDQogICBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0cnVj dCBlbmFibGVzIGxvYWQtYmFsYW5jZWQNCg0KICAgc3RlZXJpbmcgb2YgcGFja2V0LWZsb3dzIG92 ZXIgYSBzZXQgb2YgY29uc3RpdHVlbnQgY2FuZGlkYXRlDQoNCiAgIHBhdGhzLiBUaGUgZm9sbG93 aW5nIGNyaXRlcmlhIGFwcGx5IGZvciBjb25zdGl0dWVudCBjYW5kaWRhdGUNCg0KICAgcGF0aHMg dW5kZXIgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGg6DQoNCg0KDQogICBvICB0aGUgcHJlZmVy ZW5jZSBvZiB0aGUgY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGggTVVTVCBiZQ0KDQogICAgICBp Z25vcmVkLg0KDQoNCg0KICAgbyAgdGhlIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIE1VU1Qg Tk9UIGJlIGEgY29tcG9zaXRlIGNhbmRpZGF0ZQ0KDQogICAgICBwYXRoDQoNCg0KDQogICBFYWNo IGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRo IGlzDQoNCiAgIGFzc29jaWF0ZWQgd2l0aCBhIHdlaWdodCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVy cG9zZXMgKHJlZmVyDQoNCiAgIFNlY3Rpb24gMi4xMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIu MTE+IGZvciBkZXRhaWxzKS4gIFRoZSBkZWZhdWx0IHdlaWdodCBpcyAxLg0KDQoNCg0KKioNCg0K DQoNCioqIFNlY3Rpb24gMi4xMQ0KDQoNCg0KT0xEOg0KICAgV2hlbiBhIGNvbXBvc2l0ZSBjYW5k aWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93cw0KICAgc3RlZXJlZCBp bnRvIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIGVxdWFsIHRvIHRoZSByZWxhdGl2ZQ0K ICAgd2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5LiAgRnVydGhlciBsb2FkIGJh bGFuY2luZyBvZg0KICAgZmxvd3Mgc3RlZXJlZCBpbnRvIGEgY29uc3RpdHVlbnQgU1IgUG9saWN5 IGlzIHBlcmZvcm1lZCBiYXNlZCBvbiB0aGUNCiAgIHdlaWdodHMgb2YgdGhlIFNlZ21lbnQtTGlz dCBvZiB0aGUgYWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9mIHRoYXQNCiAgIGNvbnN0aXR1ZW50IFNS IFBvbGljeS4NCg0KDQoNCk5FVzoNCiAgIFdoZW4gYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgg aXMgYWN0aXZlLCB0aGUgZnJhY3Rpb24gb2YgZmxvd3MNCiAgIHN0ZWVyZWQgaW50byBlYWNoIGNv bnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIGlzIGVxdWFsIHRvIHRoZSByZWxhdGl2ZQ0KICAgd2Vp Z2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGguICBGdXJ0aGVyIGxvYWQgYmFs YW5jaW5nIG9mDQogICBmbG93cyBzdGVlcmVkIGludG8gYSBjb25zdGl0dWVudCBjYW5kaWRhdGUg cGF0aCBpcyBwZXJmb3JtZWQgYmFzZWQgb24NCiAgIHRoZSB3ZWlnaHRzIG9mIGVhY2ggYXNzb2Np YXRlZCBTZWdtZW50LUxpc3QuDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rpb24gMi4xMw0KDQoNCg0K T0xEOg0KICAgVGhlIGluZm9ybWF0aW9uIG1vZGVsIG9mIFNSIFBvbGljeSBQT0wxMDAgaGF2aW5n IGEgY29tcG9zaXRlDQogICBjYW5kaWRhdGUgcGF0aCBpcyB0aGUgZm9sbG93aW5nOg0KDQogICBT UiBwb2xpY3kgUE9MMTAwIDxoZWFkZW5kID0gSDEsIGNvbG9yID0gMTAwLCBlbmRwb2ludCA9IEUx Pg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDEgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmln aW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMT4NCiAgICAgICAgICAg IFByZWZlcmVuY2UgMjAwDQogICAgICAgICAgICBXZWlnaHQgVzEsIFNSIHBvbGljeSA8Y29sb3Ig PSAxPg0KICAgICAgICAgICAgV2VpZ2h0IFcyLCBTUiBwb2xpY3kgPGNvbG9yID0gMj4NCg0KICAg VGhlIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIFBPTDEgYW5kIFBPTDIgaGF2ZSBpbmZvcm1hdGlv biBtb2RlbCBhcw0KICAgZGVzY3JpYmVkIGF0IHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uICBU aGV5IGFyZSByZWZlcmVuY2VkIG9ubHkgYnkNCiAgIGNvbG9yIGluIHRoZSBjb21wb3NpdGUgY2Fu ZGlkYXRlIHBhdGggc2luY2UgdGhlaXIgaGVhZGVuZCBhbmQNCiAgIGVuZHBvaW50IGFyZSBpZGVu dGljYWwgdG8gdGhlIFBPTDEwMC4gIFRoZSB2YWxpZCBTZWdtZW50LUxpc3RzIG9mIHRoZQ0KICAg YWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9mIFBPTDEgYW5kIFBPTDIgYXJlIGluc3RhbGxlZCBpbiB0 aGUNCiAgIGZvcndhcmRpbmcuICBUcmFmZmljIHN0ZWVyZWQgb24gUE9MMTAwIGlzIGZsb3ctYmFz ZWQgaGFzaGVkIG9uIFBPTDENCiAgIHdpdGggYSByYXRpbyBXMS8oVzErVzIpLiAgV2l0aGluIHRo ZSBQT0wxLCB0aGUgZmxvdy1iYXNlZCBoYXNoaW5nDQogICBvdmVyIGl0cyBTZWdtZW50LUxpc3Rz IGFyZSBwZXJmb3JtZWQgYXMgZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhpcw0KICAgc2VjdGlvbi4N Cg0KDQoNCk5FVzoNCiAgIFRoZSBpbmZvcm1hdGlvbiBtb2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAw IGhhdmluZyBhIGNvbXBvc2l0ZQ0KICAgY2FuZGlkYXRlIHBhdGggaXMgdGhlIGZvbGxvd2luZzoN Cg0KICAgU1IgcG9saWN5IFBPTDEwMCA8aGVhZGVuZCA9IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9p bnQgPSBFMT4NCiAgICAgICAgQ2FuZGlkYXRlLXBhdGggQ29tcC1DUCA8cHJvdG9jb2wtb3JpZ2lu ID0gMjAsIG9yaWdpbmF0b3IgPQ0KICAgMTAwOjEuMS4xLjEsIGRpc2NyaW1pbmF0b3IgPSAxPg0K ICAgICAgICAgICAgUHJlZmVyZW5jZSAyMDANCiAgICAgICAgICAgIFdlaWdodCBXMSwgQ2FuZGlk YXRlLXBhdGggQ1AxDQogICAgICAgICAgICBXZWlnaHQgVzIsIENhbmRpZGF0ZS1wYXRoIENQMg0K ICAgICAgICBDYW5kaWRhdGUtcGF0aCBDUDEgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5h dG9yID0NCiAgIDEwMDoxLjEuMS4xLCBkaXNjcmltaW5hdG9yID0gMj4NCiAgICAgICAgICAgICBX ZWlnaHQgVzExLCBTSUQtTGlzdDEgPFNJRDExLi4uU0lEMWk+DQogICAgICAgICAgICAgV2VpZ2h0 IFcxMiwgU0lELUxpc3QyIDxTSUQyMS4uLlNJRDJqPg0KICAgICAgICBDYW5kaWRhdGUtcGF0aCBD UDIgPHByb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID0NCiAgIDEwMDoxLjEuMS4xLCBk aXNjcmltaW5hdG9yID0gMz4NCiAgICAgICAgICAgICBXZWlnaHQgVzIxLCBTSUQtTGlzdDMgPFNJ RDMxLi4uU0lEM2k+DQogICAgICAgICAgICAgV2VpZ2h0IFcyMiwgU0lELUxpc3Q0IDxTSUQ0MS4u LlNJRDRqPg0KDQogICBDb21wLUNQIGlzIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHdpdGgg dHdvIGNvbnN0aXR1ZW50cywgQ1AxDQogICBhbmQgQ1AyLiBUaGUgcHJlZmVyZW5jZSBpcyBpZ25v cmVkIGZvciBlYWNoIG9mIHRoZSB0d28gY29uc3RpdHVlbnQNCiAgIGNhbmRpZGF0ZSBwYXRocy4g VGhlIHZhbGlkIFNlZ21lbnQtTGlzdHMgb2YgdGhlIHR3byBjb25zdGl0dWVudA0KICAgY2FuZGlk YXRlIHBhdGhzIGFyZSBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcuIFRyYWZmaWMgc3RlZXJl ZA0KICAgb24gQ29tcC1DUCBpcyBmbG93LWJhc2VkIGhhc2hlZCBvbiB0byBDUDEgYW5kIENQMiB3 aXRoIGEgcmF0aW8gb2YNCiAgIFcxLyhXMStXMikgYW5kIFcyLyhXMStXMikgcmVzcGVjdGl2ZWx5 LiBXaXRoaW4gZWFjaCBjb25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBhdGgsIHRoZSBmbG93LWJh c2VkIGhhc2hpbmcgb3ZlciBpdHMgU2VnbWVudC1MaXN0cyBhcmUNCiAgIHBlcmZvcm1lZCBhcyBk ZXNjcmliZWQgZWFybGllciBpbiB0aGlzIHNlY3Rpb24uDQoNCg0KKioNCg0KDQoNCioqIFNlY3Rp b24gNS4zDQoNCg0KDQpPTEQ6DQogICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBzcGVj aWZpZWQgYXMgYSBncm91cCBvZiBpdHMgY29uc3RpdHVlbnQNCiAgIFNSIFBvbGljaWVzLg0KDQog ICBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyB2YWxpZCB3aGVuIGl0IGhhcyBhdCBsZWFz dCBvbmUgdmFsaWQNCiAgIGNvbnN0aXR1ZW50IFNSIFBvbGljeS4NCg0KDQoNCk5FVzoNCiAgIEEg Y29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHNwZWNpZmllZCBhcyBhIGdyb3VwIG9mIGl0cyBj b25zdGl0dWVudA0KICAgY2FuZGlkYXRlIHBhdGhzLg0KDQogICBBIGNvbXBvc2l0ZSBjYW5kaWRh dGUgcGF0aCBpcyB2YWxpZCB3aGVuIGl0IGhhcyBhdCBsZWFzdCBvbmUgdmFsaWQNCiAgIGNvbnN0 aXR1ZW50IGNhbmRpZGF0ZSBwYXRoLg0KDQoNCioqDQoNCg0KDQpSZWdhcmRzLA0KDQotUGF2YW4N Cg0KDQoNCk9uIFN1biwgTm92IDEsIDIwMjAgYXQgNzowMiBQTSBLZXRhbiBUYWxhdWxpa2FyIChr ZXRhbnQpIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIZWxsbyBBbGwsDQoNCldlIGhhdmUganVzdCBw b3N0ZWQgYW4gdXBkYXRlIGZvciB0aGUgZHJhZnQgYW5kIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFy eSBvZiBjaGFuZ2VzOg0KDQoxKSBJbnRyb2R1Y3Rpb24gb2YgdGhlIENvbXBvc2l0ZSBDYW5kaWRh dGUgUGF0aCBjb25zdHJ1Y3QgdG8gYWRkcmVzcyBhIHBlbmRpbmcgY29tbWVudCBmcm9tIHRoZSBX RyAoUmVmIDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZkVx RTVUT3dkaDJ2RXlGbV9NRWppWHlQMndzLyBhbmQgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9zcHJpbmcvZDlvU1NiZ3AwakNFeFJ4MFNYeUJZMEN5cVhVLykNCjIpIEJhc2Vk IG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQsIHVwZGF0ZWQgU1J2NiBzZWdtZW50IHR5cGVz IHRvIGluY2x1ZGUgb3B0aW9uYWwgU1J2NiBTSUQgYW5kIGJlaGF2aW9yIGluc3RlYWQgb2YgdGhl IG5ldyB0eXBlIHRoYXQgd2FzIGludHJvZHVjZWQgZm9yIGl0IGluIHRoZSB2MDguDQozKSBDbGFy aWZpY2F0aW9uIG9mIGhhbmRsaW5nIG9mIGNvbG9ycyBhbmQgQkdQIG11bHRpLXBhdGggc2NlbmFy aW9zIGJhc2VkIG9uIG9mZmxpbmUgZmVlZGJhY2sgcmVjZWl2ZWQuDQo0KSBDbGFyaWZpY2F0aW9u IG9uIGNvbnNpZGVyYXRpb25zIGZvciBUSS1MRkEgZm9yIFNSIFBvbGljeSBhcyBkaXNjdXNzZWQg aW4gdGhlIFdHIChSZWYgOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nw cmluZy9FVjF5dFVzZDVaZ2tNSEROMEl2Rmh3OWlkNDAvKQ0KDQpQbGVhc2UgbGV0IGtub3cgeW91 ciBjb21tZW50cy9mZWVkYmFjay4NCg0KVGhhbmtzLA0KS2V0YW4gKG9uIGJlaGFsZiBvZiBjby1h dXRob3JzKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQpTZW50OiAwMiBOb3ZlbWJlciAyMDIwIDA2OjI3DQpUbzogaS1kLWFubm91bmNl QGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYzogc3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dA0KDQoNCkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNv dXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIFdHIG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IFNlZ21lbnQgUm91dGluZyBQb2xpY3kgQXJjaGl0ZWN0dXJl DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENsYXJlbmNlIEZpbHNmaWxzDQogICAgICAgICAg ICAgICAgICAgICAgICAgIEtldGFuIFRhbGF1bGlrYXINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgRGFuaWVsIFZveWVyDQogICAgICAgICAgICAgICAgICAgICAgICAgIEFsZXggQm9nZGFub3YN CiAgICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBNYXR0ZXMNCiAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQN CiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMzcNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDog MjAyMC0xMS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBh IGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93DQogICBhbG9uZyBhbnkgcGF0aC4g IEludGVybWVkaWF0ZSBwZXItZmxvdyBzdGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtzDQogICB0 byBzb3VyY2Ugcm91dGluZy4gIFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBpbnRvIGFu IFNSIFBvbGljeS4NCiAgIFRoZSBoZWFkZXIgb2YgYSBwYWNrZXQgc3RlZXJlZCBpbiBhbiBTUiBQ b2xpY3kgaXMgYXVnbWVudGVkIHdpdGggYW4NCiAgIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBh c3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQb2xpY3kuICBUaGlzDQogICBkb2N1bWVudCBkZXRhaWxz IHRoZSBjb25jZXB0cyBvZiBTUiBQb2xpY3kgYW5kIHN0ZWVyaW5nIGludG8gYW4gU1INCiAgIFBv bGljeS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3kvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDkNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDkNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1h aWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K --_000_MW3PR11MB4570A2FB66F1BBDC7D2412EAC1E60MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h cmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFp bC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA2MjA1MTIwNTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTYxNjE3MjU3NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tSU4iIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5kcmV3L1Rh cmVrLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGFua3MgYWdhaW4gZm9yIHRoaXMgZGlzY3Vzc2lvbiBhbmQgeW91ciBpbnB1 dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkkgY29uY3VyIHdpdGggQW5kcmV3IHRoYXQgY29sb3IgaXMgc29tZXRoaW5nIHRo YXQgaXMgbGVmdCB0byB0aGUgb3BlcmF0b3IgYXMgcGFydCBvZiB0aGVpciBuZXR3b3JrIGRlc2ln biBhbmQgbm90IHNvbWV0aGluZyB0byByZXNlcnZlIG9yIGRlZmluZSBhIHNwZWNpYWwgcmFuZ2Ug Zm9yLiBUaGlzIGlzIHdoYXQgd291bGQgZ2l2ZSB0aGUgb3BlcmF0b3INCiB0byBjaG9vc2UgdGhl IHZhcmlvdXMgc3RlZXJpbmcgbWVjaGFuaXNtcyBhbmQgaG93IGFuZCB3aGVyZSB0byB1c2UgdGhl bSBpbiB0aGVpciBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+S2V0YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gU3RvbmUsIEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDthbmRyZXcu c3RvbmVAbm9raWEuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDEzIE5vdmVtYmVyIDIwMjAg MDQ6NDI8YnI+DQo8Yj5Ubzo8L2I+IFRhcmVrIFNhYWQgJmx0O3RzYWFkLm5ldEBnbWFpbC5jb20m Z3Q7OyBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRhbnRAY2lzY28uY29tJmd0Ozsg VmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmlzaG51cGF2YW5AZ21haWwuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5n XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj5IaSBUYXJlayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoYW5rcyBmb3IgdGhl IGNvbW1lbnRzLiBTbWFsbCByZXBseSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoYW5rczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlRhcmVrIFNhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzp0c2FhZC5uZXRAZ21haWwuY29tIj50c2Fh ZC5uZXRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE5vdmVt YmVyIDEyLCAyMDIwIGF0IDI6MjIgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1N0b25lLCBBbmRy ZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5z dG9uZUBub2tpYS5jb20iPmFuZHJldy5zdG9uZUBub2tpYS5jb208L2E+Jmd0OywgJnF1b3Q7S2V0 YW4gVGFsYXVsaWthciAoa2V0YW50KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudD00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDssIFZpc2hudSBQYXZhbiBCZWVyYW0NCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZp c2hudXBhdmFuQGdtYWlsLmNvbSI+dmlzaG51cGF2YW5AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNw cmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc3ByaW5nXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+SGkgYWxsLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+U2VlIGlubGluZSBmb3Igc29tZSBjb21tZW50cy4u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3 YSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbmRyZXcuc3RvbmVAbm9raWEuY29tIj5hbmRy ZXcuc3RvbmVAbm9raWEuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBO b3ZlbWJlciAxMSwgMjAyMCBhdCA2OjE2IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtLZXRhbiBU YWxhdWxpa2FyIChrZXRhbnQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50PTQwY2lz Y28uY29tQGRtYXJjLmlldGYub3JnIj5rZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0OywgVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpc2hudXBh dmFuQGdtYWlsLmNvbSI+dmlzaG51cGF2YW5AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzog PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc3ByaW5nXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5LnR4dDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLUNBIj5IaSBLZXRhbiwgUGF2YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5Hb29kIGRpc2N1c3Np b24uIEp1c3QgZ29pbmcgdG8gY2hpcCBpbiBzb21lIHRob3VnaHRz4oCmPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB Ij5PbmUgb2YgdGhlIGVsZW1lbnRzIEkgcGVyc29uYWxseSBsaWtlIG9mIHRoZSBTUiBQb2xpY3kg bW9kZWwgaXMgdGhhdCBtYW55IENhbmRpZGF0ZSBQYXRocyBtYXkgZXhpc3QsIGJ1dCBvbmx5IG9u ZSBtYXkgYmUgYWN0aXZlIGFuZCBhIGNhbmRpZGF0ZSBwYXRoIGNvbnRhaW5zIDEgb3IgbWFueSBT SUQgbGlzdHMuIEl04oCZcyBhIHNpbXBsZQ0KIHBhcmVudC9jaGlsZCAtIHJvb3QvbGVhZiB0cmVl IHdpdGggdmVyeSBjbGVhciBydWxlcyB3aXRoaW4gdGhlIFNSIHBvbGljeSBjb250ZXh0IGluc3Rh bmNlLiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHdoYXQgaXMgYmVpbmcgcHJvcG9zZWQgaW4gdGhl IC0wOSBkb2N1bWVudCBzdGlsbCBmb2xsb3dzIHRob3NlIHJ1bGVzIGFuZCB0aGUgZ2VuZXJhbCB0 b3AtZG93biB0cmVlIGJlaGF2aW91ci4gRGVzcGl0ZSB0aGUgY29tcG9zaXRlIENQIHBvaW50aW5n DQogdG8gYSBkaWZmZXJlbnQgU1IgUG9saWN5LCB0aGF0IFNSIFBvbGljeSBzdGlsbCBmb2xsb3dz IGFsbCBvZiB0aGUgc2FtZSBydWxlcyB0b3AgZG93biBpbiBpdHMgb3duIGlzb2xhdGVkIGNvbnRl eHQuIENvbXBhcmUgdGhhdCB0byBzYXksIGhhdmluZyBhIGNhbmRpZGF0ZSBwYXRoIGNvbnRhaW4g YSBjaGlsZCB0aGF0IHBvaW50cyB0byBvdGhlciBjYW5kaWRhdGUgcGF0aHMgd2l0aGluIHRoZSBz YW1lIFNSIFBvbGljeSBjb250ZXh0OiB3aXRoaW4gdGhlDQogc2FtZSBjb250ZXh0IGEgY2hpbGQg aXMgcG9pbnRpbmcgdG8gYSBzaWJsaW5nIG9mIGl0cyBwYXJlbnQuIFRoZSBydWxlcyBub3cgaGF2 ZSB0byBiZW5kIHNsaWdodGx5LiBBcyBub3RlZCBiZWxvdywgc29tZSBvZiB0aGUgcnVsZXMgYXJv dW5kIHdoYXQgaXMgY29uc2lkZXJlZCBhbiBhY3RpdmUgY2FuZGlkYXRlIHBhdGggd291bGQgbmVl ZCB0byBjaGFuZ2UsIHNpbmNlIHRoZSBjb25zdGl0dWVudHMgZXNzZW50aWFsbHkgYXJlIGFjdGl2 ZSAodGhleeKAmXJlDQogaW5zdGFsbGVkKSBkZXNwaXRlIG5vdCBiZWluZyB0aG91Z2h0IG9mIGFz IGJlaW5nIGFjdGl2ZS4gTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBuZXcgdGV4dCBiZWxvdyBzYXlz IOKAnFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhlIHR3byBjb25zdGl0 dWVudCBjYW5kaWRhdGUgcGF0aHMmcXVvdDsgd2hpY2ggaXMgYWxzbyBhIG5ldyBydWxlLCBob3dl dmVyIG9uZSBjb3VsZCBwZXJoYXBzIHdvcmsgYXJvdW5kIHRoYXQgYnkganVzdCByZXF1aXJpbmcN CiB0aGUgcHJlZmVyZW5jZSBvbiB0aGUgY29uc3RpdHVlbnRzIGJlIGxlc3MgcHJlZmVycmVkIHRo YW4gYW55IG90aGVyIHN0YW5kYXJkIG9yIGNvbXBvc2l0ZSBDUCDigJMgYnV0IHRoYXQgcmFpc2Vz IGl0cyBvd24gdHJvdWJsZXMgd2l0aCBtdWx0aXBsZSBzb3VyY2VzIG9mIHByb3Zpc2lvbmluZyDi gJMgd2hpY2ggbGVhZHMgdG8gYSBydWxlIGFza2luZyB0byBpZ25vcmUgdGhlIHByZWZlcmVuY2Uu IEluIHN1bW1hcnksIGZyb20gbXkgcC5vLnYgbmV3IHJ1bGVzDQogaW4gdGhlIGhpZXJhcmNoeSB3 b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5SZWdhcmRpbmcgc3Rl ZXJpbmcgaW50byBhbiBTUiBQb2xpY3ksIHllcywgeW91IGJ1cm4gY29sb3JzIGluIGRvaW5nIHRo aXMgKDMyYml0cy4uLikgYW5kIGl0IHdvdWxkIHJlcXVpcmUgZGVwbG95aW5nIGFuIGVudGlyZWx5 IGRlZGljYXRlZCBTUiBQb2xpY3kgY29uc3RydWN0LCBhbmQgcnVuIHRoZSByaXNrIG9mIHN0ZWVy aW5nIOKAmG90aGVy4oCZDQogdHJhZmZpYyBpbnRvIHRoYXQgcG9saWN5LiBJZiB0aGlzIGlzIGEg Y29uY2Vybiwgd291bGQgdGhlIGNvbXBvc2l0ZSBTUiBQb2xpY2llcyBub3QgYmUgZW5naW5lZXJl ZCBpbiBhIHdheSB3aGVyZSB0aGUgY29sb3IgYmxvY2sgdXNlZCBpcyBkZXNpZ25lZCB0byBub3Qg YmUgdXNlZCBlbHNld2hlcmUgaW4gdGhlIG5ldHdvcmsgZm9yIG90aGVyIHB1cnBvc2VzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+W1RTXTogVG9kYXkgY29sb3JzIG9mIFNSIFBvbGlj aWVzIHRoYXQgYXJlIGluc3RhbnRpYXRlZCDigJxvbi1kZW1hbmTigJ0gb3IgaW5zdGFudGlhdGVk IHZpYSBQQ0VQIGZyb20gYSBQQ0UgYXJlIGRlcml2ZWQgZnJvbSB0aGUgaW50ZW50L3NlcnZpY2Uu IFdpdGggdGhlIGhpZXJhcmNoaWNhbCBTUiBwb2xpY2llcyBwcm9wb3NhbCwgYSBQQ0UgbWF5DQog bmVlZCB0byBpbnN0YW50aWF0ZSB0aGUgY29sb3JlZCBjaGlsZCBTUiBwb2xpY2llcyBvbi1kZW1h bmQgdG9vLCBidXQgaXQgaXMgbm90IGNsZWFyIHdoZXJlIHRoZSBjb2xvcnMgb2YgdGhvc2UgY2hp bGQgU1IgcG9saWNpZXMgd291bGQgYmUgZGVyaXZlZCBmcm9tLiBBcyBBbmRyZXcgc3VnZ2VzdHMs IGEgYmxvY2sgb2YgY29sb3JzIGNvdWxkIGJlIGNhcnZlZCBmcm9tIGV2ZXJ5IGhlYWRlbmTigJlz IHNwYWNlIC0tIHNwZWNpZmljYWxseSBmb3IgdGhpcw0KIHB1cnBvc2UgYW5kIGJlIG1hbmFnZWQg YnkgdGhlIFBDRS4gQWx0ZXJuYXRpdmVseSwgb25lIGNvdWxkIGNvbnNpZGVyIGNyZWF0aW5nIHN1 Y2ggU1IgUG9saWNpZXMgd2l0aCBhIHNwZWNpYWwvcmVzZXJ2ZWQgY29sb3IgdGhhdCB3b3VsZCBz aW1wbGlmeSB0aGVpciBjcmVhdGlvbi4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZXJlIGFy ZSBvdGhlciBjYXNlcyB3aGVyZSBTUiBQb2xpY2llcyBtYXkgYmUgaW5zdGFudGlhdGVkIChlLmcu IGZvcg0KIHRhY3RpY2FsIFRFIOKAkyBlLmcuIG9uIFAgbm9kZXMpIHRoYXQgd291bGQgbm90IHJl cXVpcmUgY29sb3IgcmVzb2x1dGlvbiwgYW5kIGNyZWF0aW9uIG9mIHRob3NlIGNvdWxkIGJlbmVm aXQgZnJvbSBhIHJlc2VydmVkIGNvbG9yIHRvby48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5b QW5kcmV3XSBHb29kIHBvaW50IGluZGVlZC4gVGhlIFAgbm9kZSBpcyB3aGF0IEkgd2FzIHBvaW50 aW5nIGF0IHdpdGggdGhlIEJTSUQgZXhhbXBsZSwgd2hlcmUsIGZvciBleGFtcGxlLCB3ZeKAmWxs IGhhdmUgdG8gYnVybiBhIGNvbG9yIHRvIGRlcGxveSBhIFNSIFBvbGljeSBvbiBhIHRyYW5zaXQg bm9kZSB3aGVuIHRoZSBjb25zdW1lciBpbnRlbnQgaXMgc2ltcGx5IGZvciB0aGUNCiBCU0lELiBU aGF0IGNvbG9yIHNlbGVjdGlvbiB3b3VsZCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQg4oCYc3BlY2lh bOKAmSBhbmQgdGFrZW4gZnJvbSBhIHVuaXF1ZSBibG9jayBpZiBvbmUgd2FudHMgdG8gYXZvaWQg dXNpbmcgaXQgZm9yIGhlYWQtZW5kIHN0ZWVyaW5nIG9uIHRoYXQgUCBub2RlLiAmbmJzcDtOb3Rp bmcgdGhhdCBjb2xvciBpcyBwYXJ0IG9mIHdoYXQgdW5pcXVlbmVzcywgdG8gZGVmaW5lIHRoZSDi gJxub3QgZm9yIHN0ZWVyaW5n4oCdIGJlaGF2aW91ciwgaXQNCiB3b3VsZCBuZWVkIHRvIGJlIGEg cmVzZXJ2ZWQgYmxvY2sgb3IgYml0IGVuY29kZWQgaW4gY29sb3IgYXMgb3Bwb3NlZCB0byBhIHNp bmdsZSBzcGVjaWFsIHZhbHVlLiBJ4oCZbSBub3Qgc3VyZSBhIHNwZWNpYWwgcmFuZ2UgbmVlZHMg dG8gYmUgSUVURiBzdGFuZGFyZGl6ZWQgb3Igc2ltcGx5IGxlZnQgdG8gaW1wbGVtZW50YXRpb25z L1BDRSAvIG5ldHdvcmsgZGVzaWduIHRvIGFsbG9jYXRlIGFuZCBlbmZvcmNlLiBJdCBzZWVtcyB0 aGF0IHRoZSBtb2RlbA0KIHRvIHN0ZWVyIGFuIFNSIFBvbGljeSBjYW5kaWRhdGUgcGF0aCBpbnRv IGFub3RoZXIgU1IgUG9saWN5IHdpdGggZWl0aGVyIGNvbG9yIG9yIHRoZSBjb25jZXB0IG9mIGEg c3BlY2lhbCBjb2xvciBzdGlsbCBzZWVtcyBmZWFzaWJsZSBpbiB0aGUgcHJlc2VudCBkb2N1bWVu dC4gSXQgbWlnaHQgYmUgd29ydGggaGF2aW5nIHRleHQgZGVzY3JpYmluZyB0aGF0IGEgY29uc3Rp dHVlbnQgY2FuZGlkYXRlIHBhdGggbWF5IGJlIHVzZWQgZm9yIHN0ZWVyaW5nDQogb24gdGhlIGhl YWRlbmQsIGFuZCBpZiBpbnRlbnRpb24gaXMgdG8gYXZvaWQgdGhhdCB0aGVuIHRoZSB1c2VyL3Bj ZS9uZXR3b3JrIGRlc2lnbiBzaG91bGQgYWxsb2NhdGUgYSBibG9jayBvZiB2YWx1ZXMgZm9yIGNv bnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRocyBhbmQgc2VsZWN0IG9ubHkgZnJvbSB0aGF0IGJsb2Nr LCBub3QgdG8gYmUgdXNlZCBvbiBhbnkgb3RoZXIgcm91dGVzIGluIHRoZSBuZXR3b3JrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5SZWdhcmRzLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5U YXJlazwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPklzIHRoZXJlIG5vdCBhIGRpZmZlcmVudCBidXQg a2luZCBvZiBzaW1pbGFyIHByb2JsZW0gd2l0aCBCaW5kaW5nIFNJRHMsIGluIHRoYXQgdGhleeKA mXJlIGVsaWdpYmxlIGZvciB1c2UgYnkgb3RoZXIgY29uc3VtZXJzIGV2ZW4gaWYgbm90IGRpcmVj dGx5IGludGVuZGVkPyAoYWx0aG91Z2ggYXQgbGVhc3QgQlNJRHMgYXJlIG9wdGlvbmFsDQogYW5k IG5vdCBtYW5kYXRvcnkpLiBJbiBhZGRpdGlvbiB0byB0aGUgc3BsaXQgVEUgY2FzZXMsIGJlaW5n IGFibGUgdG8gaGF2ZSBhbiBTUiBQb2xpY3kgc3RlZXIgaW50byBhbm90aGVyIFNSIFBvbGljeSBt aWdodCBhbHNvIGhhdmUgc29tZSB2YWx1ZSBpbiBhIGJhY2t1cCBjYW5kaWRhdGUgc2NlbmFyaW8g d2hlbiBvbmUgaGFzIG11bHRpcGxlIFNSIFBvbGljaWVzIHdpdGggdGhlIHNhbWUgZW5kcG9pbnQs IGJ1dCBjYW4gc2hhcmUgYSBjb21tb24gZmFsbGJhY2svYmVzdA0KIGVmZm9ydCBjYW5kaWRhdGUg cGF0aC4gVGhlIGVudGl0eSAoPGk+SSdtIHRoaW5raW5nIFBDRTwvaT4pIG1hbmFnaW5nIHRoYXQg d291bGQgb25seSBuZWVkIHRvIG1haW50YWluIHRoZSBmYWxsYmFjay9iZXN0IGVmZm9ydCBDUCBT SUQgbGlzdChzKSwgaW5zdGVhZCBvZiBvbmUgZm9yIGVhY2ggTiAqIENQcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiPlNvbWV0aGluZyBJIGhhdmVu4oCZdCBjb25jbHVkZWQgdG8gbXlzZWxmIHlldCBhcmUgcXVl c3Rpb25zIHN1Y2ggYXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tQ0EiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1DQSI+ZG9lcyBoYXZpbmcg YSBjYW5kaWRhdGUgcGF0aCBzdGVlciBpbnRvIGFub3RoZXIgU1IgUG9saWN5IHNhdGlzZnkgdGhl IGFiaWxpdHkgdG8gZG8gdmFyaW91cyBzdWItcGF0aCBzcGVjaWZpYyBURS9jb25zdHJhaW50L29i amVjdCBjb21iaW5hdGlvbnMgc3VmZmljaWVudGx5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz0iRU4tQ0EiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBsYW5nPSJFTi1DQSI+aXMgdGhlIG1vZGVsIHJlbGF0aXZlbHkgc3RyYWlnaHQgZm9y d2FyZCB0byBtYXAgaW50byB5YW5nL2JncC9wY2VwIGV0Yy4uPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tQ0EiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1DQSI+ZG9lcyB1c2luZyBhbiBhZGRpdGlvbmFsIFNSIFBv bGljeSBjcmVhdGUgdG9vIG11Y2ggb3ZlcmhlYWQgb3Igc3RhdGUgYnVybiB0byBjb25maWd1cmUs IGRlcGxveSwgbWFuYWdlLCB0cmFjayBldGMuLiA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5DaGVlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZyI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgJnF1b3Q7S2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+a2V0YW50PTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92 ZW1iZXIgMTAsIDIwMjAgYXQgMTA6MzMgUE08YnI+DQo8Yj5UbzogPC9iPlZpc2hudSBQYXZhbiBC ZWVyYW0gJmx0OzxhIGhyZWY9Im1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20iPnZpc2hudXBh dmFuQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOS50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBQYXZhbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiPlBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxiPjxzcGFuIGxhbmc9IkVOLUNBIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0Ei PiBWaXNobnUgUGF2YW4gQmVlcmFtICZsdDs8YSBocmVmPSJtYWlsdG86dmlzaG51cGF2YW5AZ21h aWwuY29tIj52aXNobnVwYXZhbkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+ IDExIE5vdmVtYmVyIDIwMjAgMDA6MjY8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIg KGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIj5rZXRhbnRAY2lz Y28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJp bmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+S2V0YW4sIEhpITxi cj4NCjxicj4NClBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNwb25zZXMgKHByZWZpeGVkIFZQQiku PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQotUGF2YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLUNBIj5PbiBUdWUsIE5vdiAxMCwgMjAyMCBhdCA0OjA0IEFNIEtldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIj5rZXRh bnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPkhpIFBhdmFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+UGxlYXNlIGNoZWNr IGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNv bG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0EiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+IFZpc2hudSBQYXZhbiBCZWVyYW0gJmx0OzxhIGhyZWY9 Im1haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52aXNobnVwYXZh bkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDEwIE5vdmVtYmVyIDIwMjAg MDA6MDg8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhy ZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS0wOS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5LZXRhbiw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+TXVjaCBUaGFua3MgZm9yIHRha2luZyBhIHN0YWIgYXQgYWRkcmVz c2luZyB0aGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIHVzZS1jYXNlITxzcGFuIGNsYXNzPSJn bWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7V2Ugc2VlbSB0byBiZSBjb252ZXJnaW5nLjwvc3Bhbj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiPltLVF0gVGhhbmtz IGZvciB0aGF0IGZlZWRiYWNrIGFuZCBjb25maXJtYXRpb24gdGhhdCB0aGUgcHJvcG9zYWwgaW4g dGhlIGRyYWZ0IGRvZXMgYWRkcmVzcyB0aGUgdXNlLWNhc2UuIEkgYmVsaWV2ZSB3ZSBhcmUgbm93 IGRpc2N1c3NpbmcgdGhlIG1lY2hhbmljcyBvZiBob3cgdGhpcyBpcyBhY2hpZXZlZCB3aXRoaW4g dGhlDQogY3VycmVudCBTUiBQb2xpY3kgZnJhbWV3b3JrLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJz cDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ib3dldmVy LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgeW91IG5lZWQgdG8gdXNlIGFkZGl0aW9uYWwgU1Ig cG9saWNpZXMgKGFuZCB1bm5lY2Vzc2FyaWx5IGJ1cm4gYWRkaXRpb25hbCBjb2xvcnMpIHRvIGFk ZHJlc3MgdGhpcy4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tQ0EiPltLVF0gSSBkbyBub3QgZm9sbG93IHdoYXQgeW91IG1lYW4g Ynkg4oCcYnVybiBhZGRpdGlvbmFsIGNvbG9yc+KAnS4gQ29sb3IgaXMganVzdCBhIDMyIGJpdCBu dW1iZXIgdGhhdCBpbmRpY2F0ZXMgdGhlIOKAnGludGVudOKAnSBhbmQgaXMgbm90IHJlYWxseSBh IHNjYXJjZSByZXNvdXJjZS4gQXNzaWduaW5nIGEgY29sb3IgdG8g4oCcYSBjb21wb3NpdGUNCiBp bnRlbnTigJ0gc2VlbXMgbGlrZSBhIHNlYW1sZXNzIHdheSB0byBpbnRlZ3JhdGUgd2l0aCBleGlz dGluZyBtZWNoYW5pc21zIGZvciBTdGVlcmluZyBvdmVyIFNSIFBvbGljaWVzLiBUaGlzIGdpdmVz IHRoZSBmbGV4aWJpbGl0eSBmb3Igc2F5IHNvbWUgQkdQIHNlcnZpY2VzIHRvIGJlIHN0ZWVyZWQg b3ZlciB0aGUgY29uc3RpdHVlbnQgZXhwbGljaXQvZHluYW1pYyBpbnRlbnQgd2hpbGUgb3RoZXJz IGNhbiBzdGVlciBvdmVyIGEgY29tcG9zaXRlIGludGVudA0KIHRoYXQgaW5jbHVkZXMgdGhvc2Ug aW5kaXZpZHVhbCBleHBsaWNpdC9keW5hbWljIGludGVudHMuPC9zcGFuPjwvaT48L2I+PHNwYW4g bGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPltWUEJdIFRoZSDigJxmbGV4aWJpbGl0 eeKAnSB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIGlzIHVuZGVzaXJhYmxlIGZvciB0aGlzIHVz ZS1jYXNlLiBGb3IgdGhlIHRyYWZmaWMtc3BsaXQgdXNlLWNhc2UsIHdlIGRvbuKAmXQgd2FudCBh bnkgb3RoZXIgc2VydmljZXMgdG8gYmUgZGlyZWN0bHkgc3RlZXJlZCBvdmVyIHRoZSBjb25zdGl0 dWVudHMNCiB3aGVuIHRoZXkgYXJlIHBhcnQgb2YgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNDQ3 MkM0Ij5bS1RdIEkgYmVsaWV2ZSB0aGUgdXNlLWNhc2UgdGhhdCB5b3UgYXJlIHJlZmVycmluZyB0 byB3YXMgZm9yIHNwbGl0dGluZyBzb21lIHRyYWZmaWMgZm9yIGEgc2VydmljZSBvdmVyIGEgYmx1 ZSBwbGFuZSBhbmQgdGhlIHJlc3Qgb3ZlciBhIHJlZCBwbGFuZS4gQXQgdGhlIHNhbWUgdGltZSwN CiB0aGVyZSBtYXkgYmUgb3RoZXIgc2VydmljZXMgdGhhdCB1dGlsaXplIG9ubHkgYSBzaW5nbGUg cGxhbmUuIFRoZSBmbGV4aWJpbGl0eSB0aGF0IEkgd2FzIHJlZmVycmluZyB0byB3YXMgdG8gZW5h YmxlL2FsbG93IGZvciBlaXRoZXIgb2YgdGhlIHR3byBzY2VuYXJpb3MgYW5kIHRoZXJlIG1heSBi ZSBvdGhlci9tb3JlIHVzZS1jYXNlcyBmb3Igd2hpY2ggd2UgbmVlZCBhIG1vcmUgZ2VuZXJpYyBm cmFtZXdvcmsuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1D QSI+VGhlIGN1cnJlbnQgcHJvcG9zYWwgaW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgYmVlbiBhY2Nl cHRhYmxlIGlmIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyB3ZXJlIHVuY29sb3JlZCDigJMg YnV0IHRoYXQgd291bGQgdmlvbGF0ZSB0aGUgY3VycmVudCBydWxlcyBpbXBvc2VkIGJ5IHRoZSBk cmFmdC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNw YW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPldoeSBjYW7igJl0IHRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGgganVz dCBiZSBhIGdyb3VwaW5nIG9mIGV4cGxpY2l0IGNhbmRpZGF0ZSBwYXRocyBhbmQvb3IgZHluYW1p YyBjYW5kaWRhdGUgcGF0aHM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1DQSI+W0tUXSBUaGlzIGlzIGJlY2F1c2UgaW4gdGhlIFNS IFBvbGljeSBmcmFtZXdvcmssIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgYWN0aXZlIENQIOKAkyBp dCBtYXkgYmUgZXhwbGljaXQgb3IgZHluYW1pYy4gTm93IHdl4oCZdmUgYWRkZWQgYW5vdGhlciBD b21wb3NpdGUgQ1AgdHlwZSB0byBjb3ZlciB0aGlzIHNwZWNpZmljIHVzZS1jYXNlLg0KIFlvdXIg cHJvcG9zYWwgd2lsbCByZXN1bHQgaW4gMyBjYW5kaWRhdGUgcGF0aHMgYmVpbmcgYWN0aXZlIHdp dGhpbiB0aGUgc2FtZSBTUiBQb2xpY3kg4oCTIG9uZSBlYWNoIG9mIHRoZSBleHBsaWNpdCBhbmQg ZHluYW1pYyBDUCBhbmQgdGhlbiBhZGRpdGlvbmFsbHkgdGhlIENvbXBvc2l0ZSBDUC4gVGhpcyBi cmVha3MgdGhlIGV4aXN0aW5nIHJ1bGVzIGZvciBzZWxlY3Rpb24gb2YgQ1AgYmFzZWQgb24gcHJl ZmVyZW5jZSBhbmQgbWVjaGFuaXNtcyBsaWtlDQogZmFsbGJhY2sgYmV0d2VlbiBDUHMuIFdoaWxl IHRoZSBjdXJyZW50IHByb3Bvc2FsIGluIHRoZSBkcmFmdCBwcm92aWRlcyBhIHdheSB0byBhZGRy ZXNzIHRoZSBuZXcgdXNlLWNhc2Ugd2l0aCBhIGJhY2t3YXJkcyBjb21wYXRpYmxlIGV4dGVuc2lv biB0byB0aGUgU1IgUG9saWN5IGZyYW1ld29yay48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+W1ZQQl0gVGhlIHByb3Bvc2FsIGluIG15IHByZXZp b3VzIGVtYWlsIGlzIGJhY2t3YXJkcyBjb21wYXRpYmxlIGFuZCBkb2VzIG5vdCBpbnRlbmQgdG8g YnJlYWsgYW55IGV4aXN0aW5nIHJ1bGVzIGZvciBkZWVtaW5nIGEgY2FuZGlkYXRlIHBhdGggYWN0 aXZlLiBBcyBwZXIgdGhlIHJ1bGVzIHRoYXQgYXJlIG91dGxpbmVkIGluIFNlY3Rpb24NCiAyLjks IG9ubHkgdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyDigJxhY3RpdmXigJ0gZ2l2ZW4g aXRzIHByZWZlcmVuY2UuIFRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aHMgd2lsbCBuZXZl ciBiZSBhY3RpdmUgb24gdGhlaXIgb3duLiBJZiBpdCBpcyBuZWNlc3NhcnksIHdlIGNhbiBhZGQg YSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiAyLjkgdG8gZXhwbGljaXRseSBzdGF0ZSB0aGF0IHRoZSBj YW5kaWRhdGUgcGF0aCBzZWxlY3Rpb24gY3JpdGVyaWENCiBkb2VzIG5vdCBhcHBseSB0byB0aGUg Y29uc3RpdHVlbnQgY2FuZGlkYXRlIHBhdGhzLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM0NDcyQzQiPltLVF0gV2hlbiBhIENQIGlz IOKAnGFjdGl2ZeKAnSBpdCBpcyBhY3R1YWxseSB0aGUgb25lIHRoYXQgaXMgYmVpbmcgdXNlZCBm b3IgZm9yd2FyZGluZy48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij4mbmJz cDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5UaGFua3MsPC9zcGFuPjwv aT48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+S2V0YW48L3NwYW4+PC9pPjwvYj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48c3Bh biBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGFua3MsPC9zcGFuPjwvaT48 L2I+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVO LUNBIj5LZXRhbjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Q29uc2lk ZXIgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4qKiBTZWN0aW9uIDIuMjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+T0xEOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBBIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aCBhY3RzIGFzIGEgY29udGFpbmVyIGZvciBncm91cGluZyBvZiBTUjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IFBvbGljaWVzLiZuYnNwOyBUaGUgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGNvbnN0 cnVjdCBlbmFibGVzIGNvbWJpbmF0aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb2YgU1IgUG9s aWNpZXMsIGVhY2ggd2l0aCBleHBsaWNpdCBjYW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFtaWM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGUgcGF0aHMgd2l0aCBwb3RlbnRpYWxseSBk aWZmZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBh bmQgY29uc3RyYWludHMsIGZvciBhIGxvYWQtYmFsYW5jZWQgc3RlZXJpbmcgb2YgcGFja2V0IGZs b3dzIG92ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpdHMgY29uc3RpdHVlbnQgU1IgUG9saWNp ZXMuJm5ic3A7IFRoZSBmb2xsb3dpbmcgY3JpdGVyaWEgYXBwbHkgZm9yPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgaW5jbHVzaW9uIG9mIGNvbnN0aXR1ZW50IFNSIFBvbGljaWVzIHVzaW5nIGEgY29t cG9zaXRlIGNhbmRpZGF0ZSBwYXRoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdW5kZXIgYSBwYXJl bnQgU1IgUG9saWN5Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZu YnNwOyB0aGUgZW5kcG9pbnRzIG9mIHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBhbmQgdGhl IHBhcmVudCBTUjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBvbGlj eSBNVVNUIGJlIGlkZW50aWNhbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgbyZuYnNwOyBUaGUgY29sb3JzIG9mIGVhY2ggb2YgdGhlIGNvbnN0aXR1ZW50IFNSIFBvbGlj aWVzIGFuZCB0aGUgcGFyZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU1IgUG9saWN5IE1VU1QgYmUgZGlmZmVyZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBvJm5ic3A7IHRoZSBjb25zdGl0dWVudCBTUiBQb2xpY2llcyBNVVNUIE5P VCB1c2UgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgRWFjaCBjb25zdGl0dWVudCBTUiBQb2xpY3kgb2YgYSBjb21wb3NpdGUg Y2FuZGlkYXRlIHBhdGggaXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGgg YSB3ZWlnaHQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2VzIChyZWZlcjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5I3NlY3Rpb24tMi4xMSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5TZWN0aW9uIDIuMTE8L3NwYW4+PC9h PiBmb3IgZGV0YWlscykuJm5ic3A7IFRoZSBkZWZhdWx0IHdlaWdodCBpcyAxLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBjb21wb3Np dGUgY2FuZGlkYXRlIHBhdGggYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgZ3JvdXBpbmcgb2Y8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBleHBsaWNpdCBjYW5kaWRhdGUgcGF0aHMgYW5kL29yIGR5bmFt aWMgY2FuZGlkYXRlIHBhdGhzIHdpdGggPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtwb3Rl bnRpYWxseSBkaWZmZXJlbnQgb3B0aW1pemF0aW9uIG9iamVjdGl2ZXMgYW5kIGNvbnN0cmFpbnRz Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggY29u c3RydWN0IGVuYWJsZXMgbG9hZC1iYWxhbmNlZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0ZWVy aW5nIG9mIHBhY2tldC1mbG93cyBvdmVyIGEgc2V0IG9mIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IHBhdGhzLiBUaGUgZm9sbG93aW5nIGNyaXRlcmlhIGFwcGx5 IGZvciBjb25zdGl0dWVudCBjYW5kaWRhdGUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cGF0 aHMgdW5kZXIgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGg6PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgY29uc3RpdHVl bnQgY2FuZGlkYXRlIHBhdGggTVVTVCBiZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtpZ25vcmVkLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBvJm5ic3A7IHRoZSBjb25zdGl0dWVudCBjYW5kaWRhdGUgcGF0aCBNVVNUIE5PVCBiZSBh IGNvbXBvc2l0ZSBjYW5kaWRhdGUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtwYXRoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBF YWNoIGNvbnN0aXR1ZW50IGNhbmRpZGF0ZSBwYXRoIG9mIGEgY29tcG9zaXRlIGNhbmRpZGF0ZSBw YXRoIGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXNzb2NpYXRlZCB3aXRoIGEgd2VpZ2h0IGZv ciBsb2FkLWJhbGFuY2luZyBwdXJwb3NlcyAocmVmZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOSNzZWN0aW9uLTIuMTEiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6Izk1NEY3MiI+U2VjdGlvbiAyLjExPC9zcGFuPjwvYT4gZm9yIGRldGFp bHMpLiZuYnNwOyBUaGUgZGVmYXVsdCB3ZWlnaHQgaXMgMS48L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Kio8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+KiogU2VjdGlvbiAyLjEx PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4 Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0 ZSBjYW5kaWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRoZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzEx MDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+c3RlZXJl ZCBpbnRvIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIGVxdWFsIHRvIHRoZSByZWxhdGl2 ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00 NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+d2VpZ2h0IG9mIGVhY2ggY29uc3RpdHVlbnQgU1IgUG9saWN5LiZuYnNwOzxzcGFuIGNsYXNz PSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkZ1cnRoZXINCiBsb2FkIGJhbGFuY2luZyBvZjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4 Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Zmxvd3Mgc3RlZXJlZCBp bnRvIGEgY29uc3RpdHVlbnQgU1IgUG9saWN5IGlzIHBlcmZvcm1lZCBiYXNlZCBvbiB0aGU8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5 MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndl aWdodHMgb2YgdGhlIFNlZ21lbnQtTGlzdCBvZiB0aGUgYWN0aXZlIGNhbmRpZGF0ZSBwYXRoIG9m IHRoYXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFp bC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPmNvbnN0aXR1ZW50IFNSIFBvbGljeS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPk5FVzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+V2hlbiBhIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBpcyBhY3RpdmUsIHRo ZSBmcmFjdGlvbiBvZiBmbG93czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+c3RlZXJlZCBpbnRvIGVhY2ggY29uc3RpdHVlbnQgY2FuZGlk YXRlIHBhdGggaXMgZXF1YWwgdG8gdGhlIHJlbGF0aXZlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1h cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53ZWlnaHQgb2YgZWFjaCBjb25zdGl0 dWVudCBjYW5kaWRhdGUgcGF0aC4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEw MTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GdXJ0aGVy DQogbG9hZCBiYWxhbmNpbmcgb2Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZsb3dzIHN0ZWVyZWQgaW50byBhIGNvbnN0aXR1ZW50IGNh bmRpZGF0ZSBwYXRoIGlzIHBlcmZvcm1lZCBiYXNlZCBvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dGhlIHdlaWdodHMgb2YgZWFjaCBh c3NvY2lhdGVkIFNlZ21lbnQtTGlzdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPioqPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPioqIFNlY3Rpb24gMi4x Mzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlh bnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYy OGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZSBpbmZvcm1hdGlv biBtb2RlbCBvZiBTUiBQb2xpY3kgUE9MMTAwIGhhdmluZyBhIGNvbXBvc2l0ZTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEz OTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y2FuZGlkYXRl IHBhdGggaXMgdGhlIGZvbGxvd2luZzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U1Ig cG9saWN5IFBPTDEwMCAmbHQ7aGVhZGVuZCA9IEgxLCBjb2xvciA9IDEwMCwgZW5kcG9pbnQgPSBF MSZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENQMSAm bHQ7cHJvdG9jb2wtb3JpZ2luID0gMjAsIG9yaWdpbmF0b3IgPTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTAwOjEuMS4xLjEsIGRpc2Ny aW1pbmF0b3IgPSAxJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UHJlZmVyZW5jZSAyMDA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdodCBXMSwgU1IgcG9saWN5ICZsdDtjb2xv ciA9IDEmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21h aWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5XZWlnaHQgVzIsIFNSIHBvbGljeSAmbHQ7Y29sb3IgPSAyJmd0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgY29uc3RpdHVlbnQgU1IgUG9saWNpZXMgUE9MMSBhbmQg UE9MMiBoYXZlIGluZm9ybWF0aW9uIG1vZGVsIGFzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kZXNjcmliZWQgYXQgdGhlIHN0YXJ0IG9m IHRoaXMgc2VjdGlvbi4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2 MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGV5DQogYXJlIHJl ZmVyZW5jZWQgb25seSBieTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Y29sb3IgaW4gdGhlIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0aCBz aW5jZSB0aGVpciBoZWFkZW5kIGFuZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZW5kcG9pbnQgYXJlIGlkZW50aWNhbCB0byB0aGUgUE9M MTAwLiZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZQ0KIHZhbGlkIFNlZ21lbnQtTGlz dHMgb2YgdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5hY3RpdmUgY2FuZGlkYXRlIHBhdGggb2YgUE9MMSBhbmQgUE9MMiBhcmUgaW5z dGFsbGVkIGluIHRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Zm9yd2FyZGluZy4mbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3 OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5U cmFmZmljIHN0ZWVyZWQNCiBvbiBQT0wxMDAgaXMgZmxvdy1iYXNlZCBoYXNoZWQgb24gUE9MMTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEz NzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ d2l0aCBhIHJhdGlvIFcxLyhXMStXMikuJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkw NzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2l0 aGluDQogdGhlIFBPTDEsIHRoZSBmbG93LWJhc2VkIGhhc2hpbmc8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdt YWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm92ZXIgaXRzIFNlZ21lbnQt TGlzdHMgYXJlIHBlcmZvcm1lZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEw MTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zZWN0aW9u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2Mjhn bWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgaW5mb3JtYXRpb24g bW9kZWwgb2YgU1IgUG9saWN5IFBPTDEwMCBoYXZpbmcgYSBjb21wb3NpdGU8L3NwYW4+PHNwYW4g bGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBw YXRoIGlzIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNSIHBv bGljeSBQT0wxMDAgJmx0O2hlYWRlbmQgPSBIMSwgY29sb3IgPSAxMDAsIGVuZHBvaW50ID0gRTEm Z3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhbmRpZGF0ZS1wYXRoIENvbXAtQ1AgJmx0 O3Byb3RvY29sLW9yaWdpbiA9IDIwLA0KIG9yaWdpbmF0b3IgPTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTAwOjEuMS4xLjEsIGRpc2Ny aW1pbmF0b3IgPSAxJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UHJlZmVyZW5jZSAyMDA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VpZ2h0IFcxLCBDYW5kaWRhdGUtcGF0aCBDUDE8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcx MTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlaWdo dCBXMiwgQ2FuZGlkYXRlLXBhdGggQ1AyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3 MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYW5k aWRhdGUtcGF0aCBDUDEgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgMTAwOjEuMS4xLjEsIGRpc2NyaW1p bmF0b3IgPSAyJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzExLCBTSUQtTGlzdDEgJmx0O1NJRDExLi4uU0lEMWkmZ3Q7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt bTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5XZWlnaHQgVzEyLCBTSUQtTGlzdDIgJmx0O1NJRDIxLi4uU0lEMmomZ3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYW5k aWRhdGUtcGF0aCBDUDIgJmx0O3Byb3RvY29sLW9yaWdpbiA9IDIwLCBvcmlnaW5hdG9yID08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgMTAwOjEuMS4xLjEsIGRpc2NyaW1p bmF0b3IgPSAzJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5XZWlnaHQgVzIxLCBTSUQtTGlzdDMgJmx0O1NJRDMxLi4uU0lEM2kmZ3Q7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt bTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5XZWlnaHQgVzIyLCBTSUQtTGlzdDQgJmx0O1NJRDQxLi4uU0lENGomZ3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IENvbXAt Q1AgaXMgYSBjb21wb3NpdGUgY2FuZGlkYXRlIHBhdGggd2l0aCB0d28gY29uc3RpdHVlbnRzLCBD UDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t NDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmFuZCBDUDIuIFRoZSBwcmVmZXJlbmNlIGlzIGlnbm9yZWQgZm9yIGVhY2ggb2YgdGhlIHR3 byBjb25zdGl0dWVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2FuZGlkYXRlIHBh dGhzLiBUaGUgdmFsaWQgU2VnbWVudC1MaXN0cyBvZiB0aGUgdHdvPHNwYW4gY2xhc3M9ImdtYWls LW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+Y29uc3RpdHVlbnQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2FuZGlk YXRlIHBhdGhzIGFyZSBpbnN0YWxsZWQgaW4gdGhlIGZvcndhcmRpbmcuJm5ic3A7VHJhZmZpYyBz dGVlcmVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21h aWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw O29uDQo8L3NwYW4+Q29tcC1DUCBpcyBmbG93LWJhc2VkIGhhc2hlZCBvbiB0byBDUDEgYW5kIENQ MiB3aXRoIGEgcmF0aW8gb2Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXMS8o VzErVzIpIGFuZCBXMi8oVzErVzIpIHJlc3BlY3RpdmVseS4gV2l0aGluIGVhY2ggY29uc3RpdHVl bnQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2FuZGlkYXRlIHBhdGgsIHRoZTxz cGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmZsb3ctYmFzZWQgaGFzaGluZyBvdmVyIGl0cyBTZWdtZW50 LUxpc3RzDQogYXJlIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGVyZm9ybWVkIGFz PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhpcyBzZWN0aW9u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4qKjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1z cGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4qKiBTZWN0aW9uIDUuMzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHNwZWNpZmllZCBh cyBhIGdyb3VwIG9mIGl0cyBjb25zdGl0dWVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U1IgUG9saWNpZXMuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkEgY29tcG9zaXRlIGNhbmRpZGF0ZSBwYXRoIGlzIHZhbGlkIHdoZW4g aXQgaGFzIGF0IGxlYXN0IG9uZSB2YWxpZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29uc3RpdHVlbnQgU1IgUG9saWN5Ljwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5NTI2MjhnbWFpbC1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5BIGNvbXBvc2l0ZSBjYW5kaWRhdGUgcGF0 aCBpcyBzcGVjaWZpZWQgYXMgYSBncm91cCBvZiBpdHMgY29uc3RpdHVlbnQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tNDQxMzc5MDcxMTAxMzk1 MjYyOGdtYWlsLWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNhbmRpZGF0ZSBw YXRocy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW00NDEzNzkwNzExMDEzOTUyNjI4Z21haWwt YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QSBjb21wb3NpdGUgY2FuZGlkYXRl IHBhdGggaXMgdmFsaWQgd2hlbiBpdCBoYXMgYXQgbGVhc3Qgb25lIHZhbGlkPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbTQ0MTM3OTA3MTEwMTM5 NTI2MjhnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5jb25zdGl0dWVu dCBjYW5kaWRhdGUgcGF0aC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Kio8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tUGF2YW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1DQSI+T24gU3VuLCBOb3YgMSwgMjAyMCBhdCA3OjAyIFBNIEtldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkgJmx0O2tldGFudD08YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVu dGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1DQSI+SGVsbG8gQWxsLDxicj4NCjxicj4NCldlIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRl IGZvciB0aGUgZHJhZnQgYW5kIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBvZiBjaGFuZ2VzOjxi cj4NCjxicj4NCjEpIEludHJvZHVjdGlvbiBvZiB0aGUgQ29tcG9zaXRlIENhbmRpZGF0ZSBQYXRo IGNvbnN0cnVjdCB0byBhZGRyZXNzIGEgcGVuZGluZyBjb21tZW50IGZyb20gdGhlIFdHIChSZWYg Og0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcv ZkVxRTVUT3dkaDJ2RXlGbV9NRWppWHlQMndzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZkVxRTVUT3dkaDJ2RXlGbV9NRWpp WHlQMndzLzwvYT4gYW5kDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NwcmluZy9kOW9TU2JncDBqQ0V4UngwU1h5QlkwQ3lxWFUvIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9kOW9TU2Jn cDBqQ0V4UngwU1h5QlkwQ3lxWFUvPC9hPik8YnI+DQoyKSBCYXNlZCBvbiBvZmZsaW5lIGZlZWRi YWNrIHJlY2VpdmVkLCB1cGRhdGVkIFNSdjYgc2VnbWVudCB0eXBlcyB0byBpbmNsdWRlIG9wdGlv bmFsIFNSdjYgU0lEIGFuZCBiZWhhdmlvciBpbnN0ZWFkIG9mIHRoZSBuZXcgdHlwZSB0aGF0IHdh cyBpbnRyb2R1Y2VkIGZvciBpdCBpbiB0aGUgdjA4Ljxicj4NCjMpIENsYXJpZmljYXRpb24gb2Yg aGFuZGxpbmcgb2YgY29sb3JzIGFuZCBCR1AgbXVsdGktcGF0aCBzY2VuYXJpb3MgYmFzZWQgb24g b2ZmbGluZSBmZWVkYmFjayByZWNlaXZlZC48YnI+DQo0KSBDbGFyaWZpY2F0aW9uIG9uIGNvbnNp ZGVyYXRpb25zIGZvciBUSS1MRkEgZm9yIFNSIFBvbGljeSBhcyBkaXNjdXNzZWQgaW4gdGhlIFdH IChSZWYgOg0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9z cHJpbmcvRVYxeXRVc2Q1WmdrTUhETjBJdkZodzlpZDQwLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvRVYxeXRVc2Q1WmdrTUhE TjBJdkZodzlpZDQwLzwvYT4pPGJyPg0KPGJyPg0KUGxlYXNlIGxldCBrbm93IHlvdXIgY29tbWVu dHMvZmVlZGJhY2suPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCktldGFuIChvbiBiZWhhbGYgb2Yg Y28tYXV0aG9ycyk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYg T2YNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KU2VudDogMDIgTm92ZW1iZXIg MjAyMCAwNjoyNzxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCkNjOiA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYu b3JnPC9hPjxicj4NClN1YmplY3Q6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNv dXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBTZWdtZW50IFJvdXRpbmcgUG9saWN5IEFyY2hpdGVjdHVy ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzogQ2xhcmVuY2UgRmlsc2ZpbHM8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgS2V0YW4gVGFsYXVsaWthcjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBEYW5pZWwgVm95ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgQWxleCBCb2dkYW5vdjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBQYXVsIE1hdHRlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBG aWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1wb2xpY3ktMDkudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDM3PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMjAtMTEtMDE8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+ DQombmJzcDsgJm5ic3A7U2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGEgaGVhZGVuZCBub2Rl IHRvIHN0ZWVyIGEgcGFja2V0IGZsb3c8YnI+DQombmJzcDsgJm5ic3A7YWxvbmcgYW55IHBhdGgu Jm5ic3A7IEludGVybWVkaWF0ZSBwZXItZmxvdyBzdGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtz PGJyPg0KJm5ic3A7ICZuYnNwO3RvIHNvdXJjZSByb3V0aW5nLiZuYnNwOyBUaGUgaGVhZGVuZCBu b2RlIHN0ZWVycyBhIGZsb3cgaW50byBhbiBTUiBQb2xpY3kuPGJyPg0KJm5ic3A7ICZuYnNwO1Ro ZSBoZWFkZXIgb2YgYSBwYWNrZXQgc3RlZXJlZCBpbiBhbiBTUiBQb2xpY3kgaXMgYXVnbWVudGVk IHdpdGggYW48YnI+DQombmJzcDsgJm5ic3A7b3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGFzc29j aWF0ZWQgd2l0aCB0aGF0IFNSIFBvbGljeS4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDtk b2N1bWVudCBkZXRhaWxzIHRoZSBjb25jZXB0cyBvZiBTUiBQb2xpY3kgYW5kIHN0ZWVyaW5nIGlu dG8gYW4gU1I8YnI+DQombmJzcDsgJm5ic3A7UG9saWN5Ljxicj4NCjxicj4NCjxicj4NClRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1wb2xpY3kvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS88 L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1w b2xpY3ktMDk8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA5PC9hPjxicj4NCjxicj4NCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5 LTA5PC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4N Cjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIg dGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxi cj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwv YT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MW3PR11MB4570A2FB66F1BBDC7D2412EAC1E60MW3PR11MB4570namp_-- From nobody Fri Nov 13 03:12:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC93A0E5C; Fri, 13 Nov 2020 03:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=kMtMuXVK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Sm8AcW1M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK6b_7sVAZeE; Fri, 13 Nov 2020 03:12:23 -0800 (PST) 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 647A63A0E5D; Fri, 13 Nov 2020 03:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17737; q=dns/txt; s=iport; t=1605265943; x=1606475543; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ktrLkpmZZAkjmsdZ35op8R0haiFQGrQpljHKt+bo6TI=; b=kMtMuXVKwY6w3jh/soxlxJzB6CWot1CpPbydLTfMZxgR8PBYt/bW8mMi prGnbZa3KwRBwDTvyj9EviPjR1CDzicmaQ3HLMntfBbKGECHqJ2qmyOQR GCIa4nEfv+6H5TtVNQQB/Wyz0dT0s+wfmKyjGrpjkU0aEzSBm4D5hfTGd A=; X-IPAS-Result: =?us-ascii?q?A0AgBQBlaa5ffYYNJK1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BIy8jLntZLy4Kh3wDjViBBZd+gUKBEQNUCwEBAQ0BASUIAgQBAYRKAoIbA?= =?us-ascii?q?iU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBhjwMhXIBAQEBAxILEBMBATcBD?= =?us-ascii?q?wIBCBEEAQEkBAcyFAkIAQEEAQ0FCBqDBYF+VwMuAQ6kMQKBPIhodIE0gwQBA?= =?us-ascii?q?QWBR0GDFhiCEAMGgTiCc4pNG4FBP4ERQ4IaBy4+gQSBWQEBAgEBgSE8KwmDF?= =?us-ascii?q?IIskD6KSIwOkR4Kgm2JD5IogxmKFpRKh1yLdop9lVYCBAIEBQIOAQEFgWshg?= =?us-ascii?q?VlwFYMkUBcCDY4fDBcUgzqFFIVEdDgCBgoBAQMJfIsILYEGAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AXZCxMxd6ldTBFF5H6/YUQTLJlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fb9vtbhuuQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNF3Pq2K/7HgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,475,1596499200"; d="scan'208,217";a="588897395" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Nov 2020 11:12:22 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ADBCLLY019612 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2020 11:12:22 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 05:12:21 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 05:12:21 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 13 Nov 2020 06:12:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A0yrabld6C1DokwDsginJv9K4amHB/ID1nnjVQdZtCs42nQMdDjvtVuo59Q/8jLGlWh0u+0bGYiyIPUR6NqTrt5nXmcuQSOuFy09/w1LqxfFHtQYgOmQ0G9CQVQ70wGsn6XlJng9L+KgmoXb99VYHsLE9aE2eQgORbcXlkoVazT96WzBLd5OTto9W0QHAXa1sW9agV/9uRzrgFU3/Kg8IiYaM/judSV+MQooY7w+JyvgtIbs0G/aAMdaRyUq/L1h6et/jYKS5LOpCJpaqnJAAkFUTb0cWGM75K63alpSknKh48wx23H+P3lyKPOOurSkV06flWQ7RCxCJn1OjLVDJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bo/fVwOLsFj+xI1yu6cWnl06BfwEU9VEMswLn3v/P68=; b=BvD/YzV7AKjNH/L8kcTpgNfzWJCSpJn5KNIFAMPg1IZMg/MggTrRrNCSpe1kqJx2sAa4yDS23bfHBNxVTtX8VHW0U9Xbb2hOenjx5qQkH/0+LFhLWeLdKROHMH76HtJeWe0eYoqgxHsEMOfdJIstUYx7770Dzu1vzzhh5CrLx3z+7+id5aehs0okZKbIDm7Q0XCRBthagDhu9MXsr5L8It1bxQ5EYZMAuvRtxbGpQVr1Q0dIor5iNgB8q5z/NIRjrhUpGmDnKJdWlr8PY1n/2e2zo/EN4WUv7al5MZ/OV5W3nTaOQmVp8rW7G9RudLcBo9b23Mwto4trJ5T2s1kItw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bo/fVwOLsFj+xI1yu6cWnl06BfwEU9VEMswLn3v/P68=; b=Sm8AcW1MByos+5ghaNqBUnBp5XbUvFE0xrFEUnrz3T4GH8DGt7BNXX4MOvnZgCaWjGeX/KI0XHLptEJgcdf1bkcEQrFuYcirSAPbQAsj87wcsmDNzpyh8uU3R02RcvsdcmnArgEhifhj4aADFOnXQxIEm/Eyn+uw8QedC4boqUE= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1823.namprd11.prod.outlook.com (2603:10b6:300:10e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Fri, 13 Nov 2020 11:12:20 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Fri, 13 Nov 2020 11:12:19 +0000 From: "Ketan Talaulikar (ketant)" To: Giuseppe Fioccola , Susan Hares , "idr@ietf.org" CC: "spring@ietf.org" Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSA= Date: Fri, 13 Nov 2020 11:12:19 +0000 Message-ID: References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> In-Reply-To: <1057d25807be466c97af61844fddfa35@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2dda39b5-1ac7-4d3d-edb9-08d887c4fcdf x-ms-traffictypediagnostic: MWHPR11MB1823: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rZk3woeF77zAehkgDhPPSzXpDc4m53N/HI/P0BBftucXysdGwidKprW1LVkIbeIqVOmD5i7fbmcw32Ep3F+33ILOAaTNfJPZQ4XIY0zbZVwkY6CYaLN5Fi8wh5ROFNDgEMIMnrP4GpeD2bo9fQ3LbcZvJxAFHORWA5xLa+bHOT1bItn7xOdWfZRmlSpdn6lioL48ykjhe0Yd8IXkUIUwD2tHkbmvohoMYSRBuOKXhnK96knyBOI1x0y2zwAEEdjuSUbYFXEJZy26R7XLOEWeFouXZopmzl/JMTKZEKFhwmogG8LH/rupnOMrgf3zgk8E55ikO+ghUDMCQX9dvSoUji2KcMQjRVCazpHc5twb0KwS1dsBT3iEnxQoSwzWD3On91fXNKTkrlCR5j4CpDJ10w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(396003)(366004)(136003)(6506007)(26005)(9686003)(64756008)(71200400001)(4326008)(8676002)(83380400001)(66946007)(66476007)(76116006)(478600001)(166002)(66556008)(110136005)(53546011)(55016002)(316002)(186003)(52536014)(7696005)(66446008)(5660300002)(33656002)(8936002)(9326002)(86362001)(2906002)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zcFdchXj123x4o/zBlBC0YH8LIAaeXxwsYySE6mg/5NKLBXMXFnbCDPklW1a5Vq8JtHhH9OtkLK5KmxY1WcO4v+jy2QUqrtFN5HFczWQLWob0Lz5AVBc2QpSIRcMSXdQv3M5pp1EUgAtocfjAxA/qMm9rsN8O2S2rie9XDbmUymS6omWZA/xc12kwNwBDF11Djk8sXZ7H4vRMBKN8AoMviT8TZrwK3NB1H4iPwVtQOXYqJlp+t8/joqDpUGTF/eCZusUij9tXALNlRpD0XikEkXx2eEEs69ZT86hluBx8gkvamHNdamQa33u+dnApzbxvloL4xqZLa6xgSIakk2Wi2sh/VGQc4kKN4VPkpHfwK+OPEknTxu7Nxo2qfHb1riMLSDipoksJwZGLZU9cdM5pfqIzssJpY3oLnno/oBJ5VYzxMKbc2IyYXVi4AqIrQyA1T4JqeslRksmeXJ8dpa3NMIK8eMKToV/jZJsfn7Pt558JBXrOf3gvmuTNy/CBAm/5NwuaFkQZSNIYb9uXAAz6Y7nuHxq3C8oaV/KPJ/P9ij6c4442bIK9y37ABEAgy9K3J3xdJenKccIHIMQmHyBhngoE+37KoE2EpQyOn75FeUYP+dpa+rMCAioIAUI3jScMYuJ2WJnqUfg57lUW24ox0qTnZVCXKmIPQB3hxkbm8UEB//+XFTcd+RCLa3++mOcvVtEMoXETj1iXkQ9k11Vx2xC2oUfd0XweU8KcmNlLjG3Eiy1D8oIjrjL4Dbp1Rkzyk8jySEaJ3NeYUm1+aN7gBN6sFBA38tI1wVG7IJ2525gy4tSwPTKx+vKQldke9AU7jlWkrZkBN4+R06fs9mGOs5Vc7fo1j5y3VgllYp3mzBZHPpPqMoO9HMzu76WYiquoXtvJUe23KvwLtaF6qg0hA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570F61EF1B19F636AFD671DC1E60MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2dda39b5-1ac7-4d3d-edb9-08d887c4fcdf X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 11:12:19.7723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TDVTXkhlVpoeEHzgZlvUHCgQXLoIZk8CFBZrViaOVli8KzNqSZgeyKWTsxDtDMyrS7QaaG92k8BbekLqbkEalA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1823 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 11:12:26 -0000 --_000_MW3PR11MB4570F61EF1B19F636AFD671DC1E60MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Giuseppe, First of all, thanks for making the updates to the document to clarify the = objective and applicability of IFIT and this draft extensions specifically = to the SR Policy signalled by BGP. A good part of the puzzle is at least cl= earer to me now. Sec 3 says (and I am trying to paraphrase here - so please correct me), tha= t these IFIT attributes (new TLVs) are signalled via BGP along with the SR = Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for= that SR Policy. This way all traffic steered over that SR Policy with have= the IOAM and Alt Marking headers inserted on them. Is there a Spring WG document that describes the implications of actually h= ow this would get applied to the SR Policy forwarding planes (SR-MPLS and S= Rv6) and what types of Steering would be possible to be used for such SR Po= licies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-p= olicy-09#section-8). ? E.g. if a packet is arriving at the headend with a s= tack of labels and gets steered via BSID into such an SR Policy where "IFIT= is applied", how does that work? Sec 6 (SR Policy operations with IFIT Attributes) says the following: The validation of the individual fields of the IFIT Attributes sub-TLVs are handled by the SRPM (SR Policy Module). However, I am still missing a document that describes how these are actuall= y "handled" by the SRPM? I understand that there is a similar draft in PCE WG as well, but it is als= o missing this information. My concern is that we have documents for the protocol signaling mechanisms = for IFIT but I am not able to locate a document that describes how exactly = this information is going to get used/applied by SRPM. Please do point/clarify if I am missing something here. Thanks, Ketan From: Idr On Behalf Of Giuseppe Fioccola Sent: 02 November 2020 22:28 To: Susan Hares ; idr@ietf.org Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Dear Susan, All, I'm not aware of any IPR related to this draft. I also support its adoption= as coauthor. Best Regards, Giuseppe From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, November 2, 2020 6:57 AM To: idr@ietf.org Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04= .txt (11/1/2020 to 11/16/2020) This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.t= xt (11/2/2020 to 11/16/2020). The draft can be accessed at: https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/ The authors should provide IPR statements by 11/5/2020 so the IDR WG can co= nsider the IPR status in their decision. This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the= SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel typ= es. Within the IFIT sub-TLV value field, 5 sub-TLVs may be included (4 fo= r IOAM and 1 for Enhanced Alternate Marking). The IDR co-chairs thank the authors for their patience. The WG adoption ca= ll for this draft has been delayed by the process of switching shepherds fo= r BGP Tunnel Encaps draft. Many BESS and IDR drafts currently refer to the= BGP tunnel encapsulation drafts. In your review of this draft, please differentiate between the following: * Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing te= chnology, * Support/rejection of alternate marking as a IP routing technology, * Support/rejection of adding new sub-TLVS for SR Policy tunnel type of= BGP Tunnel Encap Attribute, and * Specific issues with the descriptions of these features in the draft. Cheers, Susan Hares --_000_MW3PR11MB4570F61EF1B19F636AFD671DC1E60MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Giusep= pe,

    &nbs= p;

    First of = all, thanks for making the updates to the document to clarify the objective= and applicability of IFIT and this draft extensions specifically to the SR= Policy signalled by BGP. A good part of the puzzle is at least clearer to me now.

    &nbs= p;

    Sec 3 say= s (and I am trying to paraphrase here – so please correct me), that t= hese IFIT attributes (new TLVs) are signalled via BGP along with the SR Pol= icy Candidate Path to “enable IOAM and Alternate Marking” mechanisms for that SR Policy. This way all traffic steered= over that SR Policy with have the IOAM and Alt Marking headers inserted on= them.

    &nbs= p;

    Is there = a Spring WG document that describes the implications of actually how this w= ould get applied to the SR Policy forwarding planes (SR-MPLS and SRv6) and = what types of Steering would be possible to be used for such SR Policies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#sec= tion-8). ? E.g. if a packet is arriving at the headend with a stack of = labels and gets steered via BSID into such an SR Policy where “IFIT i= s applied”, how does that work?

    &nbs= p;

    Sec 6 (SR= Policy operations with IFIT Attributes) says the following:

    &nbs= p;

    The validation of the individual fields of the= IFIT

       Attributes sub-TLVs are handled b= y the SRPM (SR Policy Module).

    &nbs= p;

    However, = I am still missing a document that describes how these are actually “= handled” by the SRPM?

    &nbs= p;

    I underst= and that there is a similar draft in PCE WG as well, but it is also missing= this information.

    &nbs= p;

    My concer= n is that we have documents for the protocol signaling mechanisms for IFIT = but I am not able to locate a document that describes how exactly this info= rmation is going to get used/applied by SRPM.

    &nbs= p;

    Please do= point/clarify if I am missing something here.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Idr <idr-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
    Sent: 02 November 2020 22:28
    To: Susan Hares <shares@ndzh.com>; idr@ietf.org
    Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Dear Su= san, All,

    I'm not= aware of any IPR related to this draft. I also support its adoption as coa= uthor.

    &n= bsp;

    Best Re= gards,

    &n= bsp;

    Giusepp= e

    &n= bsp;

    &n= bsp;

    From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares
    Sent: Monday, November 2, 2020 6:57 AM
    To: idr@ietf.org
    Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-= ifit-04.txt (11/1/2020 to 11/16/2020)

     

    This begins a 2 week WG adoptio= n call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

     

    The draft can be accessed at: <= o:p>

    https://datatracker.ietf.org/d= oc/draft-zhu-idr-bgp-ls-path-mtu/

     

    The authors should provide IPR = statements by 11/5/2020 so the IDR WG can consider the IPR status in their

    decision.

     

    This draft adds the IFIT sub-TL= V to the BGP Tunnel Encaps attribute for the SR policy tunnel type. This su= b-TLV is only valid for SR Policy tunnel types.  Within the IFIT  = ;sub-TLV value field, 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).   =

     

    The IDR co-chairs thank the aut= hors for their patience.  The WG adoption call for this draft has been= delayed by the process of switching shepherds for BGP Tunnel Encaps draft.=  Many BESS and IDR drafts currently refer to the BGP tunnel encapsulation drafts.

     

    In your review of this draft, p= lease differentiate between the following:

    • Support/rejection of In-situ Flow Telemetry (IFI= T) as a IP routing technology,
    • Support/rejection of alternate marking as a IP routing technology, &nb= sp;
    • Support/rejection of a= dding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute,= and   
    • Specific= issues with the descriptions of these features in the draft.

     

    Cheers, Susan Hares =

     

     

     

    --_000_MW3PR11MB4570F61EF1B19F636AFD671DC1E60MW3PR11MB4570namp_-- From nobody Fri Nov 13 07:31:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5173A0DC4 for ; Fri, 13 Nov 2020 07:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pqT5904MgZQJ for ; Fri, 13 Nov 2020 07:31:36 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 E37953A0DC1 for ; Fri, 13 Nov 2020 07:31:35 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id z16so9249655otq.6 for ; Fri, 13 Nov 2020 07:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:accept-language:content-language:mime-version; bh=WGiSw7j0R+BzWKOV07ZA/X0ADzT8u5yxwHdRPtMBcKw=; b=R4xV1SJYX905kg3/175xFTAppImbElVxAHMDx+FV+X+esX0TLz5hyUMnTFTTCHINgC U0bNTHSfXaW4HpsoiUET6FqHrSRbBPeBfEBfOY5io5V9ttghsJ5xfTnhHhQITsLBpLft YzFsHbp44mMdzUV4JDupLOZCdP0cyf6XYkKf9PT0k8eXm0C2YqtZOzYWPpqBcsgkKbrf lHqptxNllYTvP6TmTWQxFqmflDkCXNp0l2OKS1b7Ur6X8LfXHS3r7peXvYMOKiFJmceL o9uNGFivoF+Ee+J3kNhAFWX9ewmfkTr9p6IlmuPTTtpRXLMT5SxhB0bAuQNxC7Qkkyyc wXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:accept-language:content-language :mime-version; bh=WGiSw7j0R+BzWKOV07ZA/X0ADzT8u5yxwHdRPtMBcKw=; b=rPaBaJ8VJ1L2fDj8ZHbOOKytjOgVP3gzRfhUyfLnjOqV5Wl0zsVsJGtsjMALKJAhXY hRw13qFGDh/XaXzWgVzvSLxJjCsWm9nr7AfRUdtR87tCZc9LXaw/VRNpHeyqB8w5mxRa zLpHo+a0Z0khL4EwdxxwPp/x194ipOyuDu6/W4K2CnUyplUtbA17rgRYcCBCQ1Hulw60 62xC8YP8rQsr+wwG6hr7dw2ApQgKgQFvKN5TTXFu5cibTicBzDrhlz+SxOYcKISFGQB2 OEOSnkN3T8fluu7gdVPMqw6eIvShWpCX3VLNx9Pw2do2BNfdfuFF+joqm/SyJOgCB7Gu qPdw== X-Gm-Message-State: AOAM533w8EWBNiZ7vlZ6sAgt/kvSLTm6P3g6XeGLzb4z9hHEYh91+mh7 4JMkjH5U0jq2cu70I0kSvzM= X-Google-Smtp-Source: ABdhPJytrUgo45SGujA9xAvU01wh4R41MfQt87dnbrfEmz2Dgcf9b1c6TwvwpC2usoR3654rQpkYnA== X-Received: by 2002:a05:6830:22d2:: with SMTP id q18mr1733537otc.305.1605281489528; Fri, 13 Nov 2020 07:31:29 -0800 (PST) Received: from SN6PR1901MB2158.namprd19.prod.outlook.com ([2603:1036:805:3::5]) by smtp.gmail.com with ESMTPSA id w70sm1942216oiw.29.2020.11.13.07.31.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 07:31:28 -0800 (PST) From: Tarek Saad To: "Ketan Talaulikar (ketant)" , "Stone, Andrew (Nokia - CA/Ottawa)" , Vishnu Pavan Beeram CC: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt Thread-Index: ATAwMzc2qfPqQNapuJZk9Cc0Tdn5cw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 13 Nov 2020 15:31:26 +0000 Message-ID: References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <3E1EC667-7B17-45AC-9CDE-F121FB75F14B@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_SN6PR1901MB21584BB2FFD9F04A83A47491FCE60SN6PR1901MB2158_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 15:31:40 -0000 --_000_SN6PR1901MB21584BB2FFD9F04A83A47491FCE60SN6PR1901MB2158_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andrew/Ketan, It=92s fine to suggest a static allocation of such block of colors for use = in (example) dynamic instantiation of hierarchical SR policies =96 but this= needs to be configured on all potential headends to ensure device/controll= er consistency (or signaled via PCEP/other). In any case, I think the draft= can benefit of a statement to this matter. Regards, Tarek From: "Ketan Talaulikar (ketant)" Date: Friday, November 13, 2020 at 3:43 AM To: "Stone, Andrew (Nokia - CA/Ottawa)" , Tarek Saa= d , Vishnu Pavan Beeram Cc: "spring@ietf.org" Subject: RE: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Andrew/Tarek, Thanks again for this discussion and your inputs. I concur with Andrew that color is something that is left to the operator a= s part of their network design and not something to reserve or define a spe= cial range for. This is what would give the operator to choose the various = steering mechanisms and how and where to use them in their networks. Thanks, Ketan From: Stone, Andrew (Nokia - CA/Ottawa) Sent: 13 November 2020 04:42 To: Tarek Saad ; Ketan Talaulikar (ketant) ; Vishnu Pavan Beeram Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Tarek, Thanks for the comments. Small reply below. Thanks Andrew From: Tarek Saad > Date: Thursday, November 12, 2020 at 2:22 PM To: "Stone, Andrew (Nokia - CA/Ottawa)" >, "Ketan Talaulikar (ketant)" >, Vishnu Pavan Beer= am > Cc: "spring@ietf.org" > Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi all, See inline for some comments.. From: spring > on b= ehalf of "Stone, Andrew (Nokia - CA/Ottawa)" > Date: Wednesday, November 11, 2020 at 6:16 PM To: "Ketan Talaulikar (ketant)" >, Vishnu Pavan Beeram > Cc: "spring@ietf.org" > Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Ketan, Pavan, Good discussion. Just going to chip in some thoughts=85 One of the elements I personally like of the SR Policy model is that many C= andidate Paths may exist, but only one may be active and a candidate path c= ontains 1 or many SID lists. It=92s a simple parent/child - root/leaf tree = with very clear rules within the SR policy context instance. From my point = of view, what is being proposed in the -09 document still follows those rul= es and the general top-down tree behaviour. Despite the composite CP pointi= ng to a different SR Policy, that SR Policy still follows all of the same r= ules top down in its own isolated context. Compare that to say, having a ca= ndidate path contain a child that points to other candidate paths within th= e same SR Policy context: within the same context a child is pointing to a = sibling of its parent. The rules now have to bend slightly. As noted below,= some of the rules around what is considered an active candidate path would= need to change, since the constituents essentially are active (they=92re i= nstalled) despite not being thought of as being active. Note that the propo= sed new text below says =93The preference is ignored for each of the two co= nstituent candidate paths" which is also a new rule, however one could perh= aps work around that by just requiring the preference on the constituents b= e less preferred than any other standard or composite CP =96 but that raise= s its own troubles with multiple sources of provisioning =96 which leads to= a rule asking to ignore the preference. In summary, from my p.o.v new rule= s in the hierarchy would need to be introduced. Regarding steering into an SR Policy, yes, you burn colors in doing this (3= 2bits...) and it would require deploying an entirely dedicated SR Policy co= nstruct, and run the risk of steering =91other=92 traffic into that policy.= If this is a concern, would the composite SR Policies not be engineered in= a way where the color block used is designed to not be used elsewhere in t= he network for other purposes? [TS]: Today colors of SR Policies that are instantiated =93on-demand=94 or = instantiated via PCEP from a PCE are derived from the intent/service. With = the hierarchical SR policies proposal, a PCE may need to instantiate the co= lored child SR policies on-demand too, but it is not clear where the colors= of those child SR policies would be derived from. As Andrew suggests, a bl= ock of colors could be carved from every headend=92s space -- specifically = for this purpose and be managed by the PCE. Alternatively, one could consid= er creating such SR Policies with a special/reserved color that would simpl= ify their creation. My understanding is that there are other cases where SR= Policies may be instantiated (e.g. for tactical TE =96 e.g. on P nodes) th= at would not require color resolution, and creation of those could benefit = from a reserved color too. [Andrew] Good point indeed. The P node is what I was pointing at with the B= SID example, where, for example, we=92ll have to burn a color to deploy a S= R Policy on a transit node when the consumer intent is simply for the BSID.= That color selection would need to be considered =91special=92 and taken f= rom a unique block if one wants to avoid using it for head-end steering on = that P node. Noting that color is part of what uniqueness, to define the = =93not for steering=94 behaviour, it would need to be a reserved block or b= it encoded in color as opposed to a single special value. I=92m not sure a = special range needs to be IETF standardized or simply left to implementatio= ns/PCE / network design to allocate and enforce. It seems that the model to= steer an SR Policy candidate path into another SR Policy with either color= or the concept of a special color still seems feasible in the present docu= ment. It might be worth having text describing that a constituent candidate= path may be used for steering on the headend, and if intention is to avoid= that then the user/pce/network design should allocate a block of values fo= r constituent candidate paths and select only from that block, not to be us= ed on any other routes in the network. Regards, Tarek Is there not a different but kind of similar problem with Binding SIDs, in = that they=92re eligible for use by other consumers even if not directly int= ended? (although at least BSIDs are optional and not mandatory). In additio= n to the split TE cases, being able to have an SR Policy steer into another= SR Policy might also have some value in a backup candidate scenario when o= ne has multiple SR Policies with the same endpoint, but can share a common = fallback/best effort candidate path. The entity (I'm thinking PCE) managing= that would only need to maintain the fallback/best effort CP SID list(s), = instead of one for each N * CPs. Something I haven=92t concluded to myself yet are questions such as: 1. does having a candidate path steer into another SR Policy satisfy = the ability to do various sub-path specific TE/constraint/object combinatio= ns sufficiently? 2. is the model relatively straight forward to map into yang/bgp/pcep= etc..? 3. does using an additional SR Policy create too much overhead or sta= te burn to configure, deploy, manage, track etc.. ? Cheers Andrew From: spring > on b= ehalf of "Ketan Talaulikar (ketant)" > Date: Tuesday, November 10, 2020 at 10:33 PM To: Vishnu Pavan Beeram > Cc: "spring@ietf.org" > Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Hi Pavan, Please check inline below. From: Vishnu Pavan Beeram > Sent: 11 November 2020 00:26 To: Ketan Talaulikar (ketant) > Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Ketan, Hi! Please see inline for responses (prefixed VPB). Regards, -Pavan On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) > wrote: Hi Pavan, Please check inline below. From: Vishnu Pavan Beeram > Sent: 10 November 2020 00:08 To: Ketan Talaulikar (ketant) > Cc: spring@ietf.org Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-= 09.txt Ketan, Much Thanks for taking a stab at addressing the composite candidate path us= e-case! We seem to be converging. [KT] Thanks for that feedback and confirmation that the proposal in the dra= ft does address the use-case. I believe we are now discussing the mechanics= of how this is achieved within the current SR Policy framework. However, I don=92t understand why you need to use additional SR policies (a= nd unnecessarily burn additional colors) to address this. [KT] I do not follow what you mean by =93burn additional colors=94. Color i= s just a 32 bit number that indicates the =93intent=94 and is not really a = scarce resource. Assigning a color to =93a composite intent=94 seems like a= seamless way to integrate with existing mechanisms for Steering over SR Po= licies. This gives the flexibility for say some BGP services to be steered = over the constituent explicit/dynamic intent while others can steer over a = composite intent that includes those individual explicit/dynamic intents. [VPB] The =93flexibility=94 that you are referring to is undesirable for th= is use-case. For the traffic-split use-case, we don=92t want any other serv= ices to be directly steered over the constituents when they are part of a c= omposite candidate path. [KT] I believe the use-case that you are referring to was for splitting som= e traffic for a service over a blue plane and the rest over a red plane. At= the same time, there may be other services that utilize only a single plan= e. The flexibility that I was referring to was to enable/allow for either o= f the two scenarios and there may be other/more use-cases for which we need= a more generic framework. The current proposal in the draft would have been acceptable if the constit= uent SR Policies were uncolored =96 but that would violate the current rule= s imposed by the draft. Why can=92t the composite candidate path just be a grouping of explicit can= didate paths and/or dynamic candidate paths? [KT] This is because in the SR Policy framework, there is only a single act= ive CP =96 it may be explicit or dynamic. Now we=92ve added another Composi= te CP type to cover this specific use-case. Your proposal will result in 3 = candidate paths being active within the same SR Policy =96 one each of the = explicit and dynamic CP and then additionally the Composite CP. This breaks= the existing rules for selection of CP based on preference and mechanisms = like fallback between CPs. While the current proposal in the draft provides= a way to address the new use-case with a backwards compatible extension to= the SR Policy framework. [VPB] The proposal in my previous email is backwards compatible and does no= t intend to break any existing rules for deeming a candidate path active. A= s per the rules that are outlined in Section 2.9, only the composite candid= ate path is =93active=94 given its preference. The constituent candidate pa= ths will never be active on their own. If it is necessary, we can add a sta= tement in Section 2.9 to explicitly state that the candidate path selection= criteria does not apply to the constituent candidate paths. [KT] When a CP is =93active=94 it is actually the one that is being used fo= r forwarding. Thanks, Ketan Thanks, Ketan Consider the following changes: ** Section 2.2 OLD: A composite candidate path acts as a container for grouping of SR Policies. The composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies. The following criteria apply for inclusion of constituent SR Policies using a composite candidate path under a parent SR Policy: o the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical o The colors of each of the constituent SR Policies and the parent SR Policy MUST be different o the constituent SR Policies MUST NOT use composite candidate paths Each constituent SR Policy of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. NEW: A composite candidate path acts as a container for grouping of explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints. The composite candidate path construct enables load-balanced steering of packet-flows over a set of constituent candidate paths. The following criteria apply for constituent candidate paths under a composite candidate path: o the preference of the constituent candidate path MUST be ignored. o the constituent candidate path MUST NOT be a composite candidate path Each constituent candidate path of a composite candidate path is associated with a weight for load-balancing purposes (refer Section 2.11 for details). The default weight is 1. ** ** Section 2.11 OLD: When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load balancing of flows steered into a constituent SR Policy is performed based on the weights of the Segment-List of the active candidate path of that constituent SR Policy. NEW: When a composite candidate path is active, the fraction of flows steered into each constituent candidate path is equal to the relative weight of each constituent candidate path. Further load balancing of flows steered into a constituent candidate path is performed based on the weights of each associated Segment-List. ** ** Section 2.13 OLD: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path CP1 Preference 200 Weight W1, SR policy Weight W2, SR policy The constituent SR Policies POL1 and POL2 have information model as described at the start of this section. They are referenced only by color in the composite candidate path since their headend and endpoint are identical to the POL100. The valid Segment-Lists of the active candidate path of POL1 and POL2 are installed in the forwarding. Traffic steered on POL100 is flow-based hashed on POL1 with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. NEW: The information model of SR Policy POL100 having a composite candidate path is the following: SR policy POL100 Candidate-path Comp-CP Preference 200 Weight W1, Candidate-path CP1 Weight W2, Candidate-path CP2 Candidate-path CP1 Weight W11, SID-List1 Weight W12, SID-List2 Candidate-path CP2 Weight W21, SID-List3 Weight W22, SID-List4 Comp-CP is a composite candidate path with two constituents, CP1 and CP2. The preference is ignored for each of the two constituent candidate paths. The valid Segment-Lists of the two constituent candidate paths are installed in the forwarding. Traffic steered on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent candidate path, the flow-based hashing over its Segment-Lists are performed as described earlier in this section. ** ** Section 5.3 OLD: A composite candidate path is specified as a group of its constituent SR Policies. A composite candidate path is valid when it has at least one valid constituent SR Policy. NEW: A composite candidate path is specified as a group of its constituent candidate paths. A composite candidate path is valid when it has at least one valid constituent candidate path. ** Regards, -Pavan On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) > wrote: Hello All, We have just posted an update for the draft and following is the summary of= changes: 1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring= /fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spr= ing/d9oSSbgp0jCExRx0SXyBY0CyqXU/) 2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08. 3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received. 4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHD= N0IvFhw9id40/) Please let know your comments/feedback. Thanks, Ketan (on behalf of co-authors) -----Original Message----- From: spring > On B= ehalf Of internet-drafts@ietf.org Sent: 02 November 2020 06:27 To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking WG of = the IETF. Title : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-09.txt Pages : 37 Date : 2020-11-01 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-polic= y-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_SN6PR1901MB21584BB2FFD9F04A83A47491FCE60SN6PR1901MB2158_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Andrew/Ketan,

     

    It=92s fine to sugg= est a static allocation of such block of colors for use in (example) dynami= c instantiation of hierarchical SR policies =96 but this needs to be config= ured on all potential headends to ensure device/controller consistency (or signaled via PCEP/other). In any case, I= think the draft can benefit of a statement to this matter.

     

    Regards,=

    Tarek

     

     

    From: "Ketan Talauli= kar (ketant)" <ketant@cisco.com>
    Date: Friday, November 13, 2020 at 3:43 AM
    To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@n= okia.com>, Tarek Saad <tsaad.net@gmail.com>, Vishnu Pavan Beeram &= lt;vishnupavan@gmail.com>
    Cc: "spring@ietf.org" <spring@ietf.org>
    Subject: RE: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Hi Andrew/Tarek,

     

    Thanks again for this dis= cussion and your inputs.

     

    I concur with Andrew that= color is something that is left to the operator as part of their network d= esign and not something to reserve or define a special range for. This is w= hat would give the operator to choose the various steering mechanisms and how and where to use them in their net= works.

     

    Thanks,

    Ketan

     

    From: Stone, Andre= w (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
    Sent: 13 November 2020 04:42
    To: Tarek Saad <tsaad.net@gmail.com>; Ketan Talaulikar (ketant= ) <ketant@cisco.com>; Vishnu Pavan Beeram <vishnupavan@gmail.com&g= t;
    Cc: spring@ietf.org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

     

    Hi T= arek,

    &nbs= p;

    Than= ks for the comments. Small reply below.

    &nbs= p;

    Than= ks

    Andr= ew

    &nbs= p;

    From: Tare= k Saad <tsaad.net@gmail.com&g= t;
    Date: Thursday, November 12, 2020 at 2:22 PM
    To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>, "Ketan Tal= aulikar (ketant)" <ketant=3D40cisco.com@dmarc.ietf.org>, Vishnu Pavan Beeram <vishnupavan@gmail.com>=
    Cc: "spring@ietf.org&quo= t; <spring@ietf.org>
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    &nbs= p;

    Hi all,

     

    See inline for some comments..

     

    From: spri= ng <spring-bounces@ietf.org> on behalf of "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
    Date: Wednesday, November 11, 2020 at 6:16 PM
    To: "Ketan Talaulikar (ketant)" <ketant=3D40cisco.com@dmarc.ietf.org>= ;, Vishnu Pavan Beeram <vishnup= avan@gmail.com>
    Cc: "spring@ietf.org&quo= t; <spring@ietf.org>
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    &nb= sp;

    Hi = Ketan, Pavan,

    &nb= sp;

    Goo= d discussion. Just going to chip in some thoughts=85

    &nb= sp;

    One= of the elements I personally like of the SR Policy model is that many Cand= idate Paths may exist, but only one may be active and a candidate path cont= ains 1 or many SID lists. It=92s a simple parent/child - root/leaf tree with very clear rules within the SR policy c= ontext instance. From my point of view, what is being proposed in the -09 d= ocument still follows those rules and the general top-down tree behaviour. = Despite the composite CP pointing to a different SR Policy, that SR Policy still follows all of the same rul= es top down in its own isolated context. Compare that to say, having a cand= idate path contain a child that points to other candidate paths within the = same SR Policy context: within the same context a child is pointing to a sibling of its parent. The rules now= have to bend slightly. As noted below, some of the rules around what is co= nsidered an active candidate path would need to change, since the constitue= nts essentially are active (they=92re installed) despite not being thought of as being active. Note that the pro= posed new text below says =93The preference is ignored for each of the two = constituent candidate paths" which is also a new rule, however one cou= ld perhaps work around that by just requiring the preference on the constituents be less preferred than any other standa= rd or composite CP =96 but that raises its own troubles with multiple sourc= es of provisioning =96 which leads to a rule asking to ignore the preferenc= e. In summary, from my p.o.v new rules in the hierarchy would need to be introduced.

    &nb= sp;

    Reg= arding steering into an SR Policy, yes, you burn colors in doing this (32bi= ts...) and it would require deploying an entirely dedicated SR Policy const= ruct, and run the risk of steering =91other=92 traffic into that policy. If this is a concern, would the composite SR Pol= icies not be engineered in a way where the color block used is designed to = not be used elsewhere in the network for other purposes?<= /p>

    [TS]: Today colors of SR Policies that are instantia= ted =93on-demand=94 or instantiated via PCEP from a PCE are derived from th= e intent/service. With the hierarchical SR policies proposal, a PCE may need to instantiate the colored child SR policies on-d= emand too, but it is not clear where the colors of those child SR policies = would be derived from. As Andrew suggests, a block of colors could be carve= d from every headend=92s space -- specifically for this purpose and be managed by the PCE. Alternatively, on= e could consider creating such SR Policies with a special/reserved color th= at would simplify their creation. My understanding is that there are other = cases where SR Policies may be instantiated (e.g. for tactical TE =96 e.g. on P nodes) that would not require color re= solution, and creation of those could benefit from a reserved color too.

     

    &nbs= p;

    [And= rew] Good point indeed. The P node is what I was pointing at with the BSID = example, where, for example, we=92ll have to burn a color to deploy a SR Po= licy on a transit node when the consumer intent is simply for the BSID. That color selection would need to be consi= dered =91special=92 and taken from a unique block if one wants to avoid usi= ng it for head-end steering on that P node.  Noting that color is part= of what uniqueness, to define the =93not for steering=94 behaviour, it would need to be a reserved block or bit encoded= in color as opposed to a single special value. I=92m not sure a special ra= nge needs to be IETF standardized or simply left to implementations/PCE / n= etwork design to allocate and enforce. It seems that the model to steer an SR Policy candidate path into another = SR Policy with either color or the concept of a special color still seems f= easible in the present document. It might be worth having text describing t= hat a constituent candidate path may be used for steering on the headend, and if intention is to avoid that= then the user/pce/network design should allocate a block of values for con= stituent candidate paths and select only from that block, not to be used on= any other routes in the network.

    &nbs= p;

     

    Regards,

    Tarek

     

     

     

    Is = there not a different but kind of similar problem with Binding SIDs, in tha= t they=92re eligible for use by other consumers even if not directly intend= ed? (although at least BSIDs are optional and not mandatory). In addition to the split TE cases, being able to have = an SR Policy steer into another SR Policy might also have some value in a b= ackup candidate scenario when one has multiple SR Policies with the same en= dpoint, but can share a common fallback/best effort candidate path. The entity (I'm thinking PCE) managing that = would only need to maintain the fallback/best effort CP SID list(s), instea= d of one for each N * CPs.

    &nb= sp;

    Som= ething I haven=92t concluded to myself yet are questions such as:

    &nb= sp;

    1.       does having a candidate path s= teer into another SR Policy satisfy the ability to do various sub-path spec= ific TE/constraint/object combinations sufficiently?

    2.       is the model relatively straig= ht forward to map into yang/bgp/pcep etc..?

    3.       does using an additional SR Po= licy create too much overhead or state burn to configure, deploy, manage, t= rack etc.. ?

    &nb= sp;

    Che= ers

    And= rew

    &nb= sp;

    From: spri= ng <spring-bounces@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <ketant=3D40cisco.com@dmarc.ietf.o= rg>
    Date: Tuesday, November 10, 2020 at 10:33 PM
    To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Cc: "spring@ietf.org&quo= t; <spring@ietf.org>
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    &nb= sp;

    Hi = Pavan,

    &nb= sp;

    Ple= ase check inline below.

    &nb= sp;

    = From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Sent: 11 November 2020 00:26
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf.org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    &nb= sp;

    Ket= an, Hi!

    Please see inline for responses (prefixed VPB).

    Regards,
    -Pavan

    &nb= sp;

    On = Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:

    Hi = Pavan,

    &nb= sp;

    Ple= ase check inline below.

    &nb= sp;

    = From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
    Sent: 10 November 2020 00:08
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf= .org
    Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-= policy-09.txt

    &nb= sp;

    Ketan,

     

    Much Thanks for= taking a stab at addressing the composite candidate path use-case! We seem= to be converging.

    [KT] Thanks for that feedback and confirmation that the proposal in the = draft does address the use-case. I believe we are now discussing the mechan= ics of how this is achieved within the current SR Policy framework. 

     

    However, I don=92t understand why you n= eed to use additional SR policies (and unnecessarily burn additional colors= ) to address this.

    [KT] I do not follow what you mean by =93burn additional colors=94. Colo= r is just a 32 bit number that indicates the =93intent=94 and is not really= a scarce resource. Assigning a color to =93a composite intent=94 seems like a seamless way to integrate with existing mechanisms = for Steering over SR Policies. This gives the flexibility for say some BGP = services to be steered over the constituent explicit/dynamic intent while o= thers can steer over a composite intent that includes those individual explicit/dynamic intents.

    &nb= sp;

    [VP= B] The =93flexibility=94 that you are referring to is undesirable for this = use-case. For the traffic-split use-case, we don=92t want any other service= s to be directly steered over the constituents when they are part of a composite candidate path.

    [KT] I believe the use-case that you are referri= ng to was for splitting some traffic for a service over a blue plane and th= e rest over a red plane. At the same time, there may be other services that utilize only a single plane. The flexibil= ity that I was referring to was to enable/allow for either of the two scena= rios and there may be other/more use-cases for which we need a more generic= framework.

    &nb= sp;

    The= current proposal in the draft would have been acceptable if the constituen= t SR Policies were uncolored =96 but that would violate the current rules i= mposed by the draft. 

    &nb= sp;

     

    Why can=92t the composite candidate pat= h just be a grouping of explicit candidate paths and/or dynamic candidate p= aths?

    [KT] This is because in the SR Policy framework, there is only a single = active CP =96 it may be explicit or dynamic. Now we=92ve added another Comp= osite CP type to cover this specific use-case. Your proposal will result in 3 candidate paths being active within the sam= e SR Policy =96 one each of the explicit and dynamic CP and then additional= ly the Composite CP. This breaks the existing rules for selection of CP bas= ed on preference and mechanisms like fallback between CPs. While the current proposal in the draft provides a w= ay to address the new use-case with a backwards compatible extension to the= SR Policy framework.

    &nb= sp;

    [VP= B] The proposal in my previous email is backwards compatible and does not i= ntend to break any existing rules for deeming a candidate path active. As p= er the rules that are outlined in Section 2.9, only the composite candidate path is =93active=94 given its preferenc= e. The constituent candidate paths will never be active on their own. If it= is necessary, we can add a statement in Section 2.9 to explicitly state th= at the candidate path selection criteria does not apply to the constituent candidate paths. 

    [KT] When a CP is =93active=94 it is actually th= e one that is being used for forwarding.

     

    Thanks,

    Ketan

    &nb= sp;

     

    Thanks,

    Ketan

     

    Consider the fo= llowing changes:

     

    ** Section 2.2<= /span>

    OLD:

       A =
composite candidate path acts as a container for grouping of SR=

       Po=
licies.  The composite candidate path construct enables combination
       of=
 SR Policies, each with explicit candidate paths and/or dynamic=

       ca=
ndidate paths with potentially different optimization objectives
       an=
d constraints, for a load-balanced steering of packet flows over
       it=
s constituent SR Policies.  The following criteria apply for
       in=
clusion of constituent SR Policies using a composite candidate path<=
o:p>
       un=
der a parent SR Policy:
     
       o&=
nbsp; the endpoints of the constituent SR Policies and the parent SR=

      &nb=
sp;   Policy MUST be identical
     
       o&=
nbsp; The colors of each of the constituent SR Policies and the parent
      &nb=
sp;   SR Policy MUST be different
     
       o&=
nbsp; the constituent SR Policies MUST NOT use composite candidate paths
     
       Ea=
ch constituent SR Policy of a composite candidate path is=

       as=
sociated with a weight for load-balancing purposes (refer=

       Section=
 2.11 for details).  The default weight is 1.
     
    NEW:
       A =
composite candidate path acts as a container for grouping of
       ex=
plicit candidate paths and/or dynamic candidate paths with 
      &nb=
sp;potentially different optimization objectives and constraints.
       Th=
e composite candidate path construct enables load-balanced
       st=
eering of packet-flows over a set of constituent candidate
       pa=
ths. The following criteria apply for constituent candidate 
       paths under a composite candidate path:
     
       o&=
nbsp; the preference of the constituent candidate path MUST be =

          ignored. 
     
       o&=
nbsp; the constituent candidate path MUST NOT be a composite candidate 
      &nb=
sp;   path
     
       Ea=
ch constituent candidate path of a composite candidate path is<=
/o:p>
       as=
sociated with a weight for load-balancing purposes (refer=

       Section=
 2.11 for details).  The default weight is 1.
     
    **
     
    ** Section 2.11
     
    OLD:

       When a composite candidate path is= active, the fraction of flows

       steered into each constituent SR P= olicy is equal to the relative

       weight of each constituent SR Poli= cy.  Further load balancing of

       flows steered into a constituent S= R Policy is performed based on the

       weights of the Segment-List of the= active candidate path of that

       constituent SR Policy.= 

     
    NEW:

       When a composite candidate path is= active, the fraction of flows

       steered into each constituent cand= idate path is equal to the relative

       weight of each constituent candida= te path.  Further load balancing of

       flows steered into a constituent c= andidate path is performed based on

       the weights of each associated Seg= ment-List.

     

    **
     
    ** Section 2.13
     
    OLD:

       The information model of SR Policy= POL100 having a composite

       candidate path is the following:

     

       SR policy POL100 <headend =3D H= 1, color =3D 100, endpoint =3D E1>

            Can= didate-path CP1 <protocol-origin =3D 20, originator =3D

       100:1.1.1.1, discriminator =3D 1&g= t;

             =    Preference 200

             =    Weight W1, SR policy <color =3D 1>

             =    Weight W2, SR policy <color =3D 2>

     

       The constituent SR Policies POL1 a= nd POL2 have information model as

       described at the start of this sec= tion.  They are referenced only by

       color in the composite candidate p= ath since their headend and

       endpoint are identical to the POL1= 00.  The valid Segment-Lists of the

       active candidate path of POL1 and = POL2 are installed in the

       forwarding.  Traffic s= teered on POL100 is flow-based hashed on POL1

       with a ratio W1/(W1+W2).  Within the POL1, the flow-based hashing

       over its Segment-Lists are perform= ed as described earlier in this

       section.

     
    NEW:

       The information model of SR Policy= POL100 having a composite

       candidate path is the following:

     

       SR policy POL100 <headend =3D H= 1, color =3D 100, endpoint =3D E1>

    &nb= sp;       Candidate-path Comp-CP <p= rotocol-origin =3D 20, originator =3D

       100:1.1.1.1, discriminator =3D 1&g= t;

             =    Preference 200

    &nb= sp;           Wei= ght W1, Candidate-path CP1

             =    Weight W2, Candidate-path CP2    &n= bsp;&= nbsp;

            Can= didate-path CP1 <protocol-origin =3D 20, originator =3D

    &nb= sp;  100:1.1.1.1, discriminator =3D 2>

    &nb= sp;            Weight W11, SID-List1 <SID11...SID1i>

             =     Weight W12, SID-List2 <SID21...SID2j>

    &nb= sp;       Candidate-path CP2 <protocol-ori= gin =3D 20, originator =3D

    &nb= sp;  100:1.1.1.1, discriminator =3D 3>

    &nb= sp;            Weight W21, SID-List3 <SID31...SID3i>

             =     Weight W22, SID-List4 <SID41...SID4j>

     

    &nb= sp;  Comp-CP is a composite candidate path with two constituents, CP1<= /span>

       and CP2. The preference is ignored= for each of the two constituent

    &nb= sp;  candidate paths. The valid Segment-Lists of the two consti= tuent

    &nb= sp;  candidate paths are installed in the forwarding. Traffic ste= ered

       on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of

       W1/(W1+W2) and W2/(W1+W2) respectively. W= ithin each constituent

    &nb= sp;  candidate path, the flow-based hashing over its Segment-Li= sts are

    &nb= sp;  performed as described earlier in this section.

    &nb= sp;

    **
     
    ** Section 5.3
     
    OLD:

       A composite candidate path is spec= ified as a group of its constituent

       SR Policies.

     

       A composite candidate path is vali= d when it has at least one valid

       constituent SR Policy.= 

     
    NEW:

       A composite candidate path is spec= ified as a group of its constituent

       candidate paths.=

     

       A composite candidate path is vali= d when it has at least one valid

       constituent candidate path.= 

     

    **<= /o:p>

     
    Regards,

    -Pavan
    

    
 
    

    &nb=
sp;

    &nb= sp;

    On = Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.= ietf.org> wrote:

    Hel= lo All,

    We have just posted an update for the draft and following is the summary of= changes:

    1) Introduction of the Composite Candidate Path construct to address a pend= ing comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
    2) Based on offline feedback received, updated SRv6 segment types to includ= e optional SRv6 SID and behavior instead of the new type that was introduce= d for it in the v08.
    3) Clarification of handling of colors and BGP multi-path scenarios based o= n offline feedback received.
    4) Clarification on considerations for TI-LFA for SR Policy as discussed in= the WG (Ref :     https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

    Please let know your comments/feedback.

    Thanks,
    Ketan (on behalf of co-authors)

    -----Original Message-----
    From: spring <    spring-bounces@ietf.org> On Behalf Of internet-draf= ts@ietf.org
    Sent: 02 November 2020 06:27
    To: i-d-announce= @ietf.org
    Cc: spring@ietf.org
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.t= xt


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

            Title           := Segment Routing Policy Architecture
            Authors         : Clar= ence Filsfils
                         = ;     Ketan Talaulikar
                         = ;     Daniel Voyer
                         = ;     Alex Bogdanov
                         = ;     Paul Mattes
            Filename        : draft-iet= f-spring-segment-routing-policy-09.txt
            Pages           := 37
            Date            := 2020-11-01

    Abstract:
       Segment Routing (SR) allows a headend node to steer a packet f= low
       along any path.  Intermediate per-flow states are elimina= ted thanks
       to source routing.  The headend node steers a flow into a= n SR Policy.
       The header of a packet steered in an SR Policy is augmented wi= th an
       ordered list of segments associated with that SR Policy. = This
       document details the concepts of SR Policy and steering into a= n SR
       Policy.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-spring-se= gment-routing-policy-09
    https://datatracker.ietf.org/doc/html/= draft-ietf-spring-segment-routing-policy-09

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-spring-segment-routing-policy-09


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

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


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

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

    --_000_SN6PR1901MB21584BB2FFD9F04A83A47491FCE60SN6PR1901MB2158_-- From nobody Fri Nov 13 20:05:36 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C943A1006; Fri, 13 Nov 2020 20:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fUICD095-2aB; Fri, 13 Nov 2020 20:05:33 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 3C42F3A0FF9; Fri, 13 Nov 2020 20:05:02 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 34so5399542pgp.10; Fri, 13 Nov 2020 20:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6+W1MrX51kVe2DfnFoJzgbJ2OrVoY6AXs6zJ5o2sJhI=; b=BWwk46RVKn6EBSNV6maWZBq5y1WkpbvxP1beqFAmwQYbcrDsfNYp2dIUGnzxZ8GHGP WzGpOP24q7cITySGAbL1+dT6SQPQYixqjFiqw1co5B9+XqUaBmjiw0762+4r8fWTVw/w YYfuQIJcuYths/foo8V1aqpDQkGty07PkAVg2oUmatFBbpblqi09j9SOqE++lIePp7pw IhnrNahAQQnBqFOSYd3PQAfzWfoD2H+tH7obHClVNtRqfNBruzL/t1JE5+HdKeXefd86 1sOuYHjlbDEKmOHXvuep0ejy/gBW7qZi1AmScel8OhQplSz4K3Ei46/HYBaiRjdwgUgh LXzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6+W1MrX51kVe2DfnFoJzgbJ2OrVoY6AXs6zJ5o2sJhI=; b=EqtKxNIJes+Zkg8BfEikcd9kndvjtkHzaizHOiFudpvR2UbnD3fviChZ4dclrxtR5D OnNA292HIxA5JelRusYordGwCnlghll5eMiFFBqj/Y/wLs1zWnrUEk3cHEseA8l2CfE5 J28MWHtpHrWyC43io3TcTjgiaSs0/gy7PHygNgXA1eBUUXWpzl4uOXTVzhu1zfhj/WrF DDW5VtbG3pb1TxU9oBUMZZkLMLOaQYsZu3M9tIfYAgXv3aowSuFK/PdGhdPppeUyZEVp 2ViK4rYqqfFSrYBOUABKYAToX3HF8QpwBIqDz8KOKg9o85LJ2acqoDevzGVGdaEodv7X 1w+g== X-Gm-Message-State: AOAM533NMLjZ3lTj4M5nvAobbvcrOtfmGkb3E2ujJu+X1Ae7+jKVe1+e ZefMVMH7VNbrH79klcZjFxyqnYhSf91BRg== X-Google-Smtp-Source: ABdhPJyyxaj9mS9L/mGrkgr66z/bZvQi7TLOaqSpaSso/Hki/2f28Ad9IBRjkc0Tgd7lAu6UHj97FA== X-Received: by 2002:a62:e40c:0:b029:18b:ad5:18a8 with SMTP id r12-20020a62e40c0000b029018b0ad518a8mr4660139pfh.16.1605326701444; Fri, 13 Nov 2020 20:05:01 -0800 (PST) Received: from ?IPv6:2400:2411:8900:0:754f:699f:402:9a3b? ([2400:2411:8900:0:754f:699f:402:9a3b]) by smtp.gmail.com with ESMTPSA id a81sm11214442pfd.178.2020.11.13.20.04.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 20:05:00 -0800 (PST) From: Satoru Matsushima Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0FDD36D1-6128-4EDE-9F34-1F40777003C1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 14 Nov 2020 13:04:58 +0900 In-Reply-To: Cc: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 04:05:36 -0000 --Apple-Mail=_0FDD36D1-6128-4EDE-9F34-1F40777003C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Support this adoption. Cheers, --satoru > 2020/10/22 21:51=E3=80=81James Guichard = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Dear WG: > =20 > This message starts a 3 week WG adoption call for = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 = , ending = November 12th 2020. Please note that this document has several changes = from v-02 that were requested by the SPRING and IPPM chairs. For this = reason, the chairs have extended the adoption call for an additional = week to allow the WG enough time to review these changes before deciding = on WG adoption. > =20 > Some background: =20 > =20 > Several review comments were received previously for document = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 = . The = SPRING and IPPM chairs considered those comments, and upon review of = this version of the document, determined the following: > =20 > The SPRING document should describe only the procedures relevant to = SPRING with pointers to non-SPRING document/s that define any = extensions. Several extensions including Control Code Field Extension = for STAMP Messages, Loss Measurement Query Message Extensions, Loss = Measurement Response Message Extensions, Node Address TLV Extensions, = and Return Path TLV Extensions were included in = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 = and = should be removed from the SPRING document. > The STAMP extensions included in = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 = should = be described in a new document published in the IPPM WG. =20 > =20 > These conclusions were discussed with the authors of = https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 = the = result of which is the publication of the following two documents: > =20 > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 = . The = subject of this WG adoption call. > https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 = . This = document will be progressed (if determined by the WG) within the IPPM = WG. > =20 > After review of the SPRING document please indicate support (or not) = for WG adoption to the mailing list. Please also provide = comments/reasons for that support (or lack thereof) as silence will not = be considered as consent. > =20 > Finally, the chairs would like to thank the authors for their efforts = in this matter. > =20 > Thanks! > =20 > Jim, Bruno, & Joel > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_0FDD36D1-6128-4EDE-9F34-1F40777003C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Support this adoption.

    Cheers,
    Date: 2020-11-04&= nbsp;01:39
    Subject: [spring] WG Adoption Call fo= r draft-li-spring-srv6-path-segment
    =0A=0A=0A=0A=0A
    =0A

    Dear WG:

    =0A

     =0A

    This message starts a 3 we= ek WG adoption call for=0Ahttps://tools.ietf.org/html/draft-li-spring-srv6-path-seg= ment-07, ending November 24th 2020. Please note that this d= ocument has several changes from v-06 that were requested=0A by the SPRING= chairs. For this reason, the chairs have extended the adoption call for a= n additional week to allow the WG enough time to review these changes befo= re deciding on WG adoption.=0A

    =0A

     

    =0A

    Af= ter review of the document please indicate support (or not) for WG adoptio= n to the mailing list.=0APlease also provide comments/reasons for that support (or = lack thereof) as silence will not be considered as consent.

    =0A

     

    =0A

    Thanks!<= /span>

    =0A

     

    =0A

    = Jim, Bruno &= Joel

    =0A

     

    =0A

     =0A

     

    =0A

    =  

    =0A

     

    =0A=0A
    --satoru

    2020/10/22= 21:51=E3=80=81James Guichard <james.n.guichard@futurewei.com>=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB:

    Dear WG:
     
    This message starts a 3 week WG adoption call = for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending November 12th 2020. Please note that this = document has several changes from v-02 that were requested by the SPRING = and IPPM chairs. For this reason, the chairs have extended the adoption = call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.
     
    Some background:  
     
    Several review comments = were received previously for document https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chairs considered those comments, and = upon review of this version of the document, determined the = following:
     
     
    These = conclusions were discussed with the authors of https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result of which = is the publication of the following two documents:
     
     
    After review of the SPRING document please indicate support = (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or = lack thereof) as silence will not be considered as consent.
     
    Finally, the chairs would like to thank the authors for their = efforts in this matter.
     
    Thanks!
     
    Jim, Bruno, & Joel
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_0FDD36D1-6128-4EDE-9F34-1F40777003C1-- From nobody Fri Nov 13 20:06:08 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045BF3A0EAD; Fri, 13 Nov 2020 20:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CQgfLPrJeibt; Fri, 13 Nov 2020 20:06:04 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 08B883A0FF9; Fri, 13 Nov 2020 20:06:03 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id gv24so1267306pjb.3; Fri, 13 Nov 2020 20:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JLHGHVMKuS34Fs4b/8vZQvjeOIpN+MaGUFLaEfkREw4=; b=IBh6dV/rlUd3OXQ0BBzJ+LUYrHDAcrRsuwJLZVUi3Zv9JQkHg3nB0496S03qsqBuRE tL7U2UDOCzBqqk/wTeMXaUqWo8gj01kKfJ2kqvkRKWooGwaU/prcEWgoaJ+48IcoLY6c D7UQAifCT1EvMV2Ag3sUnyGF2jGxJUS+jm+l5qIrXlrP0tTGYbfJnk2xr1NvrjxVJ9z2 Fd5IhNWAWoUJ0lJ/kV6Lhk00i1oDAcLIFLVnBqfqW/4GqaMKT5QFfF5846KdBz3WEeO/ mBH6YoFdQvrTtGEw1fOUvJfawPKfxnXYyHFb7fNS3wMQlePVyOScoS52cfbcIMqjL9ET qVXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JLHGHVMKuS34Fs4b/8vZQvjeOIpN+MaGUFLaEfkREw4=; b=H2LjBi7umQl9BpVRML60uwPNa8noVFrRygoI0ncEBoo2Nh/HkDHX8OfZ7JUBRm2w68 tUqaZoZeL2pt4Sb16TVJDhmBxnUcvzBWR2Lzwb6H+hVT/KD9JQy5S6WqBuDyL3ssC8jq zJgSuUIQH3EVBSSOH9KkAMqByI1HmCKmOTD8/SwYu+mnpcNXblG5xCm0ZKJO9dIYWTnd H/bMXovHdN8iPTM6blVg8Z1DRRZJ+wQkC9dDPLJbsh+XWezVkUTnvR6MD2KKqNkKYxBe dglZNoNH8OHbblCigadJb1Fi4Rb6ySHb8+rIaxzog/MJkl3nj40MgGBKg+mNrjjKdACO H4cA== X-Gm-Message-State: AOAM530cQEASEzHRvRAQDawF0vz2gKaVSPXaT0xWLqJONotLH+w55YhC O0W5qCzaLV4OV/J3k+chQnv52eHqGpqvSg== X-Google-Smtp-Source: ABdhPJzesZhyc6H+K9JJWEdHFQ3Hpi6TzcBMt3x5orCoV1ZxKyCbyJ9OIFLuR4AFoQn9YcnnLUnZcw== X-Received: by 2002:a17:90a:6e4a:: with SMTP id s10mr6397615pjm.58.1605326763274; Fri, 13 Nov 2020 20:06:03 -0800 (PST) Received: from ?IPv6:2400:2411:8900:0:754f:699f:402:9a3b? ([2400:2411:8900:0:754f:699f:402:9a3b]) by smtp.gmail.com with ESMTPSA id a81sm11214442pfd.178.2020.11.13.20.06.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 20:06:02 -0800 (PST) From: Satoru Matsushima Message-Id: <60E42BC2-6F0C-48A2-B8D7-F8152098E759@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B7DE9A99-C4CE-4218-8EC8-BFFE55E91014" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 14 Nov 2020 13:06:01 +0900 In-Reply-To: Cc: "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 04:06:06 -0000 --Apple-Mail=_B7DE9A99-C4CE-4218-8EC8-BFFE55E91014 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Support this adoption too. Cheers, --satoru > 2020/10/22 21:51=E3=80=81James Guichard = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Dear WG: > =20 > This message starts a 3 week WG adoption call for document = https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 = ending = November 12th 2020. Please note that this document has several changes = from v-10 that were requested by the SPRING and IPPM chairs. For this = reason, the chairs have extended the adoption call for an additional = week to allow the WG enough time to review these changes before deciding = on WG adoption. > =20 > Some background: =20 > =20 > Several review comments were received previously for document = https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 = . The = SPRING and IPPM chairs considered those comments, and upon review of = this version of the document, determined the following: > =20 > The SPRING document should describe only the procedures relevant to = SPRING with pointers to non-SPRING document/s that define any = extensions. Several extensions including Control Code Field Extension = for TWAMP Light Messages, Loss Measurement Query Message Extensions, and = Loss Measurement Response Message Extensions were included = inhttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 = and = should be removed from the SPRING document. > The TWAMP extensions included in = https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 = should = be described in a new document published in the IPPM WG. =20 > =20 > These conclusions were discussed with the authors of = https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 = the = result of which is the publication of the following two documents: > =20 > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 = . The = subject of this WG adoption call. > https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 = . This = document will be progressed (if determined by the WG) within the IPPM = WG. > =20 > After review of the SPRING document please indicate support (or not) = for WG adoption to the mailing list. Please also provide = comments/reasons for that support (or lack thereof) as silence will not = be considered as consent. > =20 > Finally, the chairs would like to thank the authors for their efforts = in this matter. > =20 > Thanks! > =20 > Jim, Bruno, & Joel > =20 > =20 > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_B7DE9A99-C4CE-4218-8EC8-BFFE55E91014 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Support this adoption too.

    Cheers,
    --satoru

    2020/10/22 21:51=E3=80=81James Guichard <james.n.guichard@futurewei.com>=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB:

    Dear WG:
     
    This message starts a 3 week WG adoption call = for document https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11ending November 12th 2020. Please note that this = document has several changes from v-10 that were requested by the SPRING = and IPPM chairs. For this reason, the chairs have extended the adoption = call for an additional week to allow the WG enough time to review these = changes before deciding on WG adoption.
     
    Some background:  
     
    Several review comments = were received previously for document https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and = upon review of this version of the document, determined the = following:
     
     
    These = conclusions were discussed with the authors of  https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result of which = is the publication of the following two documents:
     
     
    After review of the SPRING document please indicate support = (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or = lack thereof) as silence will not be considered as consent.
     
    Finally, the chairs would like to thank the authors for their = efforts in this matter.
     
    Thanks!
     
    Jim, Bruno, & Joel
     
     
     
     
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_B7DE9A99-C4CE-4218-8EC8-BFFE55E91014-- From nobody Sun Nov 15 04:05:11 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0BD3A1120; Sun, 15 Nov 2020 04:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 HzfxsLQloNrk; Sun, 15 Nov 2020 04:04:48 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 3494D3A112B; Sun, 15 Nov 2020 04:04:44 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AFC4f3f006034; Sun, 15 Nov 2020 12:04:41 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5FE6122048; Sun, 15 Nov 2020 12:04:41 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 499B922044; Sun, 15 Nov 2020 12:04:41 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.234.140]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AFC4dpW024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Nov 2020 12:04:39 GMT Reply-To: From: "Adrian Farrel" To: "'Gyan Mishra'" Cc: "'TEAS WG'" , , "'IDR List'" , "'lsr'" , "'BESS'" , "'BIER WG'" , "'SPRING WG'" References: In-Reply-To: Date: Sun, 15 Nov 2020 12:04:38 -0000 Organization: Old Dog Consulting Message-ID: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01D6BB47.7EE27210" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF9YbXHIOSWBk8yeY9fu/naMBX0B6p7sJrg Content-Language: en-gb X-Originating-IP: 87.112.234.140 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25790.007 X-TM-AS-Result: No--14.922-10.0-31-10 X-imss-scan-details: No--14.922-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25790.007 X-TMASE-Result: 10--14.921600-10.000000 X-TMASE-MatchedRID: jFqw+1pFnMyx4Q5iE/G4VXFPUrVDm6jtrkGhd90/DD6ysPB8dBBorQkt GlyfnEqw/hPqYBjXRvrPRQhYb82CUWsWrPYGNN4DW4uRcqTgBLkDxXNNkwM2slY9yet6QEd8gXF 85i45Zx5Tycok6DUSPnBV0D37nd4oZb4YJkoMChswiJTf3kjwfauRJbBnR9QZE4klva9z5JyCdz yKMpTh4n0GH8UPE5XGeeOhgmVGz4sS887lpka72zCj6xe3SuezzwGOnesXThUDE8ggmrXnNIE/v INhyffjbALKww3fgKQ+IJsxz6/MG3PH+Ely1RppPE3khmVvHO5rakICcm9AUWNDqjXOO0YeCPIv P3uOlZdZMihSZb4ZQBFBD6+ejtliafdXgMs+pqB2GcWKGZufBQ4m7nrLKGA2JHwDAsNOgHhYXKg fzjvaWW342qvQHtJUfzzZvLDv3Oa2F9mW29B7siT9vTe4FHdQh8Ytn75ClDNhlbn6/nmOL9SE+o oSMqbWa2yjxi6DegzSPy86eVaxBAZzDl2stMKuzLo88rvlvYHR/CLTQxTQNLKeTtOdjMy6Y02UY ybf3M77zimhwE/anR6mA7svqvZCjlwExZ+3TSZfYa9W9OjitdZvZ5Gv+ByDw62uSG5kL1aNLo7J HtqcJUMJm1dGoan80AAsttmoS5lQdboikf/uEGwTEruL9ObTIfyQNHR2naZd9fDYSm945TdZExW GZtg3vRozbZIuTOAuNvTj5Xfp1u3FFtXLEvOmwP5c8K0bHlchjEPz8ZIh1hlLPW+8b7SaCSqvzM Gx6vFvy64TFAGuDliSlwChW1m5XC8g0bRla6SeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyJck9lvx NcntWLHjeGkjh9XKzfM9B6IRt7+efAnnZBiL0OAfBu/XeE86LVkcqC+5HQYK8bS5pq70eGEvXqw fEwp6gc/7grXMri0yp4Dr5imaJLC9paZso429IKhPJLZpaVAdYFEV4Px7Pv1leB13UrM X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [spring] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 12:04:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D6_01D6BB47.7EE27210 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Gyan, =20 Sorry, I missed this (got caught on a filter cos it was a bit spammed to = a lot of lists :-). =20 > I have noticed that after reviewing many drafts across many WGs it = seems in the > industry that the lines seem to be blurred between a PCE controller, = ODL or > Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X > provisioning. =20 Yes, blurriness our speciality. =20 You my find RFC 7491 useful in this respect, although it is a little = dated. And, of course, RFC 8283 is a good starting point. =20 > As this is a software sitting on a server you can have a swiss army = knife server that > does everything from PCE path computation to Netconf/Yang ZTP & Day N = > provisioning as well as any SDN Controller ODL or Openflow controller = type > functions as well. =20 Yes, and this is one of the risks of PCE as a shiny thing: that it be = converted from a useful toolkit into some form of god-box. I = pontificated on this way back in 2014 at = http://www.olddog.co.uk/PCEPandOnwards.pdf =20 > How this comes into play and realization of the lines being blurred is = the use of > BGP-LS in building the IGP topological graph of the network which was = designed > for PCEP and PCE & PCC active & passive off line path computation for = both > RSVP-TE or SR-TE path instantiation. =20 =20 In some senses, BGP-LS didn=E2=80=99t add anything because a PCE could = have snooped on the IGP. But BGP-LS provides an export mechanism and = importantly adds to that some policy filters to determine what is = exported thus giving the network some control over what is exported. =20 FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ = proposes using PCEP for the same function. The argument in favor is that = a PCE has to implement PCEP anyway, so why not include the LS export as = well. The argument against is that BGP-LS has wider applicability and = that it will typically be exported from an ASBR which already supports = BGP. =20 > However now BGP-LS can also be used for other functions now such as = usage as > I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use = BGP-LS to > gather the elements internals within BIER using the same BGP-LS data = structures > to populate with BIER specific information to graph the BIER topology. = So here > we are not doing any path computations as we are using in this use = case for > NMS type function to gather data for ZTP & Day N provisioning. >=20 > Similarly other use cases such as with TEAS TS-Transport slice and = being able > to provision TS and capturing the TS Enhanced VPN RT & resource = information > and leveraging BGP-LS to do the same data gathering & ZTP like = controller style > provisioning.=20 =20 Is there a fundamental difference between ZTP & Day N provisioning and = path computation for traffic engineering provisioning? It=E2=80=99s all = determining how to configure the network to best carry traffic. =20 > It does seem as though BGP-LS as its a means of "data gathering" "dump = truck" > of anything with the kitchen sink included to build any type of = topological graph > of literally anything under the sun. =20 Remembering Yakov Rekhter saying you could use BGP to transport = Shakespeare.=20 This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets = added, further use gets made. =20 BGP-LS was intended to export routing information = =E2=80=9Cnorthbound=E2=80=9D from the network. =20 > I see that is a nice to leverage but it does in fact blur the lines of = NMS Netconf/Yang > Controller based functionality and PCE path computation functionality = and SDN > controller based ZTP functionality into a single ubiquitous server = that can do all of > the above and use BGP-LS to accomplish the "kitchen sink" tasks. It = does however > transform BGP to be an NMS tool but a "tool" and not just the original = function > which it was intended NLRI network reachability. =20 Not sure that BGP-LS is BGP. But I agree that BGP-LS is =E2=80=9Can NMS = tool=E2=80=9D. I might argue that BGP distributing policies from installation on PEs is = an NMS protocol. =20 > Am I off base and please let me know as its BGP-LS is being way over = leveraged.=20 > There are pros & cons to everything but I thought I would bring up to = the WG as > an important discussion point. =20 Who are we to argue with real implementations? Assuming that there is a = push for implementation and deployment, then the thing to look for is = =E2=80=9Charm=E2=80=9D. Does this use of BGP-LS cause harm, sow = confusion, risk destabilising the network? Should it use a different = code point to be distinguishable? =20 I think the argument that =E2=80=9Cthere is already another protocol for = doing this=E2=80=9D is worth examining. But we have to be careful that = it doesn=E2=80=99t get us stuck, or force everyone to do something they = don=E2=80=99t want to do. After all, we could carry any protocol message = using Netconf/YANG, but we don=E2=80=99t do =E2=80=9CRSVP-TE over = Netconf=E2=80=9D. =20 Best, Adrian =20 ------=_NextPart_000_00D6_01D6BB47.7EE27210 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Hi Gyan,

     

    Sorry, I = missed this (got caught on a filter cos it was a bit spammed to a lot of = lists :-).

     

    > I have noticed that after reviewing many = drafts across many WGs it seems in the

    > industry that the lines seem to be blurred = between a PCE controller, ODL or

    > = Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day = X

    > provisioning.

     

    Yes, = blurriness our speciality.

     

    You my find = RFC 7491 useful in this respect, although it is a little dated. And, of = course, RFC 8283 is a good starting point.

     

    > As this is a software sitting on a server you can = have a swiss army knife server that

    > does everything from PCE path computation = to  Netconf/Yang ZTP & Day N

    > provisioning as well as any SDN Controller ODL or = Openflow controller type

    > = functions as well.

     

    Yes, and = this is one of the risks of PCE as a shiny thing: that it be converted = from a useful toolkit into some form of god-box. I pontificated on this = way back in 2014 at = http://www.olddog.co.uk/PCEPandOnwards.pdf

     

    > How this comes into play and realization of the = lines being blurred is the use of

    > BGP-LS in building the IGP topological graph of = the network which was designed

    > = for PCEP and PCE & PCC active & passive off line path = computation for both

    > RSVP-TE or = SR-TE path instantiation.  

     

    In some = senses, BGP-LS didn=E2=80=99t add anything because a PCE could have = snooped on the IGP. But BGP-LS provides an export mechanism and = importantly adds to that some policy filters to determine what is = exported thus giving the network some control over what is = exported.

     

    FWIW, htt= ps://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ proposes = using PCEP for the same function. The argument in favor is that a PCE = has to implement PCEP anyway, so why not include the LS export as well. = The argument against is that BGP-LS has wider applicability and that it = will typically be exported from an ASBR which already supports = BGP.

     

    > However now BGP-LS can also be used for other = functions now such as usage as

    > I = am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS = to

    > gather the elements internals = within BIER using the same BGP-LS data structures

    > to populate with BIER specific information to = graph the BIER topology.  So here

    > we are not doing any path computations as we are = using in this use case  for

    > = NMS type function to gather data for ZTP & Day N = provisioning.

    > 

    > Similarly other use cases such as with TEAS = TS-Transport slice and being able

    > to provision TS and capturing the TS Enhanced VPN = RT & resource information

    > = and leveraging BGP-LS to do the same data gathering & ZTP like = controller style

    > = provisioning. 

     

    Is there a = fundamental difference between ZTP & Day N provisioning and path = computation for traffic engineering provisioning? It=E2=80=99s all = determining how to configure the network to best carry = traffic.

     

    > It does seem as though BGP-LS as its a means of = "data gathering" "dump truck"

    > of anything with the kitchen sink included to = build any type of topological graph

    > of literally anything under the = sun.

     

    Remembering Yakov Rekhter saying you could use BGP to = transport Shakespeare.

    This is a = tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, = further use gets made.

     

    BGP-LS was = intended to export routing information =E2=80=9Cnorthbound=E2=80=9D from = the network.

     

    > I see that is a nice to leverage but it does = in fact blur the lines of NMS Netconf/Yang

    > Controller based functionality and  PCE path = computation functionality and SDN

    > controller based ZTP functionality into a single = ubiquitous server that can do all of

    > the above and use BGP-LS to accomplish the = "kitchen sink" tasks.  It does however

    > transform BGP to be an NMS tool but a = "tool" and not just the original function

    > which it was intended NLRI network = reachability.

     

    Not sure that BGP-LS is BGP. But I agree that BGP-LS = is =E2=80=9Can NMS tool=E2=80=9D.

    I = might argue that BGP distributing policies from installation on PEs is = an NMS protocol.

     

    > Am I off base and please let me know as its = BGP-LS is being way over leveraged. 

    > There are pros & cons to everything but I = thought I would bring up to the WG as

    > an important discussion point.

     

    Who are we = to argue with real implementations? Assuming that there is a push for = implementation and deployment, then the thing to look for is = =E2=80=9Charm=E2=80=9D. Does this use of BGP-LS cause harm, sow = confusion, risk destabilising the network? Should it use a different = code point to be distinguishable?

     

    I think the = argument that =E2=80=9Cthere is already another protocol for doing = this=E2=80=9D is worth examining. But we have to be careful that it = doesn=E2=80=99t get us stuck, or force everyone to do something they = don=E2=80=99t want to do. After all, we could carry any protocol message = using Netconf/YANG, but we don=E2=80=99t do =E2=80=9CRSVP-TE over = Netconf=E2=80=9D.

     

    Best,

    Adrian

     


    On Thu, Nov 12, 2020 at 8:14 AM <= zhuyq8@chinatelecom.cn> wr= ote:

    It=E2=80=99s useful for us to deploy SR Protection. Support. Thanks.

    B.R.

    Zhu Yongqing

    =C2=A0

    =E5=8F=91=E4=BB=B6=E4=BA=BA: spring <spring-bounces@ietf.org> =E4=BB=A3=E8=A1=A8 James Guichard
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=884= =E6=97=A5 1:39

    =E6=94=B6=E4=BB=B6=E4=BA=BA: spring@ietf.org
    =E6=8A=84=E9=80=81: = spring-chairs@ietf.org
    =E4=B8=BB=E9=A2=98: [sp= ring] WG Adoption Call for draft-li-spring-srv6-path-segment    =

    =C2=A0

    Dear WG:=

    =C2=A0=

    This message = starts a 3 week WG adoption call for https://tools.ietf= .org/html/draft-li-spring-srv6-path-segment-07, ending November 24= th 2020. Please note that this document has several changes from v-06= that were requested by the SPRING chairs. For this reason, the chairs have= extended the adoption call for an additional week to allow the WG enough t= ime to review these changes before deciding on WG adoption. <= /span>

    =C2=A0<= /span>

    After review of the d= ocument please indicate support (or not) for WG adoption to the mailing lis= t. Please also provide comments/reasons for that support (or lack thereof) = as silence will not be considered as consent.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel=

    =C2=A0=

    =C2=A0=

    =C2=A0=

    =C2=A0=

    =C2=A0=

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    ------=_NextPart_000_00D6_01D6BB47.7EE27210-- From nobody Sun Nov 15 07:27:54 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785523A1340; Sun, 15 Nov 2020 07:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Rh9RXwgQYD6p; Sun, 15 Nov 2020 07:27:46 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 379583A133F; Sun, 15 Nov 2020 07:27:43 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee55fb148df33c-73d5c; Sun, 15 Nov 2020 23:27:28 +0800 (CST) X-RM-TRANSID: 2ee55fb148df33c-73d5c X-RM-SPAM-FLAG: 00000000 Received: from chengweiqiang@chinamobile.com ( [10.1.6.7] ) by ajax-webmail-syy-appsvr04-11004 (Richmail) with HTTP; Sun, 15 Nov 2020 23:27:28 +0800 (CST) Date: Sun, 15 Nov 2020 23:27:28 +0800 (CST) From: =?utf-8?B?56iL5Lyf5by6?= To: spring Cc: srcomp , "spring-chairs@ietf.o" Message-ID: <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_970426_1771485172.1605454048655" X-Priority: 3 X-RM-TRANSID: 2afc5fb1438eaff-00007 X-RM-OA-ENC-TYPE: 0 X-RM-FontColor: 0 X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0 X-Mailer: Richmail_Webapp(V2.2.26) Archived-At: Subject: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 15:27:49 -0000 ------=_Part_970426_1771485172.1605454048655 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Group, SR compression design team have submitted a new version of compression requ= irement draft. Main changes as follows:=20 - added 3 items about scalibility with agreement within the design team=20 - added an appendix including 3 items without without unanimous consensus w= ithin the design team - some minor text issue fixed Please review it and let us know your comments. BTW: We will have 1-hour session for the design team topic on Friday and we= lcome to join us. B.R. Weiqiang on behalf of design team =20 ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----=E5=8F=91=E4=BB=B6=E4=BA=BA=EF= =BC=9Ainternet-drafts =E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9AWeiqiang Cheng ,Sander Steffann ,SJM Steffann =E6=8A=84=E3=80=80=E9=80= =81: (=E6=97=A0)=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:= 58:57=E4=B8=BB=E9=A2=98=EF=BC=9ANew Version Notification for draft-srcompdt= -spring-compression-requirement-01.txtA new version of I-D, draft-srcompdt-= spring-compression-requirement-01.txthas been successfully submitted by Wei= qiang Cheng and posted to theIETF repository.Name:=09=09draft-srcompdt-spri= ng-compression-requirementRevision:=0901Title:=09=09Compressed SRv6 SID Lis= t RequirementsDocument date:=092020-11-13Group:=09=09Individual SubmissionP= ages:=09=0913URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-com= pression-requirement-01.txtStatus: https://datatracker.ietf.org/doc/draft-s= rcompdt-spring-compression-requirement/Htmlized: https://datatracker.ietf.o= rg/doc/html/draft-srcompdt-spring-compression-requirementHtmlized: https://= tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01Diff: h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requir= ement-01Abstract: This document specifies requirements for solutions to com= press SRv6 SID lists. Please note that it may take a couple of minutes from= the time of submissionuntil the htmlized version and diff are available at= tools.ietf.org.The IETF SecretariatSubject=EF=BC=9ANew Version Notificatio= n for draft-srcompdt-spring-compression-requirement-01.txtA new version of = I-D, draft-srcompdt-spring-compression-requirement-01.txthas been successfu= lly submitted by Weiqiang Cheng and posted to theIETF repository.Name:=09= =09draft-srcompdt-spring-compression-requirementRevision:=0901Title:=09=09C= ompressed SRv6 SID List RequirementsDocument date:=092020-11-13Group:=09=09= Individual SubmissionPages:=09=0913URL: https://www.ietf.org/archive/id/dra= ft-srcompdt-spring-compression-requirement-01.txtStatus: https://datatracke= r.ietf.org/doc/draft-srcompdt-spring-compression-requirement/Htmlized: http= s://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-require= mentHtmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression= -requirement-01Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spr= ing-compression-requirement-01Abstract: This document specifies requirement= s for solutions to compress SRv6 SID lists. Please note that it may take a = couple of minutes from the time of submissionuntil the htmlized version and= diff are available at tools.ietf.org.The IETF Secretariat ------=_Part_970426_1771485172.1605454048655 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Hi Group,

    SR compression design team have submitted a new version = of compression requirement draft.

    Main changes as follows: 

    <= p>- added 3 items about scalibility with agreement within the design t= eam 

    - added an appendix including 3 items without wit= hout unanimous consensus within the design team

    - some minor text iss= ue fixed

    Please review it and let us know your comments.


    <= /p>

    BTW: We will have 1-hour session for the design team topic on Friday and welcome to join us.


    B.R.<= /p>

    Weiqiang on behalf of design team


     

    ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----
    =E5=8F= =91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts <internet-drafts@ietf= .org>
    =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng &= lt;chengweiqiang@chinamobile.com>,Sander Steffann <sander@s= teffann.nl>,SJM Steffann <sander@steffann.nl>
    =E6=8A= =84=E3=80=80=E9=80=81: (=E6=97=A0)
    =E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4=EF=BC=9A2020-11-15 22:58:57
    =E4=B8=BB=E9=A2=98=EF=BC=9ANew&= nbsp;Version Notification for draft-srcompdt-spring-compress= ion-requirement-01.txt


    A new version of I= -D, draft-srcompdt-spring-compression-requirement-01.txt
    has = been successfully submitted by Weiqiang Cheng = ;and posted to the
    IETF repository.

    Name:= =09=09draft-srcompdt-spring-compression-requirement
    Revision:=0901
    = Title:=09=09Compressed SRv6 SID List Requirements
    D= ocument date:=092020-11-13
    Group:=09=09Individual Submission<= br/>Pages:=09=0913
    URL: https://www.ietf.org/archive/id/draft-srco= mpdt-spring-compression-requirement-01.txt
    Status: https://datatra= cker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
    Htmliz= ed: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compre= ssion-requirement
    Htmlized: https://tools.ietf.org/html/draft-srco= mpdt-spring-compression-requirement-01
    Diff: https://www.ietf.org/= rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requirement-01

    Ab= stract:
     This document specifies requirements = for solutions to compress SRv6
     SID lists= .

     


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

    The IETF Secretariat



    Subject=EF=BC=9ANew=  Version Notification for draft-srcompdt-spring-compres= sion-requirement-01.txt


    A new version of = I-D, draft-srcompdt-spring-compression-requirement-01.txt
    has = ;been successfully submitted by Weiqiang Cheng&nbs= p;and posted to the
    IETF repository.

    Name:= =09=09draft-srcompdt-spring-compression-requirement
    Revision:=0901
    = Title:=09=09Compressed SRv6 SID List Requirements
    D= ocument date:=092020-11-13
    Group:=09=09Individual Submission<= br/>Pages:=09=0913
    URL: https://www.ietf.org/archive/id/draft-srco= mpdt-spring-compression-requirement-01.txt
    Status: https://datatra= cker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
    Htmliz= ed: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compre= ssion-requirement
    Htmlized: https://tools.ietf.org/html/draft-srco= mpdt-spring-compression-requirement-01
    Diff: https://www.ietf.org/= rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requirement-01

    Ab= stract:
     This document specifies requirements = for solutions to compress SRv6
     SID lists= .

     


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

    The IETF Secretariat



    ------=_Part_970426_1771485172.1605454048655-- From nobody Sun Nov 15 08:07:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA73A03C9 for ; Sun, 15 Nov 2020 08:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jSwpvWCFlhpj for ; Sun, 15 Nov 2020 08:07:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E883A0365 for ; Sun, 15 Nov 2020 08:07:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CYxt95mkxz1nvQf for ; Sun, 15 Nov 2020 08:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605456433; bh=Cf7tDZxbp1kcRSWPzPj2qqwlXgdkD6yRNh3lvb8R+yo=; h=To:From:Subject:Date:From; b=YJnsTXlynkKlyFSPDKBkmwwKcPOOsujKcctbeORFzvyo9wu/Ml8/hp3UPDLgWw6YR PkJm2q3y+IPYeKwvPlg68XdRzopMU86hAGRLcxJZ2eth9rvNlIaN4O7o/waEO9LBRu q1JYpdj0q4fujl+UUOdLOB57yUr9640AttBTgVF8= X-Quarantine-ID: <82KmBFILDmS7> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (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 4CYxt92gVNz1nvJH for ; Sun, 15 Nov 2020 08:07:13 -0800 (PST) To: "spring@ietf.org" From: "Joel M. Halpern" Message-ID: <6e92a4db-96d8-8cc9-0484-49050b6ffdb4@joelhalpern.com> Date: Sun, 15 Nov 2020 11:07:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Meeting presentation material X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 16:07:15 -0000 As far as I can tell, as of now only one presenter has posted their slides. Possibly the WG secretary has some more from folks to post. Also, I realize that many people have time zone issues. But so do your chairs :-) Please post your slides. If we get to the session and you have not posted before-hand, it will at best slow things down. And may result in your losing your slot. Yours, Joel From nobody Sun Nov 15 16:07:53 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF63A0639; Sun, 15 Nov 2020 16:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 o6FGMlA2EpJ8; Sun, 15 Nov 2020 16:07:43 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1293A0400; Sun, 15 Nov 2020 16:07:42 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v20so18165017ljk.8; Sun, 15 Nov 2020 16:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+agt6KNEuzE+CcAvcMKcLZdvv578x69KTjtQixgKdHM=; b=fyi/YVnPAGvANwslwE8/VXamAUyvyGs+4WMI6tIVQI/IRXvinYeHQO5AKzzxTeU81d OF4Es+nSDmhpZh8MHCAQ1HiREQrexiUsXbODB6liJOi4eeYxmePpYib+uCECGWHWfu6n uTkCJv5+IpQKjoOPrPywcUdk6GTPuZOmgaTzO+N1p3lw6hrjTKjUTUM2sK1il55MKV1w pCyFvQxXZ8gjItDMe5wzHAhOTMJ6UmpMasVylGz/vz7f/XTyOHOayjsRq1DEHxgLxEb1 it3tBEOMC2/lVi6Tc+ep4oW5h07PTkwAFQGsYMJU3xvlXbFDTUCkgavtV61OIYJBPXw2 CTGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+agt6KNEuzE+CcAvcMKcLZdvv578x69KTjtQixgKdHM=; b=gDvd8NvlmsR9Jp5C4TCa9lKdAPpjqLRjdohoe1ZtwFIgLBYPkO0n4AwCkU0amR59Q2 /k+bFYA0NYKue32gJEifP4A3HcuFUx5nt41ef49i3QsQxwk5ETiswBWZRZZg4z4rWnzx uNOe50WagY6RVp4+VVwf1/Wh6lPx4cqBSXQsqcRHSPQFfbVq9jEDINcEeYMmKrqam4Ib f6IkR+EhtusRLi6vmu5ZFDq06sCvx6kEA2Qrg5wLSOzBL2swIRrF2PwLWo4VfFn/ELEm 671SPcp2KVn6kfWxhyzGbcpGN75YC5HtpEM1v8TMyGN3pTdNEqf2FmHehe0g3d5EFI06 5e+A== X-Gm-Message-State: AOAM531NhAtIZ0tUsXbWY2wHR6VKKqXWhmGD1Z3hxrMFLxUqPv23aVrJ t/mc7Sa8hIRNFU4VINjyZUMusmVM8jkwiEPNV2P7gjofeXA= X-Google-Smtp-Source: ABdhPJw+EMv3ZiHqjgwkYsHHcb6VhSqrhmOiPQGGfQTt+7e9Yf31tC52798mUuxi0kdzkYCY+BSCmJ6Z/ltRL5uw3JI= X-Received: by 2002:a2e:9694:: with SMTP id q20mr5354384lji.279.1605485260314; Sun, 15 Nov 2020 16:07:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 15 Nov 2020 16:07:28 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: James Guichard , "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000a21bee05b42e2a49" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 00:07:48 -0000 --000000000000a21bee05b42e2a49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 8:01 AM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. Note that many of the comments here on STAMP draf= t > are repeated from the previous comments on the TWAMP Light draft. Please > see replies inline with . The repeated comments are tagged with > to avoid duplicated discussions. > > > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > It was a surprise finding out that both drafts don't use the terminology > from RFC 8762 STAMP and introduce their own terminology for Session-Sende= r > and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", > are used in the documents without proper definitions. Other than that, bo= th > drafts are readable. > > > > We can change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > GIM>> I believe that the consistency in terminology between the core RFC 8762 and what is intended as its extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specifications. But I don't think that switching the terminology will fix the fundamental issue with *stamp-srpm drafts. The operation that is required from the remote entity, whether it is referred to as responder or Session-Reflector, is not defined in RFC 8762, nor even in draft-ietf-ippm-stamp-option-tlv. In my opinion, the behavior required, as described in the *stamp-srpm drafts, cannot be characterized as an extension of STAMP but presents a completely new protocol that, if there's a need in the new PM OAM protocol, must be properly defined. > There are many existing RFCs that use term Link (e.g. RFC 5613, > 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > GIM>> Thank you for the references to these RFCs. I think I need to clarify my questions. I don't think that a reference to any RFC will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR domain that includes all the nodes shown in the network diagram. An SR tunnel from A to F that traverses the network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the other", it looks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet of an active OAM intended to monitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts *-twamp-srpm, direct loss measurement can be performed, as information collected from node F and packets that collect the counters are not required to be in-band with the monitored flow. So, this example, in my opinion, illustrates two of my concerns: - using a congruent path for active performance measurement, e.g., TWAMP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored flow. - there are no technical requirements to justify using in-band test packets for direct packet loss measurement. In fact, using the in-band method for collecting in-profile counters leads to a waste of bandwidth, which may have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this example, direct packet l= oss can be performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model. > > - Does the document solve a real problem? > > No, it appears that the changes described in these drafts are only to > achieve in-band collection of counters of "in-profile" packets. Firstly, > drafts don't provide any arguments about why such collection should be > performed using the in-band method rather than using the out-of-band > collection approach. Secondly, even if there are any benefits of in-band > collection, that can be more easily achieved by extending other OAM, e.g.= , > ICMP, tools. > > > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > GIM>> While I agree with the generic requirements you've listed I'm a bit confused about how the deployment of OWAMP and TWAMP protocols can be related to the proposed in *-stamp-srpm extensions. STAMP, similar to OWAMP and TWAMP, is the active measurement protocol, per the definition of RFC 7799. The direct loss measurement method is clearly a passive method and, in my opinion, it is decremental to the network to use in-band active method collecting in-profile counters when there is no technical requirement to use such an intrusive method. > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for STAMP. Other than this, I did not find > any other security related issue in your review below. > GIM>> I don't think that a mere reference sufficiently explains why the use of zero UDP checksum in IPv6 header is not decremental, does not create a security risk for the protocol. > draft-gandhi-spring-stamp-srpm > > - Can you define a Link and how it is different from an SR Path? > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D = (e.g. RFC 5613, > 5340, 8330, etc.). Similarly term =E2=80=9CSR Path=E2=80=9D has been used= in existing RFCs > (e.g. 8664). I suspect these are well-known terms. > GIM>> I believe that every well-known term has been defined somewhere. Since the document differentiates between the two, I hope that it would not be too difficult to explain or illustrate what is the difference. > > - It is not clear how the destination UDP port numbers are selected. > Does the draft change procedure defined in Section 4.1 RFC 8762? > > There is no change. > GIM>> Thank you for clarifying that. I'd note that the current text is not clear about that. > > - It is not clear what "the congruent path" means. The definition of > the congruent in geometry tells that a congruent object has the same s= hape > and size, but is allowed to flip, slide or turn. How a path can be > congruent to another path? > > There are many existing RFCs that use term =E2=80=9CCongruent Path= =E2=80=9D (e.g. > RFC 5921, 6669) without defining them. I suspect it is because it is > well-known term. Having said that, we can add a reference for it if it > helps reader. > GIM>> I've clarified my question about the term "congruent path" above. I hope that the diagram makes it clearer. > > - An example of the provisional model is Section 3.1 seems well-suited > for a YANG data model. What changes to the STAMP YANG data model defin= ed in > draft-ietf-ippm-stamp-yang > propose= d > in these drafts? > > Yes, this can be Yang model. We can review > draft-ietf-ippm-stamp-yang > and add any > missing items in a separate draft. We can also add a reference in this > draft. > GIM>> Management of a protocol, configuration is an integral part of the protocol specification. I've expected that *-stamp-srpm drafts include more substantial text about the management than "out of the scope". In my opinion, a section on the management is required and if the authors decide to augment STAMP Yang data model, it should include the new YANG module. > > - In Section 4.1 noted that > > The probe messages defined in [RFC8762] are used for delay > measurement for Links and end-to-end SR Paths including SR Policies. > For loss measurement, the probe messages defined in [I-D.gandhi-ippm- > stamp-srpm] are used. > > It necessary to point that RFC 8762 support packet delay and packet loss > measurements in the same test session using test packets defined in the > STAMP base specification. I believe that the need yet for another method = to > perform the loss measurement is not sufficiently demonstrated and does > appear as duplication of functionality already available in STAMP. > > > > This is explained in the third paragraph of Section 1. > GIM>> I cannot find any technical explanation for the introduction of the new PM protocol to collect in-profile counters and not use the Direct Measurement TLV defined in draft-ietf-ippm-stamp-option-tlv (already cleared IESG review). Could you help me by pointing to the explanatory test in the paragraph you're referring to: This document specifies procedures for sending and processing probe query and response messages for Performance Measurement in SR networks. The procedure uses the mechanisms defined in [RFC8762] (STAMP) and its TLV extensions [I-D.ietf-ippm-stamp-option-tlv] for Performance Measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes and is used for both Links and end-to- end SR Paths including SR Policies and Flex-Algo IGP Paths. Unless otherwise specified, the mechanisms defined in [RFC8762] and [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document. > > - Could you expand on the reasoning why in Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > I cannot find similar requirement in RFC 8762 and would appreciate a > technical explanation of the choice made in this specification. > > > > Does RFC 8762 support simultaneous sessions for authenticated and > non-authenticated modes? If yes, can you please point to the procedure in > the RFC 8762 and we can simply refer to it? I am not sure how both packe= t > formats be distinguished by a reflector node when using the same UDP port= . > GIM>> Whether STAMP test session is in authenticated or unauthenticated mode is the matter of configuration (as it is for TWAMP). You can check the STAMP YANG data model draft and TWAMP YANG data model (the latter could be useful for *-twamp-srpm drafts). As for distinguished of two concurrent sessions between a pair of nodes, in STAMP one can take advantage of the STAMP Session Identifier (SSID) that is defined in Section 3 of draft-ietf-ippm-stamp-option-tlv. If there is only one session, then, in my view, the configuration of the STAMP session's mode should suffice. Would you agree? > > - Section 4.2.1 refers to Sender Control Code (though it is defined > in draft-gandhi-ippm-stamp-srpm. Could you explain why it is important= to > inform the Session-Reflector that the reflected test packet be sent > out-of-band? What if only in-band return path is available? Would the > Session-Reflector discard test packets in such situation? > > Out-of-band is the current behaviour and there is no change in the > existing behaviour. We can clarify in the next revision. > GIM>> I'm confused. An active measurement protocol cannot be out-of-band, otherwise, the measured metrics are meaningless. Thus, an implementation of STAMP must ensure that the test packet is in-band with the monitored flow. So, when you're saying "there is no change in the existing behavior" are you referring to the behavior of STAMP or to something else? If your intention to use the new protocol out-of-band, that clearly will be a change of STAMP behavior. > > - I got confused by the following in Section 4.2.2 > > In two-way measurement mode, when using a bidirectional path, the > probe response message as defined in Figure 6 is sent back to the > sender node on the congruent path of the data traffic on the same > reverse direction Link or associated reverse SR Policy > [I-D.ietf-pce-sr-bidir-path]. > > If a Path Segment SID associated with the test session, there seems no > need to require the Session-Reflector look for in-band path. Would you > agree? > > > > No. Existence of Path Segment ID does not mean in-band reply. It may > be needed for RX counter for direct-mode loss measurement. > GIM>> Can you please clarify the use case for using the Path Segment SID in the test packet? The text, as quoted, gives the impression that it is needed for "the probe response message as defined in Figure 6 is sent back to the sender node on the congruent path of the data traffic on the same reverse direction Link or associated reverse SR Policy." I cannot find any text that explains how the Segment Path SID in the test packet may be used by "RX counter for direct-mode loss measurement". > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or STAMP / TWAMP / RFC 5357 / > RFC 8762 in RFC 8403. > GIM>> Yes, RFC 8403 doesn't mention these RFCs, nor refers to RFC 8762. In my opinion, it was demonstrated in RFC 8403 how SR, SR-MPLS in the case discussed, can be used to circle the test packet through the SR domain. By using that method, an operator may not only detect the failure in the network but, by correlating failure reports from the intersecting traces, automate the failure localization. What is the use case for the Loopback mode? Roundtrip delay and roundtrip packet loss measurement? What requires standardization? Is the "liveness monitoring" functionally identical to path continuity > monitoring provided by BFD? > > STAMP probe messages are used for synthetic packet loss which can > be used to detect connection loss. The draft simply highlights this obvio= us > metric. > GIM>> I cannot agree that STAMP can efficiently be used to detect the path continuity loss. Perhaps even stronger, I would not advise and strongly discourage the use of STAMP for path continuity monitoring. BFD (RFC 5880) is intentionally lightweight and is capable of detecting a failure within 10 msec. Do you believe that STAMP test packets should be transmitted with 3.3 msec interval? > > - It appears that second and third paragraphs on Section 4.3.1 > contradict with the first paragraph. Need to point that RFC 8762 does = not > specify the value set in TTL/Hop Limit field, thus reference in the fi= rst > paragraph seems misleading. I couldn't find ::FFFF:127/104 range being > mentioned in the draft. Could you clarify when it is used? > > We can update the sentence in the first paragraph as following: > > The TTL field in the IPv4 and MPLS headers of the probe query messages is > set to 255 *[RFC5357] except following two cases*. > GIM>> Can please you quote the text in RFC 5357 that requires setting TTL/Hop Limit to 255? > > The IPv6 address ::1/128 is mentioned in the draft at couple of plac= es. We can update the above text. > > > - Section 4.3.3 states that a zero-value UDP checksum may be used in > some scenarios. RFC 8085 allows that but in very specific cases that a= re > documented in detail in Section 3.4.1. Do you believe that the case of= this > protocol checks all the requirements for allowing the use of Zero UDP > checksum as specified in RFC 8085? Also, I believe that allowing the u= se of > Zero UDP checksum in some scenarios, this protocol introduces a securi= ty > threat that must be thoroughly analyzed in the Security Considerations > section. > > This is described in RFC 6936. It will be very specific to the UDP > port provisioned for STAMP. We will add reference to RFC 6936 in Security > Section. > GIM>> RFC 6936 provides us with an exceptionally detailed analysis of that question. I don't think that a reference can explain why using zero UDP checksum is an acceptable practice. I recall that concern about the IPv6 security was the reason why RFC 7820 is applicable only to IPv4 and includes the following text in regard to IPv6: UDP over IPv6, as defined in [IPv6], does not allow a zero checksum, except in specific cases [ZeroChecksum]. As discussed in [ZeroChecksum], the use of a zero checksum is generally not recommended and should be avoided to the extent possible. And if the authors believe that they have an exceptional case, the case must be stated. > > - Section 7, as I understand it, suggests that performance measurement > can be combined with "liveness monitoring", i.e.path continuity monito= ring. > How fast path failure detection you expect in such combination? How it= is > comparable to the the failure detection time guaranteed using BFD? > > STAMP probe messages are used for synthetic packet loss which can > be used to detect connection loss (performance metric). The draft simply > highlights this obvious metric. > GIM>> What could be the detection interval when using STAMP? How that is compared with BFD? draft-gandhi-ippm-stamp-srpm > > - Introduction states that > > The STAMP message with a TLV for "direct measurement" can be used for > combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. > > In fact, that is not accurate. RFC 8762 which provides the base > specification of the STAMP protocol already supports packet delay and > packet loss (a.k.a. synthetic packet loss) measurement. > > Ok, we can update the text to indicate *synthetic* loss. > > - Further, the draft concludes that > > However, in order to use only for loss measurement purpose, it > requires the node to support the delay measurement messages and > support timestamp for these messages (which may also require clock > synchronization). > > I disagree that the the clock synchronization is required for STAMP. It i= s > recommended for one-way delay measurement but even without the clock > synchronization STAMP supports the round-trip delay measurement and one-w= ay > delay variation can be calculated. > > We can update text to : (*which requires clock synchronization for > one-way delay measurement).* > > - The conclusion on Introduction is, in my view, misleading as the > proposed solution is not an extension of STAMP but update of RFC 8762.= And > since this is changes the foundation of RFC 8762 that specifies active > two-way performance measurement protocol, another method for collectin= g > counters and/or other telemetry information should be sought. For exam= ple, > ICMP using multi-part message extensions, as defined in RFC 4884 > . > > As mentioned earlier, I am not sure extending ICMP to do PM is a > good option here. > GIM>> I think that we can have a single mechanism instead of two defined in *twamp-srpm nd *stamp-srpm. Would be interesting to hear from SPRING and IPPM WGs. > > > Thanks, > > Rakesh > > > > > > Regards, > > Greg > > > > > > On Thu, Oct 22, 2020 at 5:52 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending > November 12th 2020. Please note that this document has several changes > from v-02 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for STAMP > Messages*, *Loss Measurement Query Message Extensions*, *Loss > Measurement Response Message Extensions*, *Node Address TLV Extensions= *, > and *Return Path TLV Extensions* were included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and > should be removed from the SPRING document. > - The STAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > Thanks! > > Jim, Bruno, & Joel > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --000000000000a21bee05b42e2a49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh,
    thank you for the response= to my comments.=C2=A0Please find my follow-up notes in-lined below under t= he GIM>> tag.

    Regards,
    Greg
    <= /div>
    O= n Tue, Nov 10, 2020 at 8:01 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments. Note that many = of the comments here on STAMP draft are repeated from the previous comments= on the TWAMP Light draft. Please see replies inline with <RG>. The repeated comments are tagged with <RG00>= to avoid duplicated discussions.

    =C2=A0

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, i= ppm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, = IETF IPPM WG <ippm@ie= tf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03<= /u>

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review th= e "liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and c= omments in a single thread. I hope that would be acceptable and considered = by the SPRING WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    It was a=C2=A0surprise finding out that both drafts = don't use the terminology from RFC 8762 STAMP and introduce their own t= erminology for Session-Sender and Session-Reflector. Also, many terms, e.g.= , Links, "congruent paths", are used in the documents without proper definitions. Other than that, both drafts are rea= dable.

    =C2=A0

    <RG00> We= can change Sender to Session-Sender and Reflector to Session-Reflector if = it helps.

    GIM>= > I believe that the consistency in terminology between the core RFC 876= 2 and what is intended as its extension is not only helpful to a reader but= , to the best of my understanding, is required for IETF specifications. But= I don't think that switching the terminology will fix the fundamental = issue with *stamp-srpm drafts. The operation that is required from the remo= te entity, whether it is referred to as responder or Session-Reflector, is = not defined in RFC 8762, nor even in draft-ietf-ippm-stamp-option-tlv. In m= y opinion, the behavior required, as described in the *stamp-srpm drafts, c= annot be characterized as an extension of STAMP but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.=C2=A0

    <RG00> Th= ere are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, e= tc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I= suspect it is because these are well-known terms. Having said that, we can add a reference for them if it helps.

    <= /div>
    GIM>> Thank you for th= e references to these RFCs. I think I need to clarify my questions. I don&#= 39;t think that a reference to any RFC will address my concern. In reviewed= documents, "Link" is capitalized while referenced RFCs used the = lower case form for the term "link". Can these be used interchang= eably? Do they refer to the same network object?
    Now I'll try= to illustrate my concern with using the term "congruent path" in= these drafts (using ASCII-art):
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G-----= -------H
    Consider an SR domain that includes all the nodes shown = in the network diagram. An SR tunnel from A to F that traverses the network= as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of &qu= ot;congruent" as "two figures or objects are congruent if they ha= ve the same shape and size, or if one has the same shape and size as the mi= rror image of the other", it looks as the path A-B-G-H-E-F is congruen= t to that SR tunnel. But a packet of an active OAM intended to monitor a fl= ow over the SR tunnel is out-of-band relative to that flow and will not pro= duce any meaningful measurement. Of course, for the case of the extensions = in drafts *-twamp-srpm, direct loss measurement can be performed, as inform= ation collected from node F and packets that collect the counters are not r= equired to be in-band with the monitored flow. So, this example, in my opin= ion, illustrates two of my concerns:
    • using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packe= ts are in-band with the monitored flow.
    • = there are no technical requirements to justify using in-band test packets f= or direct packet loss measurement. In fact, using the in-band method for co= llecting in-profile counters leads to a waste of bandwidth, which may have = a negative impact on services that require low-latency and/or low packet lo= ss. As demonstrated in this example, direct packet loss can be performed us= ing an out-of-band mechanism, e.g., SNMP queries, Netconf notifications bas= ed on YANG data model.
    =C2=A0

    • Does the document solve a real problem?

    No, it appears that the changes described in these d= rafts are only to achieve in-band collection of counters of "in-profil= e" packets. Firstly, drafts don't provide any arguments about why = such collection should be performed using the in-band method rather than using the out-of-band collection approach. Secondly, ev= en if there are any benefits of in-band collection, that can be more easily= achieved by extending other OAM, e.g., ICMP, tools.

    =C2=A0

    <RG00> Th= ere is a requirement to measure performance delay as well as synthetic and = direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protoc= ols are widely deployed for performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for = LM is a good option here.

    =C2=A0GIM>> While I agree with the generic requirements you&= #39;ve listed I'm a bit confused about how the deployment=C2=A0of OWAMP= and TWAMP protocols can be related to the proposed in *-stamp-srpm extensi= ons. STAMP, similar to OWAMP and TWAMP, is the active measurement protocol,= per the definition of RFC 7799. The direct loss measurement method is clea= rly a passive method and, in my opinion, it is decremental to the network t= o use in-band active method collecting in-profile counters when there is no= technical requirement to use such an intrusive method.

    =C2=A0

    • Is the proposed solution technically viable?

    There are too many unad= dressed aspects, particularly the risk introduced by the protocol on networ= k security, to comprehensively evaluate the proposed solution.

    <RG00> Ab= out your comment on zero checksum, this is described in Security section in= RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP. Other than this, I did not find any other= security related issue in your review below.

    <= /div>
    =C2=A0GIM>> I don't think that a mer= e reference sufficiently explains why the use of zero UDP checksum in IPv6 = header is not decremental, does not create a security risk for the protocol= .
    =C2=A0
    <= div lang=3D"EN-CA" style=3D"overflow-wrap: break-word;">

    =

    draft-gandhi-spring-stamp-srpm

    • Can you define a Link and how it is different from an SR Path?

    <RG00> Th= ere are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e.g. RFC 5= 613, 5340, 8330, etc.). Similarly term =E2=80=9CSR Path=E2=80=9D has been u= sed in existing RFCs (e.g. 8664). I suspect these are well-known terms.

    <= /div>
    GIM>> I believe that every well-known te= rm has been defined somewhere. Since the document differentiates between th= e two, I hope that it would not be too difficult to explain or illustrate w= hat is the difference.=C2=A0

    • It is not clear how the destination UDP port numbers are selected. Does the= draft change procedure defined in Section 4.1 RFC 8762?
      • =

    <RG> Ther= e is no change.

    G= IM>> Thank you for clarifying that. I'd note that the current tex= t is not clear about that.=C2=A0
    =

    =

    • It is not clear what "the congruent path" means. The definition o= f the congruent in geometry tells that a congruent object has the same shap= e and size, but is allowed to flip, slide or turn. How a path can be congru= ent to another path?

    <RG00> Th= ere are many existing RFCs that use term =E2=80=9CCongruent Path=E2=80=9D (= e.g. RFC 5921, 6669) without defining them. I suspect it is because it is w= ell-known term. Having said that, we can add a reference for it if it helps reader.

    GIM>> I've clarified my question about the term "congruent = path" above. I hope that the diagram makes it clearer.=C2=A0

    • An example of the provisional model is Section 3.1 seems well-suited for a = YANG data model. What changes to the STAMP YANG data model defined in draft-ietf-ippm-stamp-yang=C2=A0=C2=A0proposed in these drafts?<= u>

    <RG00> Ye= s, this can be Yang model. We can review draft-ietf-ippm-stamp-yang=C2=A0and add any missing items in a separate draft.<= span style=3D"color:rgb(0,112,192)"> We can also add a reference in this draft.

    G= IM>> Management of a protocol, configuration is an integral part of t= he protocol specification. I've expected that *-stamp-srpm drafts inclu= de more substantial text about the management than "out of the scope&q= uot;. In my opinion, a section on the management is required and if the aut= hors decide to augment STAMP Yang data model, it should include the new YAN= G module.

    <= /p>

    • In Section 4.1 noted that

    =C2=A0 =C2=A0The probe messages defined in [RFC8762]= are used for delay
    =C2=A0 =C2=A0measurement for Links and end-to-end SR Paths including SR Pol= icies.
    =C2=A0 =C2=A0For loss measurement, the probe messages defined in [I-D.gandh= i-ippm-
    =C2=A0 =C2=A0stamp-srpm] are used.

    It necessary to point that RFC 8762 support packet d= elay and packet loss measurements in the same test session using test packe= ts defined in the STAMP base specification. I believe that the need yet for= another method to perform the loss measurement is not sufficiently demonstrated and does appear as duplicatio= n of functionality already available in STAMP.

    =C2=A0

    <RG> This= is explained in the third paragraph of Section 1.

    GIM>> I cannot find any technical e= xplanation for the introduction of the new PM protocol to collect in-profil= e counters and not use the Direct Measurement TLV defined in draft-ietf= -ippm-stamp-option-tlv (already cleared IESG review). Could you help me= by pointing to the explanatory=C2=A0test in the paragraph you're refer= ring to:
    =C2=A0 =C2=A0This document specifies procedures for send= ing and processing probe
    =C2=A0 =C2=A0query and response messages for Pe= rformance Measurement in SR
    =C2=A0 =C2=A0networks.=C2=A0 The procedure u= ses the mechanisms defined in [RFC8762]
    =C2=A0 =C2=A0(STAMP) and its TLV= extensions [I-D.ietf-ippm-stamp-option-tlv] for
    =C2=A0 =C2=A0Performanc= e Measurement.=C2=A0 The procedure specified is applicable to
    =C2=A0 =C2= =A0SR-MPLS and SRv6 data planes and is used for both Links and end-to-
    = =C2=A0 =C2=A0end SR Paths including SR Policies and Flex-Algo IGP Paths.=C2= =A0 Unless
    =C2=A0 =C2=A0otherwise specified, the mechanisms defined in [= RFC8762] and
    =C2=A0 =C2=A0[I-D.ietf-ippm-stamp-option-tlv] are not modif= ied by this document.

    • Could you expand on the reasoning why in Section 4.1.1.1 stated that=

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    I cannot find similar requirement in RFC 8762 and wo= uld appreciate a technical explanation of the choice made in this specifica= tion.

    =C2=A0

    <RG> Does= RFC 8762 support simultaneous sessions for authenticated and non-authentic= ated modes? If yes, can you please point to the procedure in the RFC 8762 a= nd we can simply refer to it? I am not sure=C2=A0 how both packet formats be distinguished by a reflector node when using the sa= me UDP port.

    =C2=A0

    <RG> The IPv6 address ::1/128 is mentioned in the draft =
at couple of places. We can update the above text.

      

    • 
Section 4.3.3 states that a zero-value UDP checksum may be used in some sce=
narios. RFC 8085 allows that but in very specific cases that are documented=
 in detail in Section 3.4.1. Do you believe that the case of this protocol =
checks all the requirements for
 allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be=
lieve that allowing the use of Zero UDP checksum in some scenarios, this pr=
otocol introduces a security threat that must be thoroughly analyzed in the=
 Security Considerations section.

    

    <RG00> Th=
is is described in RFC 6936. It will be very specific to the UDP port provi=
sioned for STAMP. We will add reference to RFC 6936 in Security Section.
    =
    GIM>> What could be the detection interval=C2=A0when using STAMP= ? How that is compared with BFD?

    draft-gandhi-ippm-stamp-srpm

    • Introduction states that

    =C2=A0 The STAMP message with a TLV for "direct= measurement" can be used for
    =C2=A0 =C2=A0combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-= tlv].

    In fact, that is not accurate. RFC 8762 which provid= es the base specification of the STAMP protocol already supports packet del= ay and packet loss (a.k.a. synthetic packet loss) measurement.

    <RG> Ok, we can update the text = to indicate synthetic loss.

    • Further, the draft concludes that

    =C2=A0 =C2=A0However, in order to use only for loss = measurement purpose, it
    =C2=A0 =C2=A0requires the node to support the delay measurement messages an= d
    =C2=A0 =C2=A0support timestamp for these messages (which may also require c= lock
    =C2=A0 =C2=A0synchronization).

    I disagree that the the clock synchronization is req= uired for STAMP. It is recommended for one-way delay measurement but even w= ithout the clock synchronization STAMP supports the round-trip delay measur= ement and one-way delay variation can be calculated.

    <RG> We can update text to : (which requires clock synchronization for one-way delay measurement).

    <RG00> As= mentioned earlier, I am not sure extending ICMP to do PM = is a good option here.

    =C2=A0

    Thanks,<= u>

    Rakesh

    =C2=A0

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Thu, Oct 22, 2020 at 5:52 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for https://tools.ietf.org/html/dr= aft-gandhi-spring-stamp-srpm-03, ending Nov= ember 12th 2020. Please note that this document has several changes from v-02 that were requested by th= e SPRING and IPPM chairs. For this reason, the chairs have extended the ado= ption call for an additional week to allow the WG enough time to review the= se changes before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0<= u>

    =C2=A0

    Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-stamp-srpm-02. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

    =C2=A0

    • The SPRING document should describe only the procedures relevant to SPRING = with pointers to non-SPRING document/s that define any extensions. Several = extensions including Control Code Field Extension for STAMP Messages,=C2=A0Loss Mea= surement Query Message Extensions,=C2=A0Loss Measurement Response Me= ssage Extensions,=C2=A0Node Address TLV Extensions, and=C2=A0Return Path TLV Extensions were inc= luded in https://tools.ietf.org/html/draft-gandhi-spring-stamp-= srpm-02 and should be removed from the SPRI= NG document.
    • The STAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-= srpm-02 should be described in a new document published in the I= PPM WG. =C2=A0

    =C2=A0

    These conclusions were discussed with the authors of https://tools.ietf.org/html/draft-gandhi-spring-stamp-= srpm-02 the result of which is the publicat= ion of the following two documents:

    =C2=A0

    =C2=A0

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

    Finally, the chairs would like = to thank the authors for their efforts in this matter.=

    Thanks!

    Jim, Bruno, & Joel

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

    =C2=A0

    --000000000000a21bee05b42e2a49-- From nobody Sun Nov 15 16:07:57 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985653A0978; Sun, 15 Nov 2020 16:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vgcI-w876s4b; Sun, 15 Nov 2020 16:07:46 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8339E3A05DF; Sun, 15 Nov 2020 16:07:45 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id 142so4554023ljj.10; Sun, 15 Nov 2020 16:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R5IgubYNIESfcWKHAbViuE+NkYUfblOqqRMqrtpf2xE=; b=GUDqjp7Y9FI7JuSJ7LbUg3jOCaLS5STZC5RMciRGQYz53WvNuIx8uogcigJ4uQG3Yu X5jRrvcXYWVjnZyY2rd07vKGMpaY/D6qmP4qDvk0K4StSBchVlkdX67PiNrCcsWfJLc3 i9H6LGfIwT+4lLzVRLrerMkHmujKOg88b+LZ8Rq0l9DGK2G52+RB/2Z0N2Hz/fjT7aFn lYcKjEE9UE2b96Azrri2veMSJK48t7eho7iy/XkrZCOqbSIPLTqalZTKoqeTgJ6MbTxl BL72CjromguGoHLp+dVtRl98ri+/HrzC2N4AY+xgAr8QsLJIWbMPrynl7cnaV2LzJ1in jIRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R5IgubYNIESfcWKHAbViuE+NkYUfblOqqRMqrtpf2xE=; b=jWWqbY3WzTe7eHonsHg0sICNoVYC6d8Ei6Ub1tZsAD1K5tOTYDZkvXXCCS9nt6dsy3 E9zt/bu3tmvY8UEVBYimBcxmjQeLZ9v6qJkfoT82SpMZ7iWRHh046LHMhbvurrtT704Q JNdrEG8sAMyRRzKGRDwpTVBC0hpAwiFN3z5ilWqp+051GPrsZaU2uibzSWLAtaNd0ROJ YV5q7bOV2KNkvkbSPfqYIRYV9oTCo67p3cjngANXmdvKExRsWoE3u8boUaRlQpdDnevp D/d6OWW3ZRppKoy1bOSeiOtJkEBykdXivecbEoQiGRBhyB+p46dpbYIUx4CpUt0ccxW0 72WQ== X-Gm-Message-State: AOAM530rnxefzveH5aTUmADRnWTfRFThy/OmheqZjWMD4SRYwDzVls9z WZrkzgYL5oD8HK3FV5jDvyMdcUi53gUXQ2SQ8jY= X-Google-Smtp-Source: ABdhPJwlMS2HqqAcWZvC/b9heAeoyVdYBLggvIFfMER7VN9XVBNbruFVtxWA/NJalRgBxg9AIlKuuFyLuC2DUaQUNH8= X-Received: by 2002:a2e:5450:: with SMTP id y16mr5371102ljd.288.1605485263533; Sun, 15 Nov 2020 16:07:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 15 Nov 2020 16:07:32 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: James Guichard , "spring@ietf.org" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000d33cc305b42e2a1b" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 00:07:57 -0000 --000000000000d33cc305b42e2a1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > GIM>> I believe that the consistency in terminology between the core RFC and what is intended as its extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specifications. But I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is required from the remote entity, whether it is referred to as responder or Session-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new protocol that, if there's a need in the new PM OAM protocol, must be properly defined. > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > GIM>> Thank you for listing these RFCs. I think I need to clarify my questions. While a reference to any of RFCs you've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the other", it looks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet of an active OAM intended to monitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts *-twamp-srpm, direct loss measurement can be performed, as information collected from node F and packets that collect the counters are not required to be in-band with the monitored flow. So, this example, in my opinion, illustrates two of my concerns: - using a congruent path for active performance measurement, e.g., TWAMP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored flow. - there are no technical requirements to justify using in-band test packets for direct packet loss measurement. In fact, using the in-band method for collecting in-profile counters leads to a waste of bandwidth, which may have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this example, direct packet l= oss can be performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model. > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > GIM>> I agree with the requirements you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusive direct packet loss measurement. > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > GIM>> I don't think that a mere reference sufficiently explains why the use of zero UDP checksum in IPv6 header is not decremental, does not create a security risk for the protocol. > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > GIM>> I cannot find where RFC 5357 defines "the probe and response messages". Could you give a more specific reference or provide the text that, in your opinion, defines such messages? But I'm more concerned with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm have learned how different are existing implementations of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper . The status of TWAMP Light is explained in RFC 8545 and I cannot see that it can be used as a foundation of any standard. > > - several parts of the proposed protocol, e.g., Zero UDP checksum in > IPv6, require detailed security analysis, which is currently absent; > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > GIM>> I've noted above that a simple reference does not sufficiently explains why the use of zero UDP checksum in IPv6 header is not decremental, does not create a security risk for the protocol. I believe that the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936. > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If anyone is interested in standardizing an "extension", I'd expect that they first define the base specification to which the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you point to the definition, for example, of the Authenticated mode in TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > - I believe that draft-gandhi-spring-twamp-srpm should be anchored at > IPPM WG as it does introduce the new PM protocol. > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > > > Since we don't have an IETF document that addressed these open questions, > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > > > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the light, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the discussion of "extension" to TWAMP Light. Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s not clear which example the sentence is referring to. Also, what is the basis for such an assumption? > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a normative reference while it is, by its nature, an Informational document. > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > GIM>> If that fits into the operational model of the new protocol you're defining. > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > GIM>> Thank you for the references. I couldn't find a definition of an object "Link" (capitalized) but only "link" (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link. > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > > > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not normative. I am familiar with the implementation of TWAMP Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does not maintain the state, the draft must define that as part of the specifying the behavior of the protocol. > > > - Further, in Section 3 the selection of UDP port explained as the > following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > > > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode > loss measurement probe messages.=E2=80=9D > GIM>> I've found that there's some misconception in the draft. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 4737 defines packet reordering metric), and packet duplication measurement. > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > GIM>> I've looked through Section 6 but I don't find anything specifically applicable to this draft we're discussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that explicitly would be the best way. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measurement uses port number different from the one used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protocol. > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draft-gandhi-ippm-twamp-srpm? > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > GIM>> I cannot assume what was the context of these RFCs. I've sketched a network diagram above to illustrate that a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band? > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > GIM>> Yes, but it appears that references to the two IOAM-related drafts have some purpose. What is it? How are these drafts related to draft-gandhi-spring-twamp-srpm? > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > GIM>> I think that theremust be some discussion on how the new protocol is configured. If TWAMP YANG data model can be augmented, I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol. > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > GIM>> True, direct loss measurement, in fact, is not active measurement and thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching counters can be done using numerous methods, e.g., SNMP, Netconf. > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > GIM>> So, can user configure a port number from the User Ports range? Or, can the same port number be used on the same system for a number of test sessions? I find the use of UDP port numbers being underspecified. > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > GIM>> I think that making it explicit would help. Also, that will highlight what is being introduced by *twamp-srpm drafts is, in fact, a new protocol to perform synthetic packet loss measurement. > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Could you please quote from any of these documents? > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came later), I don't see that there's any certainty in what is the sze of a test packet used in the direct-loss measurement. > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twamp-srpm? > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > GIM>> Perhaps you can propose some text, that would be helpful. > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > > > Yes, and Yes, and these are based on provisioning. > GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > GIM>> I cannot agree with your statement " The rest is the same as RFC 4656 and 5357" because the sender's direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the reflector. And that, in my opinion, is another clear indication that *twamp-srpm drafts define a new protocol, separate from OWAMP/TWAMP. > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > GIM>> So, LLA may be used as the source and destination addresses when testing an SR tunnel? > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > GIM>> You don't agree that the processing described cannot happen because of laws of physics or it wouldn't happen because no one will think of that? If the latter, I think that that is security threat. > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another new protocol OWAMP Light. And it is not clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-Test protocol by itself is neither in-band, nor out-of-band. It is the encapsulation of the TWAMP test packet that makes it either in-band or out-of-band. > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > GIM>> So, you believe that proposing to use the method described in RFC 8403 for the TWAMP packet is innovation? And what are the benefits of using the TWAMP test packet format in the Loopback mode? > > - What is the rationale for setting TTL/Hop Limit fields always to 255 > for IPv4, MPLS, and IPv6 (per Section 4.3.1)? > > This is as defined in Section 4.2 of RFC 5357 (Bullet 4). > GIM>> I believe you've misunderstood the text in RFC 5357. This bullet specifies the behavior of a Session-Reflector. It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Session-Reflector cannot access the TTL field, it MUST write 255 in the Sender TTL field. So, I think that my questions still remains. > > - Section 4.3.3 states that a zero-value UDP checksum may be used in > some scenarios. RFC 8085 allows that but in very specific cases that a= re > documented in detail in Section 3.4.1. Do you believe that the case of= this > protocol checks all the requirements for allowing the use of Zero UDP > checksum as specified in RFC 8085? Also, I believe that allowing the u= se of > Zero UDP checksum in some scenarios, this protocol introduces a securi= ty > threat that must be thoroughly analyzed in the Security Considerations > section. > > This is described in RFC 6936. It will be very specific to the UDP > port provisioned for TWAMP. We will add reference to RFC 6936 in Security > Section. > GIM>> I don't think that the reference is sufficient for the Securit Consideration. I'd expect some extended discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm protocol= . > > - Section 8 refers to "liveness monitoring of Links and SR Paths". > This appears as the replication of functionality provided by BFD/S-BFD > protocols. Is such comparison accurate? If it is, shouldn't the propos= al be > also reviewed by the BFD WG? > > TWAMP probe messages are used today for synthetic packet loss which > can also be used to detect connection loss (performance metric). The > section simply highlights this obvious metric. > GIM>> Can you point to a document that has defined "TWAMP probe messages are used today for synthetic packet loss"? Also, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the loss of path continuity? > > - I found the Security Section of the proposed protocol inadequately > terse and missing very important threats that this protocol introduces= in > the network. > > Other than referring RFC 6936 for zero checksum what else is missing= ? > Otherwise it is no different than RFC 8762 (STAMP). > GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use of source IP addresses, as mentioned above, appears to be another security risk introduced by *-twamp-srpm drafts. > > - draft-gandhi-ippm-twamp-srpm > > As I understand it, the motivation for the Loss Measurement mode defined > in this specification is to collect "in-profile" counters. Is that correc= t? > Do you see as essential for this mode that the query messages are in-band > with the flow being profiled? In your opinion, how using an out-of-band > method of collecting these counters, e.g., by using ICMP multi-part messa= ge > extension per RFC 4884, could affect the accuracy comparing with the meth= od > in this protocol? How the impact changes if extended ICMP messages are > in-band with the profiled flow? > > > > As mentioned earlier, I am not sure extending ICMP to do PM is a > good option here. Both TWAMP and OWAMP are widely deployed today for dela= y > and synthetic loss measurement. > GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as the connection between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet counters? > > - Section 3.1 introduces the new field, Sender Control Code. The > format of the packet, as I understand it, is presented in Figure 1. Wh= en > comparing with the format of Session-Sender's test packet defined in R= FC > 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields.= Are > these introduced by your proposal? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > - Also, it appears that the Sequence Number field in TWAMP > Session-Sender's test packet is absent in Figure 1. Is that intentiona= l? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > Thanks, > > Rakesh > > > > Regards, > > Greg > > > > > > On Thu, Oct 22, 2020 at 5:51 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for TWAMP > Light Messages*, *Loss Measurement Query Message Extensions*, and *Los= s > Measurement Response Message Extensions *were included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > - The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --000000000000d33cc305b42e2a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh,
    thank you for the response= to my comments.=C2=A0Please find my follow-up notes in-lined below under t= he GIM>> tag.

    Regards,
    Greg
    <= /div>
    O= n Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

    Please see replies inline with <RG&= gt;=E2=80=A6

    =C2=A0

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, i= ppm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, = IETF IPPM WG <ippm@ie= tf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review th= e "liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and c= omments in a single thread. I hope that would be acceptable and considered = by the SPRING WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, &= quot;congruent paths", are used in the documents without proper definitions. Other than that both drafts are readable and r= easonably well-written.

    =C2=A0

    <RG> We are ok to change Sender = to Session-Sender and Reflector to Session-Reflector if it helps.

    GIM>> I believe that= the consistency in terminology between the core RFC and what is intended a= s its extension is not only helpful to a reader but, to the best of my unde= rstanding, is required for IETF specifications. But I don't think that = switching the terminology will fix the fundamental issue with the proposal.= The operation that is required from the remote entity, whether it is refer= red to as responder or Session-Reflector, is not defined in Appendix I of R= FC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior requi= red, as described in the draft, cannot be characterized as an extension of = OWAMP, TWAMP, or TWAMP Light but presents a completely new protocol that, i= f there's a need in the new PM OAM protocol, must be properly defined.<= /div>

    <RG> There are many existing RFC= s that use term =E2=80=9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) an= d term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 5921, 6669) without defin= ing them. I suspect it is because these are well-known terms. Having said t= hat, we can add a reference for them if it helps.

    <= /div>
    GIM>> Thank you for listing these RFCs. = I think I need to clarify my questions. While a reference to any of RFCs yo= u've mentioned, I don't think that will address my concern. In revi= ewed documents, "Link" is capitalized while referenced RFCs used = the lower case form for the term "link". Can these be used interc= hangeably? Do they refer to the same network object?
    Now I'll= try to illustrate my concern with using the term "congruent path"= ; in these drafts (using ASCII-art):
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G-----= -------H
    Consider an SR tunnel from A to F that traverses the net= work as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of= "congruent" as "two figures or objects are congruent if the= y have the same shape and size, or if one has the same shape and size as th= e mirror image of the other", it looks as the path A-B-G-H-E-F is cong= ruent to that SR tunnel. But a packet of an active OAM intended to monitor = a flow over the SR tunnel is out-of-band relative to that flow and will not= produce any meaningful measurement. Of course, for the case of the extensi= ons in drafts *-twamp-srpm, direct loss measurement can be performed, as in= formation collected from node F and packets that collect the counters are n= ot required to be in-band with the monitored flow. So, this example, in my = opinion, illustrates two of my concerns:
    • using a congruent path for active performance measurement, e.g.,= TWAMP or TWAMP Light, may produce information that does not reflect the co= ndition experienced by the monitored flow. It seems that the terminology sh= ould reflect the fundamental requirement of ensuring that active OAM test p= ackets are in-band with the monitored flow.
    • there are no technical requirements to justify using in-band test packe= ts for direct packet loss measurement. In fact, using the in-band method fo= r collecting in-profile counters leads to a waste of bandwidth, which may h= ave a negative impact on services that require low-latency and/or low packe= t loss. As demonstrated in this example, direct packet loss can be performe= d using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications= based on YANG data model.
    =C2=A0

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile&q= uot; packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the e= xisting OAM mechanisms like ICMP.

    =C2=A0

    <RG> There is a requirement to m= easure performance delay as well as synthetic and direct-mode packet loss i= n segment-routing networks. OWAMP and TWAMP protocols are widely deployed f= or performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for LM is a good option he= re.

    GIM>> I= agree with the=C2=A0requirements you've listed (though the=C2=A0SPRING WG OAM requirements document=C2=A0has been aban= doned and expired 3+ years ago). I believe that there's no sufficient t= echnical reason=C2=A0to use OWAMP/TWAMP for exclusive direct packet loss me= asurement.=C2=A0=C2=A0
    =

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    <= /div>
    GIM>> I don't think that a mere refe= rence sufficiently explains why the use of zero UDP checksum in IPv6 header= is not decremental, does not create a security risk for the protocol.
    =C2=A0

    To summarize my review of=C2=A0these two drafts:<= /u>

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurem= ent messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines = "the probe and response messages". Could you give a more specific= reference or provide the text that, in your opinion, defines such messages= ? But I'm more concerned with the direction of "extending" no= n-protocol referred to as "TWAMP Light". As a contributor to BBF&= #39;s=C2=A0TR-390, I'm have learned how different are existing implemen= tations of TWAMP Light. And that is also noted in = EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

    • several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, re= quire detailed security analysis, which is currently absent;<= /li>

    <RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I&#= 39;ve noted above that a simple reference does not sufficiently explains wh= y the use of zero UDP checksum in IPv6 header is not decremental, does not = create a security risk for the protocol. I believe that the proposal to use= zero UDP header checksum requires extensive analysis, using the analysis p= rovided in RFC 6936.

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment quoted as=
:
     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0 track is more appropriate for th= is specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS.

    =
    GIM>> As explained in RFC 8545 "TWAMP Li= ght is an idea", not a protocol. If anyone is interested in standardiz= ing an "extension", I'd expect that they first define the bas= e specification to which the extension applies. I might have missed the def= inition of TWAMP Light protocol in the draft. Could you point to the defini= tion, for example, of the Authenticated mode in TWAMP Light in the=C2=A0dra= ft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

    • I believe that=C2=A0draft-gandhi-spring-twamp-srpm should be anchored at IP= PM WG as it does introduce the new PM protocol.

    <RG> The = TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only defines SR PM procedures= .

    =C2=A0

    Below, please find my detailed=C2=A0comments, questi= ons on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is= required to make it a standard is well-explained in Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long= quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0

    Since we don't have an IETF document that addres= sed these open questions, I don't think we can have a draft that propos= es extensions to a non-standard mechanism (Appendix is for Informational ma= terial, as I understand it) on the Standard track.

    =C2=A0

    <RG> This was to address your previous comment quoted as=

     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

    <RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thu= s the light, simpler, version of TWAMP-Test component of TWAMP protocol. I = cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authen= ticated mode of TWAMP Light. Also, I'll prefer not to refer to RFC 8762= STAMP in the discussion of "extension" to TWAMP Light.

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UD= P paths"?

    =C2=A0

    <RG> The Appendix I of RFC 5357 has following text. We c=
an reword and match the exact text if you prefer.

    =C2=A0
    

    =
=E2=80=9CThis example eliminate=
s the need for the TWAMP-Control protocol, and
    

    =C2=A0=C2=A0 assumes that the Ses=
sion-Reflector is configured=E2=80=9D
    <= /div>
    GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0
    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I a= s reference in the next revision. Extensions are defined in draft-gandhi-ip= pm-twamp-srpm, we can add this reference.

    GIM>> The problem, in my view, is that Appen= dix I of RFC 5357 must be a normative reference while it is, by its nature,= an Informational document.=C2=A0

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2= =80=9Ctypically=E2=80=9D from the sentence?

    GIM>> If that fits into the operational mo= del of the new protocol you're defining.=C2=A0

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the refer= ences. I couldn't find a definition of an object "Link" (capi= talized) but only "link" (lower case). Hence, since the draft con= sistently uses the capitalized form, I consider it to be something else, so= mething different from a link.=C2=A0
    <= div>

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creatin= g a state at the Session-Reflector, to achieve one-way delay and synthetic loss measurement on a bidirectional= SR tunnel?

    =C2=A0

    <RG> Quoting the text from Appen= dix I in RFC 5357. We can quote the text as is.

    =E2=80=9CIn the case of TWAMP Lig=
ht, the Session-Reflector does not necessarily have knowledge of the sessio=
n state. =E2=80=9C
    <= div>GIM>> By the informational nature of Appendix I, the text is not = normative. I am familiar with the implementation of TWAMP Light which does = maintain the session state and thus supports one-way packet loss measuremen= t. If you require that the remote node does not maintain the state, the dra= ft must define that as part of the specifying the behavior of the protocol.=

    =C2=A0

    • Further, in Section 3 the selection of UDP port explained as the following:=

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
    =C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
    =C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
    =C2=A0 =C2=A0measurement probe messages.

    To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Bes= ides, in TWAMP delay and packet loss are measured in the same test session, using the same flow of TWAMP-Test packe= ts.

    =C2=A0

    <RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify a= s =E2=80=9CThis UDP port however, is not used for direct-mode loss measurement probe messages.=E2= =80=9D

    GIM>>= ; I've found that there's some misconception in the draft. RFC 8545= re-assigned UDP port 862 not for "delay measurement probe messages&qu= ot; but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports pac= ket delay, packet loss, reordering (RFC 4737 defines packet reordering metr= ic), and packet duplication measurement.

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    =C2=A0

    <RG> Please see section 6 in [RF= C6335]. We can cite the range which will be the same as used in [RFC8762]. = This was also discussed earlier.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 bu= t I don't find anything specifically applicable to this draft we're= discussing. If the protocol to use UDP port numbers from the Dynamic ports= range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

    =C2=A0

    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

    GIM= >> Can UDP port 862 be used? Also, requiring that the direct-loss mea= surement uses port number different from the one used by a TWAMP-Test packe= t, in my opinion, is another indication that this is the definition of a di= fferent from TWAMP Light PM OAM protocol.

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the s= ame procedure as defined in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Tes= t packets as well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2= =A0

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" = means. The definition of=C2=A0congruency in geometry tells us that an objec= t B is congruent=C2=A0to object A if it has the same shape and size, but is= allowed to flip, slide or turn. How a path can be congruent to another path?

    <RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Havi= ng said that, we can add a reference for it if it helps reader.

    GI= M>> I cannot assume what was the context of these RFCs. I've sket= ched a network diagram above to illustrate=C2=A0that a "congruent path= " may well lead to out-of-band path. Is that the intention of the auth= ors of the draft to use this protocol out-of-band?

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, = IOAM is outside the scope.

    GIM>> Yes, but it appears that references to the two IOAM-r= elated drafts have some purpose. What is it? How are these drafts related t= o=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some = discussion on how the new protocol is configured. If TWAMP YANG data model = can be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ip= pm-twamp-srpm. But I couldn't find anything about the configuration of = the protocol.=C2=A0
    =

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

    GIM>> True, d= irect loss measurement, in fact, is not active measurement and thus is outs= ide the scope of Two-Way Active Measurement Protocol (TWAMP). The direct-lo= ss measurement is, by the definition of RFC 7799, passive measurement metho= d and fetching counters can be done using numerous methods, e.g., SNMP, Net= conf.

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used f= or the Delay measurement is unique throughout the particular domain?=

    <RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

    GIM>> S= o, can user configure a port number from the User Ports range? Or, can the = same port number be used on the same system for a number of test sessions? = I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.

    GIM>> I think that m= aking it explicit would help. Also, that will highlight what is being intro= duced by *twamp-srpm drafts is, in fact, a new protocol to perform syntheti= c packet loss measurement.=C2=A0
    =

    =

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

    GIM>= > I cannot find any reference to a query format in RFCs 4656/5357. Could= you please quote from any of these documents?

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted below:<=
/u>
    =E2=80=9CFor symmetrical size query and response messages as def=
ined in [RFC6038],=E2=80=9D
    GIM>> RFC 6038 defines an extension to RFC 5357 for OPTI= ONAL use of the symmetrical test packets. Since *-twamp-srpm proposals do n= ot use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing a= bout that either (in part because RFC 6038 came later), I don't see tha= t there's any certainty in what is the sze of a test packet used in the= direct-loss measurement.=C2=A0
    <= div>
    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This= is same as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format.= Is that the case for *-twamp-srpm?=C2=A0

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

    GIM>> Pe= rhaps you can propose some text, that would be helpful.=C2=A0

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP po= rt numbers?

    =C2=A0

    <RG> Yes,= and Yes, and these are based on provisioning.

    =
    GIM>> But that requirement is far outsi= de the TWAMP, as defined in RFC 5357.
    =

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and= 5357.

    GIM>>= ; I cannot agree with your statement " The rest is the same as RFC 4656 and 5357" because the sender's di= rect-loss format does not have Error Estimate field, Thus, a reflected pack= et does not have Sender's Error Estimate, nor Error Estimate of the ref= lector. And that, in my opinion, is another clear indication that *twamp-sr= pm drafts define a new protocol, separate from OWAMP/TWAMP.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am= assuming this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "= ;pre-routed". What does it mean?=C2=A0

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am= assuming this is well-known (e.g. RFC 5613).

    <= /div>
    GIM>> So, LLA may be used as the source = and destination addresses when testing an SR tunnel?=C2=A0

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

    GIM>> You don't agree that the processing described cannot happe= n because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

    =

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    =C2=A0

    <RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does not speci= fy that it defines another new protocol OWAMP Light. And it is not clear wh= at you reference as "this is existing behavior". Is it to referen= ce behavior of TWAMP test packet? But the behavior of the TWAMP-Test protoc= ol by itself is neither in-band, nor out-of-band. It is the encapsulation o= f the TWAMP test packet that makes it either in-band or out-of-band.=C2=A0<= /div>

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

    GIM>> I don'= ;t think that the reference is sufficient for the Securit=C2=A0Consideratio= n. I'd expect some extended discussion on why using zero UDP header che= cksum is not a security threat for *twamp-srpm=C2=A0 protocol.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

    <RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

    <= /div>
    GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the = loss of path continuity?

    <= u>

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant= to *twamp-srpm drafts. The use of source IP addresses, as mentioned above,= appears to be another security risk introduced by *-twamp-srpm drafts.=C2= =A0

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that = the query messages are in-band with the flow being profiled? In your opinion, how using an out-of-band method of collec= ting these counters, e.g., by using ICMP multi-part=C2=A0message extension = per RFC 4884, could affect the accuracy comparing with the method in this p= rotocol? How the impact changes if extended ICMP messages are in-band with the profiled flow?

    =C2=A0

    <RG> As m= entioned earlier, I am not sure extending ICMP to do PM = is a good option here. Both TWAMP and OWAMP are widely deployed today for d= elay and synthetic loss measurement.

    GIM>> What is the reason mentioning OWAMP? Are dr= afts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as the = connection between using active measurement methods to measure packet delay= and packet loss, on one hand, and collecting packet counters?

    • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP i= n Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender'= ;s test packet is absent in Figure 1. Is that intentional?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    Thanks,<= u>

    Rakesh

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    On Thu, Oct 22, 2020 at 5:51 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0<= u>

    =C2=A0

    Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

    =C2=A0

    =C2=A0

    These conclusions were discussed with the authors of= =C2=A0https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:<= /u>

    =C2=A0

    =C2=A0

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like = to thank the authors for their efforts in this matter.=

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    =C2=A0

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

    =C2=A0

    --000000000000d33cc305b42e2a1b-- From nobody Sun Nov 15 23:11:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F6E3A14A9; Sun, 15 Nov 2020 23:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AXvq7YG9ajrL; Sun, 15 Nov 2020 23:11:35 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7F73A14A5; Sun, 15 Nov 2020 23:11:35 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CZKv85yYXz67Cml; Mon, 16 Nov 2020 15:09:24 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 16 Nov 2020 08:11:32 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 16 Nov 2020 08:11:32 +0100 From: Giuseppe Fioccola To: "Ketan Talaulikar (ketant)" , Susan Hares , "idr@ietf.org" CC: "spring@ietf.org" Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSAAkCn8MA== Date: Mon, 16 Nov 2020 07:11:32 +0000 Message-ID: <832cd20c50a941e19d06e41b339a6c8c@huawei.com> References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.215.142] Content-Type: multipart/alternative; boundary="_000_832cd20c50a941e19d06e41b339a6c8chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 07:11:38 -0000 --_000_832cd20c50a941e19d06e41b339a6c8chuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thanks a lot for your revision. My answers inline tagged as [GF] Regards, Giuseppe From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, November 13, 2020 12:12 PM To: Giuseppe Fioccola ; Susan Hares ; idr@ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Giuseppe, First of all, thanks for making the updates to the document to clarify the = objective and applicability of IFIT and this draft extensions specifically = to the SR Policy signalled by BGP. A good part of the puzzle is at least cl= earer to me now. Sec 3 says (and I am trying to paraphrase here - so please correct me), tha= t these IFIT attributes (new TLVs) are signalled via BGP along with the SR = Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for= that SR Policy. This way all traffic steered over that SR Policy with have= the IOAM and Alt Marking headers inserted on them. [GF]: Yes, this is correct. Is there a Spring WG document that describes the implications of actually h= ow this would get applied to the SR Policy forwarding planes (SR-MPLS and S= Rv6) and what types of Steering would be possible to be used for such SR Po= licies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-p= olicy-09#section-8). ? E.g. if a packet is arriving at the headend with a s= tack of labels and gets steered via BSID into such an SR Policy where "IFIT= is applied", how does that work? [GF]: Good point, in the next revision we can add some considerations on th= e Steering into an SR Policy. This can be useful also for the data plane dr= afts. Regarding SRv6, the relevant documents are already adopted: draft-iet= f-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for Alt= Mark. These Options are defined for IPv6 and can be used with any Routing H= eader (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandh= i-spring-ioam-sr-mpls) are still individual. Sec 6 (SR Policy operations with IFIT Attributes) says the following: The validation of the individual fields of the IFIT Attributes sub-TLVs are handled by the SRPM (SR Policy Module). However, I am still missing a document that describes how these are actuall= y "handled" by the SRPM? [GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-leve= l functionality of SRPM. I think we need to include more details in draft-q= in-idr-sr-policy-ifit in order to describe the functionalities that are spe= cific for IFIT (IOAM and AltMark). I understand that there is a similar draft in PCE WG as well, but it is als= o missing this information. [GF]: I can address this comment in both drafts. My concern is that we have documents for the protocol signaling mechanisms = for IFIT but I am not able to locate a document that describes how exactly = this information is going to get used/applied by SRPM. [GF]: Some details about the SRPM operation for IFIT could be added in this= draft. Please do point/clarify if I am missing something here. Thanks, Ketan From: Idr > On Behalf Of = Giuseppe Fioccola Sent: 02 November 2020 22:28 To: Susan Hares >; idr@ietf.org Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Dear Susan, All, I'm not aware of any IPR related to this draft. I also support its adoption= as coauthor. Best Regards, Giuseppe From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, November 2, 2020 6:57 AM To: idr@ietf.org Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04= .txt (11/1/2020 to 11/16/2020) This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.t= xt (11/2/2020 to 11/16/2020). The draft can be accessed at: https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/ The authors should provide IPR statements by 11/5/2020 so the IDR WG can co= nsider the IPR status in their decision. This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the= SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel typ= es. Within the IFIT sub-TLV value field, 5 sub-TLVs may be included (4 fo= r IOAM and 1 for Enhanced Alternate Marking). The IDR co-chairs thank the authors for their patience. The WG adoption ca= ll for this draft has been delayed by the process of switching shepherds fo= r BGP Tunnel Encaps draft. Many BESS and IDR drafts currently refer to the= BGP tunnel encapsulation drafts. In your review of this draft, please differentiate between the following: * Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing te= chnology, * Support/rejection of alternate marking as a IP routing technology, * Support/rejection of adding new sub-TLVS for SR Policy tunnel type of= BGP Tunnel Encap Attribute, and * Specific issues with the descriptions of these features in the draft. Cheers, Susan Hares --_000_832cd20c50a941e19d06e41b339a6c8chuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Ketan,

    Thanks a lot for your = revision.

    My answers inline tagg= ed as [GF]

     

    Regards,

     

    Giuseppe

     

    From: Ketan Talaulikar (ketant) [mailto:ketan= t@cisco.com]
    Sent: Friday, November 13, 2020 12:12 PM
    To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Ha= res <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Giuseppe,<= /p>

     

    First of all, thanks for making= the updates to the document to clarify the objective and applicability of = IFIT and this draft extensions specifically to the SR Policy signalled by B= GP. A good part of the puzzle is at least clearer to me now.

     

    Sec 3 says (and I am trying to = paraphrase here – so please correct me), that these IFIT attributes (= new TLVs) are signalled via BGP along with the SR Policy Candidate Path to = “enable IOAM and Alternate Marking” mechanisms for that SR Policy. This way all traffic steered over that SR Policy with = have the IOAM and Alt Marking headers inserted on them.

    &n= bsp;

    [GF]: Yes, this is cor= rect.=

     

    Is there a Spring WG document t= hat describes the implications of actually how this would get applied to th= e SR Policy forwarding planes (SR-MPLS and SRv6) and what types of Steering= would be possible to be used for such SR Policies (ref https://to= ols.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-8). ? E.g. if a packet is arriving at the headend with a stack of labels and gets ste= ered via BSID into such an SR Policy where “IFIT is applied”, h= ow does that work?

    &n= bsp;

    [GF]: Good point, in t= he next revision we can add some considerations on the Steering into an SR = Policy. This can be useful also for the data plane drafts. Regarding SRv6, = the relevant documents are already adopted: draft-ietf-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-ma= rk for AltMark. These Options are defined for IPv6 and can be used with any= Routing Header (including SRH). For SR-MPLS the relevant documents (e.g. d= raft-gandhi-spring-ioam-sr-mpls) are still individual.

    &n= bsp;

     

    Sec 6 (SR Policy operations wit= h IFIT Attributes) says the following:

     

    The validation of the individua= l fields of the IFIT

       Attributes sub-TLV= s are handled by the SRPM (SR Policy Module).

     

    However, I am still missing a d= ocument that describes how these are actually “handled” by the = SRPM?

     

    [GF]: draft-ietf-idr-s= egment-routing-te-policy also mentions some high-level functionality of SRP= M. I think we need to include more details in draft-qin-idr-sr-policy-ifit = in order to describe the functionalities that are specific for IFIT (IOAM and AltMark).=

     

    I understand that there is a si= milar draft in PCE WG as well, but it is also missing this information.

     

    [GF]: I can address th= is comment in both drafts.

     

    My concern is that we have docu= ments for the protocol signaling mechanisms for IFIT but I am not able to l= ocate a document that describes how exactly this information is going to ge= t used/applied by SRPM.

     

    [GF]: Some details abo= ut the SRPM operation for IFIT could be added in this draft.

     

    Please do point/clarify if I am= missing something here.

     

    Thanks,

    Ketan

     

    From: Idr <idr-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
    Sent: 02 November 2020 22:28
    To: Susan Hares <shares@ndzh.c= om>; idr@ietf.org
    Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Dear Susan, All,<= /o:p>

    I'm not aware of any I= PR related to this draft. I also support its adoption as coauthor.

     

    Best Regards,

     

    Giuseppe

     

     

    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
    Sent: Monday, November 2, 2020 6:57 AM
    To: idr@ietf.org
    Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-= ifit-04.txt (11/1/2020 to 11/16/2020)

     

    This begins a 2 week WG adoption call for draft-qin-= idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

     

    The draft can be accessed at:

    https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-= ls-path-mtu/

     

    The authors should provide IPR statements by 11/5/20= 20 so the IDR WG can consider the IPR status in their

    decision.

     

    This draft adds the IFIT sub-TLV to the BGP Tunnel E= ncaps attribute for the SR policy tunnel type. This sub-TLV is only valid f= or SR Policy tunnel types.  Within the IFIT  sub-TLV value field,= 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).   

     

    The IDR co-chairs thank the authors for their patien= ce.  The WG adoption call for this draft has been delayed by the proce= ss of switching shepherds for BGP Tunnel Encaps draft.  Many BESS and = IDR drafts currently refer to the BGP tunnel encapsulation drafts.

     

    In your review of this draft, please differentiate b= etween the following:

    • Support/rejection= of In-situ Flow Telemetry (IFIT) as a IP routing technology,
    • Support/rejecti= on of alternate marking as a IP routing technology,  
      • <= li class=3D"MsoNormal" style=3D"mso-list:l1 level1 lfo3">Support/rejection = of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attrib= ute, and   
    • Specific issues with the descriptions of these features= in the draft.

     

    Cheers, Susan Hares

     

     

     

    --_000_832cd20c50a941e19d06e41b339a6c8chuaweicom_-- From nobody Sun Nov 15 23:39:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D776C3A14F4; Sun, 15 Nov 2020 23:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=UsUp1skY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bFtDIyBu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Biqhc4Kx5wAZ; Sun, 15 Nov 2020 23:39:13 -0800 (PST) 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 564433A0816; Sun, 15 Nov 2020 23:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28616; q=dns/txt; s=iport; t=1605512353; x=1606721953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wodjsNmFuTX8QiLkEdqNh2R81igUNVZUgEYEqqo/dHs=; b=UsUp1skYc66DQC+Q9ZxEewbHEYT/714PHaSH+jXMEwXq0uzJUa2+vGjF 8RjsmsYwc1dNqtSmMUA6imSG7XEU/uqXxRQ1g4q7n8s/+W2GCQ9ru69Fx 63ayG9OQWUz58lgxyYLfzv5pucwMjQGQ/fvBCadpvddFH87wP9dxE91YR Q=; X-IPAS-Result: =?us-ascii?q?A0AhBQCDKrJffYgNJK1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BIy8jLntZLy6IBQONV4EFl36BQoERA1QLAQEBDQEBJQgCBAEBhEoCgh4CJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDEgsQEwEBKQ4BD?= =?us-ascii?q?wIBCBEEAQEhAwQHMhQJCAEBBAENBQgagwWBflcDLgEOoS0CgTyIaHSBNIMEA?= =?us-ascii?q?QEFgUdBgnoYghADBoE4gnOKTRuBQT+BEUOBUUkHLj6BBIFZAQECAQGBITwrC?= =?us-ascii?q?YMUgiyQLw+KSIwOkR4Kgm2JD4Zki0SDGYoWlEqHXIt2in2SboJoAgQCBAUCD?= =?us-ascii?q?gEBBYFrIYFZcBWDJFAXAg2OHwwXFIM6hRSFRHQ3AgYKAQEDCXyLCC2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AX6l/Jx9cScTC/f9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,481,1596499200"; d="scan'208,217";a="590923293" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2020 07:39:12 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AG7dBpQ008083 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2020 07:39:12 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Nov 2020 01:39:11 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Nov 2020 01:39:11 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 16 Nov 2020 01:39:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XjcBjKRmflG/qUP/0MQVguOKUug6ydzYmeKD7AM7AWp7R32NxuN7azw+QB8oQRGTmCOBvG7S1ZTdSYM/k88x2ZWZipOk9JKFlyh/4sDrXVuxnK45MInIyMWQ7uEE5vf5lzKyRTRi2JtXBeF0gKsfr87BPdi6EVyRZmdN9Ecrv6jEJFFM4MgQYQbDOPJHJLFlibU9uXYV55BwIREEEXTVTnwkGO2Ijxa3wKNoR2sty3XCuuQqbs1k3bzzNpnMXwvPMWx0TqofNYZPu3VgXjJs9FRfeVDGyjzv6ScpN9pCtly4WE/4IFIyW/fGIadn8yv4etTuFbvF6HhQpPBoJ0E/9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VYFsXYd6fGxIt0CO4xLn+ca3s2TRASXfCEadqeXqjao=; b=NgBV9nQRWkd2Yek3W67/qD5ivfun4cvMXlP7AynYyIF9dYLBZ5Q+9eiRS52Gv8YlAb2Tabzcu1PJ/yfjO/JpUlAIMtLF8CKwQbYJhTva+pPt1Jg+hUQkSWCNx0X+gOjbv9ncugSnwQUMaN7ENSOHqSCy1c6llAcbAcAjmnQti1VeMdRSemKEtBYLoXuAjgWQHZLG8aVbIDpRY/s9G6SG5DvIOmq6+0utNPxLptu71DpQr6GvwH0gXt+8WJ87BXcdp4ghvkzoDN7E1RqCwxljZnh77K08cwIKGZ16Hq+VzRZO7HbElgARqUZ3pVXQHDM9x6BEcs9ZOPQpZeQKQJd7gA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VYFsXYd6fGxIt0CO4xLn+ca3s2TRASXfCEadqeXqjao=; b=bFtDIyBu1nFUzQR3Z1dT//ulFZbPKWR/+lnwdn3SY/gD+b6nq5X9tSBe+jB3/fgh3vJ2zOdiyN50z+6h/zi5JMCKWL0xZrX51ishsMYr/sOQtx6Phu8XwK+FjPRGgu/sBfVkdq73UoA3fnL/MEytVFj66Do0rzCJ6ZjuxpQi6aQ= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1406.namprd11.prod.outlook.com (2603:10b6:300:23::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Mon, 16 Nov 2020 07:39:10 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3564.028; Mon, 16 Nov 2020 07:39:09 +0000 From: "Ketan Talaulikar (ketant)" To: Giuseppe Fioccola , Susan Hares , "idr@ietf.org" CC: "spring@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSAAkCn8MAABrv4Q Date: Mon, 16 Nov 2020 07:39:09 +0000 Message-ID: References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> <832cd20c50a941e19d06e41b339a6c8c@huawei.com> In-Reply-To: <832cd20c50a941e19d06e41b339a6c8c@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2405:201:1006:a85b:5da7:1662:f466:12e3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87e4c56e-2620-499e-2475-08d88a02b4bd x-ms-traffictypediagnostic: MWHPR11MB1406: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3CGAWxEP0Z/zVsUM1i936lCRVQIyDcFVHVLO3Iq7bMZLazRzBp7ddMZq2r/MbDRiW62eYw5Jr+5Gm5gxW8Llp8SG4qGWNqRo+SK8ebjxzlTGo1GvcDyO19MEGJPVut4T12kPLPaEL6II6CLF9aPoRczLBMaQp9ImpYmTWdhRK1ct8+JNoh22wqMb5Tcs0vIwkaLx9hHgASIANRIEdTbduw/uHV5950vYFhGvyhbQa48l9HL585pOejawXhyzxAgGKhNUeIIcU2sNbMNjwW23Rr0gYouT8dqOO7IP+d9sBLENjNgGeB/lfbLDKOmr6EzV0sbC12Yz+fHqddI/GcgIr+gFqUIUlfg7lo0IQj0yZn4Df8vRwVUh24hNWe8Li7uX+9KHM+P/ejjK7T1c6Jn/bg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(366004)(376002)(396003)(346002)(166002)(52536014)(83380400001)(86362001)(55016002)(8676002)(5660300002)(6506007)(53546011)(110136005)(9686003)(316002)(7696005)(54906003)(186003)(64756008)(66476007)(66556008)(71200400001)(66946007)(76116006)(66446008)(2906002)(33656002)(966005)(8936002)(4326008)(478600001)(9326002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?etVDHxjk5yQxqNjJ65ICtmbGJz7tGPdM6Q83BKq3MXpEn2U0dwZPxnrLmCd7?= =?us-ascii?Q?9CaXPwhx2uDIm1jRIQJLmqjx+RBiIRH95NcDoEXvJB0XBywB6UIL7asw3QTI?= =?us-ascii?Q?V1eIbTbVFR+6+xaHvIUBdR0PugFUALVPKyBG5lCiuzET1qhkehWmt6aamvoI?= =?us-ascii?Q?CPOn+VxoEDeg8VoxOgaZt00cSu5pXvyzL+ZXe+VFiKIK3PSpIafMCOACVqUZ?= =?us-ascii?Q?VweOC+x61HywK1Y/TaNBzmtipw7W+1mye1piOT9sIIgVojK6iZyIV1CqLe4n?= =?us-ascii?Q?3MykRCkq4vhxybbTCTJpct/Eg2rGNNhe7/DDN9gDqDXkudk5QNgKGr3mwxEf?= =?us-ascii?Q?NhAqW6h8JPgmIs/pJwD6Kd+WTos0x/rxSGPsRojh3CM0DBR9VcwzWwOWXlCT?= =?us-ascii?Q?4eTCmXOVypjTTH6aorGR97Gkgw9fBoGPcV1KvFShUHRZvs8AyIY09Gz5/hGu?= =?us-ascii?Q?0bUMQo7REtdZMQrZoA20glODYYb+CxUFYJwZTuNaPrcbepN7EoMKhs9mpi3p?= =?us-ascii?Q?gjHhXF0J5G85tuzlJlSosrqTq61kimB2WDbfT2f+5yEhQ91YIYsEBQiONt3t?= =?us-ascii?Q?BijTbGk3M66igPUdVIksnOJZmO0/3XcT4BAaK+qr2i1zOEdaTYeUW7Va01Hv?= =?us-ascii?Q?Hx9/aZeseJPmXD9AltnDftOGRSWyHgaCmQ4TxeUVrBTt4/XV9JTAZ690dxkI?= =?us-ascii?Q?M/Z7G2MjvceAtJAqJdA7sqjurzoWF3+MWcQPiD+0Kb5ThSdDCHRpMsz0ovA5?= =?us-ascii?Q?kCI3xUMqJlTs412MXDsXUbAAjogNot2eBPt119fl0dkiBXkzJ4YbaKbjaF3h?= =?us-ascii?Q?1bwPVENGW44lEXAJJ2c3lKGDHdMEbeLStcYvn/f2ZvzTjF66rQatNDY8vyW7?= =?us-ascii?Q?f/1+apjOUGf+XmENUtXeuZ2N8dutqcB85TSUsy2XOv5JaX7Qs3c7ObjMM1r7?= =?us-ascii?Q?LospnIHDCW0T/VrYX9LMqw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457061E12701246675DBD374C1E30MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87e4c56e-2620-499e-2475-08d88a02b4bd X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 07:39:09.8632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0MfiHNU/6OQxQaE9ACiHj/4lzJ2uBdcUpdFIkqLfGBVG48d64rlLwAZt5NM4hI1Qlh4hMGERhTl855DQQpzGlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1406 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [spring] [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 07:39:17 -0000 --_000_MW3PR11MB457061E12701246675DBD374C1E30MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Giuseppe, Thanks for your response. Perhaps my point was not clear and so let me plea= se clarify. I am seeing the IFIT signalling related drafts for BGP and PCEP (it was als= o there in LSR?) in their individual protocol working groups. While what th= ese protocols are doing is only "carrying" (in case of BGP somewhat opaquel= y) the information and conveying it to the SR Policy Module (SRPM). The fol= lowing may clarify the picture better : https://tools.ietf.org/html/draft-f= ilsfils-spring-sr-policy-considerations-06#section-2 The key part of how this is handled by the SRPM, the related procedures and= setup in the forwarding plane along with their applicability and any other= considerations should be (IMHO) done in a Spring document. This is my sugg= estion and request to the authors - not to add all of this into an IDR docu= ment since that is not where you will find the right expertise to review th= ese aspects. Without that, it might seem like an uncoordinated protocol development effo= rt for those of us who are not intimately aware of all the IFIT internals/d= etails. Rest, I will leave it up to the chairs of the WGs involved. Thanks, Ketan From: Giuseppe Fioccola Sent: 16 November 2020 12:42 To: Ketan Talaulikar (ketant) ; Susan Hares ; idr@ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Ketan, Thanks a lot for your revision. My answers inline tagged as [GF] Regards, Giuseppe From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, November 13, 2020 12:12 PM To: Giuseppe Fioccola >; Susan Hares >; idr@= ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Giuseppe, First of all, thanks for making the updates to the document to clarify the = objective and applicability of IFIT and this draft extensions specifically = to the SR Policy signalled by BGP. A good part of the puzzle is at least cl= earer to me now. Sec 3 says (and I am trying to paraphrase here - so please correct me), tha= t these IFIT attributes (new TLVs) are signalled via BGP along with the SR = Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for= that SR Policy. This way all traffic steered over that SR Policy with have= the IOAM and Alt Marking headers inserted on them. [GF]: Yes, this is correct. Is there a Spring WG document that describes the implications of actually h= ow this would get applied to the SR Policy forwarding planes (SR-MPLS and S= Rv6) and what types of Steering would be possible to be used for such SR Po= licies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-p= olicy-09#section-8). ? E.g. if a packet is arriving at the headend with a s= tack of labels and gets steered via BSID into such an SR Policy where "IFIT= is applied", how does that work? [GF]: Good point, in the next revision we can add some considerations on th= e Steering into an SR Policy. This can be useful also for the data plane dr= afts. Regarding SRv6, the relevant documents are already adopted: draft-iet= f-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for Alt= Mark. These Options are defined for IPv6 and can be used with any Routing H= eader (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandh= i-spring-ioam-sr-mpls) are still individual. Sec 6 (SR Policy operations with IFIT Attributes) says the following: The validation of the individual fields of the IFIT Attributes sub-TLVs are handled by the SRPM (SR Policy Module). However, I am still missing a document that describes how these are actuall= y "handled" by the SRPM? [GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-leve= l functionality of SRPM. I think we need to include more details in draft-q= in-idr-sr-policy-ifit in order to describe the functionalities that are spe= cific for IFIT (IOAM and AltMark). I understand that there is a similar draft in PCE WG as well, but it is als= o missing this information. [GF]: I can address this comment in both drafts. My concern is that we have documents for the protocol signaling mechanisms = for IFIT but I am not able to locate a document that describes how exactly = this information is going to get used/applied by SRPM. [GF]: Some details about the SRPM operation for IFIT could be added in this= draft. Please do point/clarify if I am missing something here. Thanks, Ketan From: Idr > On Behalf Of = Giuseppe Fioccola Sent: 02 November 2020 22:28 To: Susan Hares >; idr@ietf.org Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Dear Susan, All, I'm not aware of any IPR related to this draft. I also support its adoption= as coauthor. Best Regards, Giuseppe From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, November 2, 2020 6:57 AM To: idr@ietf.org Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04= .txt (11/1/2020 to 11/16/2020) This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.t= xt (11/2/2020 to 11/16/2020). The draft can be accessed at: https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/ The authors should provide IPR statements by 11/5/2020 so the IDR WG can co= nsider the IPR status in their decision. This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the= SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel typ= es. Within the IFIT sub-TLV value field, 5 sub-TLVs may be included (4 fo= r IOAM and 1 for Enhanced Alternate Marking). The IDR co-chairs thank the authors for their patience. The WG adoption ca= ll for this draft has been delayed by the process of switching shepherds fo= r BGP Tunnel Encaps draft. Many BESS and IDR drafts currently refer to the= BGP tunnel encapsulation drafts. In your review of this draft, please differentiate between the following: * Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing te= chnology, * Support/rejection of alternate marking as a IP routing technology, * Support/rejection of adding new sub-TLVS for SR Policy tunnel type of= BGP Tunnel Encap Attribute, and * Specific issues with the descriptions of these features in the draft. Cheers, Susan Hares --_000_MW3PR11MB457061E12701246675DBD374C1E30MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Giusep= pe,

    &nbs= p;

    Thanks fo= r your response. Perhaps my point was not clear and so let me please clarif= y.

    &nbs= p;

    I am seei= ng the IFIT signalling related drafts for BGP and PCEP (it was also there i= n LSR?) in their individual protocol working groups. While what these proto= cols are doing is only “carrying” (in case of BGP somewhat opaquely) the information and conveying it to the SR = Policy Module (SRPM). The following may clarify the picture better : https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-= 06#section-2

    &nbs= p;

    The key p= art of how this is handled by the SRPM, the related procedures and setup in= the forwarding plane along with their applicability and any other consider= ations should be (IMHO) done in a Spring document. This is my suggestion and request to the authors – not to = add all of this into an IDR document since that is not where you will find = the right expertise to review these aspects.

    &nbs= p;

    Without t= hat, it might seem like an uncoordinated protocol development effort for th= ose of us who are not intimately aware of all the IFIT internals/details.

    &nbs= p;

    Rest, I w= ill leave it up to the chairs of the WGs involved.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
    Sent: 16 November 2020 12:42
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares = <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Keta= n,

    Thanks = a lot for your revision.

    My answ= ers inline tagged as [GF]

    &n= bsp;

    Regards= ,

    &n= bsp;

    Giusepp= e

    &n= bsp;

    From: Ketan Talaulikar (ketant) [= mailto:ketant@cisco.com]
    Sent: Friday, November 13, 2020 12:12 PM
    To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Giuseppe,

     

    First of all, thanks for making the updates to the d= ocument to clarify the objective and applicability of IFIT and this draft e= xtensions specifically to the SR Policy signalled by BGP. A good part of th= e puzzle is at least clearer to me now.

     

    Sec 3 says (and I am trying to paraphrase here ̵= 1; so please correct me), that these IFIT attributes (new TLVs) are signall= ed via BGP along with the SR Policy Candidate Path to “enable IOAM an= d Alternate Marking” mechanisms for that SR Policy. This way all traffic steered over that SR Policy with have the IOAM and Al= t Marking headers inserted on them.

     

    [GF]: Y= es, this is correct.=

     

    Is there a Spring WG document that describes the imp= lications of actually how this would get applied to the SR Policy forwardin= g planes (SR-MPLS and SRv6) and what types of Steering would be possible to= be used for such SR Policies (ref https://tools.= ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-8<= /a>). ? E.g. if a packet is arriving at the headend with a stack of labels and gets steered via BSID into such = an SR Policy where “IFIT is applied”, how does that work?<= /o:p>

     

    [GF]: G= ood point, in the next revision we can add some considerations on the Steer= ing into an SR Policy. This can be useful also for the data plane drafts. R= egarding SRv6, the relevant documents are already adopted: draft-ietf-ippm-ioam-ipv6-options for IOAM and draft-= ietf-6man-ipv6-alt-mark for AltMark. These Options are defined for IPv6 and= can be used with any Routing Header (including SRH). For SR-MPLS the relev= ant documents (e.g. draft-gandhi-spring-ioam-sr-mpls) are still individual.

     

     

    Sec 6 (SR Policy operations with IFIT Attributes) sa= ys the following:

     

    The validation of the individual fields of the= IFIT

       Attributes sub-TLVs are handled b= y the SRPM (SR Policy Module).

     

    However, I am still missing a document that describe= s how these are actually “handled” by the SRPM?

     

    [GF]: d= raft-ietf-idr-segment-routing-te-policy also mentions some high-level funct= ionality of SRPM. I think we need to include more details in draft-qin-idr-= sr-policy-ifit in order to describe the functionalities that are specific for IFIT (IOAM and AltMark).=

     

    I understand that there is a similar draft in PCE WG= as well, but it is also missing this information.

     

    [GF]: I= can address this comment in both drafts.

     

    My concern is that we have documents for the protoco= l signaling mechanisms for IFIT but I am not able to locate a document that= describes how exactly this information is going to get used/applied by SRP= M.

     

    [GF]: S= ome details about the SRPM operation for IFIT could be added in this draft.=

     

    Please do point/clarify if I am missing something he= re.

     

    Thanks,

    Ketan

     

    From: Idr <idr-bounces@iet= f.org> On Behalf Of Giuseppe Fioccola
    Sent: 02 November 2020 22:28
    To: Susan Hares <shares@ndzh.c= om>; idr@ietf.org
    Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Dear Su= san, All,

    I'm not= aware of any IPR related to this draft. I also support its adoption as coa= uthor.

    &n= bsp;

    Best Re= gards,

    &n= bsp;

    Giusepp= e

    &n= bsp;

    &n= bsp;

    From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares
    Sent: Monday, November 2, 2020 6:57 AM
    To: idr@ietf.org
    Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-= ifit-04.txt (11/1/2020 to 11/16/2020)

     

    This begins a 2 week WG adoptio= n call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

     

    The draft can be accessed at: <= o:p>

    https://datatracker.ietf.org/d= oc/draft-zhu-idr-bgp-ls-path-mtu/

     

    The authors should provide IPR = statements by 11/5/2020 so the IDR WG can consider the IPR status in their

    decision.

     

    This draft adds the IFIT sub-TL= V to the BGP Tunnel Encaps attribute for the SR policy tunnel type. This su= b-TLV is only valid for SR Policy tunnel types.  Within the IFIT  = ;sub-TLV value field, 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).   =

     

    The IDR co-chairs thank the aut= hors for their patience.  The WG adoption call for this draft has been= delayed by the process of switching shepherds for BGP Tunnel Encaps draft.=  Many BESS and IDR drafts currently refer to the BGP tunnel encapsulation drafts.

     

    In your review of this draft, p= lease differentiate between the following:

    • Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing tech= nology,
    • Support/rejection of alternate marking as= a IP routing technology,  
    • Support/rejectio= n of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attr= ibute, and   
    • Specific issues with the = descriptions of these features in the draft.

     

    Cheers, Susan Hares =

     

     

     

    --_000_MW3PR11MB457061E12701246675DBD374C1E30MW3PR11MB4570namp_-- From nobody Mon Nov 16 00:43:42 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578453A11AB; Mon, 16 Nov 2020 00:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pZDPGi9dUdvx; Mon, 16 Nov 2020 00:43:33 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DF33A15C7; Mon, 16 Nov 2020 00:43:27 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CZMxt38kdz67Dnv; Mon, 16 Nov 2020 16:41:54 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 16 Nov 2020 09:43:25 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 16 Nov 2020 09:43:25 +0100 From: Giuseppe Fioccola To: "Ketan Talaulikar (ketant)" , Susan Hares , "idr@ietf.org" CC: "spring@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSAAkCn8MAABrv4QAAGxpCA= Date: Mon, 16 Nov 2020 08:43:25 +0000 Message-ID: <97b2cfd508c84da19d9483d80427bd3b@huawei.com> References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> <832cd20c50a941e19d06e41b339a6c8c@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.215.142] Content-Type: multipart/alternative; boundary="_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:43:37 -0000 --_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, As discussed at the IDR session, I see your point. draft-qin-idr-sr-policy-ifit is one building block of the SR Policy Archite= cture and a new SPRING document that describes the SRPM operations and proc= edures for IFIT (IOAM and AltMark) would be the best choice. Considering yo= ur contributions on related documents, we could also cooperate on that. So, I agree, there is no need to add this into draft-qin-idr-sr-policy-ifit= so far. Regards, Giuseppe From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Monday, November 16, 2020 8:39 AM To: Giuseppe Fioccola ; Susan Hares ; idr@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Giuseppe, Thanks for your response. Perhaps my point was not clear and so let me plea= se clarify. I am seeing the IFIT signalling related drafts for BGP and PCEP (it was als= o there in LSR?) in their individual protocol working groups. While what th= ese protocols are doing is only "carrying" (in case of BGP somewhat opaquel= y) the information and conveying it to the SR Policy Module (SRPM). The fol= lowing may clarify the picture better : https://tools.ietf.org/html/draft-f= ilsfils-spring-sr-policy-considerations-06#section-2 The key part of how this is handled by the SRPM, the related procedures and= setup in the forwarding plane along with their applicability and any other= considerations should be (IMHO) done in a Spring document. This is my sugg= estion and request to the authors - not to add all of this into an IDR docu= ment since that is not where you will find the right expertise to review th= ese aspects. Without that, it might seem like an uncoordinated protocol development effo= rt for those of us who are not intimately aware of all the IFIT internals/d= etails. Rest, I will leave it up to the chairs of the WGs involved. Thanks, Ketan From: Giuseppe Fioccola > Sent: 16 November 2020 12:42 To: Ketan Talaulikar (ketant) >; = Susan Hares >; idr@ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Ketan, Thanks a lot for your revision. My answers inline tagged as [GF] Regards, Giuseppe From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, November 13, 2020 12:12 PM To: Giuseppe Fioccola >; Susan Hares >; idr@= ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Giuseppe, First of all, thanks for making the updates to the document to clarify the = objective and applicability of IFIT and this draft extensions specifically = to the SR Policy signalled by BGP. A good part of the puzzle is at least cl= earer to me now. Sec 3 says (and I am trying to paraphrase here - so please correct me), tha= t these IFIT attributes (new TLVs) are signalled via BGP along with the SR = Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for= that SR Policy. This way all traffic steered over that SR Policy with have= the IOAM and Alt Marking headers inserted on them. [GF]: Yes, this is correct. Is there a Spring WG document that describes the implications of actually h= ow this would get applied to the SR Policy forwarding planes (SR-MPLS and S= Rv6) and what types of Steering would be possible to be used for such SR Po= licies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-p= olicy-09#section-8). ? E.g. if a packet is arriving at the headend with a s= tack of labels and gets steered via BSID into such an SR Policy where "IFIT= is applied", how does that work? [GF]: Good point, in the next revision we can add some considerations on th= e Steering into an SR Policy. This can be useful also for the data plane dr= afts. Regarding SRv6, the relevant documents are already adopted: draft-iet= f-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for Alt= Mark. These Options are defined for IPv6 and can be used with any Routing H= eader (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandh= i-spring-ioam-sr-mpls) are still individual. Sec 6 (SR Policy operations with IFIT Attributes) says the following: The validation of the individual fields of the IFIT Attributes sub-TLVs are handled by the SRPM (SR Policy Module). However, I am still missing a document that describes how these are actuall= y "handled" by the SRPM? [GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-leve= l functionality of SRPM. I think we need to include more details in draft-q= in-idr-sr-policy-ifit in order to describe the functionalities that are spe= cific for IFIT (IOAM and AltMark). I understand that there is a similar draft in PCE WG as well, but it is als= o missing this information. [GF]: I can address this comment in both drafts. My concern is that we have documents for the protocol signaling mechanisms = for IFIT but I am not able to locate a document that describes how exactly = this information is going to get used/applied by SRPM. [GF]: Some details about the SRPM operation for IFIT could be added in this= draft. Please do point/clarify if I am missing something here. Thanks, Ketan From: Idr > On Behalf Of = Giuseppe Fioccola Sent: 02 November 2020 22:28 To: Susan Hares >; idr@ietf.org Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Dear Susan, All, I'm not aware of any IPR related to this draft. I also support its adoption= as coauthor. Best Regards, Giuseppe From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, November 2, 2020 6:57 AM To: idr@ietf.org Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04= .txt (11/1/2020 to 11/16/2020) This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.t= xt (11/2/2020 to 11/16/2020). The draft can be accessed at: https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/ The authors should provide IPR statements by 11/5/2020 so the IDR WG can co= nsider the IPR status in their decision. This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the= SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel typ= es. Within the IFIT sub-TLV value field, 5 sub-TLVs may be included (4 fo= r IOAM and 1 for Enhanced Alternate Marking). The IDR co-chairs thank the authors for their patience. The WG adoption ca= ll for this draft has been delayed by the process of switching shepherds fo= r BGP Tunnel Encaps draft. Many BESS and IDR drafts currently refer to the= BGP tunnel encapsulation drafts. In your review of this draft, please differentiate between the following: * Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing te= chnology, * Support/rejection of alternate marking as a IP routing technology, * Support/rejection of adding new sub-TLVS for SR Policy tunnel type of= BGP Tunnel Encap Attribute, and * Specific issues with the descriptions of these features in the draft. Cheers, Susan Hares --_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Ketan,

    As discussed at the ID= R session, I see your point.

    draft-qin-idr-sr-polic= y-ifit is one building block of the SR Policy Architecture and a new SPRING= document that describes the SRPM operations and procedures for IFIT (IOAM = and AltMark) would be the best choice. Considering your contributions on related documents, we could also coopera= te on that.

    So, I agree, there is = no need to add this into draft-qin-idr-sr-policy-ifit so far.

     

    Regards,

     

    Giuseppe

     

     

    From: Ketan Talaulikar (ketant) [mailto:ketan= t@cisco.com]
    Sent: Monday, November 16, 2020 8:39 AM
    To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Ha= res <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org; spring-chairs@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Giuseppe,<= /p>

     

    Thanks for your response. Perha= ps my point was not clear and so let me please clarify.

     

    I am seeing the IFIT signalling= related drafts for BGP and PCEP (it was also there in LSR?) in their indiv= idual protocol working groups. While what these protocols are doing is only= “carrying” (in case of BGP somewhat opaquely) the information and conveying it to the SR Policy Module (SRPM).= The following may clarify the picture better : https://tools.ietf.org= /html/draft-filsfils-spring-sr-policy-considerations-06#section-2

     

    The key part of how this is han= dled by the SRPM, the related procedures and setup in the forwarding plane = along with their applicability and any other considerations should be (IMHO= ) done in a Spring document. This is my suggestion and request to the authors – not to add all of this in= to an IDR document since that is not where you will find the right expertis= e to review these aspects.

     

    Without that, it might seem lik= e an uncoordinated protocol development effort for those of us who are not = intimately aware of all the IFIT internals/details.

     

    Rest, I will leave it up to the= chairs of the WGs involved.

     

    Thanks,

    Ketan

     

    From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
    Sent: 16 November 2020 12:42
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Ketan,

    Thanks a lot for your = revision.

    My answers inline tagg= ed as [GF]

     

    Regards,

     

    Giuseppe

     

    From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
    Sent: Friday, November 13, 2020 12:12 PM
    To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
    Cc: spring@ietf.org
    Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Hi Giuseppe,<= /p>

     

    First of all, thanks for making= the updates to the document to clarify the objective and applicability of = IFIT and this draft extensions specifically to the SR Policy signalled by B= GP. A good part of the puzzle is at least clearer to me now.

     

    Sec 3 says (and I am trying to = paraphrase here – so please correct me), that these IFIT attributes (= new TLVs) are signalled via BGP along with the SR Policy Candidate Path to = “enable IOAM and Alternate Marking” mechanisms for that SR Policy. This way all traffic steered over that SR Policy with = have the IOAM and Alt Marking headers inserted on them.

    &n= bsp;

    [GF]: Yes, this is cor= rect.=

     

    Is there a Spring WG document t= hat describes the implications of actually how this would get applied to th= e SR Policy forwarding planes (SR-MPLS and SRv6) and what types of Steering= would be possible to be used for such SR Policies (ref https://to= ols.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-8). ? E.g. if a packet is arriving at the headend with a stack of labels and gets ste= ered via BSID into such an SR Policy where “IFIT is applied”, h= ow does that work?

    &n= bsp;

    [GF]: Good point, in t= he next revision we can add some considerations on the Steering into an SR = Policy. This can be useful also for the data plane drafts. Regarding SRv6, = the relevant documents are already adopted: draft-ietf-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-ma= rk for AltMark. These Options are defined for IPv6 and can be used with any= Routing Header (including SRH). For SR-MPLS the relevant documents (e.g. d= raft-gandhi-spring-ioam-sr-mpls) are still individual.

    &n= bsp;

     

    Sec 6 (SR Policy operations wit= h IFIT Attributes) says the following:

     

    The validation of the individua= l fields of the IFIT

       Attributes sub-TLV= s are handled by the SRPM (SR Policy Module).

     

    However, I am still missing a d= ocument that describes how these are actually “handled” by the = SRPM?

     

    [GF]: draft-ietf-idr-s= egment-routing-te-policy also mentions some high-level functionality of SRP= M. I think we need to include more details in draft-qin-idr-sr-policy-ifit = in order to describe the functionalities that are specific for IFIT (IOAM and AltMark).=

     

    I understand that there is a si= milar draft in PCE WG as well, but it is also missing this information.

     

    [GF]: I can address th= is comment in both drafts.

     

    My concern is that we have docu= ments for the protocol signaling mechanisms for IFIT but I am not able to l= ocate a document that describes how exactly this information is going to ge= t used/applied by SRPM.

     

    [GF]: Some details abo= ut the SRPM operation for IFIT could be added in this draft.

     

    Please do point/clarify if I am= missing something here.

     

    Thanks,

    Ketan

     

    From: Idr <idr-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
    Sent: 02 November 2020 22:28
    To: Susan Hares <shares@ndzh.c= om>; idr@ietf.org
    Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

     

    Dear Susan, All,<= /o:p>

    I'm not aware of any I= PR related to this draft. I also support its adoption as coauthor.

     

    Best Regards,

     

    Giuseppe

     

     

    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
    Sent: Monday, November 2, 2020 6:57 AM
    To: idr@ietf.org
    Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-= ifit-04.txt (11/1/2020 to 11/16/2020)

     

    This begins a 2 week WG adoption call for draft-qin-= idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

     

    The draft can be accessed at:

    https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-= ls-path-mtu/

     

    The authors should provide IPR statements by 11/5/20= 20 so the IDR WG can consider the IPR status in their

    decision.

     

    This draft adds the IFIT sub-TLV to the BGP Tunnel E= ncaps attribute for the SR policy tunnel type. This sub-TLV is only valid f= or SR Policy tunnel types.  Within the IFIT  sub-TLV value field,= 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).   

     

    The IDR co-chairs thank the authors for their patien= ce.  The WG adoption call for this draft has been delayed by the proce= ss of switching shepherds for BGP Tunnel Encaps draft.  Many BESS and = IDR drafts currently refer to the BGP tunnel encapsulation drafts.

     

    In your review of this draft, please differentiate b= etween the following:

    • Support/rejection= of In-situ Flow Telemetry (IFIT) as a IP routing technology,
    • Support/rejecti= on of alternate marking as a IP routing technology,  
      • <= li class=3D"MsoNormal" style=3D"mso-list:l1 level1 lfo3">Support/rejection = of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attrib= ute, and   
    • Specific issues with the descriptions of these features= in the draft.

     

    Cheers, Susan Hares

     

     

     

    --_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_-- From nobody Mon Nov 16 08:05:08 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 400283A122E; Mon, 16 Nov 2020 08:05:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160554270721.21359.11444128509957505969@ietfa.amsl.com> Date: Mon, 16 Nov 2020 08:05:07 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-23.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 16:05:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-23.txt Pages : 35 Date : 2020-11-16 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-23 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 16 09:51:39 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6A3A1358; Mon, 16 Nov 2020 09:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciena.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 JlRWc8OYyJag; Mon, 16 Nov 2020 09:51:35 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 2EF5D3A135B; Mon, 16 Nov 2020 09:51:34 -0800 (PST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AGHmFLb032526; Mon, 16 Nov 2020 12:51:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=06252019; bh=SaqvNuFgk4z4i5oQjhLwCb0buG0wd/oCTXdVHA9shB0=; b=gLDGcnk4GXDaPgPDILkeDY6XLc8l1DlMgZthpX1/2cL/yges2iLha7XLL/M/+JZagbgK nI8sYnBxbu8oa9MrtyZF2ULsFjpywEet1LrC0E5WJVBVHYJbsw2ZoKTFZBLw+739YRhQ QMZGGiWA7lJUXL2ZQ6TVq7UrUEYR37BvM9gQGx7jeIJCiFTqs2u3vg177mF5aujXBf0s Emra9KjeT0K93zOveuVkJyH3nXupPTLZupruSZCUhzAoNnfWDDQVnCI6V94h7JEP0vsl gIxPqHzEvGImMkBO6lVo46FO/7tFEQr4zGxdZlooKiZztR1fE062F9D2bNa92m/rxuCo lg== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2173.outbound.protection.outlook.com [104.47.57.173]) by mx0b-00103a01.pphosted.com with ESMTP id 34tcbsbw7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 12:51:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jpYDIWGgz48I166o/X+lCOWFpHhkbStDDXlrUeCbXBlNz2OpuaHDpfb4Po+F63wzxBbVSuNIVAoyUIubcuFD1Vawu19W25zq0C2C5jEd6Uq99b84LDDXvTdxVEGWrw90fz2RObmgPj167tbpJ9Ftxq+dZ5O+QbSObIWRz+VVzriYWpg+1n8UoEa1AK5R5skF4WamlfCFMKv69zFq2oUUE8SQ+EIGbSsnObSz7cS2uGMTj2FDIISuV8fbA4lItRQt1Py9WkR5fdHg4Jlr50VwGatW4QJtP9xsonTblBH3XDdnH8jagr/suRc8S/Fu0mrbh3bP3VmGvg9d6xKSpfPPIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SaqvNuFgk4z4i5oQjhLwCb0buG0wd/oCTXdVHA9shB0=; b=WMyQKhWUvYif+7KSm9qbQaAwNI3JQE8sGdyGJ5Xd/bqr2NkyU5mRCQVmAjMTpJTNhPpUtsXS7KeMkMhkwLu+BFZWoPCzsPC35AEK3Cr4okLCVntzskunSwc8vYhDFFisUvdvHqikGng3fbs4jZyKF66n5h404m7muufV4jfZl853njD77MToPJ5p/jyDWYeL5r1E6CtubCW8DKeJMiWR/Q4BUbmnpQgjUUwkjhfyGLMrNWzTKM0STgRPyYrsSPf+aiwKvfV4GCcBleh+jRoO4eAJmsnMIImQfSM0uEal//sAIM5h3/tb0w+7UcKfEjfaUQjrf71Cb6GAcRGE0MOQDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none Received: from DM6PR04MB4169.namprd04.prod.outlook.com (2603:10b6:5:9e::17) by DM6PR04MB7131.namprd04.prod.outlook.com (2603:10b6:5:246::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Mon, 16 Nov 2020 17:51:30 +0000 Received: from DM6PR04MB4169.namprd04.prod.outlook.com ([fe80::e9ce:e269:e261:7205]) by DM6PR04MB4169.namprd04.prod.outlook.com ([fe80::e9ce:e269:e261:7205%3]) with mapi id 15.20.3541.028; Mon, 16 Nov 2020 17:51:30 +0000 From: "Duncan, Ian" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [**EXTERNAL**] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AQHWvEEdXwWsew8vbEuic4GUKaOGuw== Date: Mon, 16 Nov 2020 17:51:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=ciena.com; x-originating-ip: [165.225.209.37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9461c0da-34a5-4aeb-adbf-08d88a583fa3 x-ms-traffictypediagnostic: DM6PR04MB7131: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MJ9HRlQ5n2OiezNDVPcufUXQ8wCTYjslSNqo6MYfIVaoQpX9x7e/yhG5kR8PULGFbjUt/LCaMhMPljp8kzc19leb5BZ46C83eLlZzc6bcsdzk0RyvuvCniw47m5q07bijEfOXpYXOBlUXrLQiuQlrY8vI5Wlr7zIf4FuxH+Cbe21cxW8s7lt3sA41hBNIwUw9TUYe+HaN+4V5d8mgqWfuWYs1bjZKNyop/zMkGlHeSM8girrGkKQoDBUxBZ3Yqev7q4mxInKIbm1IaJM2vJHf3BdheF+3imbaOaHZypljs3r0O8O8uLomecVpbvrSjE0vpqgJiN1hQlL4rus9irhWW/+nYgaUOCshSIimCT8JHq/b7B7/mVhT0VeQWIE3xwubxdp4koZbLWUpVWxP46OQQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR04MB4169.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(346002)(376002)(396003)(54906003)(110136005)(316002)(6512007)(966005)(478600001)(5660300002)(66556008)(91956017)(33656002)(66946007)(66446008)(66476007)(71200400001)(2906002)(8936002)(86362001)(64756008)(76116006)(8676002)(4326008)(36756003)(6486002)(55236004)(2616005)(53546011)(26005)(186003)(166002)(83380400001)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zZSx1SJLbiKh1HmhPLa1V6+dbjzSFuC4q6meezFLcSqdK4tGGb9pL73nGz7ZN02wUumDjOpUQp+fqnss4EZ+NHcl8Hv5rGzoybl80xOWLdYT7si31Vv6/oTioGnZMUpiaJBbOAY2TJI85x9c2+Dt5Ty/eBxXVv336mmXm67CBvXjRSkEb/uhicr5avyjmV8an64oqR2DdYBTsBGk02dQJo8JGU23yEJuDm0mq07Y9WotDxllL4Uvavg9t8+JtH63mdZGoenJbqPDjP0eN9y7DOA2y7yAMLNs7YiV1hubliwsSAFnBoS0KGgS+s5vuLbudW/O+z/fg3qOp6zYuoVugBfTg87RW56zgA1RdGb69TYvWM4hY2EL4pjkSkCYGXVgcPUz4/3GQI3RwsG++epYhWhj0vsLfWVXa+bsj8anGPOazFemZMdpY5+Ll+eZ/CTNRIeHMRLKCiOKJKMRRIscUT6nnqQJGAHo995gcsZk9cARa4LP2xRxEvs6xLf46KckVOWYuj5eYk6MlDdeX8N5G1Ul96NPn/DQ9NsQ8rtGVzcrN5ovJfd+VqymACXS8yF0W/LczofSrEpKm9rQUIEwpWv2RNPQO5dQSsaDVO+WZxzbWzE0f0ZhF2i8bdBwPRMITuxfOzPXa3/U6g3dtG/awQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FDB9DBA2461242848E7C4BC080FC44A4cienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR04MB4169.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9461c0da-34a5-4aeb-adbf-08d88a583fa3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 17:51:30.1109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 97FyS9BqFacDXTkBK3VK6u0RB7OI8Da8EU69ES4v/J/62MjKwuI0npSZgnuZ6ZBwFpDQMblXudK/+Xjy4B6x9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB7131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-16_09:2020-11-13, 2020-11-16 signatures=0 Archived-At: Subject: Re: [spring] [**EXTERNAL**] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 17:51:38 -0000 --_000_FDB9DBA2461242848E7C4BC080FC44A4cienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8g4oCTDQoNCkkgc3VwcG9ydCBhZG9wdGlvbiBieSBvdXIgV0cuDQoNCkJlc3QgLi4gSWFu DQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBK YW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTogVGh1 cnNkYXksIE9jdG9iZXIgMjIsIDIwMjAgYXQgODo1MiBBTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmci IDxzcHJpbmdAaWV0Zi5vcmc+DQpDYzogImlwcG0tY2hhaXJzQGlldGYub3JnIiA8aXBwbS1jaGFp cnNAaWV0Zi5vcmc+LCAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbKipFWFRFUk5BTCoqXSBbc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxs IGZvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFt cC1zcnBtLTAzDQoNCkRlYXIgV0c6DQoNClRoaXMgbWVzc2FnZSBzdGFydHMgYSAzIHdlZWsgV0cg YWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctc3RhbXAtc3JwbS0wMyBbdG9vbHMuaWV0Zi5vcmddPGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5n LXN0YW1wLXNycG0tMDNfXzshIU9Tc0dEdyFlN1I5X3FmSVo4Q2QyazFWUnlKUVFqUkRaWFc3Vy0t ZDVfbW16SThTakMwWk5lOTZNR3lhLUZna1VuWmskPiwgZW5kaW5nIE5vdmVtYmVyIDEydGggMjAy MC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIGNoYW5nZXMgZnJv bSB2LTAyIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMu IEZvciB0aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4dGVuZGVkIHRoZSBhZG9wdGlvbiBj YWxsIGZvciBhbiBhZGRpdGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdHIGVub3VnaCB0aW1lIHRv IHJldmlldyB0aGVzZSBjaGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBvbiBXRyBhZG9wdGlvbi4NCg0K U29tZSBiYWNrZ3JvdW5kOg0KDQpTZXZlcmFsIHJldmlldyBjb21tZW50cyB3ZXJlIHJlY2VpdmVk IHByZXZpb3VzbHkgZm9yIGRvY3VtZW50IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDIgW3Rvb2xzLmlldGYub3JnXTxodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhp LXNwcmluZy1zdGFtcC1zcnBtLTAyX187ISFPU3NHRHchZTdSOV9xZklaOENkMmsxVlJ5SlFRalJE WlhXN1ctLWQ1X21tekk4U2pDMFpOZTk2TUd5YS1LUkJCQUFlJD4uIFRoZSBTUFJJTkcgYW5kIElQ UE0gY2hhaXJzIGNvbnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFuZCB1cG9uIHJldmlldyBvZiB0 aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVkIHRoZSBmb2xsb3dpbmc6DQoN Cg0KICAqICAgVGhlIFNQUklORyBkb2N1bWVudCBzaG91bGQgZGVzY3JpYmUgb25seSB0aGUgcHJv Y2VkdXJlcyByZWxldmFudCB0byBTUFJJTkcgd2l0aCBwb2ludGVycyB0byBub24tU1BSSU5HIGRv Y3VtZW50L3MgdGhhdCBkZWZpbmUgYW55IGV4dGVuc2lvbnMuIFNldmVyYWwgZXh0ZW5zaW9ucyBp bmNsdWRpbmcgQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lvbiBmb3IgU1RBTVAgTWVzc2FnZXMs IExvc3MgTWVhc3VyZW1lbnQgUXVlcnkgTWVzc2FnZSBFeHRlbnNpb25zLCBMb3NzIE1lYXN1cmVt ZW50IFJlc3BvbnNlIE1lc3NhZ2UgRXh0ZW5zaW9ucywgTm9kZSBBZGRyZXNzIFRMViBFeHRlbnNp b25zLCBhbmQgUmV0dXJuIFBhdGggVExWIEV4dGVuc2lvbnMgd2VyZSBpbmNsdWRlZCBpbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAy IFt0b29scy5pZXRmLm9yZ108aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMl9fOyEhT1Nz R0R3IWU3UjlfcWZJWjhDZDJrMVZSeUpRUWpSRFpYVzdXLS1kNV9tbXpJOFNqQzBaTmU5Nk1HeWEt S1JCQkFBZSQ+IGFuZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcgZG9jdW1lbnQu DQogICogICBUaGUgU1RBTVAgZXh0ZW5zaW9ucyBpbmNsdWRlZCBpbiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIFt0b29scy5pZXRm Lm9yZ108aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMl9fOyEhT1NzR0R3IWU3UjlfcWZJ WjhDZDJrMVZSeUpRUWpSRFpYVzdXLS1kNV9tbXpJOFNqQzBaTmU5Nk1HeWEtS1JCQkFBZSQ+IHNo b3VsZCBiZSBkZXNjcmliZWQgaW4gYSBuZXcgZG9jdW1lbnQgcHVibGlzaGVkIGluIHRoZSBJUFBN IFdHLg0KDQpUaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3Jz IG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1w LXNycG0tMDIgW3Rvb2xzLmlldGYub3JnXTxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAy X187ISFPU3NHRHchZTdSOV9xZklaOENkMmsxVlJ5SlFRalJEWlhXN1ctLWQ1X21tekk4U2pDMFpO ZTk2TUd5YS1LUkJCQUFlJD4gdGhlIHJlc3VsdCBvZiB3aGljaCBpcyB0aGUgcHVibGljYXRpb24g b2YgdGhlIGZvbGxvd2luZyB0d28gZG9jdW1lbnRzOg0KDQoNCiAgKiAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDMgW3Rvb2xzLmll dGYub3JnXTxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzX187ISFPU3NHRHchZTdSOV9x ZklaOENkMmsxVlJ5SlFRalJEWlhXN1ctLWQ1X21tekk4U2pDMFpOZTk2TUd5YS1GZ2tVblprJD4u IFRoZSBzdWJqZWN0IG9mIHRoaXMgV0cgYWRvcHRpb24gY2FsbC4NCiAgKiAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtLTAwIFt0b29scy5p ZXRmLm9yZ108aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXN0YW1wLXNycG0tMDBfXzshIU9Tc0dEdyFlN1I5X3Fm SVo4Q2QyazFWUnlKUVFqUkRaWFc3Vy0tZDVfbW16SThTakMwWk5lOTZNR3lhLUFOOEtjbkckPi4g VGhpcyBkb2N1bWVudCB3aWxsIGJlIHByb2dyZXNzZWQgKGlmIGRldGVybWluZWQgYnkgdGhlIFdH KSB3aXRoaW4gdGhlIElQUE0gV0cuDQoNCkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3Vt ZW50IHBsZWFzZSBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0 aGUgbWFpbGluZyBsaXN0LiBQbGVhc2UgYWxzbyBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9y IHRoYXQgc3VwcG9ydCAob3IgbGFjayB0aGVyZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNv bnNpZGVyZWQgYXMgY29uc2VudC4NCg0KRmluYWxseSwgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRv IHRoYW5rIHRoZSBhdXRob3JzIGZvciB0aGVpciBlZmZvcnRzIGluIHRoaXMgbWF0dGVyLg0KDQpU aGFua3MhDQoNCkppbSwgQnJ1bm8sICYgSm9lbA0K --_000_FDB9DBA2461242848E7C4BC080FC44A4cienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D567F8267352141904ECDB9A98BBD8E@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjMyNTI4MzA2NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTExMjE0MjAw O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDozMzQxMTQyMTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwNTUyOTEyNjA7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy NTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE0 NDA4MzMzNDQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0zMjU0MzAzMDQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp c3QtaWQ6MTkzMzM5NDczODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6ODgwMjA5NDMwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9InB1cnBsZSIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyDigJM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBzdXBwb3J0IGFkb3B0aW9uIGJ5IG91ciBXRy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz dCAuLiBJYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmlu ZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKYW1lcyBHdWlj aGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UaHVyc2RheSwgT2N0b2JlciAyMiwgMjAyMCBhdCA4OjUyIEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtzcHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90O2lwcG0tY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtpcHBtLWNo YWlyc0BpZXRmLm9yZyZndDssICZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0 O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlsqKkVYVEVS TkFMKipdIFtzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBXRyBhZG9wdGlvbiBj YWxsIGZvciA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAzX187ISFPU3NH RHchZTdSOV9xZklaOENkMmsxVlJ5SlFRalJEWlhXN1ctLWQ1X21tekk4U2pDMFpOZTk2TUd5YS1G Z2tVblprJCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmlu Zy1zdGFtcC1zcnBtLTAzIFt0b29scy5pZXRmLm9yZ108L2E+LCBlbmRpbmcgTm92ZW1iZXIgMTI8 c3VwPnRoPC9zdXA+IDIwMjAuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgc2V2 ZXJhbCBjaGFuZ2VzIGZyb20gdi0wMiB0aGF0IHdlcmUgcmVxdWVzdGVkIGJ5IHRoZSBTUFJJTkcg YW5kIElQUE0gY2hhaXJzLiBGb3IgdGhpcyByZWFzb24sIHRoZSBjaGFpcnMNCiBoYXZlIGV4dGVu ZGVkIHRoZSBhZG9wdGlvbiBjYWxsIGZvciBhbiBhZGRpdGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhl IFdHIGVub3VnaCB0aW1lIHRvIHJldmlldyB0aGVzZSBjaGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBv biBXRyBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBiYWNrZ3JvdW5kOiAm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2V2ZXJhbCByZXZpZXcgY29tbWVudHMgd2Vy ZSByZWNlaXZlZCBwcmV2aW91c2x5IGZvciBkb2N1bWVudA0KPGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1z cHJpbmctc3RhbXAtc3JwbS0wMl9fOyEhT1NzR0R3IWU3UjlfcWZJWjhDZDJrMVZSeUpRUWpSRFpY VzdXLS1kNV9tbXpJOFNqQzBaTmU5Nk1HeWEtS1JCQkFBZSQiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wMiBbdG9vbHMuaWV0Zi5v cmddPC9hPi4gVGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMgY29uc2lkZXJlZCB0aG9zZSBjb21t ZW50cywgYW5kIHVwb24gcmV2aWV3IG9mIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGRl dGVybWluZWQgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPlRoZSBTUFJJTkcgZG9jdW1lbnQgc2hvdWxk IGRlc2NyaWJlIG9ubHkgdGhlIHByb2NlZHVyZXMgcmVsZXZhbnQgdG8gU1BSSU5HIHdpdGggcG9p bnRlcnMgdG8gbm9uLVNQUklORyBkb2N1bWVudC9zIHRoYXQgZGVmaW5lIGFueSBleHRlbnNpb25z LiBTZXZlcmFsIGV4dGVuc2lvbnMgaW5jbHVkaW5nPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+ DQogQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lvbiBmb3IgU1RBTVAgTWVzc2FnZXM8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8Yj5Mb3NzIE1lYXN1cmVtZW50IFF1 ZXJ5IE1lc3NhZ2UgRXh0ZW5zaW9uczwvYj4sJm5ic3A7PGI+TG9zcyBNZWFzdXJlbWVudCBSZXNw b25zZSBNZXNzYWdlIEV4dGVuc2lvbnM8L2I+LCZuYnNwOzxiPk5vZGUgQWRkcmVzcw0KIFRMViBF eHRlbnNpb25zPC9iPiwgYW5kJm5ic3A7PGI+UmV0dXJuIFBhdGggVExWIEV4dGVuc2lvbnM8L2I+ PC9zcGFuPiB3ZXJlIGluY2x1ZGVkIGluDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFt cC1zcnBtLTAyX187ISFPU3NHRHchZTdSOV9xZklaOENkMmsxVlJ5SlFRalJEWlhXN1ctLWQ1X21t ekk4U2pDMFpOZTk2TUd5YS1LUkJCQUFlJCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ2FuZGhpLXNwcmluZy1zdGFtcC1zcnBtLTAyIFt0b29scy5pZXRmLm9yZ108L2E+IGFu ZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcgZG9jdW1lbnQuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+VGhlIFNUQU1QIGV4dGVuc2lvbnMgaW5jbHVkZWQgaW4N CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDJfXzshIU9Tc0dEdyFlN1I5 X3FmSVo4Q2QyazFWUnlKUVFqUkRaWFc3Vy0tZDVfbW16SThTakMwWk5lOTZNR3lhLUtSQkJBQWUk Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1w LXNycG0tMDIgW3Rvb2xzLmlldGYub3JnXTwvYT4gc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiBhIG5l dyBkb2N1bWVudCBwdWJsaXNoZWQgaW4gdGhlIElQUE0gV0cuICZuYnNwOzxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRo ZSBhdXRob3JzIG9mIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0YW1wLXNycG0tMDJfXzsh IU9Tc0dEdyFlN1I5X3FmSVo4Q2QyazFWUnlKUVFqUkRaWFc3Vy0tZDVfbW16SThTakMwWk5lOTZN R3lhLUtSQkJBQWUkIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGkt c3ByaW5nLXN0YW1wLXNycG0tMDIgW3Rvb2xzLmlldGYub3JnXTwvYT4gdGhlIHJlc3VsdCBvZiB3 aGljaCBpcyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZvbGxvd2luZyB0d28gZG9jdW1lbnRzOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMyBsZXZlbDEg bGZvNiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctc3RhbXAtc3JwbS0wM19fOyEhT1NzR0R3 IWU3UjlfcWZJWjhDZDJrMVZSeUpRUWpSRFpYVzdXLS1kNV9tbXpJOFNqQzBaTmU5Nk1HeWEtRmdr VW5aayQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXN0 YW1wLXNycG0tMDMNCiBbdG9vbHMuaWV0Zi5vcmddPC9hPi4gVGhlIHN1YmplY3Qgb2YgdGhpcyBX RyBhZG9wdGlvbiBjYWxsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nYW5kaGktaXBwbS1zdGFtcC1zcnBtLTAwX187ISFPU3NHRHchZTdSOV9xZklaOENk MmsxVlJ5SlFRalJEWlhXN1ctLWQ1X21tekk4U2pDMFpOZTk2TUd5YS1BTjhLY25HJCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXN0YW1wLXNycG0tMDANCiBb dG9vbHMuaWV0Zi5vcmddPC9hPi4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIHByb2dyZXNzZWQgKGlm IGRldGVybWluZWQgYnkgdGhlIFdHKSB3aXRoaW4gdGhlIElQUE0gV0cuPG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50IHBsZWFz ZSBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUgbWFpbGlu ZyBsaXN0Lg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5QbGVhc2Ug YWxzbyBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0 aGVyZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2VudC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RmluYWxseSwgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZv ciB0aGVpciBlZmZvcnRzIGluIHRoaXMgbWF0dGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5vLCAmYW1wOyBK b2VsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FDB9DBA2461242848E7C4BC080FC44A4cienacom_-- From nobody Mon Nov 16 09:56:30 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB13C3A00C9; Mon, 16 Nov 2020 09:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciena.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 MK2d07-QyLLJ; Mon, 16 Nov 2020 09:56:25 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 795823A005C; Mon, 16 Nov 2020 09:56:25 -0800 (PST) Received: from pps.filterd (m0222747.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AGHo1tw015668; Mon, 16 Nov 2020 12:56:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=06252019; bh=DP6ByapJyrlO50v3fN4xIfOvy0ZN0d9YzTgZRnWgzps=; b=m9/4ZcdpebrbVt+LjVz/TquiIDMp/F01peZ6l+eWjdizPkwRg3ZDSBJ3ygGuwKcUc49R WdN4e5ADlqy8Bg7nyrOQB01q6PdydYlJJjXMY3LKmgEwjAt5iKe+V1EvUCqof0WuGE2Y 16n2MltaIsoMzXVV8Y3ec49shCCoLYRjFpRtrD2PBYCQlc7/D10VscO+TbLB6ouj8EYb WEmZPwHtmprJZ/1xd2Wwsjd63N6cFjqcqRRPIUeZgvl6K544pWnVjV4fLBkF+4hf2l2Y MFFpngYLyNQiFZyq3scZ9nL1r6kX6+hrxoxR3j/OFgdYUH0AXVJtAUS7ZjK0AGdtnNdY 0g== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2105.outbound.protection.outlook.com [104.47.70.105]) by mx0a-00103a01.pphosted.com with ESMTP id 34tqsyk4pb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 12:56:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U0qtiTP6oeTruPUpefX0jHZ/jy8aJYzk7kHKMqvDAjH5gannl0TjuHPQLCktBlbBB7MRLHLncevfxOgZEz/Atmnq3/6z71HkGbHicKsMU5gEUMv4t9gKPqht/U0o56BLcX1ojszHJj1iW44ELvQYVg7aeSScvcq0Wtztiv2JlBuGyn3CMDPsnw+PoJ2b3k+G/fjFvoBZUbBT+HgWm5W/9VwfbCwy2Tole0iCrjnMZpcvzTwRgtVIuUmdSY0ak/GvNQtj5vNanlUUgMVZHnJr7dB/kfrGG4LvqieC7Q7kkwWZr2DvIsYFNAqH956poQejNqmXOb4qn+TGrmza7dqKuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DP6ByapJyrlO50v3fN4xIfOvy0ZN0d9YzTgZRnWgzps=; b=Pu9vzTzWvuSYVptW0NrEiaVDmRWVplpfdakp4+Q0NNKYilLEoATB9ToTtgoU+e5xGkSqVweq1UgLUPKcxvgqgqT04dpqqldQz/jifBxFGGo7bbLZ3NjQFww7GuoufEbAYFkrZxCanTUi0cHP8UMj68/0BM70XmwuS9Ji3cyLDpg+9RZU35fWY4Xtzt3Nz9DIgPCuTQBMGJDsCqmN4s4ApHJPL7cDA9k2Peahm5sq6K+qoHqSBzifZBgsvzP0jqJ5TuKQ6RGelk/AytqILI0qAXgOvkDqSr3sXYi5dIUcArQQxtq/KTT1aOm8lXvxj5TZ8XQ5g6sDcp/E+nUkletgbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none Received: from DM6PR04MB4169.namprd04.prod.outlook.com (2603:10b6:5:9e::17) by DM5PR04MB0861.namprd04.prod.outlook.com (2603:10b6:3:fa::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Mon, 16 Nov 2020 17:56:20 +0000 Received: from DM6PR04MB4169.namprd04.prod.outlook.com ([fe80::e9ce:e269:e261:7205]) by DM6PR04MB4169.namprd04.prod.outlook.com ([fe80::e9ce:e269:e261:7205%3]) with mapi id 15.20.3541.028; Mon, 16 Nov 2020 17:56:20 +0000 From: "Duncan, Ian" To: James Guichard , "spring@ietf.org" CC: "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [**EXTERNAL**] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWvEHKBzbjar+ZqEKMKqU73CKC4A== Date: Mon, 16 Nov 2020 17:56:20 +0000 Message-ID: <26E7594C-A7A1-45B8-A6A0-ED197A2DE40F@ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=ciena.com; x-originating-ip: [165.225.209.37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c052fa0-cf02-4b5f-8bc4-08d88a58ecca x-ms-traffictypediagnostic: DM5PR04MB0861: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V/zpZShSaRcLeYw7MfQ9XxZ9xuVP+/vHh1RpWaAjx35egpoTOgIyvaeiKr3K7ivbqlUb7L4s9XYL+ahOFlUcNLVJ30jb3mY6L91yMiAdMbHw4hO/c2wCvnT3HkzC3ty/TcuIInBE016WbfKECfxM/JOdMaNSKCQ9XKb4gHFd8M03HHRzHw3gZGGBxaWWT4xG19kuvtziJXQOFZ+I1D3yr5npMsjojqyaE39NaRUB56gy0DaOW5LZp/1HrxuLrq/GJs/xtn8nMXqFB6PcIecerA9Suu3PuxSkByUdD7Qbs/zq//JB7FdlQ1njNUKXS2JqT5Lj7DeF/UWwMYNTCZzNIkr/CKixdbeHlrlGfDzbNdRSiSw4zTJCZ7UUs8Her8Isc1jru7S9gamD4PyVpRpITg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR04MB4169.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(366004)(376002)(346002)(8936002)(8676002)(2906002)(166002)(86362001)(71200400001)(83380400001)(2616005)(478600001)(5660300002)(33656002)(966005)(186003)(55236004)(110136005)(4326008)(6506007)(53546011)(26005)(36756003)(6486002)(66556008)(91956017)(66446008)(66476007)(64756008)(66946007)(76116006)(54906003)(6512007)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JEtl/VKCif9BkuSMtSZ8bY4Eq3uVsjSHjTRdW/Kg5hOEGFi6zYsy3KQJiYlR2mCGbNR4Tf7PeqvWTrOqJE4/HybxuZqqLLC8Vz5KM6KFFelQ/kkz2mY1oc4L0b4zmw/B+UoTaPWHSHgr7tWVW3f8o6eT2mcUB8ieZi2EQ7Da7L9X5x0hnvWbm5axU/zf5s1b+8i7e7Q0Ko3CuJAHxjM7ZiDTYqZRLcKMloF1xCxHnNYQOkx9VnwdKT0b3YDCn5XDMyK8cOSVRL12JxwHF5kXGGriuvXRXxl37/Kuu/eF3ihiF+OFgvWGI4kfuhMClOVPMpHS45akOkxFT4KsHewRhaVtgpooAfAo2eDE9AQ2uHSWHJ70AStpYLKeslcYGBf30LcncHqwtcJcTbIoMILqqiA/489bZxbIIWG4gSDjO9N+RKtORQekArlMXJ4zolTGmlEHyu5dtS94WGPMGY93i5pGcqmcfwRsmKtS9pc1iW0N33gSxrA38HVt8ylm8duXLGcgMot2IPHR7f6Np/BWbbX3aoTkUuTWTpBhBlfa61G1F14Q+OnwMIR3iW5ztrmlH+wIez1zD+qnRoCn6uFFWWZ3q3yA7qMtkDVdRgeymapvfUUo91159tDYuiNQVDd9nv+y+qKYQM9sOUQeHAj0GQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_26E7594CA7A145B8A6A0ED197A2DE40Fcienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR04MB4169.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c052fa0-cf02-4b5f-8bc4-08d88a58ecca X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 17:56:20.6314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6DNf7rqNsYGbrdzrubEby7wTa68JUXtdKgIyatUQYck2Mw61XBqSe1dCuTDxNigXc+kYRnc8RqLSi0vmSMOvkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0861 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-16_09:2020-11-13, 2020-11-16 signatures=0 Archived-At: Subject: Re: [spring] [**EXTERNAL**] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 17:56:28 -0000 --_000_26E7594CA7A145B8A6A0ED197A2DE40Fcienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8g4oCTDQoNCkFsc28gc3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIElELg0KDQpCZXN0 IC4uIElhbg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4NCkRh dGU6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIwIGF0IDg6NTQgQU0NClRvOiAic3ByaW5nQGll dGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KQ2M6ICJpcHBtLWNoYWlyc0BpZXRmLm9yZyIgPGlw cG0tY2hhaXJzQGlldGYub3JnPiwgInNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hh aXJzQGlldGYub3JnPg0KU3ViamVjdDogWyoqRVhURVJOQUwqKl0gW3NwcmluZ10gV0cgQWRvcHRp b24gQ2FsbCBmb3IgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJp bmctdHdhbXAtc3JwbS0xMQ0KDQpEZWFyIFdHOg0KDQpUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgMyB3 ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRvY3VtZW50IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTEgW3Rvb2xzLmlldGYub3JnXTxo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExX187ISFPU3NHRHchWkd6OVdpdERTQVZmZXJS Yk9nNEpjQjM5WjdLTWJ2NjdOTHltOVFQUkVWcW4tbkUtYVQtUUUyOGRybkxUJD4gZW5kaW5nIE5v dmVtYmVyIDEydGggMjAyMC4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBzZXZl cmFsIGNoYW5nZXMgZnJvbSB2LTEwIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYnkgdGhlIFNQUklORyBh bmQgSVBQTSBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwgdGhlIGNoYWlycyBoYXZlIGV4dGVuZGVk IHRoZSBhZG9wdGlvbiBjYWxsIGZvciBhbiBhZGRpdGlvbmFsIHdlZWsgdG8gYWxsb3cgdGhlIFdH IGVub3VnaCB0aW1lIHRvIHJldmlldyB0aGVzZSBjaGFuZ2VzIGJlZm9yZSBkZWNpZGluZyBvbiBX RyBhZG9wdGlvbi4NCg0KU29tZSBiYWNrZ3JvdW5kOg0KDQpTZXZlcmFsIHJldmlldyBjb21tZW50 cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTAgW3Rvb2xzLmlldGYu b3JnXTxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwX187ISFPU3NHRHchWkd6OVdpdERT QVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdOTHltOVFQUkVWcW4tbkUtYVQtUUU1Y0ZmeHFkJD4uIFRo ZSBTUFJJTkcgYW5kIElQUE0gY2hhaXJzIGNvbnNpZGVyZWQgdGhvc2UgY29tbWVudHMsIGFuZCB1 cG9uIHJldmlldyBvZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBkZXRlcm1pbmVkIHRo ZSBmb2xsb3dpbmc6DQoNCg0KICAqICAgVGhlIFNQUklORyBkb2N1bWVudCBzaG91bGQgZGVzY3Jp YmUgb25seSB0aGUgcHJvY2VkdXJlcyByZWxldmFudCB0byBTUFJJTkcgd2l0aCBwb2ludGVycyB0 byBub24tU1BSSU5HIGRvY3VtZW50L3MgdGhhdCBkZWZpbmUgYW55IGV4dGVuc2lvbnMuIFNldmVy YWwgZXh0ZW5zaW9ucyBpbmNsdWRpbmcgQ29udHJvbCBDb2RlIEZpZWxkIEV4dGVuc2lvbiBmb3Ig VFdBTVAgTGlnaHQgTWVzc2FnZXMsIExvc3MgTWVhc3VyZW1lbnQgUXVlcnkgTWVzc2FnZSBFeHRl bnNpb25zLCBhbmQgTG9zcyBNZWFzdXJlbWVudCBSZXNwb25zZSBNZXNzYWdlIEV4dGVuc2lvbnMg d2VyZSBpbmNsdWRlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhp LXNwcmluZy10d2FtcC1zcnBtLTEwIFt0b29scy5pZXRmLm9yZ108aHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmct dHdhbXAtc3JwbS0xMF9fOyEhT1NzR0R3IVpHejlXaXREU0FWZmVyUmJPZzRKY0IzOVo3S01idjY3 Tkx5bTlRUFJFVnFuLW5FLWFULVFFNWNGZnhxZCQ+IGFuZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9t IHRoZSBTUFJJTkcgZG9jdW1lbnQuDQogICogICBUaGUgVFdBTVAgZXh0ZW5zaW9ucyBpbmNsdWRl ZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2Ft cC1zcnBtLTEwIFt0b29scy5pZXRmLm9yZ108aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0x MF9fOyEhT1NzR0R3IVpHejlXaXREU0FWZmVyUmJPZzRKY0IzOVo3S01idjY3Tkx5bTlRUFJFVnFu LW5FLWFULVFFNWNGZnhxZCQ+IHNob3VsZCBiZSBkZXNjcmliZWQgaW4gYSBuZXcgZG9jdW1lbnQg cHVibGlzaGVkIGluIHRoZSBJUFBNIFdHLg0KDQpUaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1 c3NlZCB3aXRoIHRoZSBhdXRob3JzIG9mICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwIFt0b29scy5pZXRmLm9yZ108aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRo aS1zcHJpbmctdHdhbXAtc3JwbS0xMF9fOyEhT1NzR0R3IVpHejlXaXREU0FWZmVyUmJPZzRKY0Iz OVo3S01idjY3Tkx5bTlRUFJFVnFuLW5FLWFULVFFNWNGZnhxZCQ+IHRoZSByZXN1bHQgb2Ygd2hp Y2ggaXMgdGhlIHB1YmxpY2F0aW9uIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGRvY3VtZW50czoNCg0K DQogICogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10 d2FtcC1zcnBtLTExIFt0b29scy5pZXRmLm9yZ108aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3Jw bS0xMV9fOyEhT1NzR0R3IVpHejlXaXREU0FWZmVyUmJPZzRKY0IzOVo3S01idjY3Tkx5bTlRUFJF VnFuLW5FLWFULVFFMjhkcm5MVCQ+LiBUaGUgc3ViamVjdCBvZiB0aGlzIFdHIGFkb3B0aW9uIGNh bGwuDQogICogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLWlwcG0t dHdhbXAtc3JwbS0wMCBbdG9vbHMuaWV0Zi5vcmddPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBt LTAwX187ISFPU3NHRHchWkd6OVdpdERTQVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdOTHltOVFQUkVW cW4tbkUtYVQtUUU0QkxBQkRmJD4uIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwcm9ncmVzc2VkIChp ZiBkZXRlcm1pbmVkIGJ5IHRoZSBXRykgd2l0aGluIHRoZSBJUFBNIFdHLg0KDQpBZnRlciByZXZp ZXcgb2YgdGhlIFNQUklORyBkb2N1bWVudCBwbGVhc2UgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90 KSBmb3IgV0cgYWRvcHRpb24gdG8gdGhlIG1haWxpbmcgbGlzdC4gUGxlYXNlIGFsc28gcHJvdmlk ZSBjb21tZW50cy9yZWFzb25zIGZvciB0aGF0IHN1cHBvcnQgKG9yIGxhY2sgdGhlcmVvZikgYXMg c2lsZW5jZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIGNvbnNlbnQuDQoNCkZpbmFsbHksIHRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgYXV0aG9ycyBmb3IgdGhlaXIgZWZmb3J0 cyBpbiB0aGlzIG1hdHRlci4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vLCAmIEpvZWwNCg0KDQoN Cg0K --_000_26E7594CA7A145B8A6A0ED197A2DE40Fcienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <1017BF45ACEDA1479159F015806E5857@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjEwOTgyMTA2ODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODg5NjM0 MzA2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxNDQwODMzMzQ0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMzI1NDMwMzA0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjE5MzMzOTQ3Mzg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjg4MDIwOTQzMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDM2MDc4ODcxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjEyMzE5OTEzODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0icHVy cGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIOKAkzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbHNvIHN1cHBvcnQgV0cgYWRvcHRpb24gb2YgdGhpcyBJRC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QmVzdCAuLiBJYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPnNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBKYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciAyMiwgMjAyMCBhdCA4OjU0IEFNPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDtzcHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2lwcG0tY2hhaXJzQGlldGYub3JnJnF1b3Q7 ICZsdDtpcHBtLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5v cmcmcXVvdDsgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlsqKkVYVEVSTkFMKipdIFtzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBX Rzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIDMgd2VlayBX RyBhZG9wdGlvbiBjYWxsIGZvciBkb2N1bWVudCA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu Y29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10 d2FtcC1zcnBtLTExX187ISFPU3NHRHchWkd6OVdpdERTQVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdO THltOVFQUkVWcW4tbkUtYVQtUUUyOGRybkxUJCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTExIFt0b29scy5pZXRmLm9yZ108L2E+ IGVuZGluZyBOb3ZlbWJlciAxMjxzdXA+dGg8L3N1cD4gMjAyMC4gUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIGNoYW5nZXMgZnJvbSB2LTEwIHRoYXQgd2VyZSByZXF1 ZXN0ZWQgYnkgdGhlIFNQUklORyBhbmQgSVBQTSBjaGFpcnMuIEZvciB0aGlzIHJlYXNvbiwgdGhl IGNoYWlycw0KIGhhdmUgZXh0ZW5kZWQgdGhlIGFkb3B0aW9uIGNhbGwgZm9yIGFuIGFkZGl0aW9u YWwgd2VlayB0byBhbGxvdyB0aGUgV0cgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZXNlIGNoYW5n ZXMgYmVmb3JlIGRlY2lkaW5nIG9uIFdHIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Tb21lIGJhY2tncm91bmQ6ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXZlcmFs IHJldmlldyBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIHByZXZpb3VzbHkgZm9yIGRvY3VtZW50DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwX187ISFPU3NHRHchWkd6OVdp dERTQVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdOTHltOVFQUkVWcW4tbkUtYVQtUUU1Y0ZmeHFkJCI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1z cnBtLTEwIFt0b29scy5pZXRmLm9yZ108L2E+LiBUaGUgU1BSSU5HIGFuZCBJUFBNIGNoYWlycyBj b25zaWRlcmVkIHRob3NlIGNvbW1lbnRzLCBhbmQgdXBvbiByZXZpZXcgb2YgdGhpcyB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudCwgZGV0ZXJtaW5lZCB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+VGhlIFNQ UklORyBkb2N1bWVudCBzaG91bGQgZGVzY3JpYmUgb25seSB0aGUgcHJvY2VkdXJlcyByZWxldmFu dCB0byBTUFJJTkcgd2l0aCBwb2ludGVycyB0byBub24tU1BSSU5HIGRvY3VtZW50L3MgdGhhdCBk ZWZpbmUgYW55IGV4dGVuc2lvbnMuIFNldmVyYWwgZXh0ZW5zaW9ucyBpbmNsdWRpbmc8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlIj4NCiBDb250cm9sIENvZGUgRmllbGQgRXh0ZW5zaW9uIGZvciBU V0FNUCBMaWdodCBNZXNzYWdlczwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+LCZu YnNwOzxiPkxvc3MgTWVhc3VyZW1lbnQgUXVlcnkgTWVzc2FnZSBFeHRlbnNpb25zPC9iPiwgYW5k Jm5ic3A7PGI+TG9zcyBNZWFzdXJlbWVudCBSZXNwb25zZSBNZXNzYWdlIEV4dGVuc2lvbnMNCjwv Yj48L3NwYW4+d2VyZSBpbmNsdWRlZCBpbiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FuZGhpLXNwcmluZy10d2Ft cC1zcnBtLTEwX187ISFPU3NHRHchWkd6OVdpdERTQVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdOTHlt OVFQUkVWcW4tbkUtYVQtUUU1Y0ZmeHFkJCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ2FuZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwIFt0b29scy5pZXRmLm9yZ108L2E+IGFu ZCBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBTUFJJTkcgZG9jdW1lbnQuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+VGhlIFRXQU1QIGV4dGVuc2lvbnMgaW5jbHVkZWQgaW4N CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0tMTBfXzshIU9Tc0dEdyFaR3o5 V2l0RFNBVmZlclJiT2c0SmNCMzlaN0tNYnY2N05MeW05UVBSRVZxbi1uRS1hVC1RRTVjRmZ4cWQk Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1w LXNycG0tMTAgW3Rvb2xzLmlldGYub3JnXTwvYT4gc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiBhIG5l dyBkb2N1bWVudCBwdWJsaXNoZWQgaW4gdGhlIElQUE0gV0cuICZuYnNwOzxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBjb25jbHVzaW9ucyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHRo ZSBhdXRob3JzIG9mICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3ByaW5nLXR3YW1wLXNycG0t MTBfXzshIU9Tc0dEdyFaR3o5V2l0RFNBVmZlclJiT2c0SmNCMzlaN0tNYnY2N05MeW05UVBSRVZx bi1uRS1hVC1RRTVjRmZ4cWQkIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2Fu ZGhpLXNwcmluZy10d2FtcC1zcnBtLTEwDQogW3Rvb2xzLmlldGYub3JnXTwvYT4gdGhlIHJlc3Vs dCBvZiB3aGljaCBpcyB0aGUgcHVibGljYXRpb24gb2YgdGhlIGZvbGxvd2luZyB0d28gZG9jdW1l bnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1zcHJpbmctdHdhbXAtc3JwbS0xMV9fOyEh T1NzR0R3IVpHejlXaXREU0FWZmVyUmJPZzRKY0IzOVo3S01idjY3Tkx5bTlRUFJFVnFuLW5FLWFU LVFFMjhkcm5MVCQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYW5kaGktc3By aW5nLXR3YW1wLXNycG0tMTENCiBbdG9vbHMuaWV0Zi5vcmddPC9hPi4gVGhlIHN1YmplY3Qgb2Yg dGhpcyBXRyBhZG9wdGlvbiBjYWxsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzYi PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1nYW5kaGktaXBwbS10d2FtcC1zcnBtLTAwX187ISFPU3NHRHchWkd6OVdp dERTQVZmZXJSYk9nNEpjQjM5WjdLTWJ2NjdOTHltOVFQUkVWcW4tbkUtYVQtUUU0QkxBQkRmJCI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhbmRoaS1pcHBtLXR3YW1wLXNycG0t MDANCiBbdG9vbHMuaWV0Zi5vcmddPC9hPi4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIHByb2dyZXNz ZWQgKGlmIGRldGVybWluZWQgYnkgdGhlIFdHKSB3aXRoaW4gdGhlIElQUE0gV0cuPG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIHJldmlldyBvZiB0aGUgU1BSSU5HIGRvY3VtZW50 IHBsZWFzZSBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIGZvciBXRyBhZG9wdGlvbiB0byB0aGUg bWFpbGluZyBsaXN0Lg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Q bGVhc2UgYWxzbyBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3Ig bGFjayB0aGVyZW9mKSBhcyBzaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgY29uc2Vu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+RmluYWxseSwgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRo b3JzIGZvciB0aGVpciBlZmZvcnRzIGluIHRoaXMgbWF0dGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5vLCAm YW1wOyBKb2VsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_26E7594CA7A145B8A6A0ED197A2DE40Fcienacom_-- From nobody Mon Nov 16 11:32:46 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0ED3A07D3; Mon, 16 Nov 2020 11:32:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk CC: jmh@joelhalpern.com, draft-ietf-spring-sr-yang@ietf.org, spring@ietf.org, martin.vigoureux@nokia.com, Joel Halpern , spring-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160555515848.16672.7178345983262697681@ietfa.amsl.com> Date: Mon, 16 Nov 2020 11:32:38 -0800 Archived-At: Subject: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 19:32:39 -0000 The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'YANG Data Model for Segment Routing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 17 14:27:48 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC14E3A0DDE; Tue, 17 Nov 2020 14:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 UZ9OJcLew2Eg; Tue, 17 Nov 2020 14:27:39 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 655663A0DDC; Tue, 17 Nov 2020 14:27:38 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id s30so109698lfc.4; Tue, 17 Nov 2020 14:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1AScAi8g0ivXmX0+KMKYxqh33eFZH4bhmnx2n7dvgow=; b=TfUgref66hUvC+mT+MB6hVYWkv7uU15Co1AV8cSmoAtX8SiQsvJqGo0WJoOKh78IxP DDsZsk01HFwxpk1RPRmBN+J6DEBoxvL8DePJJpsrTuP2T2NBCbpaZoa5NDG/BLCznjMO FVqE33wQu94HmXqmdBvQ17km7SuY6o2g5RkV3qwcPq8JtC7etr0MSnac3LsBiuPC9x8p NAyvirelOd3g3HJHHwWDBqiF02GucVyWO1xVslEbQJAIpWHOdsfouGyHbL9Dwogs0QEv 6NpC455dXRrVTr9/gC7vJaFN5FOmUB8jG1l2lVDxGzJb4bBkHVmba1SctkDqHg8X8Tak l5tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1AScAi8g0ivXmX0+KMKYxqh33eFZH4bhmnx2n7dvgow=; b=qANUYzRftxvtadU7cdJRlbEKYrCC9QREtSJkr+01BhOieoDPzmsAEWIJI+d0LJU5WD UhxlVQchsoQkxJ9IYU288k4YXqiqjVoEkDvPsV4QKxtD50RNY3z/4dfNwjJVY0ITolkA gQF4875/i0VwaVoXObJ0vMsfJW+8WBdMK9DohbsGiHG7s8QYrcNt6xAt3Qd/Qz0CK/qb GMAQyvlssAZ0KPmBvlOuKNv/9kzGSIAMQCTsnyLqRqyTq2XjcY0+JfyAZso3xzyzd+vH BgvE/vxPp8JYnnHDkKwCPNtZxGAd6lHuK2TkzKUNCNZI/fiDq/wqxt9aLVS+pjuWex+y 3qUQ== X-Gm-Message-State: AOAM533kWWwfchKi24diWXWQ9b1Cr2//JVBsf6Uza4l9TT/12l/VDeUq EYk0qzevm8aTBuyRrPUH8/l8iIbu9KTHDGQJaGs= X-Google-Smtp-Source: ABdhPJwa3UdA1v2BkUPxCrUYn9HZcivmBeA8xjaZY9J1RyugMZLhq97ySnV84WOoMW9IX2jMqE3XLVZL9LXn9fmPGdk= X-Received: by 2002:a19:e04:: with SMTP id 4mr2360392lfo.193.1605652056474; Tue, 17 Nov 2020 14:27:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 17 Nov 2020 14:27:25 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Tommy Pauly , IPPM Chairs , "spring-chairs@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , spring Content-Type: multipart/alternative; boundary="00000000000075883305b4550031" Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 22:27:42 -0000 --00000000000075883305b4550031 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only adding references will solve the problems with the documents. If authors are interested in addressing my comments, we can start working on solving them one by one. But I am very much concerned with the technical value of these drafts. And here's why I feel that the proposed documents don't provide a sound technical solution to the task of direct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm: - What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct packet loss measurements. Note, that RFC 6374 includes a method for direct loss measurement in MPLS networks that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct packet loss measurement. STAMP and all its extensions are applicable in IPv6 networks and, thus, can be used in the SRv6 domain. - How the proposed method of direct packet loss is related to TWAMP light and STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the basic mechanisms defined for TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new formats of test packets that are decisively different from the formats defined in respective specifications. As a result, the new protocols are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is another clear indication that the proposed mechanism represents a new protocol, neither extends TWAMP Light and/or STAMP nor updates their specifications. - Is there any advantage in introducing a dedicated packet format for the direct packet loss in STAMP comparing to using the Direct Measuremen= t TLV extension? Though it appears the using a dedicated packet format instead of TLV is more efficient, but the dedicated for the direct loss measurement format is likely to precede one or even two TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more efficient and reduce the processing delay, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv. - What are the potential benefits of specifying the return path in the new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV that carries the return path information, Path TLV. If the ability to control the return path is required that can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each test packet. Hence, there seem no technical requirements to introduce the Sender Control Code field in the Base STAMP format defined in RFC 8762. - What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used to monitor for the loss of a path continuity. That may be viewed as an alternative to the BFD protocol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be made aware of the proposals. I didn't take the liberty of adding BFD WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for your prompt response, much appreciated. I'll carefully read > your responses. Looking forward to the continued discussion. > > Regards, > Greg > > On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com> wrote: > >> Hi Greg, >> >> >> >> Thank you for your review comments. As mentioned in the IPPM session >> today, the email response was sent as attachments, see archive blow: >> >> https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ >> >> >> >> I am attaching them in word documents for the convenience. We can addres= s >> your comments below in the next revision of the document. >> >> >> >> Thanks, >> >> Rakesh >> >> >> >> >> >> *From: *Greg Mirsky >> *Date: *Friday, November 13, 2020 at 10:09 AM >> *To: *Rakesh Gandhi (rgandhi) >> *Cc: *Tommy Pauly , IPPM Chairs < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> IETF IPPM WG (ippm@ietf.org) >> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm >> and draft-gandhi-ippm-stamp-srpm >> >> Hi Rakesh, >> >> thank you for your response to my review. Please find my follow-up notes >> in-lined below under the GIM>> tag. >> >> I hope you've found more detailed comments in the attachments >> (re-attached for your convenience). I'm looking forward to reading your >> responses to the detailed comments of all four drafts. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com> wrote: >> >> Thank you Greg for taking time for thoroughly reviewing the documents an= d >> providing the comments. Attached please find the email replies to your >> review sent earlier. The replies are copied inline below for convenienc= e, >> tagged with . >> >> >> >> >> >> *From: *ippm >> *Date: *Monday, November 9, 2020 at 11:48 AM >> *To: *Tommy Pauly >> *Cc: *IPPM Chairs , spring-chairs@ietf.org < >> spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) >> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm >> and draft-gandhi-ippm-stamp-srpm >> >> Dear WG Chairs, Authors, and IPPM WG community, >> >> I've reviewed these drafts and have some comments to share. Below, pleas= e >> find my thoughts on whether these drafts can be adopted. More specific >> comments on each pair of drafts (TWAMP-related and STAMP-related draft a= nd >> its accompanying draft targetted to the SPRING WG) are in the attached >> documents. >> >> >> >> Usually, the bar for the adoption of a document can be evaluated by >> answers to these three questions: >> >> =C2=B7 Is the document(s) reasonably well-written >> >> I've got surprised that the drafts don't use the terminology from RFCs >> 4656/5357 and RFC 8762, and introduce their own terminology for >> Session-Sender and Session-Reflector. Also, many terms, e.g., Links, >> "congruent paths", are used in the documents without proper definitions. >> Other than that both drafts are readable and reasonably well-written. >> >> >> >> We can change Sender to Session-Sender and Reflector to >> Session-Reflector if it helps. >> >> GIM>> I believe that the consistency in terminology between the core RFC >> and what is intended as its extension is not only helpful to a reader bu= t, >> to the best of my understanding, is required for IETF specifications. >> >> There are many existing RFCs that use term Link (e.g. RFC 5613, >> 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without >> defining them. I suspect it is because these are well-known terms. Havin= g >> said that, we can add a reference for them if it helps. >> >> GIM>> Thank you for listing these RFCs. I think I need to clarify my >> questions. While a reference to any of RFCs you've mentioned, I don't th= ink >> that will address my concern. In reviewed documents, "Link" is capitaliz= ed >> while referenced RFCs used the lower case form for the term "link". Can >> these be used interchangeably? Do they refer to the same network object? >> >> Now I'll try to illustrate my concern with using the term "congruent >> path" in these drafts (using ASCII-art): >> >> C---------D >> >> / \ >> >> A----B E-----F >> >> \ / >> >> G------------H >> >> Consider an SR tunnel from A to F that traverses the network as >> A-B-C-D-E-F. From the definition of "congruent" as "two figures or objec= ts >> are congruent if they have the same shape and size, or if one has the sa= me >> shape and size as the mirror image of the other", path A-B-G-H-E-F is >> congruent to the SR tunnel. But a packet of an active OAM intended to >> monitor a flow over the SR tunnel is out-of-band and will not produce an= y >> meaningful measurement. Of course, for the case of the extensions in >> drafts, direct loss measurement can be performed, as information collect= ed >> from node F. So, this example, in my opinion, illustrates two of my >> concerns: >> >> - using a congruent path for an active OAM protocol may produce >> information that does not reflect the condition experienced by the >> monitored flow. It seems that the terminology should reflect the >> fundamental requirement for using active OAM to maintain the test pac= kets >> in-band with the monitored flow. >> - there are no technical requirements to justify using in-band active >> OAM protocol for direct packet loss measurement. As demonstrated in t= his >> example, direct packet loss can be performed using an out-of-band >> mechanism, e.g., SNMP queries, Netconf notifications based on YANG da= ta >> model. >> >> >> >> =C2=B7 Does the document solve a real problem? >> >> No, it appears that both TWAMP and STAMP drafts define a new >> performance measurement protocol for the purpose of combining OWAMP/TWAM= P >> and STAMP functionality in the respective drafts, and adding the ability= to >> collect counters of "in-profile" packets. I couldn't find sufficient >> technical arguments for using a PM protocol instead of, for example, >> extending the existing OAM mechanisms like ICMP multi-part message >> extension per RFC 4884. >> >> >> >> There is a requirement to measure performance delay as well as >> synthetic and direct-mode packet loss in segment-routing networks. OWAMP >> and TWAMP protocols are widely deployed for performance delay and synthe= tic >> packet loss measurement today. I am not sure extending ICMP for LM is a >> good option here. >> >> GIM>> I agree with the requirements you've listed (though the SPRING WG >> OAM requirements document >> >> has been abandoned and expired 3+ years ago). I believe that there's no >> sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direc= t >> packet loss measurement. >> >> >> >> =C2=B7 Is the proposed solution technically viable? >> >> There are too many unaddressed aspects, particularly the risk introduced >> by the protocols on network security, to comprehensively evaluate the >> proposed solutions. >> >> >> >> About your comment on zero checksum, this is described in Securit= y >> section in RFC 6936. We will add reference to this RFC in our Security >> Section as well. This is only specific to the UDP port locally provision= ed >> in the domain by the operator for STAMP or TWAMP Light. Other than this,= I >> did not find any other security related issue in your review. >> >> GIM>> I don't think that a mere reference sufficiently explains why the >> use of zero UDP checksum in IPv6 header is not decremental, does not cre= ate >> a security risk for the protocol. >> >> >> >> Thanks, >> >> Rakesh >> >> >> >> >> >> Regards, >> >> Greg >> >> >> >> >> >> >> >> >> >> On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > 40apple.com@dmarc.ietf.org> wrote: >> >> Hello IPPM, >> >> >> >> For the past few meetings, we=E2=80=99ve had updates on the work in the = SPRING WG >> that was using STAMP and TWAMP. Since those documents ended up making >> extensions to the base protocols, the chairs of SPRING and IPPM decided >> that it would be best to split the documents and track the IPPM extensio= n >> work in the IPPM WG. >> >> >> >> As such, we are starting a Working Group call for adoption >> for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. >> >> >> >> The documents are here: >> >> https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 >> >> https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 >> >> >> The related SPRING documents are here: >> >> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 >> >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> >> >> Please provide your feedback on these documents, and state whether or no= t >> you believe the IPPM WG should adopt this work by replying to this email= . >> Please provide your feedback by the start of the IETF 109 meeting week, = on *Monday, >> November 16*. >> >> >> >> Best, >> >> Tommy & Ian >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> --00000000000075883305b4550031 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh, WG Chairs, and All,
    I've read the respo= nses to my detailed comments. I don't think that only adding references= will solve the problems with the documents. If authors are interested in a= ddressing my comments, we can start working on solving=C2=A0them one by one= . But I am very much concerned with the technical value of these drafts. An= d here's why I feel that the proposed documents don't provide a sou= nd technical solution to the task of direct loss measurement.=C2=A0Please f= ind my reasoning explaining=C2=A0my opinion of the *-twamp-srpm and *-stamp= -srpm:
    • What is being proposed in these drafts?
    <= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
    Drafts = *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct pack= et loss measurements. Note, that RFC 6374 includes a method for direct loss= measurement in MPLS networks that is applicable to the SR-MPLS environment= . Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 S= TAMP, the Direct Measurement TLV, that supports the direct packet loss meas= urement. STAMP and all its extensions are applicable in IPv6 networks and, = thus, can be used in the SRv6 domain.
    • How the pro= posed method of direct packet loss is related to TWAMP light and STAMP?
    There's no apparent technical relationship between *-twamp-srpm a= nd TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or r= e-use the basic mechanisms defined for=C2=A0 TWAMP-Test and/or STAMP in the= ir respective specifications. Rather than that, drafts introduce a new quer= y-response mode and new formats of test packets that are decisively differe= nt from the formats defined in respective specifications. As a result, the = new protocols are required to use different from used by TWAMP Light tr STA= MP test session UDP port numbers on the responder. And that is another clea= r indication that the proposed mechanism represents a new protocol, neither= extends TWAMP Light and/or STAMP nor updates their specifications.
    • Is there any advantage in introducing a dedicated packet= format for the direct packet loss in STAMP comparing to using the Direct M= easurement TLV extension?
    Though it appears the using a dedicated packet form= at instead of TLV is more efficient, but the dedicated for the direct loss = measurement format is likely to precede one or even two TLVs, Node Address = TLV and Path TLV, defined in=C2=A0draft-gandhi-ippm-stamp-srpm. As a result= , processing of the new packet with TLVs is unlikely to be more efficient a= nd reduce the processing delay, than if using the Direct Measurement TLV as= defined in draft-ietf-ippm-stamp-option-tlv.
    • What = are the potential benefits of specifying the return path in the new test pa= cket's Sender Control Code?
    Using the Sender Control Code may require the= use of the additional TLV that carries the return path information, Path T= LV. If the ability to control the return path is required that can be achie= ved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) ra= ther than including the Path TLV in each test packet. Hence, there seem no = technical requirements to introduce the Sender Control Code field in the Ba= se STAMP format defined in RFC 8762.
    • What is the re= lationship between the *-srpm drafts and BFD?
    Some text in the *-srpm drafts = suggest that the proposed method can be used=C2=A0to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loop= back mode and monitoring of liveness remain in the drafts, it seems logical= that the BFD WG and BFD WG's Chairs be made aware of the proposals. I = didn't take the liberty of adding BFD WG or its Chairs. I believe that = decision to be made by the Chairs of IPPM And SPRING WGs.


    Regards,



    On Sun, Nov 15, 2020 at 10= :10 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Hi Rakesh,
    thank you for y= our prompt response,=C2=A0much appreciated. I'll carefully read your re= sponses. Looking forward to the continued discussion.

    <= div>Regards,
    Greg

    On Sun, Nov 15, 2020 at 10:07 PM Rakesh Ga= ndhi (rgandhi) <r= gandhi@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    Thank you for your review comments. As mentioned in = the IPPM session today, the email response was sent as attachments, see arc= hive blow:

    https://mailarchive.ietf.= org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/

    =C2=A0

    I am attaching them in word documents for the conven= ience. We can address your comments below in the next revision of the docum= ent.

    =C2=A0

    Thanks,

    Rakesh

    =C2=A0

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, = spring-chairs@ietf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Please fin= d my follow-up notes in-lined below under the GIM>> tag.

    I hope you've found more detailed comments in th= e attachments (re-attached for your convenience). I'm looking forward t= o reading your responses=C2=A0to the detailed comments of all four drafts.<= u>

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg = for taking time for thoroughly reviewing the documents and providing the co= mments.=C2=A0 Attached please find the email replies to your review sent earlier.=C2=A0 The replies are copied inline below for convenience, t= agged with <RG00>.

    =C2=A0

    =C2=A0

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG community,

    I've reviewed these drafts and have some comment= s to share. Below, please find my thoughts on whether these drafts can be a= dopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying=C2=A0draft tar= getted=C2=A0to the SPRING WG) are in the attached documents.<= /p>

    =C2=A0

    Usually, the bar for the adoption of a document ca= n be evaluated=C2=A0by answers to these three questions:

    =C2=B7=C2=A0 Is the document(s) reasonably well-written

    I've got surprised that the drafts don't u= se the terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms= , e.g., Links, "congruent paths", are used in the documents witho= ut proper definitions. Other than that both drafts are readable and reasona= bly well-written.

    =C2=A0

    <RG00> We= can change Sender to Session-Sender and Reflector to Session-Reflector if = it helps.=C2=A0

    GIM>> I believe that the consistency in termin= ology between the core RFC and what is intended as its extension is not onl= y helpful to a reader but, to the best of my understanding, is required for= IETF specifications.

    <RG00> Th= ere are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, e= tc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that= , we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed d= ocuments, "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be = used interchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. From the definition of "congruent" as &q= uot;two figures or objects are congruent if they have the same shape and si= ze, or if one has the same shape and size as the mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts, direct loss measurement can be performed, as information collec= ted from node F. So, this example, in my opinion, illustrates two of my con= cerns:

    • using a congruent path for an active OAM protocol may produce information t= hat does not reflect the condition experienced by the monitored flow. It se= ems that the terminology should reflect the fundamental requirement for usi= ng active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using in-band active OAM pro= tocol for direct packet loss measurement. As demonstrated in this example, = direct packet loss can be performed using an out-of-band mechanism, e.g., S= NMP queries, Netconf notifications based on YANG data model.

    =C2=A0

    =C2=B7=C2=A0 Does the document solve a real problem?

    No, it appears that=C2=A0 both TWAMP and STAMP drafts=C2=A0=C2=A0define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't f= ind sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.<= /p>

    =C2=A0

    <RG00> Th= ere is a requirement to measure performance delay as well as synthetic and = direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here.

    GIM>> I agree with the=C2=A0requirements you&#= 39;ve listed (though the SPRING WG OAM requirements document has been aba= ndoned and expired 3+ years ago). I believe that there's no sufficient = technical reason=C2=A0to use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement.=C2=A0

    =C2=A0

    =C2=B7=C2=A0 Is the proposed solution technically viable?<= /p>

    There are too many unaddressed aspects, particular= ly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

    =C2=A0

    <RG00> Ab= out your comment on zero checksum, this is described in Security section in= RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP or TWAMP Light. Other than this, I did not= find any other security related issue in your review.=

    GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

    =C2=A0

    Thanks,<= u>

    Rakesh

    =C2=A0

    =C2=A0

    Regards,

    Greg

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpa= uly=3D40app= le.com@dmarc.ietf.org> wrote:

    Hello IPPM,

    =C2=A0

    For the past few meetings, we=E2=80=99ve had updates= on the work in the SPRING WG that was using STAMP and TWAMP. Since those d= ocuments ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the d= ocuments and track the IPPM extension work in the IPPM WG.

    =C2=A0

    As such, we are starting a Working Group call for ad= option for=C2=A0draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-sr= pm.

    =C2=A0

    Please provide your feedback on these documents, and= state whether or not you believe the IPPM WG should adopt this work by rep= lying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.<= u>

    =C2=A0

    Best,

    Tommy & Ian

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --00000000000075883305b4550031-- From nobody Tue Nov 17 15:40:51 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CFB3A101E; Tue, 17 Nov 2020 15:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=WfvbIESH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t9a9sO4P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWnVkfono8sD; Tue, 17 Nov 2020 15:40:47 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2733A102B; Tue, 17 Nov 2020 15:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84191; q=dns/txt; s=iport; t=1605656446; x=1606866046; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=emMfzVktHcsKZb82uLqM+I/+gcODbR0R3u6AxUNe3+8=; b=WfvbIESHzVwegdpgwsAlJr75Mv3ltA00BExoZMXdKkOFJBoSJNpBb3lV s2FpvAyk8jk8B7XDRYLB+sRc7PCUhQ7HUB9KUV07KSR5anYgrVZKxx7nU h8IkR+zY15v00iDREfeER//4rxM6Ri8P3F6pTzMBgXR2O+0PH+xzjhWri U=; X-IPAS-Result: =?us-ascii?q?A0D3CADQXbRffYcNJK1iHgEBCxIMQIJyLyMue1kvLgqHe?= =?us-ascii?q?wONW4oWjm6BQoERA08FCwEBAQ0BARgBCgoCBAEBhEoCgiICJTgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDAQEQCAMjAQElBwQHAQ8CAQgQA?= =?us-ascii?q?QMBAiEBBgchBgsUCQgCBA4FCAwHB4MFgX5XAy4BDqNVAoE8iGh0gTSDBAEBB?= =?us-ascii?q?YEzAQMCDkGDAw0LghADBoE4gnOCZk6BSIVRG4FBP4EQAUOCTz6CG0IBAQIBA?= =?us-ascii?q?YEhBQESASMFGQYHCQKDEoIskB0CGAwyihODKph4CS9VCoJtiRGMdYU1gxmKF?= =?us-ascii?q?oVMjn6eUoJujjOBToJoAgQCBAUCDgEBBYFrIWlwcBU7gjUBATJQFwINjh8MF?= =?us-ascii?q?xSDOoUUhUMBdAI1AgYKAQEDCXyMOwExXwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Aq08t/hOzl5Cc45IfFxol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,486,1596499200"; d="scan'208,217";a="592575281" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Nov 2020 23:40:45 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AHNejuf007430 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2020 23:40:45 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 17 Nov 2020 17:40:44 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 17 Nov 2020 17:40:44 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 17 Nov 2020 17:40:44 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JC8ffp9WrP47cg6AjNF3NcPJljTJeIIVHYMT1DvUkJ4xfj4uIhFOrCARctLw128YxYVEm0k6QWOm0uzBdwKayeAK+wh/TpmG8DiuU7TWFllO+UXbnb71mnTjQzcdrdvUjcDjkuLn96B3TjrAxpoYB5RpQiMzuz3zKtHOeOLjLXZl2njX0DZrUfXF6AnynMwPhgdnSjYkq6zpIurvoU5Ob2C+I/HTaQQksTbUkAz2uF5AMvEsMsyGKVue1ztkQyZE12MwzIIWwR3gymwLFj2Hcsc9J4UlW5neupDZu24hW4F6o69Xk6bGL5S8tWlKlDoe/QwM62zI7QYswX/icVRGqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9et5h31+txczkyLD2igLMLzeb0dFBKKCxZI0x+eoOG0=; b=U76SIkUUO/n+uV74Qd74NkANjMvEM578QGUG8ugaMGwocFQE1GGeyG0z/btlv8mWxX+lwea+1Z17b+Ussinyd2Yzjp/inU3oVs7kxEUxOW9cDrvFeuREffO3pYZPlMJDwuTGIUrBAgSA/VVj/NqPYVuodT07WOVrCAz0NYE091r83I4dh7Al5VCTwDSBfgX7IBerNMiNqBuTmFdpH90CRBBqPkGNDRI/WV8dYvdhWGEIb/B3uRp21Fh/T6e8FjwWkMDW3YwBdoL57BpEL+mp50GGqyavH65TAhaXwmPEvw8xqepAfA93buLImOzAeLDU+KLA0bwbqLvcQmIyoLx6KA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9et5h31+txczkyLD2igLMLzeb0dFBKKCxZI0x+eoOG0=; b=t9a9sO4Petzed5WirEtSgdF0QepCuWgFJqyZtEERIfdQ7JWfXfF7u7bBv13Ew2gCHenISzqiQ8AjrUIjg+bn4o8vboYCZyqhAohRV34NoMXaCTKsEa91KUlePM4nSUqkpBsYLP0dgBnWi3iVr8lFp+tgdmG6F5P9VRacGrkpetI= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB3308.namprd11.prod.outlook.com (2603:10b6:5:d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 17 Nov 2020 23:40:41 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Tue, 17 Nov 2020 23:40:41 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky CC: Tommy Pauly , IPPM Chairs , "spring-chairs@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , spring Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KnAEieAgAGGXIqABKdzAIAEHsI6gAAB1ACAAqNDgIAAE4+W Date: Tue, 17 Nov 2020 23:40:40 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e579edb-d9ae-4364-04f7-08d88b5231c4 x-ms-traffictypediagnostic: DM6PR11MB3308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yXvuPHwY3XsHrbolTW66kzhnWSiDylnYfig4+4TMdilgeY0NnfxYaDORaRoBWJX8cTCIX7ReJ0fhw7JaVjxHY0E/vC/vWx2BBHngphQkehsErYQvGVoInRiCNMdtwwHrjVpwf8d8JLlktoA3jKvfrH0sepg94pYPGCGiaNDVR89topWoq1aq0gXKpzFVI+CatXdCUfCijz0cqYcIf5/yI4Ya8rgKlo7uOLH0S0r8TJcen46bpidne54Ua4JoB+PZ5ByKaFq5k9mEmbOjRXklJFX+Sxs1JopHYO6vpLe+GuEiawYIRNYPI6jPFphkqYvnHgrjDKvS8k7j2Xb5ebtSZ1yY6N72r7Egm5MOSofHhBYpnQzS29Mm/JDckd15jagKJ1lqt+YR4X21SToNwb0m4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(396003)(366004)(39860400002)(376002)(478600001)(9326002)(316002)(186003)(66556008)(54906003)(76116006)(5660300002)(83380400001)(66446008)(9686003)(64756008)(966005)(33656002)(8936002)(55016002)(66476007)(71200400001)(52536014)(66946007)(8676002)(26005)(7696005)(4326008)(2906002)(53546011)(6506007)(6916009)(166002)(91956017)(30864003)(86362001)(19627235002)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nklepklklt0UpAZhV8RG5y1Bn2NVEBETi3pDLIL/aWO+nhIrQcnO43dZJvnTu+UkJoSRtft2J2LMP8fiEAvzKYb7oWFpjBPBcQMTXNLUQ3pahyAtjh3Kjmg2gSsAschQ4eHIbSEEW5u71jX3BNeQ2z+Va9bxYT8Y4b4PIjSJT0ccR69d9+d9qGO3Mnf7V0tmqaaJqqh58WBIIn1BqMVbNQi0hamXZz16OEAzJR1af6EE5Sd4e7tqf3D8X8ry+IjDZKLXvHZ+mir7dqf25NiCfFq78yKovR9sycfhqWp8R9treETqQ6WgXZk5jrNass0XdN36os19VwrF+cUC96FDzGmMUezokmZD4As0V3VTpSyjf38JP+w0uFxzlVUumYOVKsKDAh6+6kjT261FIIMTGyfBUP0/vOcPw4B3RHamjGbiGodYg4bBhTz5BTXi+7owoI5L5f4kCIFvcUdcNmX77qGCV3G9T6MbvQReY2+smnBW9//zKDFFxpUTr2eZrDFfXZCk9ImplSzHA9ddRYHiOFA5vHEo1/z3C3n+fCsovweypltx2MGCKZEK+VSXaQpKJq78xwa4un/jGZO2e4D2OCpRn9fmCbrLe+i1BjdpkPv26KwwA4J/FIEZZk5a8fOdrquDjij/+1hX5TYyvXxnyhTzkP5DXknFieNrLVK/aL9R32p7cPRBreAIZiyyXXhiXELmCNPG4pKPEnl/7Hmgly3Awh4sFkbNFGqNaYMbgS+HtCHE7WoZSV4bTloJbJSaol8jzZ5W8KgUbCXh3qvAsEURd/oaiRPM6+pwsXVNk9G0bDYUo5cydSl2rhp/TSEyL2+xcUTDNpExn0i5583Q/Xul4WyFmTQhAANb0gn6Ji+epx4DPFJ4isgprR328xIEL+Vb1yi5OyWwqB3kzVEl+w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31151E1EBD24ADBE2170E2A3BFE20DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e579edb-d9ae-4364-04f7-08d88b5231c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 23:40:40.9772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nzB7kiEjikgL93TGyp3oWUATMaozGQ9oZCiPvaL5gI5ZnqzDil9R7gq241DIckfCimPqnNbE0OdpvKaQO6immw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3308 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 23:40:50 -0000 --_000_DM6PR11MB31151E1EBD24ADBE2170E2A3BFE20DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) Cc: Tommy Pauly , IPPM Chairs , spring-chairs@ietf.org , IETF IPPM = WG (ippm@ietf.org) , spring Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If you prefer= , we can define them here. For Zero checksum field, we can add a reference = for the RFC 6936 in Security section and also add some text for it. Will be= happy to work with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. * How the proposed method of direct packet loss is related to TWAMP lig= ht and STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it=92s format, the messages and processing of them are the same for delay = and direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in the = new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. * What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: =95 Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. =95 Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. =95 Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we=92ve had updates on the work in the SPRING WG= that was using STAMP and TWAMP. Since those documents ended up making exte= nsions to the base protocols, the chairs of SPRING and IPPM decided that it= would be best to split the documents and track the IPPM extension work in = the IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_DM6PR11MB31151E1EBD24ADBE2170E2A3BFE20DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Greg,

     

    Thank you for your rev= iew and discussions on the drafts. This will help improve the work on this = important work.

    Please see replies inl= ine with <RG>..

     

     

    From: Greg Mirsky <gre= gimirsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Ch= airs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs= @ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring &= lt;spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,

    I've read the responses to my detailed comments. I d= on't think that only adding references will solve the problems with the doc= uments. If authors are interested in addressing my comments, we can start w= orking on solving them one by one.

     

    <RG> As mentione= d in previous replies, we can add references for the well-known terms =93Li= nks=94, =93Congruent Paths=94, =93SR Path=94. If you prefer, we can define them here. For Zero checksum field, we can add a reference f= or the RFC 6936 in Security section and also = add some text for it. Will be happy to work with you to address these.

     

    But I am very much concerned with the technical valu= e of these drafts. And here's why I feel that the proposed documents don't = provide a sound technical solution to the task of direct loss measurement.&= nbsp;Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp-srpm propose a new p= rotocol to support direct packet loss measurements. Note, that RFC 6374 inc= ludes a method for direct loss measurement in MPLS networks that is applica= ble to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, t= he Direct Measurement TLV, that supports the direct packet loss measurement= . STAMP and all its extensions are applicable in IPv6 networks and, thus, c= an be used in the SRv6 domain.

     

    <RG> As mentione= d in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Se= ction 8.1) define stand-alone messages for collecting TX and RX counters for direct-mode loss measurement. TWAMP/STAM= P messages defined in the drafts are equivalent of them that take advantage= of the widely deployed TWAMP protocol and as well this same protocol can b= e deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

     

    • How the proposed method of direct packet loss is related to TWAMP light and= STAMP?

    There's no apparent technical relationship between *= -twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do no= t extend or re-use the basic mechanisms defined for  TWAMP-Test and/or= STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new forma= ts of test packets that are decisively different from the formats defined i= n respective specifications. As a result, the new protocols are required to= use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is= another clear indication that the proposed mechanism represents a new prot= ocol, neither extends TWAMP Light and/or STAMP nor updates their specificat= ions.

     

    <RG> As mentione= d in previous replies, other than timestamp vs. counter and it=92s format, = the messages and processing of them are the same for delay and direct-mode loss measurement.

    • Is there any advantage in introducing a dedicated packet format for the dir= ect packet loss in STAMP comparing to using the Direct Measurement TLV exte= nsion?

    Though it appears the using a dedicated packet forma= t instead of TLV is more efficient, but the dedicated for the direct loss m= easurement format is likely to precede one or even two TLVs, Node Address T= LV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more= efficient and reduce the processing delay, than if using the Direct Measur= ement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

     

    <RG> As mentione= d in previous replies, this is explained in Section 1 of the draft-= gandhi-spring-stamp-srpm. For link loss measurement (direct-mode= ), there is no TLV required for example. For direct-mode loss measurement i= n SR networks, it would typically be forward direction packet loss measurement (and not bidi= rectional).

     

     

    • What are the potential benefits of specifying the return path in the new te= st packet's Sender Control Code?

    Using the Sender Control Code may require the use of= the additional TLV that carries the return path information, Path TLV. If = the ability to control the return path is required that can be achieved by = augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each te= st packet. Hence, there seem no technical requirements to introduce the Sen= der Control Code field in the Base STAMP format defined in RFC 8762.

     

    <RG> Per session= basis between different sender nodes and this reflector node, some senders= will request the replies in-band (e.g. for two-way mode). Sessions are provisioned on the Sender nodes and reflector = simply reflects based on the received test-packet (e.g. for a bidirectional= SR path). This is also similar to as described Section 3.1 in RFC 6374, to= p of page 22. There is no need to create a such state for each session on the reflector node and create a sc= ale limitation. Recall that we are trying to avoid the scale limitation by = eliminating the Control protocol signaling.

     

    • What is the relationship between the *-srpm drafts and BFD?
      • =

    Some text in the *-srpm drafts suggest that the prop= osed method can be used to monitor for the loss of a path continuity. = That may be viewed as an alternative to the BFD protocol method for the det= ection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems= logical that the BFD WG and BFD WG's Chairs be made aware of the proposals= . I didn't take the liberty of adding BFD WG or its Chairs. I believe that = decision to be made by the Chairs of IPPM And SPRING WGs.

     

    <RG> As mentione= d in previous replies, STAMP/TWAMP test messages are also use= d today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

     

    Thanks,

    Rakesh

     

    Regards,

     

     

    On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimirsky@gmail.c= om> wrote:

    Hi Rakesh,

    thank you for your prompt response, much apprec= iated. I'll carefully read your responses. Looking forward to the continued= discussion.

     

    Regards,

    Greg

     

    On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

    Hi Greg,

     

    Thank you for your review comments. As mentioned in the IPPM sessi= on today, the email response was sent as attachments, see archive blow:

    https://mailarchive.ietf.org/arch/msg/i= ppm/J503n-B2yOxF0urcHtGQKnqCRDE/

     

    I am attaching them in word documents for the convenience. We can = address your comments below in the next revision of the document.

     

    Thanks,

    Rakesh

     

     

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Please find my follow-up= notes in-lined below under the GIM>> tag.

    I hope you've found more detailed comments in the attachments (re-= attached for your convenience). I'm looking forward to reading your respons= es to the detailed comments of all four drafts.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

    Thank you Greg for taking time for t= horoughly reviewing the documents and providing the comments.  Attache= d please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, t= agged with <RG00>.

     

     

    From: ippm <ippm-bounces@ietf.org&= gt;
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG community,

    I've reviewed these drafts and have some comments to share. Below,= please find my thoughts on whether these drafts can be adopted. More speci= fic comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft tar= getted to the SPRING WG) are in the attached documents.

     

    Usually, the bar for the adoption of a document can be evaluat= ed by answers to these three questions:

    =B7  Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use the terminology f= rom RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms= , e.g., Links, "congruent paths", are used in the documents witho= ut proper definitions. Other than that both drafts are readable and reasona= bly well-written.

     

    <RG00> We can change Sender to= Session-Sender and Reflector to Session-Reflector if it helps. 

    GIM>> I believe that the consistency in terminology between = the core RFC and what is intended as its extension is not only helpful to a= reader but, to the best of my understanding, is required for IETF specifications.

    <RG00> There are many existing= RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congrue= nt Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that= , we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                      &nb= sp;    C---------D

                      &nb= sp;  /                 \<= o:p>

                A----B    &nbs= p;              E-----F

                      &nb= sp;  \                  /=

                      &nb= sp;  G------------H

    Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. From the definition of "congruent" as "two figure= s or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the= other", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet = of an active OAM intended to monitor a flow over the SR tunnel is out-of-ba= nd and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct l= oss measurement can be performed, as information collected from node F. So,= this example, in my opinion, illustrates two of my concerns:

    • using a congruent path for an active OAM protocol may produce information t= hat does not reflect the condition experienced by the monitored flow. It se= ems that the terminology should reflect the fundamental requirement for usi= ng active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using in-band active OAM pro= tocol for direct packet loss measurement. As demonstrated in this example, = direct packet loss can be performed using an out-of-band mechanism, e.g., S= NMP queries, Netconf notifications based on YANG data model.

     

    =B7  Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts  d= efine a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     

    <RG00> There is a requirement = to measure performance delay as well as synthetic and direct-mode packet lo= ss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here.

    GIM>> I agree with the requirements you've listed (thou= gh the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason to us= e OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. 

     

    =B7  Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly the risk = introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     

    <RG00> About your comment on z= ero checksum, this is described in Security section in RFC 6936. We will ad= d reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP or TWAMP Light. Other than this, I did not= find any other security related issue in your review.

    GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

     

    Thanks,

    Rakesh

     

     

    Regards,

    Greg

     

     

     

     

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.= ietf.org> wrote:

    Hello IPPM,

     

    For the past few meetings, we=92ve had updates on the work in the = SPRING WG that was using STAMP and TWAMP. Since those documents ended up ma= king extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the d= ocuments and track the IPPM extension work in the IPPM WG.

     

    As such, we are starting a Working Group call for adoption for&nbs= p;draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.=

     

    Please provide your feedback on these documents, and state whether= or not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.<= o:p>

     

    Best,

    Tommy & Ian

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_DM6PR11MB31151E1EBD24ADBE2170E2A3BFE20DM6PR11MB3115namp_-- From nobody Tue Nov 17 23:43:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A913A0CE8 for ; Tue, 17 Nov 2020 23:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wy-LMoEpe1oN for ; Tue, 17 Nov 2020 23:43:38 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1D63A0CE9 for ; Tue, 17 Nov 2020 23:43:37 -0800 (PST) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CbZW54rn5z67DcG for ; Wed, 18 Nov 2020 15:41:21 +0800 (CST) Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Nov 2020 08:43:35 +0100 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml701-chm.china.huawei.com (10.98.57.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Nov 2020 15:43:33 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1913.007; Wed, 18 Nov 2020 15:43:33 +0800 From: "Yangfan (IP Standard)" To: "spring@ietf.org" Thread-Topic: [spring] Reply to Ron's MTU question \\\\ New Version Notification for draft-geng-spring-sr-redundancy-protection-00.txt Thread-Index: Ada9fmWng8fsMP5sQCu1zy+mrJFCGw== Date: Wed, 18 Nov 2020 07:43:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Reply to Ron's MTU question \\\\ New Version Notification for draft-geng-spring-sr-redundancy-protection-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 07:43:40 -0000 SGkgUm9uLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgaW4gdGhlIHByZXNlbnRhdGlv bi4gSSB0aGluayB5b3UgbWF5IG1pc3VuZGVyc3Rvb2Qgd2hhdCB3ZSBwcm9wb3NlIGluIHRoZSBm aWd1cmUuIE9uIHJlZHVuZGFuY3kgbm9kZSwgU1JIIGlzIG5ld2x5IGNyZWF0ZWQgYW5kIHRoZSBz ZWdtZW50IGxpc3Qgb2YgU1JIIGlzIHRvdGFsbHkgcmVwbGFjZWQsIGl0IGlzIG5vdCBhbiBILklu c2VydCBiZWhhdmlvci4gSSBzdXBwb3NlIHRoZXkgYXJlIG5vdCB0aGUgc2FtZSBjYXNlLiBIb3dl dmVyLCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHByb2JsZW0geW91IHJhaXNlIGFjdHVhbGx5IGlz IHRydWUgYW5kIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHdlbGwuIEkgd2FzIHRoaW5rIHRvIGFk ZCBzb21lIHRleHRzIGluIHRoZSBmb2xsb3dpbmcgdmVyc2lvbi4gSG9wZSBpdCBhbnN3ZXJzIHlv dXIgcXVlc3Rpb24uDQoNClJlZ2FyZHMsDQpGYW4NCg0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAyMOW5tDEx5pyIMuaXpSAyMDozOA0K 5pS25Lu25Lq6OiBHZW5neHVlc29uZyAoR2VuZyBYdWVzb25nKSA8Z2VuZ3h1ZXNvbmdAaHVhd2Vp LmNvbT47IFlhbmdmYW4gKElQIFN0YW5kYXJkKSA8c2hpcmxleS55YW5nZmFuQGh1YXdlaS5jb20+ OyBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPjsgTWFjaCBDaGVuIDxtYWNoLmNoZW5A aHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1n ZW5nLXNwcmluZy1zci1yZWR1bmRhbmN5LXByb3RlY3Rpb24tMDAudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWdlbmctc3ByaW5nLXNyLXJlZHVuZGFuY3ktcHJvdGVjdGlvbi0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmFuIFlhbmcgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZ2VuZy1zcHJpbmct c3ItcmVkdW5kYW5jeS1wcm90ZWN0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJU2VnbWVudCBS b3V0aW5nIGZvciBSZWR1bmRhbmN5IFByb3RlY3Rpb24NCkRvY3VtZW50IGRhdGU6CTIwMjAtMTEt MDINCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWdlbmctc3ByaW5nLXNy LXJlZHVuZGFuY3ktcHJvdGVjdGlvbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nZW5nLXNwcmluZy1zci1yZWR1bmRhbmN5LXBy b3RlY3Rpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1nZW5nLXNwcmluZy1zci1yZWR1bmRhbmN5LXByb3RlY3Rpb24NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2VuZy1zcHJpbmct c3ItcmVkdW5kYW5jeS1wcm90ZWN0aW9uLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBSZWR1bmRhbmN5 IHByb3RlY3Rpb24gaXMgb25lIG9mIHRoZSBtZWNoYW5pc21zIHRvIGFjaGlldmUgc2VydmljZQ0K ICAgcHJvdGVjdGlvbiwgZm9sbG93aW5nIHRoZSBwcmluY2lwbGUgb2YgUFJFT0YgKFBhY2tldCBS ZXBsaWNhdGlvbi8NCiAgIEVsaW1pbmF0aW9uL09yZGVyaW5nIEZ1bmN0aW9uKS4gIFRvIGVtcG93 ZXIgdGhlIFNlZ21lbnQgUm91dGluZyB3aXRoDQogICB0aGUgY2FwYWJpbGl0eSBvZiByZWR1bmRh bmN5IHByb3RlY3Rpb24sIHR3byB0eXBlcyBvZiBTZWdtZW50DQogICBpbmNsdWRpbmcgUmVkdW5k YW5jeSBTZWdtZW50IGFuZCBNZXJnaW5nIFNlZ21lbnQgYXJlIGludHJvZHVjZWQuICBUaGUNCiAg IGluc3RhbnRpYXRpb24gb2YgUmVkdW5kYW5jeSBhbmQgTWVyZ2luZyBTZWdtZW50cyBjYW4gYmUg YXBwbGllZCB0bw0KICAgYm90aCBzZWdtZW50IHJvdXRpbmcgb3ZlciBNUExTIChTUi1NUExTKSBh bmQgc2VnbWVudCByb3V0aW5nIG92ZXINCiAgIElQdjYgKFNSdjYpLg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From nobody Wed Nov 18 04:39:33 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF18E3A1853; Wed, 18 Nov 2020 04:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 t-2SdDksSAxw; Wed, 18 Nov 2020 04:39:26 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2110.outbound.protection.outlook.com [40.107.22.110]) (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 B33EE3A1855; Wed, 18 Nov 2020 04:39:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Corc0GDVcb5fuG5XLqu+nv9+nUaClf0l2YjesfgcSe5iGYAIzsUsglsqDhraNo4bqEU7vcVpQBxxhqPRhU1PXAVaDiRqz3XODK15v4H7ka/ZjL+vQFl5p7hFsIBSYqd8R6R8wCG+Sr+wYysKWPqg8YnYwFDRBBOoV8Gg0b1sddluLycpjXsTsFp6MJwGExfwolAMeo0zLBDHU4BxA4T4A//ta2Hpk1rNJDnQWYTQbAVIM4VpF34p4RqZOPMjVPpf4asiFRNC9CjgJuhm0+mprzvSs4l7dMcMtUODkTkAc5PBoscH3cwPwKESpxEGU0ATf89wbWDTzygTD7Pk5+FkPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lp4Jjm2ryffauzsQZrgRWdcgWNQ2JcVMrHBj0WCnPrU=; b=LT+zd+zpjp57OngMD3ghDDkBSn6MFYkiIWHJMFdTLvydaW559BSTYWaSmBvqwiLzS4ExM449NIZ4gDOmOT2r3z3J+85DZkZnEBsYymC9FnuxrqbnOIYgi4YCo8hSQ+GF5iOBvSdhmReAiBpDuQAYRTeGiqLdPST7aApWBH/Nyk6X4BGl0AI8NPLSSaJ80pK+3VkPyiRrRZBO2fBi1377PZ93lAhVeE22uxwnctP7GByqFVLCpnjLofX2QTEWvpMh5SX5M5jnUQfbAthlmTSDaH/ypYMkRvgRKr5mXHRjgCzJRzqDhKEiLL9HUIsya2CgLpULTDMa4mih+R0xNY1qMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lp4Jjm2ryffauzsQZrgRWdcgWNQ2JcVMrHBj0WCnPrU=; b=QnS0z0fG9tr+6Y/TLYImPQqY3AQ/qEONGK2a1y44ikMJUwBRUz1YZaE2QaGSoiAwf1LDjZuVxUE+nDSRnTeSUMxopDbBQxYB+/eHg0y3VSUNYPp4GWpyYk9lXHqvgQEh2je2skWQqQEO9ZlifXZez/5hM+oMHHWqbtEuLRMY4eA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB7039.eurprd07.prod.outlook.com (2603:10a6:800:195::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.15; Wed, 18 Nov 2020 12:39:22 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%8]) with mapi id 15.20.3589.016; Wed, 18 Nov 2020 12:39:22 +0000 To: last-call@ietf.org References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> Cc: spring-chairs@ietf.org, spring@ietf.org, Joel Halpern , draft-ietf-spring-sr-yang@ietf.org From: tom petch Message-ID: <5FB515F7.1020306@btconnect.com> Date: Wed, 18 Nov 2020 12:39:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <160555515848.16672.7178345983262697681@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0101.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::17) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0101.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3589.20 via Frontend Transport; Wed, 18 Nov 2020 12:39:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cd2fe871-ed70-48f2-7302-08d88bbef9d8 X-MS-TrafficTypeDiagnostic: VI1PR0701MB7039: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: p96tQuyXn1TiYKn9bmx0iJNbH3wILhy5HjnPGDEfmdF0PqMvnJY6mu1gmIt0wWj8EB8Jh32FSVX/Ivg3HpZw7b1bGxMR1KKlfr7RUt3NtCnoNYuFz7AAqQ/1Y9X63qyyVCvsgSUYXGtLz8Oi/NkgViaea34mxhNht+EFAqmgIx8aUxgj3SpYWx/c0LKkQBI6A5F3J60pWubigyFpg+Rp9bcNI4bSNCfJQQRBKgOHSBmcyHah26fJN91kBbUU/GgwXSI5Q2nrSjVCIpxoysokhIUh8fP5evGjhHklU7VR9+2SXM2uucZYsCvQuqOz0IJRzT8XisuaTLcWD1+/PSvhHSV//i+h48StzlmQArokJR74v3p62NCsyTNpCx2WBsw30HYpYXzqVHJUSMM+W2OXCw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(366004)(376002)(136003)(396003)(16576012)(2616005)(956004)(478600001)(86362001)(33656002)(2906002)(36756003)(8676002)(8936002)(966005)(316002)(6666004)(5660300002)(16526019)(6916009)(66574015)(4326008)(4001150100001)(186003)(53546011)(26005)(6486002)(66476007)(66556008)(83380400001)(66946007)(52116002)(87266011); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 4zaYiyAbxRc8xxwyfzvqbXsBc3e5LQVRxruOCvmIXkItB1Q2Bo8zu7+uUzmtViT6HEC4lLunkUN5w6Vt/lVx+oBwI1zlEo0ycu2JdpXSBp3jJoG61JSdRpHerCGSDXoTk5xPa15XLTKHBTGFV6ERTWrCLK6+dRy1pUM1lKJUDNS9GlJj0+M2eXMy9NUsfrcrNinI3UMeNdMAjJTQeADB8lrlMSLJbqL863utsr43fE1MgT9bTXuT52dfGc94Jrlz1F5oANK5Thp6GKcD7/CzXwKUoVBJVtRYc8ZVKShqMCSpWkzHSt7YVQWIsm7uGnk3SXax3ftFO5C5jeDIqo5M/bbIkNscIuJ6SlZ8bfkmxLQ2xnzn6WNxJcKfv+dTrNbv3GBKyD5BcpbB+exFPm8Mt9axIqWjPrHKN1yl1bWMeoVeABlAAl4nIRALworKeYc1djMreX9vQJebDhRnj2SGON6yF4VNwKP8eCdKSuzJ2FYIr52dnGqvl/jHc/jBZjj72DJO2aDXjSkQoMtrwnVMLD92bOXLuZUV7ZszSD1D0NRMX+mu0W7W1km5JkiC5GMu0423sA/xoLkiJcBlYeGK70mBdPawA8vOpFogXvf3vMu4J8oklg2Ez2BPnDi4XLMGXtXqr25odwRckuwYdBeUaQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd2fe871-ed70-48f2-7302-08d88bbef9d8 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2020 12:39:22.8109 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5V/WTyh9ijvHljziV9X5kUKtRXsM5L2LnYTHmsEjqzIiQjYJi4W3Xgzc7+9c1CO9BB8Z159RCVTWcY9xGJ9Kdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7039 Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 12:39:28 -0000 IANA Considerations does not register the module names used in the modules Examples are IPv4 only, IPv6 would be good BGP is included when it comes to defining a router-id but is ignored everywhere else, such as signalling MSD, protocol extensions etc reference "RFC XXXX" would be improved by including the title in all cases not just some the scheme http: appears in many places. It would be lovely if this really was the scheme but I fear that it is not module srcmn the upper bound must be larger the value must be greater consistency is good - I think greater is better 8.3 operation states usually operational two imports lack references typedef router-id this is a well known type from RFC8394; it seems likely to confuse to redefine it with a related but different meaning leaf enabled enables protocol extensions which protocols? leaf protected it is used to protect how does it do that:-) enum dual ... In this case will be advertised with backup flag set What is the backup flag? It does not feature in RFC8660. Needs an explanation and reference container link-msd list link-msds leaf msd The usual YANG convention is for a list to be plural and the leaf singular. You have the plural list but not the leaf. And who needs the container? This is mpls not a common module that might be augmented so what does the container give apart from complexity? list policy leaf string YANG string caters for very large items of very complex character sets. Is that desirable? leaf used will used plus free equal size? Indicates if the binding is /instal/installed/ notification-segment-routing-global-srgb-collision a mix of conflict and collision; consistency is good and I prefer the latter which is the name of the notification containing /s/a/ mapping ... sid collision again consistency good, prefer collision to conflicting s.9 I would have thought the srgb worthy of mention under sensitive nodes Tom Petch On 16/11/2020 19:32, The IESG wrote: > > The IESG has received a request from the Source Packet Routing in Networking > WG (spring) to consider the following document: - 'YANG Data Model for > Segment Routing' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document defines a YANG data model for segment routing > configuration and operation, which is to be augmented by different > segment routing data planes. The document also defines a YANG model > that is intended to be used on network elements to configure or > operate segment routing MPLS data plane, as well as some generic > containers to be reused by IGP protocol modules to support segment > routing. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > . > From nobody Wed Nov 18 21:33:34 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DB43A0DA8; Wed, 18 Nov 2020 21:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 42lACIBbyRyS; Wed, 18 Nov 2020 21:33:23 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEFB3A0DA5; Wed, 18 Nov 2020 21:33:23 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cc7Zm5g26z67DSg; Thu, 19 Nov 2020 13:31:28 +0800 (CST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 06:33:20 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 13:33:19 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 19 Nov 2020 13:33:19 +0800 From: Tianran Zhou To: "Rakesh Gandhi (rgandhi)" , "Greg Mirsky" CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutyzmWv/eapkkq7mEvT+f83ham/jAuAgAGIKYCABKWmAIAEH64AgAAA6ACAAqNCgIAAFHgAgAJz+6A= Date: Thu, 19 Nov 2020 05:33:19 +0000 Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_d333def04f55416783d5078a75780685huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 05:33:27 -0000 --_000_d333def04f55416783d5078a75780685huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM= WG (ippm@ietf.org) Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms "Links", "Congruent Paths", "SR Path". If you prefer, we can def= ine them here. For Zero checksum field, we can add a reference for the RFC = 6936 in Security section and also add some text for it. Will be happy to wo= rk with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. * How the proposed method of direct packet loss is related to TWAMP lig= ht and STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it's format, the messages and processing of them are the same for delay an= d direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in = the new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. * What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. * Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we've had updates on the work in the SPRING WG t= hat was using STAMP and TWAMP. Since those documents ended up making extens= ions to the base protocols, the chairs of SPRING and IPPM decided that it w= ould be best to split the documents and track the IPPM extension work in th= e IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_d333def04f55416783d5078a75780685huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Rakesh and Greg,

     

    I may not very clear a= bout the context. Please allow me to jump in.

    It seems both of you m= ake some valid point.

    Please see in line wit= h <ZTR>.

     

    Cheers,

    Tianran

     

    From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly=3D40apple.com@dmar= c.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     

    Hi Greg= ,

    &n= bsp;

    Thank y= ou for your review and discussions on the drafts. This will help improve th= e work on this important work.

    Please = see replies inline with <RG>..

    &n= bsp;

     

    From: Greg= Mirsky <gregimirsky@gmail.com<= /a>>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <    rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,<= o:p>

    I've read the responses to my d= etailed comments. I don't think that only adding references will solve the = problems with the documents. If authors are interested in addressing my com= ments, we can start working on solving them one by one.

     

    <RG&= gt; As mentioned in previous replies, we can add references for the well-kn= own terms “Links”, “Congruent Paths”, “SR Pat= h”. If you prefer, we can define them here. For Zero checksum field, = we can add a reference for the RFC 6936 in Security section and also add some tex= t for it. Will be happy to work with you to address these.

    &n= bsp;

    But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the prop= osed documents don't provide a sound technical solution to the task of dire= ct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:=

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp= -srpm propose a new protocol to support direct packet loss measurements. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

     

    <RG&= gt; As mentioned in previous replies, both RFC 6374 (in Section 4.2) and IT= U Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and= RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.=

     

    <ZTR> I think RFC6374 for= MPLS and Y.1731 make some noise here. The point is if we need a new direct packet loss measurement for STAMP, when = STAMP already defined a Direct Measurement TLV (https://datatracker.ietf.or= g/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV = cannot fulfill some use case requirement, then how about proposing a new TLV.=

    • How the proposed method of direct packet loss is relat= ed to TWAMP light and STAMP?

    There's no apparent technical r= elationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts an= d STAMP. Drafts do not extend or re-use the basic mechanisms defined for&nb= sp; TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats defined in respective specifications. As a result, the new protocols= are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

     

    <RG&= gt; As mentioned in previous replies, other than timestamp vs. counter and = it’s format, the messages and processing of them are the same for del= ay and direct-mode loss measurement.

    • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

    Though it appears the using a d= edicated packet format instead of TLV is more efficient, but the dedicated = for the direct loss measurement format is likely to precede one or even two= TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

     

    <RG&= gt; As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

     

     

    ·         What are the potential = benefits of specifying the return path in the new test packet's Sender Cont= rol Code?

    Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

     

    <RG&= gt; Per session basis between different sender nodes and this reflector nod= e, some senders will request the replies in-band (e.g. for two-way mode). S= essions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for = a bidirectional SR path). This is also similar to as described Section 3.1 = in RFC 6374, top of page 22. There is no need to create a such state for ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

     

    <ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa. <= /o:p>

    • What is the relationship between the *-srpm drafts and= BFD?

    Some text in the *-srpm drafts = suggest that the proposed method can be used to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be = made aware of the proposals. I didn't take the liberty of adding BFD WG or = its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

     

    <RG&= gt; As mentioned in previous replies, STAMP/TWAMP test messages are also us= ed today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

    &n= bsp;

    Thanks,=

    Rakesh<= o:p>

    =  

    = Regards,

     

     

    On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,

    thank you for your prompt respo= nse, much appreciated. I'll carefully read your responses. Looking for= ward to the continued discussion.

     

    Regards,

    Greg

     

    On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Greg,

     

    Thank you for your review comments. As mentio= ned in the IPPM session today, the email response was sent as attachments, = see archive blow:

    https://mailarchiv= e.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/=

     

    I am attaching them in word documents for the= convenience. We can address your comments below in the next revision of th= e document.

     

    Thanks,

    Rakesh

     

     

    From: Greg= Mirsky <greg= imirsky@gmail.com>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Ple= ase find my follow-up notes in-lined below under the GIM>> tag.<= /o:p>

    I hope you've found more detailed comments in= the attachments (re-attached for your convenience). I'm looking forward to= reading your responses to the detailed comments of all four drafts.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi= (rgandhi) <rgand= hi@cisco.com> wrote:

    Thank you Greg for ta= king time for thoroughly reviewing the documents and providing the comments= .  Attached please find the email replies to your review sent earlier.  The replies are copied inline below for= convenience, tagged with <RG00>.

     

     

    From: ippm= <ippm-bounce= s@ietf.org>
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG communit= y,

    I've reviewed these drafts and have some comm= ents to share. Below, please find my thoughts on whether these drafts can b= e adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying=  draft targetted to the SPRING WG) are in the attached documents.=

     

    Usually, the bar for the adoption of a document= can be evaluated by answers to these three questions:

    ·=   Is the document(s) reasonably well-written=

    I've got surprised that the drafts don't use th= e terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. = Also, many terms, e.g., Links, "congruent paths", are used in the= documents without proper definitions. Other than that both drafts are read= able and reasonably well-written.

     

    <RG00> We can c= hange Sender to Session-Sender and Reflector to Session-Reflector if it hel= ps. 

    GIM>> I believe that the consistency in= terminology between the core RFC and what is intended as its extension is = not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.

    <RG00> There ar= e many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) a= nd term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having = said that, we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs.= I think I need to clarify my questions. While a reference to any of RFCs y= ou've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced RFCs used the lower case form for the term "link". Can = these be used interchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with us= ing the term "congruent path" in these drafts (using ASCII-art):<= o:p>

                &nb= sp;          C---------D

                &nb= sp;        /            &= nbsp;    \

                A--= --B                   E--= ---F

                &nb= sp;        \            &= nbsp;     /

                &nb= sp;        G------------H

    Consider an SR tunnel from A to F that traver= ses the network as A-B-C-D-E-F. From the definition of "congruent"= ; as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the= mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts, direct loss measurement can be performed, as information collected f= rom node F. So, this example, in my opinion, illustrates two of my concerns= :

    • using a congruent path for an active OAM protocol may = produce information that does not reflect the condition experienced by the = monitored flow. It seems that the terminology should reflect the fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.

     

    ·=   Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     

    <RG00> There is= a requirement to measure performance delay as well as synthetic and direct= -mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

    GIM>> I agree with the requirement= s you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3= 3; years ago). I believe that there's no sufficient technical reason t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. =

     

    ·=   Is the proposed solution technically viable?

    There are too many unaddressed aspects, particu= larly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     

    <RG00> About yo= ur comment on zero checksum, this is described in Security section in RFC 6= 936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

    GIM>> I don't think that a mere referen= ce sufficiently explains why the use of zero UDP checksum in IPv6 header is= not decremental, does not create a security risk for the protocol.

     

    Thanks,

    Rakesh

     

     

    Regards,=

    Greg

     

     

     

     

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

     

    For the past few meetings, we’ve had up= dates on the work in the SPRING WG that was using STAMP and TWAMP. Since th= ose documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be= best to split the documents and track the IPPM extension work in the IPPM = WG.

     

    As such, we are starting a Working Group call= for adoption for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-s= tamp-srpm.

     

    Please provide your feedback on these documen= ts, and state whether or not you believe the IPPM WG should adopt this work= by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, Nov= ember 16.

     

    Best,

    Tommy & Ian

    _____________________________________________= __
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_d333def04f55416783d5078a75780685huaweicom_-- From nobody Wed Nov 18 21:53:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D19C3A0E01; Wed, 18 Nov 2020 21:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 G_F2vGnWL1Je; Wed, 18 Nov 2020 21:53:40 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 430AA3A0DA6; Wed, 18 Nov 2020 21:53:40 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id d17so6483534lfq.10; Wed, 18 Nov 2020 21:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mt51ahb8xKMxpJ9vFg/Od33KrpAR1zHmD+/WbhHE4lY=; b=R8hYkYSZGNIwAlISm0lGi6rZtSzHeRnfzOeYYB6rA9xG21lL+MUsK+Lo61PjKe6dPL Ag3nRp9p4YOTKv379qYfm/xfHcrYADV+UXemcIZ3eXytdprXiA9cOUZQfBe+Kp59oQ07 Y3H6q7LMWFB9ueQv088ociQGkhtEXhr3wHAg0LcDejyhE39Isa7xCbPRPUh0Fc63KOWL PRlN0MJOT+8cdU52sZVfObSpb0NWwXYcJrrywf01fBDmVVIzM6RWxrZ0VFcbDO2HtcVp fw2QMyjFmFP1oyW3pC7mhDDCgcxOKGymHFB4fwDBT4bM61dScI7zRV624dV2jgx8wqHl 0tbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mt51ahb8xKMxpJ9vFg/Od33KrpAR1zHmD+/WbhHE4lY=; b=RORlhFAnz0aTpAiGipjX8ppRZXP66ajApLnGWBnw3cw9A49uh8OCqu4dw6RHDehhco hBpQK0ElXxe4mch+fmQETJBXRX16oNHZaprlEM8m++CdrSUfPnMAFI8+8T/lqiSzCzPi C4E9a9DrDpxDcMIJMJAGiVbyvDz3t39bDT8VoaoIgVTK3HJKUL1KtLMP8wPW/C4PZSeM URhvht4Qvqsd1QVK2KrlBmwyfx1Bi33hsFic3GAjvch6tuaaRj1qGKYoNdLsaoZaG/AT q2kO59PXvBefAnCIcV3ZpRoQn479wkHa2ogvix+WAbMDNhUau5rbkqUjTREdAeyxRfFL 60Ew== X-Gm-Message-State: AOAM531pNRuXpij5bvNEIbCmrfT8WuVgdlC1nm5EpUpnQBFRa1O3Y003 yWfWRB3mv/aL/3qs/HAuuaVgZJvCSh4XqxRCVJA= X-Google-Smtp-Source: ABdhPJw72PtsTCYu9+d3/xqbmiNp38HHpadNXammw1KphMat9QnSkbHZyc3uwXU9IPHk54y9GWokmJUhmTpAL3/vwmE= X-Received: by 2002:ac2:46cc:: with SMTP id p12mr4776254lfo.56.1605765218275; Wed, 18 Nov 2020 21:53:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 18 Nov 2020 21:53:24 -0800 Message-ID: To: Tianran Zhou Cc: "Rakesh Gandhi (rgandhi)" , spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000006d96bc05b46f59ab" Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 05:53:46 -0000 --0000000000006d96bc05b46f59ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tianran, thank you for sharing your perspective on the *-SRPM drafts and the discussion, it is very refreshing and thought-provoking. I believe that you've hit the nail on the head by pointing to what is missing from the discussion - the agreed by the WGs set of the requirements. I absolutely agree with you, without a clear understanding of the requirements documents appear as a solution that is looking for a problem to be solved. Instead of discussing issues with the proposed new protocol, it may be helpful to take a step back and discuss requirements. For example, how to evaluate the efficiency of different methods of direct packet loss measurement. Or, as you've pointed out, compare the pros and cons of configuring metadata for the duration of a test session vs. carrying metadata in each test packet. And, as was noted by other reviewers of the drafts, the requirements are likely to be applicable not only to a Segment Routing but to a network in general. Regards, Greg On Wed, Nov 18, 2020 at 9:33 PM Tianran Zhou wrote= : > Hi Rakesh and Greg, > > > > I may not very clear about the context. Please allow me to jump in. > > It seems both of you make some valid point. > > Please see in line with . > > > > Cheers, > > Tianran > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Rakesh > Gandhi (rgandhi) > *Sent:* Wednesday, November 18, 2020 7:41 AM > *To:* Greg Mirsky > *Cc:* spring ; IPPM Chairs ; > spring-chairs@ietf.org; Tommy Pauly = ; > IETF IPPM WG (ippm@ietf.org) > *Subject:* Re: [spring] [ippm] Call for adoption: > draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm > > > > Hi Greg, > > > > Thank you for your review and discussions on the drafts. This will help > improve the work on this important work. > > Please see replies inline with .. > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, November 17, 2020 at 5:27 PM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Tommy Pauly , IPPM Chairs < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG (ippm@ietf.org) , spring > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Hi Rakesh, WG Chairs, and All, > > I've read the responses to my detailed comments. I don't think that only > adding references will solve the problems with the documents. If authors > are interested in addressing my comments, we can start working on > solving them one by one. > > > > As mentioned in previous replies, we can add references for the > well-known terms =E2=80=9CLinks=E2=80=9D, =E2=80=9CCongruent Paths=E2=80= =9D, =E2=80=9CSR Path=E2=80=9D. If you prefer, we > can define them here. For Zero checksum field, we can add a reference for > the RFC 6936 in Security section and also add some text for it. Will be > happy to work with you to address these. > > > > But I am very much concerned with the technical value of these drafts. An= d > here's why I feel that the proposed documents don't provide a sound > technical solution to the task of direct loss measurement. Please find my > reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm: > > - What is being proposed in these drafts? > > Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support > direct packet loss measurements. Note, that RFC 6374 includes a method fo= r > direct loss measurement in MPLS networks that is applicable to the SR-MPL= S > environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension = to > RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et > loss measurement. STAMP and all its extensions are applicable in IPv6 > networks and, thus, can be used in the SRv6 domain. > > > > As mentioned in previous replies, both RFC 6374 (in Section 4.2) and > ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX > and RX counters for direct-mode loss measurement. TWAMP/STAMP messages > defined in the drafts are equivalent of them that take advantage of the > widely deployed TWAMP protocol and as well this same protocol can be > deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks. > > > > I think RFC6374 for MPLS and Y.1731 make some noise here. The point > is if we need a new direct packet loss measurement for STAMP, when STAMP > already defined a Direct Measurement TLV ( > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If > current Direct Measurement TLV cannot fulfill some use case requirement, > then how about proposing a new TLV. > > - How the proposed method of direct packet loss is related to TWAMP > light and STAMP? > > There's no apparent technical relationship between *-twamp-srpm and TWAMP > Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use t= he > basic mechanisms defined for TWAMP-Test and/or STAMP in their respective > specifications. Rather than that, drafts introduce a new query-response > mode and new formats of test packets that are decisively different from t= he > formats defined in respective specifications. As a result, the new > protocols are required to use different from used by TWAMP Light tr STAMP > test session UDP port numbers on the responder. And that is another clear > indication that the proposed mechanism represents a new protocol, neither > extends TWAMP Light and/or STAMP nor updates their specifications. > > > > As mentioned in previous replies, other than timestamp vs. counter > and it=E2=80=99s format, the messages and processing of them are the same= for delay > and direct-mode loss measurement. > > - Is there any advantage in introducing a dedicated packet format for > the direct packet loss in STAMP comparing to using the Direct Measurem= ent > TLV extension? > > Though it appears the using a dedicated packet format instead of TLV is > more efficient, but the dedicated for the direct loss measurement format = is > likely to precede one or even two TLVs, Node Address TLV and Path TLV, > defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the n= ew > packet with TLVs is unlikely to be more efficient and reduce the processi= ng > delay, than if using the Direct Measurement TLV as defined in > draft-ietf-ippm-stamp-option-tlv. > > > > As mentioned in previous replies, this is explained in Section 1 of > the draft-gandhi-spring-stamp-srpm > . For > link loss measurement (direct-mode), there is no TLV required for example= . > For direct-mode loss measurement in SR networks, it would *typically* be > forward direction packet loss measurement (and not bidirectional). > > > > > > =C2=B7 What are the potential benefits of specifying the return p= ath > in the new test packet's Sender Control Code? > > Using the Sender Control Code may require the use of the additional TLV > that carries the return path information, Path TLV. If the ability to > control the return path is required that can be achieved by augmenting th= e > STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including > the Path TLV in each test packet. Hence, there seem no technical > requirements to introduce the Sender Control Code field in the Base STAMP > format defined in RFC 8762. > > > > Per session basis between different sender nodes and this reflector > node, some senders will request the replies in-band (e.g. for two-way > mode). Sessions are provisioned on the Sender nodes and reflector simply > reflects based on the received test-packet (e.g. for a bidirectional SR > path). This is also similar to as described Section 3.1 in RFC 6374, top = of > page 22. There is no need to create a such state for each session on the > reflector node and create a scale limitation. Recall that we are trying t= o > avoid the scale limitation by eliminating the Control protocol signaling. > > > > I find some value to include the path TLV in wire. As Rakesh > mentioned, this can reduce the reflector configuration. But I am not > convinced to introduce the sender control code field. It seems to me, the > presence of path TLV indicates the bidirectional congruent path. Vise > versa. > > - What is the relationship between the *-srpm drafts and BFD? > > Some text in the *-srpm drafts suggest that the proposed method can be > used to monitor for the loss of a path continuity. That may be viewed as = an > alternative to the BFD protocol method for the detection of a network > failure. If the discussion of Loopback mode and monitoring of liveness > remain in the drafts, it seems logical that the BFD WG and BFD WG's Chair= s > be made aware of the proposals. I didn't take the liberty of adding BFD W= G > or its Chairs. I believe that decision to be made by the Chairs of IPPM A= nd > SPRING WGs. > > > > As mentioned in previous replies, STAMP/TWAMP test messages are also > used today for *synthetic* packet loss measurement which can be also used > to detect/monitor connection loss (performance metric). The draft simply > highlights this obvious metric. This is also very similar to what is > described in ITU Y.1731, Section 7.1. > > > > Thanks, > > Rakesh > > > > Regards, > > > > > > On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: > > Hi Rakesh, > > thank you for your prompt response, much appreciated. I'll carefully read > your responses. Looking forward to the continued discussion. > > > > Regards, > > Greg > > > > On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com> wrote: > > Hi Greg, > > > > Thank you for your review comments. As mentioned in the IPPM session > today, the email response was sent as attachments, see archive blow: > > https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ > > > > I am attaching them in word documents for the convenience. We can address > your comments below in the next revision of the document. > > > > Thanks, > > Rakesh > > > > > > *From: *Greg Mirsky > *Date: *Friday, November 13, 2020 at 10:09 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Tommy Pauly , IPPM Chairs < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG (ippm@ietf.org) > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Hi Rakesh, > > thank you for your response to my review. Please find my follow-up notes > in-lined below under the GIM>> tag. > > I hope you've found more detailed comments in the attachments (re-attache= d > for your convenience). I'm looking forward to reading your responses to t= he > detailed comments of all four drafts. > > > > Regards, > > Greg > > > > On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. Attached please find the email replies to your > review sent earlier. The replies are copied inline below for convenience= , > tagged with . > > > > > > *From: *ippm > *Date: *Monday, November 9, 2020 at 11:48 AM > *To: *Tommy Pauly > *Cc: *IPPM Chairs , spring-chairs@ietf.org < > spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Dear WG Chairs, Authors, and IPPM WG community, > > I've reviewed these drafts and have some comments to share. Below, please > find my thoughts on whether these drafts can be adopted. More specific > comments on each pair of drafts (TWAMP-related and STAMP-related draft an= d > its accompanying draft targetted to the SPRING WG) are in the attached > documents. > > > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > =C2=B7 Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFCs > 4656/5357 and RFC 8762, and introduce their own terminology for > Session-Sender and Session-Reflector. Also, many terms, e.g., Links, > "congruent paths", are used in the documents without proper definitions. > Other than that both drafts are readable and reasonably well-written. > > > > We can change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. > > There are many existing RFCs that use term Link (e.g. RFC 5613, > 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. From the definition of "congruent" as "two figures or object= s > are congruent if they have the same shape and size, or if one has the sam= e > shape and size as the mirror image of the other", path A-B-G-H-E-F is > congruent to the SR tunnel. But a packet of an active OAM intended to > monitor a flow over the SR tunnel is out-of-band and will not produce any > meaningful measurement. Of course, for the case of the extensions in > drafts, direct loss measurement can be performed, as information collecte= d > from node F. So, this example, in my opinion, illustrates two of my > concerns: > > - using a congruent path for an active OAM protocol may produce > information that does not reflect the condition experienced by the > monitored flow. It seems that the terminology should reflect the > fundamental requirement for using active OAM to maintain the test pack= ets > in-band with the monitored flow. > - there are no technical requirements to justify using in-band active > OAM protocol for direct packet loss measurement. As demonstrated in th= is > example, direct packet loss can be performed using an out-of-band > mechanism, e.g., SNMP queries, Netconf notifications based on YANG dat= a > model. > > > > =C2=B7 Does the document solve a real problem? > > No, it appears that both TWAMP and STAMP drafts define a new > performance measurement protocol for the purpose of combining OWAMP/TWAMP > and STAMP functionality in the respective drafts, and adding the ability = to > collect counters of "in-profile" packets. I couldn't find sufficient > technical arguments for using a PM protocol instead of, for example, > extending the existing OAM mechanisms like ICMP multi-part message > extension per RFC 4884. > > > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direct > packet loss measurement. > > > > =C2=B7 Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocols on network security, to comprehensively evaluate the > proposed solutions. > > > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for STAMP or TWAMP Light. Other than this, = I > did not find any other security related issue in your review. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > > > Thanks, > > Rakesh > > > > > > Regards, > > Greg > > > > > > > > > > On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > > Hello IPPM, > > > > For the past few meetings, we=E2=80=99ve had updates on the work in the S= PRING WG > that was using STAMP and TWAMP. Since those documents ended up making > extensions to the base protocols, the chairs of SPRING and IPPM decided > that it would be best to split the documents and track the IPPM extension > work in the IPPM WG. > > > > As such, we are starting a Working Group call for adoption > for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. > > > > The documents are here: > > https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 > > https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 > > > The related SPRING documents are here: > > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 > > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > > > Please provide your feedback on these documents, and state whether or not > you believe the IPPM WG should adopt this work by replying to this email. > Please provide your feedback by the start of the IETF 109 meeting week, o= n *Monday, > November 16*. > > > > Best, > > Tommy & Ian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --0000000000006d96bc05b46f59ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tianran,
    thank you for sharing your perspective=C2= =A0on the *-SRPM drafts=C2=A0and the discussion, it is very refreshing and = thought-provoking. I believe that you've hit the nail on the head by po= inting to what is missing from the discussion - the agreed by the WGs set o= f the requirements. I absolutely agree with you, without a clear understand= ing of the requirements documents appear=C2=A0as a solution that is looking= for a problem to=C2=A0be solved. Instead of discussing issues with the pro= posed new protocol, it may be helpful to take a step back and discuss requi= rements. For example, how to evaluate the efficiency of different methods o= f direct packet loss measurement. Or, as you've pointed out, compare th= e pros and cons of configuring metadata=C2=A0for the duration of a test ses= sion vs. carrying metadata=C2=A0in each test packet.=C2=A0 And, as was note= d by other=C2=A0reviewers of the drafts, the requirements are likely to be = applicable not only to a Segment Routing but to a network in general.
    =

    Regards,
    Greg

    On Wed, Nov 18, 2020 at 9:= 33 PM Tianran Zhou <zhoutianra= n@huawei.com> wrote:

    Hi Rakesh and G= reg,

    =C2=A0

    I may not very = clear about the context. Please allow me to jump in.

    It seems both o= f you make some valid point.

    Please see in l= ine with <ZTR>.

    =C2=A0

    Cheers,<= u>

    Tianran<= u>

    =C2=A0

    From: spring [mailto:spring-bounces@ietf.org] On Beh= alf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <= spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf.org>; spring-chairs@ietf.org; Tommy Pa= uly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

    =C2=A0

    = Hi Greg,

    = =C2=A0

    = Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work.

    = Please see replies inline with <RG>..

    = =C2=A0

    =C2=A0

    From: Greg M= irsky <gregim= irsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM = Chairs <ippm-c= hairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,<= u>

    I've read the responses to = my detailed comments. I don't think that only adding references will so= lve the problems with the documents. If authors are interested in addressin= g my comments, we can start working on solving=C2=A0them one by one.

    =C2=A0

    = <RG> As mentioned in previous replies, we can add references for the = well-known terms =E2=80=9CLinks=E2=80=9D, =E2=80=9CCongruent Paths=E2=80=9D= , =E2=80=9CSR Path=E2=80=9D. If you prefer, we can define them here. For Ze= ro checksum field, we can add a reference for the RFC 6936 in Security section and also add some tex= t for it. Will be happy to work with you to address these.

    = =C2=A0

    But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the = proposed documents don't provide a sound technical solution to the task= of direct loss measurement.=C2=A0Please find my reasoning explaining=C2=A0my opinion of the *-twamp-srpm and *-stamp-srpm:=

    • What is being proposed in these drafts?<= /span>

    Drafts *-twamp-srpm and *-stamp= -srpm propose a new protocol to support direct packet loss measurements. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

    =C2=A0

    = <RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2)= and ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting= TX and RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.<= /u>

    =C2=A0

    <ZTR> I think RFC6374 for= MPLS and Y.1731 make some noise here. The point is if we need a new direct packet loss measurement for STAMP, when = STAMP already defined a Direct Measurement TLV (https:= //datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If curren= t Direct Measurement TLV cannot fulfill some use case requirement, then how about proposing a new TLV.<= /u>

    • How the proposed method of direct packet loss is relat= ed to TWAMP light and STAMP?

    There's no apparent technic= al relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm draft= s and STAMP. Drafts do not extend or re-use the basic mechanisms defined fo= r=C2=A0 TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats defined in respective specifications. As a result, the new protocols= are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

    =C2=A0

    = <RG> As mentioned in previous replies, other than timestamp vs. count= er and it=E2=80=99s format, the messages and processing of them are the sam= e for delay and direct-mode loss measurement.

    • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

    Though it appears the using a d= edicated packet format instead of TLV is more efficient, but the dedicated = for the direct loss measurement format is likely to precede one or even two= TLVs, Node Address TLV and Path TLV, defined in=C2=A0draft-gandhi-ippm-stamp-srpm. As a result, processing of t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

    =C2=A0

    = <RG> As mentioned in previous replies, this is explained in Section 1= of the draft-gandhi-sprin= g-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

    =C2=A0

    =C2=A0

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 What are the potential ben= efits of specifying the return path in the new test packet's Sender Con= trol Code?

    Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

    =C2=A0

    = <RG> Per session basis between different sender nodes and this reflec= tor node, some senders will request the replies in-band (e.g. for two-way m= ode). Sessions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for = a bidirectional SR path). This is also similar to as described Section 3.1 = in RFC 6374, top of page 22. There is no need to create a such state for ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

    =C2=A0

    <ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

    • What is the relationship between the *-srpm drafts and= BFD?

    Some text in the *-srpm drafts = suggest that the proposed method can be used=C2=A0to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs= be made aware of the proposals. I didn't take the liberty of adding BF= D WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

    =C2=A0

    = <RG> As mentioned in previous replies, STAMP/TWAMP test messages are = also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

    = =C2=A0

    = Thanks,

    = Rakesh

    =C2=A0

    Re= gards,

    =C2=A0

    =C2=A0

    On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,=

    thank you for your prompt respo= nse,=C2=A0much appreciated. I'll carefully read your responses. Looking= forward to the continued discussion.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    Thank you for your review comme= nts. As mentioned in the IPPM session today, the email response was sent as= attachments, see archive blow:

    http= s://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/<= /u>

    =C2=A0

    I am attaching them in word doc= uments for the convenience. We can address your comments below in the next = revision of the document.

    =C2=A0

    Thanks,

    Rakesh

    =C2=A0

    =C2=A0

    From: Greg M= irsky <gregim= irsky@gmail.com>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm    <= /span>

    Hi Rakesh,=

    thank you for your response to = my review. Please find my follow-up notes in-lined below under the GIM>&= gt; tag.

    I hope you've found more de= tailed comments in the attachments (re-attached for your convenience). I= 9;m looking forward to reading your responses=C2=A0to the detailed comments of all four drafts.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Nov 10, 2020 at 8:11 AM= Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    = Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments.=C2=A0 Attached please find the email replies to your review sent earlier.=C2=A0 The replies are copied inline below for= convenience, tagged with <RG00>.<= u>

    = =C2=A0

    =C2=A0

    From: ippm &= lt;ippm-bounces@= ietf.org>
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm    <= /span>

    Dear WG Chairs, Authors, and IP= PM WG community,

    I've reviewed these drafts = and have some comments to share. Below, please find my thoughts on whether = these drafts can be adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying= =C2=A0draft targetted=C2=A0to the SPRING WG) are in the attached documents.=

    =C2=A0

    Usually, the bar for the adoption o= f a document can be evaluated=C2=A0by answers to these three questions:

    =C2=B7=C2=A0 Is the document(s) reasonably well-written

    I've got surprised that the dra= fts don't use the terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. = Also, many terms, e.g., Links, "congruent paths", are used in the= documents without proper definitions. Other than that both drafts are read= able and reasonably well-written.=

    =C2=A0

    = <RG00> We can change Sender to Session-Sender and Reflector to Sessio= n-Reflector if it helps.=C2=A0

    GIM>> I believe that the = consistency in terminology between the core RFC and what is intended as its= extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.

    = <RG00> There are many existing RFCs that use term Link (e.g. RFC 5613= , 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having = said that, we can add a reference for them if it helps.

    GIM>> Thank you for listi= ng these RFCs. I think I need to clarify my questions. While a reference to= any of RFCs you've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced RFCs used the lower case form for the term "link". Can = these be used interchangeably? Do they refer to the same network object?=

    Now I'll try to illustrate = my concern with using the term "congruent path" in these drafts (= using ASCII-art):

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 A----B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to= F that traverses the network as A-B-C-D-E-F. From the definition of "= congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the= mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts, direct loss measurement can be performed, as information collected f= rom node F. So, this example, in my opinion, illustrates two of my concerns= :

    • using a congruent path for an active OAM protocol may = produce information that does not reflect the condition experienced by the = monitored flow. It seems that the terminology should reflect the fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.
      • <= /ul>

    =C2=A0

    =C2=B7=C2=A0 Does the document solve a real problem?

    No, it appears that=C2=A0 both TWAMP and STAMP drafts=C2=A0define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't f= ind sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

    =C2=A0

    = <RG00> There is a requirement to measure performance delay as well as= synthetic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

    GIM>> I agree with the=C2= =A0requirements you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason=C2=A0t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement.=C2=A0=

    =C2=A0

    =C2=B7=C2=A0 Is the proposed solution technically viable?=

    There are too many unaddressed aspe= cts, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

    =C2=A0<= u>

    = <RG00> About your comment on zero checksum, this is described in Secu= rity section in RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

    GIM>> I don't think t= hat a mere reference sufficiently explains why the use of zero UDP checksum= in IPv6 header is not decremental, does not create a security risk for the protocol.

    = =C2=A0

    = Thanks,

    = Rakesh

    =C2=A0

    =C2=A0

    Regards,

    Greg=

    =C2=A0<= /p>

    =C2=A0

    =C2=A0<= /p>

    =C2=A0

    On Fri, Oct 30, 2020 at 11:35 A= M Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

    =C2=A0

    For the past few meetings, we= =E2=80=99ve had updates on the work in the SPRING WG that was using STAMP a= nd TWAMP. Since those documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be= best to split the documents and track the IPPM extension work in the IPPM = WG.

    =C2=A0

    As such, we are starting a Work= ing Group call for adoption for=C2=A0draft-gandhi-ippm-twamp-srpm and draft= -gandhi-ippm-stamp-srpm.

    =C2=A0

    Please provide your feedback on= these documents, and state whether or not you believe the IPPM WG should a= dopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, Nov= ember 16.

    =C2=A0

    Best,

    Tommy & Ian

    _______________________________= ________________
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --0000000000006d96bc05b46f59ab-- From nobody Wed Nov 18 23:41:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238E3A111A; Wed, 18 Nov 2020 23:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HhKHBTIRTSEc; Wed, 18 Nov 2020 23:41:27 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF033A1116; Wed, 18 Nov 2020 23:41:27 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CcBQX4RxRz67FD8; Thu, 19 Nov 2020 15:39:32 +0800 (CST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 08:41:24 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 19 Nov 2020 08:41:24 +0100 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.200]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 19 Nov 2020 15:41:12 +0800 From: Mach Chen To: Tianran Zhou , "Rakesh Gandhi (rgandhi)" , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutxTJVi9zzpG0iVJvrFDESlT6m/jAuAgAGIKYCABKWmAIAEH64AgAAA6ACAAqNCgIAAFHgAgAH03ICAAKEOYA== Date: Thu, 19 Nov 2020 07:41:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 07:41:32 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]... From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) ; Greg Mi= rsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM= WG (ippm@ietf.org) Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms "Links", "Congruent Paths", "SR Path". If you prefer, we can def= ine them here. For Zero checksum field, we can add a reference for the RFC = 6936 in Security section and also add some text for it. Will be happy to wo= rk with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussions= are mainly about draft*-stamp-srpm. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. How the proposed method of direct packet loss is related to TWAMP light and= STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it's format, the messages and processing of them are the same for delay an= d direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in = the new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. * Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we've had updates on the work in the SPRING WG t= hat was using STAMP and TWAMP. Since those documents ended up making extens= ions to the base protocols, the chairs of SPRING and IPPM decided that it w= ould be best to split the documents and track the IPPM extension work in th= e IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Tianran, Rakesh and Greg,

     

    Please see some responses inline with [Mach]…

     

    From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org= >; Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly=3D40apple.com@dmar= c.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Hi Rake= sh and Greg,

    &n= bsp;

    I may n= ot very clear about the context. Please allow me to jump in.

    It seem= s both of you make some valid point.

    Please = see in line with <ZTR>.

    &n= bsp;

    Cheers,=

    Tianran=

    &n= bsp;

    From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimi= rsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     

    Hi Greg= ,

    &n= bsp;

    Thank y= ou for your review and discussions on the drafts. This will help improve th= e work on this important work.

    Please = see replies inline with <RG>..

    &n= bsp;

     

    From: Greg= Mirsky <gregimirsky@gmail.com<= /a>>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <    rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,<= o:p>

    I've read the responses to my d= etailed comments. I don't think that only adding references will solve the = problems with the documents. If authors are interested in addressing my com= ments, we can start working on solving them one by one.

     

    <RG&= gt; As mentioned in previous replies, we can add references for the well-kn= own terms “Links”, “Congruent Paths”, “SR Pat= h”. If you prefer, we can define them here. For Zero checksum field, = we can add a reference for the RFC 6936 in Security section and also add some tex= t for it. Will be happy to work with you to address these.

    &n= bsp;

    But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the prop= osed documents don't provide a sound technical solution to the task of dire= ct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:=

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp= -srpm propose a new protocol to support direct packet loss measurements. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

     

    <RG&= gt; As mentioned in previous replies, both RFC 6374 (in Section 4.2) and IT= U Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and= RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.=

     

    <ZTR> I think RFC6374 for= MPLS and Y.1731 make some noise here. The point is if we need a new direct= packet loss measurement for STAMP, when STAMP already defined a Direct Mea= surement TLV (https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-opt= ion-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

     

    [Mach] Given that TWAMP does not support TLV, I assume that the d= iscussions are mainly about draft*-stamp-srpm.

     

    [Mach] In the case of direct packet loss measurement, draft-gandh= i-ippm-stamp-srpm assumes that marking-based solution (which can address th= e packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlat= e the counters from the sender and reflector. The current direct loss measu= rement TLV may just apply to the scenario without packet out-ordering.

     

    [Mach] In addition, whether to keep it as current design or to de= fine a new TLV for direct loss measurement can be debatable.  

     

    How the proposed method of dire= ct packet loss is related to TWAMP light and STAMP?

    There's no apparent technical r= elationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts an= d STAMP. Drafts do not extend or re-use the basic mechanisms defined for&nb= sp; TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats defined in respective specifications. As a result, the new protocols= are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

     

    <RG&= gt; As mentioned in previous replies, other than timestamp vs. counter and = it’s format, the messages and processing of them are the same for del= ay and direct-mode loss measurement.

    • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

    Though it appears the using a d= edicated packet format instead of TLV is more efficient, but the dedicated = for the direct loss measurement format is likely to precede one or even two= TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

     

    <RG&= gt; As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

     

     

    ·         What are the potential = benefits of specifying the return path in the new test packet's Sender Cont= rol Code?

    Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

     

    <RG&= gt; Per session basis between different sender nodes and this reflector nod= e, some senders will request the replies in-band (e.g. for two-way mode). S= essions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for = a bidirectional SR path). This is also similar to as described Section 3.1 = in RFC 6374, top of page 22. There is no need to create a such state for ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

     

    <ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa. <= /o:p>

     

    [Mach] Regarding how to specify the return path, the draft define= s two ways to achieve that, one is to use control code to direct whether th= e reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanism= s) and STAMP. At the same time, in the case of STAMP, it also defines the r= eturn path TLV to explicitly specify the return path, which bring more opti= ons to specify the return path. Therefore, I see benefit of the two ways.

     

     

    Best regards,

    Mach

     

    What is the relationship betwee= n the *-srpm drafts and BFD?

    Some text in the *-srpm drafts = suggest that the proposed method can be used to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be = made aware of the proposals. I didn't take the liberty of adding BFD WG or = its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

     

    <RG&= gt; As mentioned in previous replies, STAMP/TWAMP test messages are also us= ed today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

    &n= bsp;

    Thanks,=

    Rakesh<= o:p>

    =  

    = Regards,

     

     

    On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,

    thank you for your prompt respo= nse, much appreciated. I'll carefully read your responses. Looking for= ward to the continued discussion.

     

    Regards,

    Greg

     

    On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Greg,

     

    Thank you for your review comments. As mentio= ned in the IPPM session today, the email response was sent as attachments, = see archive blow:

    https://mailarchiv= e.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/=

     

    I am attaching them in word documents for the= convenience. We can address your comments below in the next revision of th= e document.

     

    Thanks,

    Rakesh

     

     

    From: Greg= Mirsky <greg= imirsky@gmail.com>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Ple= ase find my follow-up notes in-lined below under the GIM>> tag.<= /o:p>

    I hope you've found more detailed comments in= the attachments (re-attached for your convenience). I'm looking forward to= reading your responses to the detailed comments of all four drafts.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi= (rgandhi) <rgand= hi@cisco.com> wrote:

    Thank you Greg for ta= king time for thoroughly reviewing the documents and providing the comments= .  Attached please find the email replies to your review sent earlier.  The replies are copied inline below for= convenience, tagged with <RG00>.

     

     

    From: ippm= <ippm-bounce= s@ietf.org>
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG communit= y,

    I've reviewed these drafts and have some comm= ents to share. Below, please find my thoughts on whether these drafts can b= e adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying=  draft targetted to the SPRING WG) are in the attached documents.=

     

    Usually, the bar for the adoption of a document= can be evaluated by answers to these three questions:

    ·=   Is the document(s) reasonably well-written=

    I've got surprised that the drafts don't use th= e terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. = Also, many terms, e.g., Links, "congruent paths", are used in the= documents without proper definitions. Other than that both drafts are read= able and reasonably well-written.

     

    <RG00> We can c= hange Sender to Session-Sender and Reflector to Session-Reflector if it hel= ps. 

    GIM>> I believe that the consistency in= terminology between the core RFC and what is intended as its extension is = not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.

    <RG00> There ar= e many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) a= nd term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having = said that, we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs.= I think I need to clarify my questions. While a reference to any of RFCs y= ou've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced RFCs used the lower case form for the term "link". Can = these be used interchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with us= ing the term "congruent path" in these drafts (using ASCII-art):<= o:p>

                &nb= sp;          C---------D

                &nb= sp;        /            &= nbsp;    \

                A--= --B                   E--= ---F

                &nb= sp;        \            &= nbsp;     /

                &nb= sp;        G------------H

    Consider an SR tunnel from A to F that traver= ses the network as A-B-C-D-E-F. From the definition of "congruent"= ; as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the= mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts, direct loss measurement can be performed, as information collected f= rom node F. So, this example, in my opinion, illustrates two of my concerns= :

    • using a congruent path for an active OAM protocol may = produce information that does not reflect the condition experienced by the = monitored flow. It seems that the terminology should reflect the fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.

     

    ·=   Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     

    <RG00> There is= a requirement to measure performance delay as well as synthetic and direct= -mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

    GIM>> I agree with the requirement= s you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3= 3; years ago). I believe that there's no sufficient technical reason t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. =

     

    ·=   Is the proposed solution technically viable?

    There are too many unaddressed aspects, particu= larly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     

    <RG00> About yo= ur comment on zero checksum, this is described in Security section in RFC 6= 936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

    GIM>> I don't think that a mere referen= ce sufficiently explains why the use of zero UDP checksum in IPv6 header is= not decremental, does not create a security risk for the protocol.

     

    Thanks,

    Rakesh

     

     

    Regards,=

    Greg

     

     

     

     

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

     

    For the past few meetings, we’ve had up= dates on the work in the SPRING WG that was using STAMP and TWAMP. Since th= ose documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be= best to split the documents and track the IPPM extension work in the IPPM = WG.

     

    As such, we are starting a Working Group call= for adoption for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-s= tamp-srpm.

     

    Please provide your feedback on these documen= ts, and state whether or not you believe the IPPM WG should adopt this work= by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, Nov= ember 16.

     

    Best,

    Tommy & Ian

    _____________________________________________= __
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_-- From nobody Thu Nov 19 00:58:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055403A1221; Thu, 19 Nov 2020 00:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DxEIaeJ6_tp1; Thu, 19 Nov 2020 00:58:34 -0800 (PST) Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0673A1220; Thu, 19 Nov 2020 00:58:30 -0800 (PST) X-AuditID: 0a000f35-09bff70000001141-0d-5fb633b42675 Received: from M10-HQ-MLCEN01.cnc.intra (Unknown_Domain [10.249.212.31]) by sendg.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 03.3D.04417.4B336BF5; Thu, 19 Nov 2020 16:58:28 +0800 (HKT) Received: from M10-HQ-ML11.hq.cnc.intra (10.249.213.81) by M10-HQ-MLCEN01.cnc.intra (10.249.212.31) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 16:58:28 +0800 Received: from M10-HQ-ML02.hq.cnc.intra (10.249.213.72) by M10-HQ-ML11.hq.cnc.intra (10.249.213.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 16:58:25 +0800 Received: from M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250]) by M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250%20]) with mapi id 15.00.1497.006; Thu, 19 Nov 2020 16:58:25 +0800 From: =?utf-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?utf-8?B?5pys6YOoKQ==?= To: =?utf-8?B?56iL5Lyf5by6?= , "spring@ietf.org" CC: srcomp , "spring-chairs@ietf.org" Thread-Topic: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Thread-Index: AQHWvlEH1m+H/DRH3EOk/oVquzFWWw== Date: Thu, 19 Nov 2020 08:58:25 +0000 Message-ID: <0df1b0805de34dbc8742313200c694de@M10-HQ-ML02.hq.cnc.intra> References: <160545233786.30631.15366800831645495687@ietfa.amsl.com>, <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.203.1] Content-Type: multipart/alternative; boundary="_000_0df1b0805de34dbc8742313200c694deM10HQML02hqcncintra_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsXC9fOKvO4W423xBqdealqcXtXLbnH8wm9G i857t1kdmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXxZM97poI1/YwV1y9+Y21gPNDN2MXIySEh YCLx8sdCNhBbSOA8o8Sifv4uRi4gewejxMUrL9jgnKW9U5ggqvYzSuw9mAOSYBNoYpQ48X09 WEJEIFli1+YGsFHMAoESK34cYAGxhQVyJO72z2GBqMmV2LzwPpStJ9Ha8wSsnkVAVWLflsPM IDavgLvEw8snGSE29zJKNH36A9bAKCArMe3RfSaIBeISc6fNYoX4QUBiyZ7zzBC2qMTLx/+g 4gYSW5fuY4GwFSSW99xjhOjNlti89SQrxDJBiZMzn7BAfKYs0Xx8OusERvFZSFbMQtIyC0nL LEYOoLimxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKBns625hbGGg62+sl5yRmZdYmpeZ nJ+rl5y3iREUrwz8pjsYP976oHeIkYmD8RCjBAezkgjvWs2t8UK8KYmVValF+fFFpTmpxYcY pTlYlMR57RRWxQkJpCeWpGanphakFsFkmTg4pRqYdK+ppZzaN7HDKjcq+Z/TsbxbBTfzd+l7 rryqFsAXEVC344erdId086e5DGK37r28VH29rq6KNXHf0/tlFx6fWjB3T/6aKde3penbVfBk rvn6rlBa7UC5tdUM1YcHg98deZajuf2Mxeo1nBOSqpZlBTeWWItXV53JioieW8eWvvn8nL9O E3SKsr+GXlknPnFFPI8K708hK+vH33/qV5zuf6HJ3bNhqlfo+sn9/2dIyxiustd/dNJpjs6G XJ4NrFyVpeLq4ls3sDw/9yor6q5U2zw727KIOy+ORzOU9N2v/P3hgEd54KpCa8U4twVGkZ1f YtfONz/1b4bJ5fUn9k1jPWt1NKQgK+f8VO82xqpZSizFGYmGWsxFxYkA/nSnKUYDAAA= Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 08:58:37 -0000 --_000_0df1b0805de34dbc8742313200c694deM10HQML02hqcncintra_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2VpcWlhbmcgYW5kIFdHLA0KICAgIEkgcmVhZCB0aGUgZHJhZnQgYW5kIGFncmVlIHdpdGgg dGhlIHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4gaXQuSSB0aGluayB0aGUgcmVxdWlyZW1lbnRz IGluIEFwcGVuZGl4IEEgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRyYWZ0IGluIHRoZSBuZXh0IHZl cnNpb24uDQogICAgQ2hpbmEgVW5pY29tIGlzIHdvcmtpbmcgb24gYSBuZXR3b3JrIGV2b2x1dGlv biBwbGFuIGZvciBTUnY2IG5vdywgIGFuZCB3ZSBoYXZlIGRvbmUgc29tZSBmaWVsZCB0cmlhbHMg YmFzZWQgb24gU1J2Ni4gSW4gb3JkZXIgdG8gbWFpbnRhaW4gdGhlIGNvbnRpbnVpdHkgb2YgIHRo ZSBmdW5jdGlvbmFsaXR5LCB3ZSBzdWdnZXN0IHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB0aGUgU1J2 NiBzdGFuZGFyZHMuDQoNCkJlc3QgcmVnYXJkcywNClBhbmcgUmFuDQoNCkZyb206IOeoi+S8n+W8 ujxtYWlsdG86Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+DQpEYXRlOiAyMDIwLTExLTE1 IDIzOjI3DQpUbzogc3ByaW5nPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpDQzogc3Jjb21wPG1h aWx0bzpzcmNvbXBAaWV0Zi5vcmc+OyBzcHJpbmctY2hhaXJzQGlldGYubzxtYWlsdG86c3ByaW5n LWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIEZ3Ok5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50 LTAxLnR4dA0KDQpIaSBHcm91cCwNCg0KU1IgY29tcHJlc3Npb24gZGVzaWduIHRlYW0gaGF2ZSBz dWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBjb21wcmVzc2lvbiByZXF1aXJlbWVudCBkcmFmdC4N Cg0KTWFpbiBjaGFuZ2VzIGFzIGZvbGxvd3M6DQoNCi0gYWRkZWQgMyBpdGVtcyBhYm91dCBzY2Fs aWJpbGl0eSB3aXRoIGFncmVlbWVudCB3aXRoaW4gdGhlIGRlc2lnbiB0ZWFtDQoNCi0gYWRkZWQg YW4gYXBwZW5kaXggaW5jbHVkaW5nIDMgaXRlbXMgd2l0aG91dCB3aXRob3V0IHVuYW5pbW91cyBj b25zZW5zdXMgd2l0aGluIHRoZSBkZXNpZ24gdGVhbQ0KDQotIHNvbWUgbWlub3IgdGV4dCBpc3N1 ZSBmaXhlZA0KDQpQbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgdXMga25vdyB5b3VyIGNvbW1lbnRz Lg0KDQoNCkJUVzogV2Ugd2lsbCBoYXZlIDEtaG91ciBzZXNzaW9uIGZvciB0aGUgZGVzaWduIHRl YW0gdG9waWMgb24gRnJpZGF5IGFuZCB3ZWxjb21lIHRvIGpvaW4gdXMuDQoNCg0KQi5SLg0KDQpX ZWlxaWFuZyBvbiBiZWhhbGYgb2YgZGVzaWduIHRlYW0NCg0KDQoNCg0KLS0tLemCruS7tuWOn+aW hy0tLS0NCuWPkeS7tuS6uu+8mmludGVybmV0LWRyYWZ0cyA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0K5pS25Lu25Lq677yaV2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFtb2Jp bGUuY29tPixTYW5kZXIgU3RlZmZhbm4gPHNhbmRlckBzdGVmZmFubi5ubD4sU0pNIFN0ZWZmYW5u IDxzYW5kZXJAc3RlZmZhbm4ubmw+DQrmioTjgIDpgIE6ICjml6ApDQrlj5HpgIHml7bpl7TvvJoy MDIwLTExLTE1IDIyOjU4OjU3DQrkuLvpopjvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9u LXJlcXVpcmVtZW50LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBX ZWlxaWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQNClJldmlzaW9u OiAwMQ0KVGl0bGU6IENvbXByZXNzZWQgU1J2NiBTSUQgTGlzdCBSZXF1aXJlbWVudHMNCkRvY3Vt ZW50IGRhdGU6IDIwMjAtMTEtMTMNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OiAxMw0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNClN0YXR1czogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9u LXJlcXVpcmVtZW50Lw0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpIdG1s aXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0w MQ0KDQpBYnN0cmFjdDoNCiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9y IHNvbHV0aW9ucyB0byBjb21wcmVzcyBTUnY2DQogU0lEIGxpc3RzLg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K U3ViamVjdO+8mk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3By aW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaXFpYW5nIENoZW5nIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudA0KUmV2aXNpb246IDAxDQpUaXRsZTogQ29tcHJl c3NlZCBTUnY2IFNJRCBMaXN0IFJlcXVpcmVtZW50cw0KRG9jdW1lbnQgZGF0ZTogMjAyMC0xMS0x Mw0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEzDQpVUkw6IGh0dHBzOi8v d3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9u LXJlcXVpcmVtZW50LTAxLnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQvDQpIdG1s aXplZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQNCkh0bWxpemVkOiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxDQpEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxDQoNCkFic3RyYWN0Og0KIFRo aXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXBy ZXNzIFNSdjYNCiBTSUQgbGlzdHMuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCuWmguaenOaCqOmUmeivr+aO peaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7tueri+WNs+mAmuefpeaIkeS7 rOOAguivt+WbnuWkjemCruS7tuWIsCBocXMtc3BtY0BjaGluYXVuaWNvbS5jbu+8jOWNs+WPr+S7 pemAgOiuouatpOmCruS7tuOAguaIkeS7rOWwhueri+WNs+WwhuaCqOeahOS/oeaBr+S7juaIkeS7 rOeahOWPkemAgeebruW9leS4reWIoOmZpOOAgiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLiBQbGVh c2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20uY24gLHlvdSBjYW4gdW5zdWJzY3JpYmUg ZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRp b24gZnJvbSBzZW5kIGNhdGFsb2d1ZSBvZiBvdXIuDQo= --_000_0df1b0805de34dbc8742313200c694deM10HQML02hqcncintra_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyB9ZGl2LkZveERpdjIwMjAxMTE5MTY0ODI1NDU1MzgxIHsgfWJvZHkgeyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGxpbmUt aGVpZ2h0OiAxLjU7IH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmksIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0LjY2NjdweDsi PjxzcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic3JjIiBkYXRhLWdyb3VwPSIwLTAiIHN0eWxlPSJi b3gtc2l6aW5nOiBib3JkZXItYm94OyBsaW5lLWhlaWdodDogMjZweDsgd2lkb3dzOiBhdXRvOyI+ SGkmbmJzcDtXZWlxaWFuZyBhbmQgV0csJm5ic3A7PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDE0LjY2NjdweDsiPjxzcGFuIGNsYXNzPSJzcmMiIGRhdGEtZ3JvdXA9IjAtMCIgc3R5 bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGxpbmUtaGVpZ2h0OiAyNnB4OyB3aWRvd3M6IGF1 dG87Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuNTsiPiZuYnNwOyAmbmJzcDsmbmJzcDs8 L3NwYW4+SSByZWFkIHRoZSBkcmFmdCBhbmQgYWdyZWUgd2l0aCB0aGUgcmVxdWlyZW1lbnRzDQog c3BlY2lmaWVkIGluIGl0Ljwvc3Bhbj48c3BhbiBjbGFzcz0ic3JjIiBkYXRhLWdyb3VwPSIxLTAi IHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBsaW5lLWhlaWdodDogMjZweDsgd2lkb3dz OiBhdXRvOyI+SSB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGluIEFwcGVuZGl4IEEgc2hvdWxkIGJl IHBhcnQgb2YgdGhlIGRyYWZ0IGluIHRoZSBuZXh0IHZlcnNpb24uPC9zcGFuPjxiciBzdHlsZT0i Ym94LXNpemluZzogYm9yZGVyLWJveDsgbGluZS1oZWlnaHQ6IDI2cHg7IHdpZG93czogYXV0bzsi Pg0KPHNwYW4gY2xhc3M9InNyYyIgZGF0YS1ncm91cD0iMi0wIiBzdHlsZT0iYm94LXNpemluZzog Ym9yZGVyLWJveDsgbGluZS1oZWlnaHQ6IDI2cHg7IHdpZG93czogYXV0bzsiPiZuYnNwOyAmbmJz cDsmbmJzcDtDaGluYSBVbmljb20gaXMgd29ya2luZyBvbiBhIG5ldHdvcmsgZXZvbHV0aW9uIHBs YW4gZm9yIFNSdjYgbm93LCAmbmJzcDthbmQgd2UgaGF2ZSBkb25lIHNvbWUgZmllbGQgdHJpYWxz Jm5ic3A7YmFzZWQgb24gU1J2Ni4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9InNyYyIgZGF0YS1n cm91cD0iMi0xIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbGluZS1oZWlnaHQ6IDI2 cHg7IHdpZG93czogYXV0bzsiPkluDQogb3JkZXIgdG8gbWFpbnRhaW4gdGhlIGNvbnRpbnVpdHkg b2YgJm5ic3A7dGhlIGZ1bmN0aW9uYWxpdHksIHdlIHN1Z2dlc3QgdGhlIHNvbHV0aW9uIGJhc2Vk IG9uIHRoZSBTUnY2IHN0YW5kYXJkcy48L3NwYW4+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ PHNwYW4gY2xhc3M9InNyYyIgZGF0YS1ncm91cD0iMi0xIiBzdHlsZT0iYm94LXNpemluZzogYm9y ZGVyLWJveDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6IEFyaWFsLCAnTWlj cm9zb2Z0IFlhSGVpJywgJ1xcNUZBRei9r+mbhem7kScsICdcXDVCOELkvZMnLCAnTWFsZ3VuIEdv dGhpYycsIE1laXJ5bywgc2Fucy1zZXJpZjsgbGluZS1oZWlnaHQ6IDI2cHg7IHdpZG93czogYXV0 bzsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9InNyYyIgZGF0YS1ncm91 cD0iMi0xIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6IHJnYig1MSwgNTEs IDUxKTsgZm9udC1mYW1pbHk6IEFyaWFsLCAnTWljcm9zb2Z0IFlhSGVpJywgJ1xcNUZBRei9r+mb hem7kScsICdcXDVCOELkvZMnLCAnTWFsZ3VuIEdvdGhpYycsIE1laXJ5bywgc2Fucy1zZXJpZjsg bGluZS1oZWlnaHQ6IDI2cHg7IHdpZG93czogYXV0bzsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICdNaWNyb3NvZnQgWWFIZWkgVUknLCBUYWhvbWE7IGxp bmUtaGVpZ2h0OiAyMXB4OyI+DQo8ZGl2IHN0eWxlPSJwb3NpdGlvbjogc3RhdGljICFpbXBvcnRh bnQ7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2hpdGUtc3Bh Y2U6IHByZS13cmFwOyB3aWRvd3M6IDI7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGln YXR1cmVzOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48c3BhbiBzdHlsZT0id2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAxOyBmb250LXNpemU6IDE0LjY2NjdweDsiPjxmb250IGZh Y2U9IkNhbGlicmksIHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6ICdNaWNyb3NvZnQgWWFIZWkgVUknLCBUYWhvbWE7IGxpbmUtaGVpZ2h0OiAyMXB4OyBm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7Ij4NCjxzcGFuIHN0eWxl PSJsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDE0LjY2NjdweDsiPjxmb250IGZhY2U9 IkNhbGlicmksIHNhbnMtc2VyaWYiPlBhbmcgUmFuPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjwvc3Bh bj48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tVG9wOiAwcHg7IG1hcmdpbi1Cb3R0 b206IDBweDsgbWFyZ2luLUxlZnQ6IDAuNWVtOyBtYXJnaW4tUmlnaHQ6IGluaGVyaXQiPg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXYgc3R5bGU9IlBB RERJTkctUklHSFQ6IDhweDsgUEFERElORy1MRUZUOiA4cHg7IEZPTlQtU0laRTogMTJweDtGT05U LUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsgQkFDS0dST1VORDogI2VmZWZlZjsgUEFERElO Ry1CT1RUT006IDhweDsgUEFERElORy1UT1A6IDhweCI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSI+56iL5Lyf5by6 PC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDIwLTExLTE1Jm5ic3A7MjM6Mjc8 L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPnNwcmluZzwvYT48L2Rpdj4NCjxkaXY+PGI+Q0M6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0 bzpzcmNvbXBAaWV0Zi5vcmciPnNyY29tcDwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmctY2hh aXJzQGlldGYub3JnIj4NCnNwcmluZy1jaGFpcnNAaWV0Zi5vPC9hPjwvZGl2Pg0KPGRpdj48Yj5T dWJqZWN0OjwvYj4mbmJzcDtbc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iRm94RGl2MjAyMDExMTkxNjQ4 MjU0NTUzODEiPg0KPHA+SGkgR3JvdXAsPC9wPg0KPHA+U1IgY29tcHJlc3Npb24gZGVzaWduIHRl YW0gaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBjb21wcmVzc2lvbiByZXF1aXJlbWVu dCBkcmFmdC48L3A+DQo8cD5NYWluIGNoYW5nZXMgYXMgZm9sbG93czombmJzcDs8L3A+DQo8cD4t IGFkZGVkIDMgaXRlbXMgYWJvdXQgc2NhbGliaWxpdHkmbmJzcDt3aXRoIGFncmVlbWVudCB3aXRo aW4gdGhlIGRlc2lnbiB0ZWFtJm5ic3A7PC9wPg0KPHA+LSZuYnNwO2FkZGVkIGFuIGFwcGVuZGl4 Jm5ic3A7aW5jbHVkaW5nIDMgaXRlbXMgd2l0aG91dCB3aXRob3V0IHVuYW5pbW91cyBjb25zZW5z dXMgd2l0aGluIHRoZSBkZXNpZ24gdGVhbTwvcD4NCjxwPi0gc29tZSBtaW5vciB0ZXh0IGlzc3Vl IGZpeGVkPC9wPg0KPHA+UGxlYXNlIHJldmlldyBpdCBhbmQgbGV0IHVzIGtub3cgeW91ciBjb21t ZW50cy48L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5CVFc6IFdlIHdpbGwgaGF2ZTxzcGFuIHN0eWxl PSJmb250LWZhbWlseTo7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kzsiPiZuYnNw OzEtaG91ciBzZXNzaW9uIGZvciB0aGUgZGVzaWduIHRlYW0gdG9waWM8L3NwYW4+PC9zcGFuPiZu YnNwO29uIEZyaWRheSBhbmQgd2VsY29tZSB0byBqb2luIHVzLjwvcD4NCjxwPjxicj4NCjwvcD4N CjxwPkIuUi48L3A+DQo8cD5XZWlxaWFuZyBvbiBiZWhhbGYgb2YgZGVzaWduIHRlYW08L3A+DQo8 cD48YnI+DQo8L3A+DQo8ZGl2IGlkPSJkaXZzaWduYXR1cmUiPiZuYnNwOzwvZGl2Pg0KPHA+LS0t LemCruS7tuWOn+aWhy0tLS08YnI+DQrlj5Hku7bkurrvvJppbnRlcm5ldC1kcmFmdHMmbmJzcDsm bHQ7aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnJmd0Ozxicj4NCuaUtuS7tuS6uu+8mldlaXFpYW5n Jm5ic3A7Q2hlbmcmbmJzcDsmbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7LFNh bmRlciZuYnNwO1N0ZWZmYW5uJm5ic3A7Jmx0O3NhbmRlckBzdGVmZmFubi5ubCZndDssU0pNJm5i c3A7U3RlZmZhbm4mbmJzcDsmbHQ7c2FuZGVyQHN0ZWZmYW5uLm5sJmd0Ozxicj4NCuaKhOOAgOmA gTombmJzcDso5pegKTxicj4NCuWPkemAgeaXtumXtO+8mjIwMjAtMTEtMTUmbmJzcDsyMjo1ODo1 Nzxicj4NCuS4u+mimO+8mk5ldyZuYnNwO1ZlcnNpb24mbmJzcDtOb3RpZmljYXRpb24mbmJzcDtm b3ImbmJzcDtkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEu dHh0PGJyPg0KPGJyPg0KPGJyPg0KQSZuYnNwO25ldyZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNw O0ktRCwmbmJzcDtkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQt MDEudHh0PGJyPg0KaGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRl ZCZuYnNwO2J5Jm5ic3A7V2VpcWlhbmcmbmJzcDtDaGVuZyZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZu YnNwO3RvJm5ic3A7dGhlPGJyPg0KSUVURiZuYnNwO3JlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt ZTogZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PGJyPg0KUmV2 aXNpb246IDAxPGJyPg0KVGl0bGU6IENvbXByZXNzZWQmbmJzcDtTUnY2Jm5ic3A7U0lEJm5ic3A7 TGlzdCZuYnNwO1JlcXVpcmVtZW50czxicj4NCkRvY3VtZW50Jm5ic3A7ZGF0ZTogMjAyMC0xMS0x Mzxicj4NCkdyb3VwOiBJbmRpdmlkdWFsJm5ic3A7U3VibWlzc2lvbjxicj4NClBhZ2VzOiAxMzxi cj4NClVSTDombmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29t cGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8YnI+DQpTdGF0dXM6Jm5i c3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5n LWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lzxicj4NCkh0bWxpemVkOiZuYnNwO2h0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNz aW9uLXJlcXVpcmVtZW50PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMTxi cj4NCkRpZmY6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNy Y29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMTxicj4NCjxicj4NCkFic3Ry YWN0Ojxicj4NCiZuYnNwO1RoaXMmbmJzcDtkb2N1bWVudCZuYnNwO3NwZWNpZmllcyZuYnNwO3Jl cXVpcmVtZW50cyZuYnNwO2ZvciZuYnNwO3NvbHV0aW9ucyZuYnNwO3RvJm5ic3A7Y29tcHJlc3Mm bmJzcDtTUnY2PGJyPg0KJm5ic3A7U0lEJm5ic3A7bGlzdHMuPGJyPg0KPGJyPg0KJm5ic3A7PGJy Pg0KPGJyPg0KPGJyPg0KUGxlYXNlJm5ic3A7bm90ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21h eSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxlJm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7 ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtvZiZuYnNwO3N1Ym1pc3Npb248YnI+DQp1bnRp bCZuYnNwO3RoZSZuYnNwO2h0bWxpemVkJm5ic3A7dmVyc2lvbiZuYnNwO2FuZCZuYnNwO2RpZmYm bmJzcDthcmUmbmJzcDthdmFpbGFibGUmbmJzcDthdCZuYnNwO3Rvb2xzLmlldGYub3JnLjxicj4N Cjxicj4NClRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDxicj4NCjxicj4NCjxicj4NCjxi cj4NClN1YmplY3TvvJpOZXcmbmJzcDtWZXJzaW9uJm5ic3A7Tm90aWZpY2F0aW9uJm5ic3A7Zm9y Jm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4 dDxicj4NCjxicj4NCjxicj4NCkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJ LUQsJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAx LnR4dDxicj4NCmhhcyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQm bmJzcDtieSZuYnNwO1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJzcDtwb3N0ZWQmbmJz cDt0byZuYnNwO3RoZTxicj4NCklFVEYmbmJzcDtyZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6 IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDxicj4NClJldmlz aW9uOiAwMTxicj4NClRpdGxlOiBDb21wcmVzc2VkJm5ic3A7U1J2NiZuYnNwO1NJRCZuYnNwO0xp c3QmbmJzcDtSZXF1aXJlbWVudHM8YnI+DQpEb2N1bWVudCZuYnNwO2RhdGU6IDIwMjAtMTEtMTM8 YnI+DQpHcm91cDogSW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248YnI+DQpQYWdlczogMTM8YnI+ DQpVUkw6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPg0KU3RhdHVzOiZuYnNw O2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC88YnI+DQpIdG1saXplZDombmJzcDtodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lv bi1yZXF1aXJlbWVudDxicj4NCkh0bWxpemVkOiZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8YnI+ DQpEaWZmOiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNv bXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8YnI+DQo8YnI+DQpBYnN0cmFj dDo8YnI+DQombmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDtzcGVjaWZpZXMmbmJzcDtyZXF1 aXJlbWVudHMmbmJzcDtmb3ImbmJzcDtzb2x1dGlvbnMmbmJzcDt0byZuYnNwO2NvbXByZXNzJm5i c3A7U1J2Njxicj4NCiZuYnNwO1NJRCZuYnNwO2xpc3RzLjxicj4NCjxicj4NCiZuYnNwOzxicj4N Cjxicj4NCjxicj4NClBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQmbmJzcDttYXkm bmJzcDt0YWtlJm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRlcyZuYnNwO2Zy b20mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJyPg0KdW50aWwm bmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5i c3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48YnI+DQo8 YnI+DQpUaGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K5aaC5p6c5oKo6ZSZ6K+v5o6l 5pS25LqG6K+l6YKu5Lu277yM6K+36YCa6L+H55S15a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus 44CC6K+35Zue5aSN6YKu5Lu25YiwJm5ic3A7aHFzLXNwbWNAY2hpbmF1bmljb20uY27vvIzljbPl j6/ku6XpgIDorqLmraTpgq7ku7bjgILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47m iJHku6znmoTlj5HpgIHnm67lvZXkuK3liKDpmaTjgIIgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbC4g UGxlYXNlIHJlcGx5IHRvJm5ic3A7aHFzLXNwbWNAY2hpbmF1bmljb20uY24mbmJzcDsseW91IGNh biB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseQ0KIHJlbW92 ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20gc2VuZCBjYXRhbG9ndWUgb2Ygb3VyLg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_0df1b0805de34dbc8742313200c694deM10HQML02hqcncintra_-- From nobody Thu Nov 19 02:21:07 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0983A1377; Thu, 19 Nov 2020 02:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 zN6nTYEduTaz; Thu, 19 Nov 2020 02:21:04 -0800 (PST) Received: from out0-142.mail.aliyun.com (out0-142.mail.aliyun.com [140.205.0.142]) (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 144313A1384; Thu, 19 Nov 2020 02:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1605781256; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=pMlpgGcITcDqrC/tML3AwdI5S6pkbBn6ItW7OSqgg7w=; b=wUYh5rneVHaeF95a4vVWUpQ3YX8tiplKTPRqHwrtmR3VIWpRON8xx5pFRWeDBQ4qxjvPRzFLRmp5GmObGTa8DNvQt2j0/6PUZMdbhu7syhNNRQCuSiW1HlhNHGKGxm3x17Tcy8QDjNp6TuFaRtJWz/nJlGmvbX/mw2cuWNTbHA4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047202; MF=yitai.syc@alibaba-inc.com; NM=1; PH=DW; RN=5; SR=0; TI=W4_6056262_DEFAULT_0AC264DF_1605779549159_o7001c51e; Received: from WS-web (yitai.syc@alibaba-inc.com[W4_6056262_DEFAULT_0AC264DF_1605779549159_o7001c51e]) by ay29a011140100189.et135 at Thu, 19 Nov 2020 18:20:54 +0800 Date: Thu, 19 Nov 2020 18:20:54 +0800 From: "=?UTF-8?B?6IuP6L+c6LaFKOS7peazsCk=?=" To: "spring@ietf.org" , "srcomp" , "spring" Cc: "spring-chairs@ietf.org" , "=?UTF-8?B?56iL5Lyf5by6?=" Reply-To: "=?UTF-8?B?6IuP6L+c6LaFKOS7peazsCk=?=" Message-ID: <05216f3e-939b-4649-bbb6-fe10201c4058.yitai.syc@alibaba-inc.com> X-Mailer: [Alimail-Mailagent][W4_6056262][DEFAULT][Chrome] MIME-Version: 1.0 x-aliyun-mail-creator: W4_6056262_DEFAULT_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfNSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzgxLjAuNDA0NC4xMzggU2FmYXJpLzUzNy4zNg==vN Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_57687_7fa9c1eab700_5fb64706_15566d1" Archived-At: Subject: [spring] =?utf-8?q?Fw=3ANew_Version_Notification_for_draft-srcom?= =?utf-8?q?pdt-spring-compression-requirement-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 10:21:06 -0000 ------=ALIBOUNDARY_57687_7fa9c1eab700_5fb64706_15566d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGVhciBTcHJpbmcgV0csCiAgIFRoaXMgaXMgWXVhbmNoYW8gU3UsIG5ldHdvcmsgYXJjaGl0 ZWN0IGxlYWQgb2YgQWxpYmFiYSBDbG91ZC4gV2Ugc3VwcG9ydCB0aGUgcmVxdWlyZW1lbnRzIGlu IEFwcGVuZGl4IEEgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRyYWZ0IGluIHRoZSBuZXh0IHZlcnNp b24uCiAgIEFsaWJhYmEgaGF2ZSBiZWVuIHdvcmtpbmcgb24gU1J2NiAmIHVTSUQgZm9yIGEgd2hp bGUsIHdlIHJlcXVpcmUgYWxsIFNSLXJlbGF0ZWQgdGVjaG5vbG9neSB0byBiZSBzdGFuZGFyZCBj b21wbGllZCBmcm9tIGRheSAxLCBhcyB3ZSBiZWxpZXZlIHRoaXMgaXMgdGhlIHJpZ2h0IHdheSB0 byBhdm9pZCBpbnRlci1vcGVyYXRhYmlsaXR5IGlzc3VlcyBhbmQgYWNjZWxlcmF0ZSBkZXBsb3lt ZW50LgogICBGcm9tIGEgY2xvdWQgcHJvdmlkZXIgcG9pbnQgb2YgdmlldywgYW4gb3BlbiAmIHN0 cm9uZyBlY28tc3lzdGVtIGlzIHZlcnkgdmVyeSBrZXkuIEFmdGVyIHNldmVyYWwgeWVhcnMgZGV2 ZWxvcG1lbnQsIFNSdjYncyBlY29zeXN0ZW0gaXMgcmFtcGluZyB1cC4gV2UgZG8gY29uc2lkZXIg U0lEIGNvbXByZXNzaW9uIHNvbHV0aW9uIHNob3VsZCBiYXNlIG9uIGN1cnJlbnQgU1J2NiBlY29z eXRlbSBidXQgbm90IGJ1aWxkIGZyb20gc2NyYXRjaC4KICAgVGhhbmtzLgoKICAgICAgICAgICBZ dWFuY2hhbyBTdQogICAgICAgICAgIEFsaWJhYmEgQ2xvdWQKCgpGcm9tOiDnqIvkvJ/lvLoKRGF0 ZTogMjAyMC0xMS0xNSAyMzoyNwpUbzogc3ByaW5nCkNDOiBzcmNvbXA7ICBzcHJpbmctY2hhaXJz QGlldGYubwpTdWJqZWN0OiBbc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQKSGkg R3JvdXAsClNSIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZl cnNpb24gb2YgY29tcHJlc3Npb24gcmVxdWlyZW1lbnQgZHJhZnQuCk1haW4gY2hhbmdlcyBhcyBm b2xsb3dzOiAKLSBhZGRlZCAzIGl0ZW1zIGFib3V0IHNjYWxpYmlsaXR5IHdpdGggYWdyZWVtZW50 IHdpdGhpbiB0aGUgZGVzaWduIHRlYW0gCi0gYWRkZWQgYW4gYXBwZW5kaXggaW5jbHVkaW5nIDMg aXRlbXMgd2l0aG91dCB3aXRob3V0IHVuYW5pbW91cyBjb25zZW5zdXMgd2l0aGluIHRoZSBkZXNp Z24gdGVhbQotIHNvbWUgbWlub3IgdGV4dCBpc3N1ZSBmaXhlZApQbGVhc2UgcmV2aWV3IGl0IGFu ZCBsZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzLgoKQlRXOiBXZSB3aWxsIGhhdmUgMS1ob3VyIHNl c3Npb24gZm9yIHRoZSBkZXNpZ24gdGVhbSB0b3BpYyBvbiBGcmlkYXkgYW5kIHdlbGNvbWUgdG8g am9pbiB1cy4KCkIuUi4KV2VpcWlhbmcgb24gYmVoYWxmIG9mIGRlc2lnbiB0ZWFtCgotLS0t6YKu 5Lu25Y6f5paHLS0tLQog5Y+R5Lu25Lq677yaaW50ZXJuZXQtZHJhZnRzIDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+CiDmlLbku7bkurrvvJpXZWlxaWFuZyBDaGVuZyA8Y2hlbmd3ZWlxaWFuZ0Bj aGluYW1vYmlsZS5jb20+LFNhbmRlciBTdGVmZmFubiA8c2FuZGVyQHN0ZWZmYW5uLm5sPixTSk0g U3RlZmZhbm4gPHNhbmRlckBzdGVmZmFubi5ubD4KIOaKhOOAgOmAgTogKOaXoCkKIOWPkemAgeaX tumXtO+8mjIwMjAtMTEtMTUgMjI6NTg6NTcKIOS4u+mimO+8mk5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAx LnR4dAoKCiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dAogaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBXZWlxaWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQogSUVURiByZXBvc2l0b3J5LgoK IE5hbWU6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudAogUmV2 aXNpb246IDAxCiBUaXRsZTogQ29tcHJlc3NlZCBTUnY2IFNJRCBMaXN0IFJlcXVpcmVtZW50cwog RG9jdW1lbnQgZGF0ZTogMjAyMC0xMS0xMwogR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbgog UGFnZXM6IDEzCiBVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dAogU3RhdHVzOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJl c3Npb24tcmVxdWlyZW1lbnQvCiBIdG1saXplZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQK IEh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3By aW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxCiBEaWZmOiBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxCgogQWJzdHJhY3Q6CiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRz IGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3MgU1J2NgogIFNJRCBsaXN0cy4KCgoKCiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uCiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLgoKIFRoZSBJRVRGIFNlY3JldGFyaWF0CgoKCiBTdWJq ZWN077yaTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmct Y29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0CgoKIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0CiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaXFpYW5nIENoZW5nIGFuZCBwb3N0ZWQg dG8gdGhlCiBJRVRGIHJlcG9zaXRvcnkuCgogTmFtZTogZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNv bXByZXNzaW9uLXJlcXVpcmVtZW50CiBSZXZpc2lvbjogMDEKIFRpdGxlOiBDb21wcmVzc2VkIFNS djYgU0lEIExpc3QgUmVxdWlyZW1lbnRzCiBEb2N1bWVudCBkYXRlOiAyMDIwLTExLTEzCiBHcm91 cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uCiBQYWdlczogMTMKIFVSTDogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWly ZW1lbnQtMDEudHh0CiBTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC8KIEh0bWxpemVkOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmlu Zy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudAogSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEK IERpZmY6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNvbXBkdC1z cHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEKCiBBYnN0cmFjdDoKICBUaGlzIGRvY3Vt ZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBjb21wcmVzcyBTUnY2 CiAgU0lEIGxpc3RzLgoKCgoKIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24KIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuCgogVGhl IElFVEYgU2VjcmV0YXJpYXQKCgoKIOWmguaenOaCqOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8 jOivt+mAmui/h+eUteWtkOmCruS7tueri+WNs+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7 tuWIsCBocXMtc3BtY0BjaGluYXVuaWNvbS5jbu+8jOWNs+WPr+S7pemAgOiuouatpOmCruS7tuOA guaIkeS7rOWwhueri+WNs+WwhuaCqOeahOS/oeaBr+S7juaIkeS7rOeahOWPkemAgeebruW9leS4 reWIoOmZpOOAgiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNw bWNAY2hpbmF1bmljb20uY24gLHlvdSBjYW4gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdl IHdpbGwgaW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBzZW5kIGNhdGFs b2d1ZSBvZiBvdXIuIAoKCgo= ------=ALIBOUNDARY_57687_7fa9c1eab700_5fb64706_15566d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij5IaSBEZWFyIFNwcmluZyBXRyw8L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsi PiZuYnNwOyAmbmJzcDtUaGlzIGlzIFl1YW5jaGFvIFN1LCBuZXR3b3JrIGFyY2hpdGVjdCBsZWFk IG9mIEFsaWJhYmEgQ2xvdWQuIFdlIHN1cHBvcnQmbmJzcDs8c3BhbiAgc3R5bGU9ImNvbG9yOiMw MDAwMDA7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNC43cHg7Zm9u dC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aWRvd3M6Mjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6 aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6 aW5saW5lOyI+dGhlIHJlcXVpcmVtZW50cyBpbiBBcHBlbmRpeCBBIHNob3VsZCBiZSBwYXJ0IG9m IHRoZSBkcmFmdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLjwvc3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPiZuYnNwOyAmbmJzcDtBbGliYWJhIGhhdmUgYmVlbiB3b3JraW5nIG9uIFNS djYgJmFtcDsgdVNJRCBmb3IgYSB3aGlsZSwgd2UgcmVxdWlyZSBhbGwgU1ItcmVsYXRlZCB0ZWNo bm9sb2d5IHRvIGJlIHN0YW5kYXJkIGNvbXBsaWVkIGZyb20gZGF5IDEsIGFzIHdlIGJlbGlldmUg dGhpcyBpcyB0aGUgcmlnaHQgd2F5IHRvIGF2b2lkIGludGVyLW9wZXJhdGFiaWxpdHkgaXNzdWVz IGFuZCBhY2NlbGVyYXRlIGRlcGxveW1lbnQuPC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7 Ij4mbmJzcDsgJm5ic3A7RnJvbSBhIGNsb3VkIHByb3ZpZGVyIHBvaW50IG9mIHZpZXcsIGFuIG9w ZW4gJmFtcDsgc3Ryb25nIGVjby1zeXN0ZW0gaXMgdmVyeSB2ZXJ5IGtleS4gQWZ0ZXIgc2V2ZXJh bCB5ZWFycyBkZXZlbG9wbWVudCwgU1J2NidzIGVjb3N5c3RlbSBpcyByYW1waW5nIHVwLiBXZSBk byBjb25zaWRlciBTSUQgY29tcHJlc3Npb24gc29sdXRpb24gc2hvdWxkIGJhc2Ugb24gY3VycmVu dCBTUnY2IGVjb3N5dGVtIGJ1dCBub3QgYnVpbGQgZnJvbSBzY3JhdGNoLjwvZGl2PjxkaXYgIHN0 eWxlPSJjbGVhcjpib3RoOyI+Jm5ic3A7ICZuYnNwO1RoYW5rcy48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1l1YW5jaGFvIFN1PC9kaXY+PGRpdiAg c3R5bGU9ImNsZWFyOmJvdGg7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0FsaWJhYmEgQ2xvdWQ8L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxiciA+PC9k aXY+PGJsb2NrcXVvdGUgIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjBweDttYXJnaW4tdG9wOi4wcHg7 bWFyZ2luLWJvdHRvbTouMHB4OyI+PGRpdiA+Jm5ic3A7PC9kaXY+PGRpdiAgc3R5bGU9ImJvcmRl ci1yaWdodDpub25lO2JvcmRlci1ib3R0b206bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci1p bWFnZTppbml0aWFsO2JvcmRlci10b3A6MS4wcHggc29saWQgI2I1YzRkZjtwYWRkaW5nOjQuMHB4 IC4wY20gLjBjbTsiPjxkaXYgIGNsYXNzPSIgX19hbGl5dW5fbm9kZV9oYXNfY29sb3IgX19hbGl5 dW5fbm9kZV9oYXNfYmdjb2xvciIgc3R5bGU9InBhZGRpbmc6OC4wcHg7Zm9udC1zaXplOjEyLjBw eDtmb250LWZhbWlseTp0YWhvbWE7Y29sb3I6IzAwMDAwMDtiYWNrZ3JvdW5kOiNlZmVmZWY7Ij48 ZGl2ID48YiA+RnJvbTo8L2I+Jm5ic3A7PGEgIGhyZWY9Im1haWx0bzpjaGVuZ3dlaXFpYW5nQGNo aW5hbW9iaWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPueoi+S8n+W8ujwvYT48L2Rpdj48ZGl2ID48 YiA+RGF0ZTo8L2I+Jm5ic3A7MjAyMC0xMS0xNSZuYnNwOzIzOjI3PC9kaXY+PGRpdiA+PGIgPlRv OjwvYj4mbmJzcDs8YSAgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZzwvYT48L2Rpdj48ZGl2ID48YiA+Q0M6PC9iPiZuYnNwOzxhICBocmVmPSJtYWls dG86c3Jjb21wQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3Jjb21wPC9hPjsgPGEgIGhyZWY9 Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+CnNwcmluZy1j aGFpcnNAaWV0Zi5vPC9hPjwvZGl2PjxkaXYgPjxiID5TdWJqZWN0OjwvYj4mbmJzcDtbc3ByaW5n XSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8L2Rpdj48L2Rpdj48L2Rpdj48ZGl2ID48ZGl2 ICBjbGFzcz0iRm94RGl2MjAyMDExMTkxNjQ4MjU0NTUzODEiPjxwID5IaSBHcm91cCw8L3A+PHAg PlNSIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24g b2YgY29tcHJlc3Npb24gcmVxdWlyZW1lbnQgZHJhZnQuPC9wPjxwID5NYWluIGNoYW5nZXMgYXMg Zm9sbG93czombmJzcDs8L3A+PHAgPi0gYWRkZWQgMyBpdGVtcyBhYm91dCBzY2FsaWJpbGl0eSZu YnNwO3dpdGggYWdyZWVtZW50IHdpdGhpbiB0aGUgZGVzaWduIHRlYW0mbmJzcDs8L3A+PHAgPi0m bmJzcDthZGRlZCBhbiBhcHBlbmRpeCZuYnNwO2luY2x1ZGluZyAzIGl0ZW1zIHdpdGhvdXQgd2l0 aG91dCB1bmFuaW1vdXMgY29uc2Vuc3VzIHdpdGhpbiB0aGUgZGVzaWduIHRlYW08L3A+PHAgPi0g c29tZSBtaW5vciB0ZXh0IGlzc3VlIGZpeGVkPC9wPjxwID5QbGVhc2UgcmV2aWV3IGl0IGFuZCBs ZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzLjwvcD48cCA+PGJyID48L3A+PHAgPkJUVzogV2Ugd2ls bCBoYXZlPHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Ij4mbmJzcDsxLWhvdXIgc2Vz c2lvbiBmb3IgdGhlIGRlc2lnbiB0ZWFtIHRvcGljPC9zcGFuPiZuYnNwO29uIEZyaWRheSBhbmQg d2VsY29tZSB0byBqb2luIHVzLjwvcD48cCA+PGJyID48L3A+PHAgPkIuUi48L3A+PHAgPldlaXFp YW5nIG9uIGJlaGFsZiBvZiBkZXNpZ24gdGVhbTwvcD48cCA+PGJyID48L3A+PGRpdiAgaWQ9ImRp dnNpZ25hdHVyZSI+Jm5ic3A7PC9kaXY+PHAgPi0tLS3pgq7ku7bljp/mloctLS0tPGJyID4K5Y+R 5Lu25Lq677yaaW50ZXJuZXQtZHJhZnRzJm5ic3A7Jmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyZndDs8YnIgPgrmlLbku7bkurrvvJpXZWlxaWFuZyZuYnNwO0NoZW5nJm5ic3A7Jmx0O2NoZW5n d2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tJmd0OyxTYW5kZXImbmJzcDtTdGVmZmFubiZuYnNwOyZs dDtzYW5kZXJAc3RlZmZhbm4ubmwmZ3Q7LFNKTSZuYnNwO1N0ZWZmYW5uJm5ic3A7Jmx0O3NhbmRl ckBzdGVmZmFubi5ubCZndDs8YnIgPgrmioTjgIDpgIE6Jm5ic3A7KOaXoCk8YnIgPgrlj5HpgIHm l7bpl7TvvJoyMDIwLTExLTE1Jm5ic3A7MjI6NTg6NTc8YnIgPgrkuLvpopjvvJpOZXcmbmJzcDtW ZXJzaW9uJm5ic3A7Tm90aWZpY2F0aW9uJm5ic3A7Zm9yJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3By aW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dDxiciA+PGJyID48YnIgPgpBJm5ic3A7 bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8YnIgPgpoYXMmbmJzcDtiZWVuJm5i c3A7c3VjY2Vzc2Z1bGx5Jm5ic3A7c3VibWl0dGVkJm5ic3A7YnkmbmJzcDtXZWlxaWFuZyZuYnNw O0NoZW5nJm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8YnIgPgpJRVRGJm5i c3A7cmVwb3NpdG9yeS48YnIgPjxiciA+Ck5hbWU6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21w cmVzc2lvbi1yZXF1aXJlbWVudDxiciA+ClJldmlzaW9uOiAwMTxiciA+ClRpdGxlOiBDb21wcmVz c2VkJm5ic3A7U1J2NiZuYnNwO1NJRCZuYnNwO0xpc3QmbmJzcDtSZXF1aXJlbWVudHM8YnIgPgpE b2N1bWVudCZuYnNwO2RhdGU6IDIwMjAtMTEtMTM8YnIgPgpHcm91cDogSW5kaXZpZHVhbCZuYnNw O1N1Ym1pc3Npb248YnIgPgpQYWdlczogMTM8YnIgPgpVUkw6Jm5ic3A7PGEgIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNz aW9uLXJlcXVpcmVtZW50LTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxLnR4dDwvYT48YnIgPgpTdGF0dXM6Jm5ic3A7PGEgIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQvPC9hPjxiciA+ Ckh0bWxpemVkOiZuYnNwOzxhICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt c3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PC9hPjxiciA+Ckh0bWxpemVk OiZuYnNwOzxhICBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3Jjb21w ZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lv bi1yZXF1aXJlbWVudC0wMTwvYT48YnIgPgpEaWZmOiZuYnNwOzxhICBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9u LXJlcXVpcmVtZW50LTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0w MTwvYT48YnIgPjxiciA+CkFic3RyYWN0OjxiciA+CiZuYnNwO1RoaXMmbmJzcDtkb2N1bWVudCZu YnNwO3NwZWNpZmllcyZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO2ZvciZuYnNwO3NvbHV0aW9ucyZu YnNwO3RvJm5ic3A7Y29tcHJlc3MmbmJzcDtTUnY2PGJyID4KJm5ic3A7U0lEJm5ic3A7bGlzdHMu PGJyID48YnIgPgombmJzcDs8YnIgPjxiciA+PGJyID4KUGxlYXNlJm5ic3A7bm90ZSZuYnNwO3Ro YXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxlJm5ic3A7b2Ym bmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtvZiZuYnNwO3N1 Ym1pc3Npb248YnIgPgp1bnRpbCZuYnNwO3RoZSZuYnNwO2h0bWxpemVkJm5ic3A7dmVyc2lvbiZu YnNwO2FuZCZuYnNwO2RpZmYmbmJzcDthcmUmbmJzcDthdmFpbGFibGUmbmJzcDthdCZuYnNwO3Rv b2xzLmlldGYub3JnLjxiciA+PGJyID4KVGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0PGJy ID48YnIgPjxiciA+PGJyID4KU3ViamVjdO+8mk5ldyZuYnNwO1ZlcnNpb24mbmJzcDtOb3RpZmlj YXRpb24mbmJzcDtmb3ImbmJzcDtkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVx dWlyZW1lbnQtMDEudHh0PGJyID48YnIgPjxiciA+CkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5i c3A7b2YmbmJzcDtJLUQsJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJl cXVpcmVtZW50LTAxLnR4dDxiciA+CmhhcyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJz cDtzdWJtaXR0ZWQmbmJzcDtieSZuYnNwO1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJz cDtwb3N0ZWQmbmJzcDt0byZuYnNwO3RoZTxiciA+CklFVEYmbmJzcDtyZXBvc2l0b3J5LjxiciA+ PGJyID4KTmFtZTogZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50 PGJyID4KUmV2aXNpb246IDAxPGJyID4KVGl0bGU6IENvbXByZXNzZWQmbmJzcDtTUnY2Jm5ic3A7 U0lEJm5ic3A7TGlzdCZuYnNwO1JlcXVpcmVtZW50czxiciA+CkRvY3VtZW50Jm5ic3A7ZGF0ZTog MjAyMC0xMS0xMzxiciA+Ckdyb3VwOiBJbmRpdmlkdWFsJm5ic3A7U3VibWlzc2lvbjxiciA+ClBh Z2VzOiAxMzxiciA+ClVSTDombmJzcDs8YSAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJj aGl2ZS9pZC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEu dHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PC9hPjxiciA+ ClN0YXR1czombmJzcDs8YSAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC88L2E+PGJyID4KSHRtbGl6ZWQ6Jm5ic3A7PGEg IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21w ZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29t cHJlc3Npb24tcmVxdWlyZW1lbnQ8L2E+PGJyID4KSHRtbGl6ZWQ6Jm5ic3A7PGEgIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Np b24tcmVxdWlyZW1lbnQtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxPC9h PjxiciA+CkRpZmY6Jm5ic3A7PGEgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxPC9hPjxiciA+PGJyID4KQWJz dHJhY3Q6PGJyID4KJm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7c3BlY2lmaWVzJm5ic3A7 cmVxdWlyZW1lbnRzJm5ic3A7Zm9yJm5ic3A7c29sdXRpb25zJm5ic3A7dG8mbmJzcDtjb21wcmVz cyZuYnNwO1NSdjY8YnIgPgombmJzcDtTSUQmbmJzcDtsaXN0cy48YnIgPjxiciA+CiZuYnNwOzxi ciA+PGJyID48YnIgPgpQbGVhc2UmbmJzcDtub3RlJm5ic3A7dGhhdCZuYnNwO2l0Jm5ic3A7bWF5 Jm5ic3A7dGFrZSZuYnNwO2EmbmJzcDtjb3VwbGUmbmJzcDtvZiZuYnNwO21pbnV0ZXMmbmJzcDtm cm9tJm5ic3A7dGhlJm5ic3A7dGltZSZuYnNwO29mJm5ic3A7c3VibWlzc2lvbjxiciA+CnVudGls Jm5ic3A7dGhlJm5ic3A7aHRtbGl6ZWQmbmJzcDt2ZXJzaW9uJm5ic3A7YW5kJm5ic3A7ZGlmZiZu YnNwO2FyZSZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0Jm5ic3A7dG9vbHMuaWV0Zi5vcmcuPGJyID48 YnIgPgpUaGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnIgPjxiciA+PGJyID48YnIgPjwv cD48L2Rpdj48L2Rpdj4KCuWmguaenOaCqOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mA mui/h+eUteWtkOmCruS7tueri+WNs+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsCZu YnNwO2hxcy1zcG1jQGNoaW5hdW5pY29tLmNu77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC 5oiR5Lus5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit 5Yig6Zmk44CCIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byZuYnNwO2hx cy1zcG1jQGNoaW5hdW5pY29tLmNuJm5ic3A7LHlvdSBjYW4gdW5zdWJzY3JpYmUgZnJvbSB0aGlz IG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkKIHJlbW92ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20g c2VuZCBjYXRhbG9ndWUgb2Ygb3VyLgoKCjwvYmxvY2txdW90ZT48ZGl2ID48YnIgPjwvZGl2Pjxz dHlsZSA+Ym9keXtsaW5lLWhlaWdodDoxLjU7fWJsb2NrcXVvdGV7bWFyZ2luLXRvcDouMHB4O21h cmdpbi1ib3R0b206LjBweDttYXJnaW4tbGVmdDouNWVtO31we21hcmdpbi10b3A6LjBweDttYXJn aW4tYm90dG9tOi4wcHg7fWRpdi5Gb3hEaXYyMDIwMTExOTE2NDgyNTQ1NTM4MXt9Ym9keXtmb250 LXNpemU6MTQuMHB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTtjb2xvcjojMDAwMDAwO2xpbmUt aGVpZ2h0OjEuNTt9PC9zdHlsZT48ZGl2ID48YnIgPjwvZGl2PjwvZGl2Pg== ------=ALIBOUNDARY_57687_7fa9c1eab700_5fb64706_15566d1-- From nobody Thu Nov 19 05:21:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE9D3A0E84; Thu, 19 Nov 2020 05:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HkUbXFUYKoA8; Thu, 19 Nov 2020 05:21:19 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 D44253A0E83; Thu, 19 Nov 2020 05:21:18 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id 23so6392577wrc.8; Thu, 19 Nov 2020 05:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AFkFzMwOV6zyD1wXWIQnQrGScrAlyJdrQ5n2HLgVTy8=; b=X36H8tYSMZMeO02QHIXrz1EesJwnCn3MUotbQEYdYgClSZwo+WqP6TitV7LNOSzl+o eLODcL0p9GocosoovQVKgaZipJN+J69W2ReyzplO+UayI+kmaP9mif5yjetMBNdCXWGy DIHX/niFSnWDHhGLhjlv2G8Uvmc7ptY6Ejknj/pviWujiUakfZsAt8oRFX6TqjGID1q1 XqP1c7XY3EdIOKtUIOM3HrxKP/Kil70lcb+k0CeNG1NqJjIJX9JcVxMFAoWkpo+0EcL3 IWPR7pftR2PHV4pH13XtUi/7SLMgZJ0YNa0l6py7CsCh1/Rhmvuxk3oalFtdN68Gwu6D rLjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AFkFzMwOV6zyD1wXWIQnQrGScrAlyJdrQ5n2HLgVTy8=; b=XepSIwE2133w1BR6Bk5ARUiXeqykRm4K5Ogwi4rc9eS+utdNXpK7DHlZRMLEu4NXpH P51G89TNV2H2yYEx3ruDCbGcZVNPkMrV5Z9XAaDE+cc0TGMPmlA9kEaCQG3af8+lmi24 bgLqbjvayCfG1pzRn/h2OTSCctzxEOBUKkPn3z0sJoCjBldgOkNbWnAAqzXJoLcCi1xl CsMoN5CJM/W/VbwZLkZtpl+v8VNBEIoD+rxLAq/Q7/rLWHLlokXKeKXfsJ7L8RtS/TDC I02+vefiknj7pssY4ptxrtUVhPiNY+wrOe35BGrpicvfI5GNlQajqUEMoLaR+wsFD4fO FLEA== X-Gm-Message-State: AOAM531bN7yhrbMa1vj48FQ6zhQij4FqWYkixHBxUs1nQXFEkNyzP2uC yyo+D15eTZH7/IzHG2Jynz6euu5brSa1YQ== X-Google-Smtp-Source: ABdhPJxFBsGxBuVAZYd5tVdaar5iLLAj99T+oKL64agaWEdhZamIpi//O5qfIknDMM44iBQrTYmSLw== X-Received: by 2002:a5d:69d1:: with SMTP id s17mr10471850wrw.104.1605792076935; Thu, 19 Nov 2020 05:21:16 -0800 (PST) Received: from [192.168.1.50] ([197.60.206.65]) by smtp.gmail.com with ESMTPSA id l16sm37738407wrx.5.2020.11.19.05.21.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 05:21:16 -0800 (PST) To: =?UTF-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?UTF-8?B?5pys6YOoKQ==?= , =?UTF-8?B?56iL5Lyf5by6?= , "spring@ietf.org" Cc: srcomp , "spring-chairs@ietf.org" References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> <0df1b0805de34dbc8742313200c694de@M10-HQ-ML02.hq.cnc.intra> From: Ahmed Bashand Message-ID: Date: Thu, 19 Nov 2020 05:21:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <0df1b0805de34dbc8742313200c694de@M10-HQ-ML02.hq.cnc.intra> Content-Type: multipart/alternative; boundary="------------122B5FF495FD3471BB79580F" Content-Language: en-US Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:21:23 -0000 This is a multi-part message in MIME format. --------------122B5FF495FD3471BB79580F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I also agree that the requirements in Appendix A should be part of the draft. Having of existing standard as a basis greatly simplifies the development and deployment of any compression scheme Thanks Ahmed On 11/19/20 12:58 AM, Ran Pang(è”通集团中国è”通研究院-本部) wrote: > Hi Weiqiang and WG, > I read the draft and agree with the requirements specified in it.I > think the requirements in Appendix A should be part of the draft in > the next version. >     China Unicom is working on a network evolution plan for SRv6 now, >  and we have done some field trials based on SRv6. In order to > maintain the continuity of  the functionality, we suggest the solution > based on the SRv6 standards. > > Best regards, > Pang Ran > > *From:* 程伟强 > *Date:* 2020-11-15 23:27 > *To:* spring > *CC:* srcomp ; spring-chairs@ietf.o > > *Subject:* [spring] Fw:New Version Notification for > draft-srcompdt-spring-compression-requirement-01.txt > > Hi Group, > > SR compression design team have submitted a new version of > compression requirement draft. > > Main changes as follows: > > - added 3 items about scalibility with agreement within the design > team > > - added an appendix including 3 items without without unanimous > consensus within the design team > > - some minor text issue fixed > > Please review it and let us know your comments. > > > BTW: We will have 1-hour session for the design team topic on > Friday and welcome to join us. > > > B.R. > > Weiqiang on behalf of design team > > > ----邮件原文---- > å‘件人：internet-drafts  > 收件人：Weiqiang Cheng ,Sander Steffann ,SJM Steffann  > 抄　é€: (æ— ) > å‘é€æ—¶é—´ï¼š2020-11-15 22:58:57 > 主题：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt > Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement > Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01 > > Abstract: >  This document specifies requirements for solutions to compress SRv6 >  SID lists. > > > > > 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 > > > > Subject：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt > Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement > Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01 > > Abstract: >  This document specifies requirements for solutions to compress SRv6 >  SID lists. > > > > > 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 > > > > 如果您错误接收了该邮件，请通过电å­é‚®ä»¶ç«‹å³é€šçŸ¥æˆ‘们。请回å¤é‚®ä»¶åˆ°Â hqs-spmc@chinaunicom.cn，å³å¯ä»¥é€€è®¢æ­¤é‚®ä»¶ã€‚我们将立å³å°†æ‚¨çš„ä¿¡æ¯ä»Žæˆ‘们的å‘é€ç›®å½•ä¸­åˆ é™¤ã€‚ > If you have received this email in error please notify us immediately > by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can > unsubscribe from this mail. We will immediately remove your > information from send catalogue of our. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------122B5FF495FD3471BB79580F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    I also agree that the requirements in Appendix A should be part of the draft. Having of existing standard as a basis greatly simplifies the development and deployment of any compression scheme


    Thanks


    Ahmed



    On 11/19/20 12:58 AM, Ran Pang(è”通集团中国è”通研究院-本部) wrote:
    Hi Weiqiang and WG, 
        I read the draft and agree with the requirements specified in it.I think the requirements in Appendix A should be part of the draft in the next version.
        China Unicom is working on a network evolution plan for SRv6 now,  and we have done some field trials based on SRv6. In order to maintain the continuity of  the functionality, we suggest the solution based on the SRv6 standards.

    Best regards,
    Pang Ran
     
    Date: 2020-11-15 23:27
    To: spring
    Subject: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

    Hi Group,

    SR compression design team have submitted a new version of compression requirement draft.

    Main changes as follows: 

    - added 3 items about scalibility with agreement within the design team 

    - added an appendix including 3 items without without unanimous consensus within the design team

    - some minor text issue fixed

    Please review it and let us know your comments.


    BTW: We will have 1-hour session for the design team topic on Friday and welcome to join us.


    B.R.

    Weiqiang on behalf of design team


     

    ----邮件原文----
    å‘件人：internet-drafts <internet-drafts@ietf.org>
    收件人：Weiqiang Cheng <chengweiqiang@chinamobile.com>,Sander Steffann <sander@steffann.nl>,SJM Steffann <sander@steffann.nl>
    抄　é€: (æ— )
    å‘é€æ—¶é—´ï¼š2020-11-15 22:58:57
    主题：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt
    has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed SRv6 SID List Requirements
    Document date: 2020-11-13
    Group: Individual Submission
    Pages: 13
    URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
    Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
    Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
    Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
    Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01

    Abstract:
     This document specifies requirements for solutions to compress SRv6
     SID lists.

     


    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



    Subject：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt
    has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed SRv6 SID List Requirements
    Document date: 2020-11-13
    Group: Individual Submission
    Pages: 13
    URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
    Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
    Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
    Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
    Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01

    Abstract:
     This document specifies requirements for solutions to compress SRv6
     SID lists.

     


    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



    如果您错误接收了该邮件，请通过电å­é‚®ä»¶ç«‹å³é€šçŸ¥æˆ‘们。请回å¤é‚®ä»¶åˆ°Â hqs-spmc@chinaunicom.cn，å³å¯ä»¥é€€è®¢æ­¤é‚®ä»¶ã€‚我们将立å³å°†æ‚¨çš„ä¿¡æ¯ä»Žæˆ‘们的å‘é€ç›®å½•ä¸­åˆ é™¤ã€‚ If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our. 
    _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
    --------------122B5FF495FD3471BB79580F-- From nobody Thu Nov 19 07:16:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945B03A0A26; Thu, 19 Nov 2020 07:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=MBmJpvkk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kmEPn5ip Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TPe4BD8434m; Thu, 19 Nov 2020 07:16:08 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4429F3A09CC; Thu, 19 Nov 2020 07:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87550; q=dns/txt; s=iport; t=1605798966; x=1607008566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j8bQafjxvdYlFUTeyXmxR96+i4P5WYOogPn8Tv9N1IU=; b=MBmJpvkkT98/1JKoyuu+bXwVftaO+9QkdKbkPaMzJDZrE1Md7L6VALtB G54wmPi6D0Zbm7VOsg4sVEXEBVKcyIFB44ZdvRquur3NJFfPkN0oSdIwU QER2taFYCCmvhqu3KueA7Gxxl/GmuFVeUaXOTrrbn10K94wJfB6GOTmVQ g=; X-IPAS-Result: =?us-ascii?q?A0DmAQBbi7Zf/4wNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4EjLyMuB3RZLy4Kh3wDjVyKFY5ugUKBEQNPBQsBAQENAQEYAQwIA?= =?us-ascii?q?gQBAYRKAoIpAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBBAEBE?= =?us-ascii?q?AgBAiMBASUHBAcBDwIBCBABAwEBASEBBgchBgsUCQgCBAENBQgMBweDBYF+V?= =?us-ascii?q?wMuAQ6kIwKBPIhodIE0gwQBAQWBMwEDAg5BgxENC4IQAwaBOIJzgmZOgUiBP?= =?us-ascii?q?oQTG4FBP4EQAUOCTz6CG0IBAQIBAYEhBQESASMFGQYHCQKDEoIskB8CEgYMC?= =?us-ascii?q?SmCOIdbgyqYdwkvVQqCbYkShmSGEYU1gxqKF4VMjn+TVIsBgm6ONIFOgmgCB?= =?us-ascii?q?AIEBQIOAQEFgWsjZ3BwFTuCNQEBMlAXAg2OHwwXFIM6hRSFQwF0AjUCBgoBA?= =?us-ascii?q?QMJfIw7ATFfAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AbAdaSB8a97lXjv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,490,1596499200"; d="scan'208,217";a="586894189" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2020 15:15:33 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AJFFTbe007790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2020 15:15:31 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 09:15:30 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 10:15:29 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 19 Nov 2020 10:15:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RX4CDgg/Z3CLs9dBeuID/2dXiXMqVsfxQ4C2bS9k7hi94uCPx5YtZaNjWGqglImu1xHB9RV4bvpc+Wo8Thp0x2u8S1SO7OYzoi7SQ8pDsDJ0yh29tZdEdlY5jdclpw+yWzXpZcChhcHR7eApOySSXopdfAK1X9ft0zaJRwEsLswIWFUucFcA4bVFlB7NfkqtRX3limYJ0p7vn3UjxSIC4L5UicQju4CU6Lcy9zp9SDt9X2exmt11xuR2Gx8v5voEQlizkyplpxiS3V+YgC4YrjNtp9BnrRSF+JdZcxVNoghc3ksYuBiXoiLi57rn6CjgbMIV3zjovig726YKA2hqbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xwADS3b0YQzFfh90jE6YIf5JKg7YtV5OplyUqV/Ab0E=; b=SthC3Qxr6S/es4bAAydl40G52u5cMsABqXNQW+gdrAUc0C0UkKBaojUhDI2kD/oDzUKOS5hkv0ukcGlHxxxUKqDF7IJ+Yh+ORKhRiOQtNhpQiR1g2sIKAWVc80IMl4eAaZ3TUmiKB+Ngc+bigTi1f/TnEvw9ZhXGsnAxeBLs6Hk9dYEuG1QdFgoanKZJj4FqhUWFOUJIp1D8nZZf68kqdvwO+6ku42PeRoOUGn0ULU/pLnBxIdFtMafs4R3OARhJM0nQlAPY1bCQtCBi7YIe3jjv+T8x3DbxDeR0qhHInIKytXlkBXerDMZeFIE8Wd7RcChS3uIrPI+Jd96D/1OFCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xwADS3b0YQzFfh90jE6YIf5JKg7YtV5OplyUqV/Ab0E=; b=kmEPn5ipvat6upFmF/4FzuaNyTcw/FSyKxnL8PX3V+Oo43ROiWTkQEmAVdb5MOiEldCJjtcr+OS9Ni4bFlA443OU3POmeaUYTmbSPkmmg0cPG41V9oF/7TOPX3xE0s2Ab9B2jxIkRz+5GK4bnKLM+Npbc0D+fZozXjeauckgMJY= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2683.namprd11.prod.outlook.com (2603:10b6:5:c6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Thu, 19 Nov 2020 15:15:27 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Thu, 19 Nov 2020 15:15:27 +0000 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen , Tianran Zhou , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KnAEieAgAGGXIqABKdzAIAEHsI6gAAB1ACAAqNDgIAAE4+WgAH1xICAACO6gIAAfByt Date: Thu, 19 Nov 2020 15:15:26 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5d6c633-297a-4cb5-e7b8-08d88c9df204 x-ms-traffictypediagnostic: DM6PR11MB2683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XRGPAiQZDcgVbD0hkOFXT2mWrtPbnBuNSGty8FmmU1FNlwCMT80trevwm0mdEGdlNyN1Sl/5OLHaP32f1HLwhuI5UzurLNfUqYmTBASf2yZQzYlG66LK1mCqL8uis5Eka6yPfysYTTzWIOh53nHL7Dp5Zb1pTqqzdo/uHk3bJduv1zi2Ts/ZadOQK5+ZWWuGb0yarC0AWBJHN+Jl9QjpC1BHJxofr3UvvZ+JyJx0CkupZ2Hqd1WcgTAEgNXSwKbBHP7kxByP4XXgaHsY8H7Q3TLfsLbtaF8ISSP1gJ5l8LSUP2S970EpN6npjLwgxIvsaIDvgFe1fw6uL2n5jDDEqmoiX8JYdcuSvE8xJ4lH8iw0tMDEjET29GGqhOQC3f0o2jEBO+PQ7RNSuQF09qe/nA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(396003)(366004)(39860400002)(52536014)(966005)(110136005)(55016002)(478600001)(2906002)(30864003)(86362001)(9686003)(5660300002)(4326008)(71200400001)(8936002)(8676002)(83380400001)(6506007)(53546011)(54906003)(33656002)(7696005)(66946007)(316002)(26005)(186003)(166002)(76116006)(66556008)(64756008)(19627235002)(66476007)(91956017)(66446008)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LtMcWKm3u7z76YTEBxmp+TqxPOGYiZvlXWFuz9mlWhxsDtWNpb7BlzMOuiuQKSHvge44UiIxqlc6BAA5iyGWz53OCoAtQYjCUSsE84mMBFmZV9OUmo5gcm5g9/SpX3bEo+SC3aKS1mfQruiK3vm8fv34D5e+6grAHTDPF2ZgbH+ksPoL2FfHN1AcLoMlfyLr9EN5LU76nZLax6xKfthL9PCkORI9Lpz2eqGYQRWO+JwrATXbisHAUPu9rasi69v8Isvyf57ccPypad/WJ6nfiTyhWEppknxCDGaV6sGILlfmYPl0DLPTA614LESYL7O4WlJNW9+8wRiPS+PUbAmR34remCkFdvNZr/ubXI49Qi+iWIXkKUSPT5MNnMuih/MQXF7iDxdgrtoDCE1T8KnRkX/lKlkjB2TaBxSgYUogUB/T2/OHbYOSt+m7a8dzjxOPAHm+aJ3reyUHRCugpD9dllFgg6ePY41H75o4wedHZSctUSpaUkxlzRoMWpyvPvmSqhwZnRWX5q6MiSkbxqF/nUI2JV3GcdHEq6FTCQexDSJOsNtKrsvLr1U1PrjXt8nnghGfu4kQ6Dn/nKyRLbI8P90+jR0a4heD3GIzZe6cOk2YQfJR0hWQLRNRXhk+6UiJFPd60RnHqWQJd8w1CSZnWBuCLJ/szt0rrgfw2E/JeCYgpg1Gs48k2gRo9ig9+unvoy9F9vIFbBmsXQbXy67tQdMj7mZU9wAI5Ou3v7bqyClhETl0MwA/HrzlkKsmY/vLUeNVX/9n7HnvfH7qIcSJMp2J/WoaKoiGlLf0Pg2uprNYPWiW6cPQsQVIGT+V8TLOTgVhibLsItRMrqwtjbIbHRmAsg3g+5bmV8vfZBMeJI3gEbtweHbgDaq7etoYL9LVYJCauvL88p871MOSZQfWZw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5d6c633-297a-4cb5-e7b8-08d88c9df204 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 15:15:26.9814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qyXoWsHcgO33u2MHyjGZs7zCNN5AVTyJpB/mXDzdJ3UTR2LSedNxOVNUANZ09Pp0qZz5l5uxReRk6mIImZS5EQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2683 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:16:13 -0000 --_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Mach and Tianran for your review comments. Please see inline reply with =85 From: Mach Chen Date: Thursday, November 19, 2020 at 2:41 AM To: Tianran Zhou , Rakesh Gandhi (rgandhi) , Greg Mirsky Cc: spring , IPPM Chairs , spring-ch= airs@ietf.org , Tommy Pauly , IET= F IPPM WG (ippm@ietf.org) Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]=85 From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) ; Greg Mi= rsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM= WG (ippm@ietf.org) Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If you prefer= , we can define them here. For Zero checksum field, we can add a reference = for the RFC 6936 in Security section and also add some text for it. Will be= happy to work with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussions= are mainly about draft*-stamp-srpm. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. To further add to this, as TWAMP Light does not have a TLV, we need = to define a stand-alone message for direct-mode LM. STAMP is just the same = message but fixed length, so this way both can interoperate and also we can= leverage the message for both of these protocols. For STAMP direct-mode LM TLV approach, some technical details are in the dr= aft as well: The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization for one-way delay). Furthermore, for hardware-based cou= nter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. How the proposed method of direct packet loss is related to TWAMP light and= STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it=92s format, the messages and processing of them are the same for delay = and direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in the = new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. To further add to this, the IPPM draft simply defines protocol extens= ions. The use-cases are there in the corresponding spring drafts. For examp= le, for links, no return Path TLV is used, etc. In other words, the use-cas= es are different for the two, and there is no TLV in TWAMP anyways. Thanks, Rakesh Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: =95 Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. =95 Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. =95 Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we=92ve had updates on the work in the SPRING WG= that was using STAMP and TWAMP. Since those documents ended up making exte= nsions to the base protocols, the chairs of SPRING and IPPM decided that it= would be best to split the documents and track the IPPM extension work in = the IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thank you Mach and Tia= nran for your review comments.

    Please see inline repl= y with <RG2>=85

     

    From: Mach Chen <mach.= chen@huawei.com>
    Date: Thursday, November 19, 2020 at 2:41 AM
    To: Tianran Zhou <zhoutianran@huawei.com>, Rakesh Gandhi (rgan= dhi) <rgandhi@cisco.com>, Greg Mirsky <gregimirsky@gmail.com> Cc: spring <spring@ietf.org>, IPPM Chairs <ippm-chairs@ietf= .org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, Tommy Paul= y <tpauly@apple.com>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org&= gt;
    Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Tianran, Rakesh and Greg,

     

    Please see some responses inline with [Mach]=85=

     

    From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org= >; Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly=3D40apple.com@dmar= c.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Hi Rake= sh and Greg,

     <= /span>

    I may n= ot very clear about the context. Please allow me to jump in.

    It seem= s both of you make some valid point.

    Please = see in line with <ZTR>.

     <= /span>

    Cheers,=

    Tianran=

     <= /span>

    From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimi= rsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     

    Hi Greg,

     

    Thank you for your rev= iew and discussions on the drafts. This will help improve the work on this = important work.

    Please see replies inl= ine with <RG>..

     

     

    From: Greg Mirsky <gregimirsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,

    I've read the responses to my detailed comments. I d= on't think that only adding references will solve the problems with the doc= uments. If authors are interested in addressing my comments, we can start w= orking on solving them one by one.

     

    <RG> As mentione= d in previous replies, we can add references for the well-known terms =93Li= nks=94, =93Congruent Paths=94, =93SR Path=94. If you prefer, we can define = them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will b= e happy to work with you to address these.

     

    But I am very much concerned with the technical valu= e of these drafts. And here's why I feel that the proposed documents don't = provide a sound technical solution to the task of direct loss measurement.&= nbsp;Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp-srpm propose a new p= rotocol to support direct packet loss measurements. Note, that RFC 6374 inc= ludes a method for direct loss measurement in MPLS networks that is applica= ble to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, t= he Direct Measurement TLV, that supports the direct packet loss measurement= . STAMP and all its extensions are applicable in IPv6 networks and, thus, c= an be used in the SRv6 domain.

     

    <RG> As mentione= d in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Se= ction 8.1) define stand-alone messages for collecting TX and RX counters fo= r direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that take advantage = of the widely deployed TWAMP protocol and as well this same protocol can be= deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

     

    <ZTR> I think RFC6374 for MPLS and Y.1731 make= some noise here. The point is if we need a new direct packet loss measurem= ent for STAMP, when STAMP already defined a Direct Measurement TLV (http= s://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

     = ;

    [Mach= ] Given that TWAMP does not support TLV, I assume that the discussions are = mainly about draft*-stamp-srpm.

     = ;

    [Mach= ] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-sr= pm assumes that marking-based solution (which can address the packet out-or= dering issue) is used, hence the block number is introduced. The block number is used to correlate the counters f= rom the sender and reflector. The current direct loss measurement TLV may j= ust apply to the scenario without packet out-ordering.

     = ;

    <RG2> To further= add to this,  as TWAMP Light does not have a TLV, we need to define a stand-alone message f= or direct-mode LM. STAMP is just the same message but fixed length, so this= way both can interoperate and also we can leverage the message for both of= these protocols.

     

    For STAMP direct-mode LM TLV approach, some t= echnical details are in the draft as well:

     

       The STAMP message with a TLV for "direct measurem= ent" can be used for

       combined Delay + Loss measurement [I-D.ietf-ippm-stamp-op= tion-tlv].

       However, in order to use only for loss measurement pur= pose, it

       requires the node to support the delay measurement mes= sages and

       support timestamp for these messages (which may also r= equire clock

       synchronization for one-way delay).  Furthermore,= for hardware-based counter collection=

       for direct-mode loss measurement, the optional TLV bas= ed processing

       adds unnecessary overhead (as counters are not at well= -known

       locations).<= /o:p>

     

     

     

    [Mach= ] In addition, whether to keep it as current design or to define a new TLV = for direct loss measurement can be debatable.  

     

     

     = ;

    How the proposed method of direct packet loss is rel= ated to TWAMP light and STAMP?

    There's no apparent technical relationship between *= -twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do no= t extend or re-use the basic mechanisms defined for  TWAMP-Test and/or= STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new forma= ts of test packets that are decisively different from the formats defined i= n respective specifications. As a result, the new protocols are required to= use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is= another clear indication that the proposed mechanism represents a new prot= ocol, neither extends TWAMP Light and/or STAMP nor updates their specificat= ions.

     

    <RG> As mentione= d in previous replies, other than timestamp vs. counter and it=92s format, = the messages and processing of them are the same for delay and direct-mode = loss measurement.

    • Is there any advantage in introducing a dedicated packet format for the dir= ect packet loss in STAMP comparing to using the Direct Measurement TLV exte= nsion?

    Though it appears the using a dedicated packet forma= t instead of TLV is more efficient, but the dedicated for the direct loss m= easurement format is likely to precede one or even two TLVs, Node Address T= LV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more= efficient and reduce the processing delay, than if using the Direct Measur= ement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

     

    <RG> As mentione= d in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

     

     

    • Using the Sender Control Code may require the use of= the additional TLV that carries the return path information, Path TLV. If = the ability to control the return path is required that can be achieved by = augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each te= st packet. Hence, there seem no technical requirements to introduce the Sen= der Control Code field in the Base STAMP format defined in RFC 8762.

       

      <RG> Per session= basis between different sender nodes and this reflector node, some senders= will request the replies in-band (e.g. for two-way mode). Sessions are pro= visioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectiona= l SR path). This is also similar to as described Section 3.1 in RFC 6374, t= op of page 22. There is no need to create a such state for each session on = the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation = by eliminating the Control protocol signaling.

       

      <ZTR> I find some value to include the path TL= V in wire. As Rakesh mentioned, this can reduce the reflector configuration= . But I am not convinced to introduce the sender control code field. It see= ms to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

       = ;

      [Mach= ] Regarding how to specify the return path, the draft defines two ways to a= chieve that, one is to use control code to direct whether the reflected Tes= t should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and S= TAMP. At the same time, in the case of STAMP, it also defines the return pa= th TLV to explicitly specify the return path, which bring more options to s= pecify the return path. Therefore, I see benefit of the two ways.

       

      <RG2> To further= add to this, the IPPM draft simply defines protocol extensions. The use-ca= ses are there in the corresponding spring drafts. For example, for links, no return Path TLV is used, etc. In other = words, the use-cases are different for the two, and there is no TLV in TWAM= P anyways.

       

      Thanks,

      Rakesh

       

       = ;

       = ;

      Best = regards,

      Mach<= /span>

       = ;

      What is the relationship between the *-srpm drafts a= nd BFD?

      Some text in the *-srpm drafts suggest that the prop= osed method can be used to monitor for the loss of a path continuity. = That may be viewed as an alternative to the BFD protocol method for the det= ection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems= logical that the BFD WG and BFD WG's Chairs be made aware of the proposals= . I didn't take the liberty of adding BFD WG or its Chairs. I believe that = decision to be made by the Chairs of IPPM And SPRING WGs.

       

      <RG> As mentione= d in previous replies, STAMP/TWAMP test messages are also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

       

      Thanks,

      Rakesh

       

      Regards,

       

       

      On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimirsky@gmail.c= om> wrote:

      Hi Rakesh,

      thank you for your prompt response, much apprec= iated. I'll carefully read your responses. Looking forward to the continued= discussion.

       

      Regards,

      Greg

       

      On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

      Hi Greg,

       

      Thank you for your review comments. As mentioned in the IPPM sessi= on today, the email response was sent as attachments, see archive blow:

      https://mailarchive.ietf.org/arch/msg/i= ppm/J503n-B2yOxF0urcHtGQKnqCRDE/

       

      I am attaching them in word documents for the convenience. We can = address your comments below in the next revision of the document.

       

      Thanks,

      Rakesh

       

       

      From: Greg Mirsky <gregimirsky@gmail.c= om>
      Date: Friday, November 13, 2020 at 10:09 AM
      To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
      Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
      Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

      Hi Rakesh,

      thank you for your response to my review. Please find my follow-up= notes in-lined below under the GIM>> tag.

      I hope you've found more detailed comments in the attachments (re-= attached for your convenience). I'm looking forward to reading your respons= es to the detailed comments of all four drafts.

       

      Regards,

      Greg

       

      On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

      Thank you Greg for taking time for t= horoughly reviewing the documents and providing the comments.  Attache= d please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, t= agged with <RG00>.

       

       

      From: ippm <ippm-bounces@ietf.org&= gt;
      Date: Monday, November 9, 2020 at 11:48 AM
      To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
      Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
      Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

      Dear WG Chairs, Authors, and IPPM WG community,

      I've reviewed these drafts and have some comments to share. Below,= please find my thoughts on whether these drafts can be adopted. More speci= fic comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft tar= getted to the SPRING WG) are in the attached documents.

       

      Usually, the bar for the adoption of a document can be evaluat= ed by answers to these three questions:

      =B7  Is the document(s) reasonably well-written

      I've got surprised that the drafts don't use the terminology f= rom RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms= , e.g., Links, "congruent paths", are used in the documents witho= ut proper definitions. Other than that both drafts are readable and reasona= bly well-written.

       

      <RG00> We can change Sender to= Session-Sender and Reflector to Session-Reflector if it helps. 

      GIM>> I believe that the consistency in terminology between = the core RFC and what is intended as its extension is not only helpful to a= reader but, to the best of my understanding, is required for IETF specifications.

      <RG00> There are many existing= RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congrue= nt Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that= , we can add a reference for them if it helps.

      GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

      Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                        &nb= sp;    C---------D

                        &nb= sp;  /                 \<= o:p>

                  A----B    &nbs= p;              E-----F

                        &nb= sp;  \                  /=

                        &nb= sp;  G------------H

      Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. From the definition of "congruent" as "two figure= s or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the= other", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet = of an active OAM intended to monitor a flow over the SR tunnel is out-of-ba= nd and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct l= oss measurement can be performed, as information collected from node F. So,= this example, in my opinion, illustrates two of my concerns:

      • using a congruent path for an active OAM protocol may produce information t= hat does not reflect the condition experienced by the monitored flow. It se= ems that the terminology should reflect the fundamental requirement for usi= ng active OAM to maintain the test packets in-band with the monitored flow.
      • there are no technical requirements to justify using in-band active OAM pro= tocol for direct packet loss measurement. As demonstrated in this example, = direct packet loss can be performed using an out-of-band mechanism, e.g., S= NMP queries, Netconf notifications based on YANG data model.

       

      =B7  Does the document solve a real problem?

      No, it appears that  both TWAMP and STAMP drafts  d= efine a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

       

      <RG00> There is a requirement = to measure performance delay as well as synthetic and direct-mode packet lo= ss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here.

      GIM>> I agree with the requirements you've listed (thou= gh the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason to us= e OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. 

       

      =B7  Is the proposed solution technically viable?

      There are too many unaddressed aspects, particularly the risk = introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

       

      <RG00> About your comment on z= ero checksum, this is described in Security section in RFC 6936. We will ad= d reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP or TWAMP Light. Other than this, I did not= find any other security related issue in your review.

      GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

       

      Thanks,

      Rakesh

       

       

      Regards,

      Greg

       

       

       

       

      On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.= ietf.org> wrote:

      Hello IPPM,

       

      For the past few meetings, we=92ve had updates on the work in the = SPRING WG that was using STAMP and TWAMP. Since those documents ended up ma= king extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the d= ocuments and track the IPPM extension work in the IPPM WG.

       

      As such, we are starting a Working Group call for adoption for&nbs= p;draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.=

       

      Please provide your feedback on these documents, and state whether= or not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.<= o:p>

       

      Best,

      Tommy & Ian

      _______________________________________________
      ippm mailing list
      ippm@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_-- From nobody Thu Nov 19 07:47:08 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D03A0B8F for ; Thu, 19 Nov 2020 07:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lapishills-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 6gBFZSluUl2O for ; Thu, 19 Nov 2020 07:47:04 -0800 (PST) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 817753A0B98 for ; Thu, 19 Nov 2020 07:47:03 -0800 (PST) Received: by mail-ed1-f52.google.com with SMTP id v22so6304065edt.9 for ; Thu, 19 Nov 2020 07:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lapishills-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZDE0suv4vXls7/0WKpTlV0yvuyWlbgUBmc4zKTD/2H0=; b=U+emqKOSiCxJ2ZiUtIyJBNadEqNdV2CjjvecbkGjYJ0kKkfbXdJNLZcy9Uyg1Ye2SM CgLbxF27DDGvOy5jaM0GJiAynDtMydo+luxe+vjTR9WyFjvh/ooBdS+y2BnUuD1MFBrE JR9EzQaoVhwMsYALmMsNauYeehpCA9VSJ8s9md/0CBjQd1ry0unW0RuZPE90Nb1iOpXo m9phrsT3pUDnfD7PsnxdpBdQ6nBiTPw+SLBrwFm11tu/h4S3EMlf35Oc/M/HxZwpx1hE GIhgCg1/pTHU72lRPQGhMGcP2ghR56gEcH34HXK65t9kWtlWgFpPw5/8BtAcN8yC1wWH g67g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZDE0suv4vXls7/0WKpTlV0yvuyWlbgUBmc4zKTD/2H0=; b=Bf6Y459vLZNefgpt6MdtsqLGSf6wELYONt4gLqY+bDS/PIipqdYzjOQsaADsrr4M6B iEBaWvy0Q7UL7JJsoa9hcC3GJo1aOtz5OA7kfXoP6tBuwQxA+XbNvCbIShujkrAz6/uq n24m6Rl9OyI/6jDkbgCTnCqlKAb/JSl8iM2YWGowfwJug7qAnoVor6L6VHCNmkDpoN6U CSbPvW1YD0CU3RfVPpDz6JZbkuVIENGLh9kgsPV8kwtlRzE5rMu2kWSHMbOgV7O2XjRm mX8ErxDiL58kqEm0DU/94loW71GN/FXy/YeywgxTnepEfE/bxoPvAgtrGbGv6KT6yHfr dsrw== X-Gm-Message-State: AOAM531A9Zv54frAKjML8tU8d1POdBs+IbwRy+pk9GS9DB628NjnUluY fNdGVNK0uqglGDQAFZGM6JkS2lEoSKs5JM4YyFkSRMOI0oPQepnlLEY= X-Google-Smtp-Source: ABdhPJzXK5V8aR+GnYKZVoViNCVcK5wH2jMoq0G1cUt46ddDhCVf0R1GE4rXPhDGrF+hFg1POM1Aoiq1KkosgdlsdC4= X-Received: by 2002:aa7:c44a:: with SMTP id n10mr32464367edr.145.1605800821157; Thu, 19 Nov 2020 07:47:01 -0800 (PST) MIME-Version: 1.0 References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> <0df1b0805de34dbc8742313200c694de@M10-HQ-ML02.hq.cnc.intra> In-Reply-To: From: Dirk Steinberg Date: Thu, 19 Nov 2020 17:46:50 +0200 Message-ID: To: "spring@ietf.org" , srcomp , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086ca1d05b477a3cc" Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:47:07 -0000 --00000000000086ca1d05b477a3cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello SPRING WG, I have read the SRComp design team requirements draft and would like to comment. I truly believe that a SID compression scheme MUST integrate into the existing SRv6 framework. Otherwise it does not make much sense, or said another way, it will not be a SID compression scheme for SRv6 at all but another animal altogether. SID compression should be used where the use case justifies it, i.e. strict path TE inside a given domain. Inter-Domain usage of SRv6, especially end systems in data centers, may have different requirements and thus decide to use uncompressed SRv6 SIDs. It is important that a SID list that describes a service that spans across multiple domains be able to contain both compressed and uncompressed SIDs. Consequently, the same CP needs to support both compressed and uncompressed SIDs. I am currently working on an architecture based on SRv6 for different domains within a carrier network. These domains have different requirements and also different hardware capabilities that may lead to different designs for each subnetwork. But all these domains/ subnetworks must be able to interoperate seamlessly based on SRv6 standards, regardless of whether SID compression is used or not. Therefore I strongly agree that Appendix A should be part of the draft. I would also like to suggest another requirement: IMHO the single biggest advantage that SRv6 has compared to MPLS is aggregation (route summarization), something that is absolutely not possible with MPLS labels (SIDs). Aggregation (CIDR) is the very technology that has enabled the Internet to scale and to become the worldwide internetwork that it is today. In retrospect I believe the omission of aggregation has been the biggest design mistake in MPLS -- but back then there were a lot of other factors and the idea to use a very short tag for forwarding. After all Tag Switching and MPLS were inspired from ATM and within this context aggregation made no sense. Consequently I propose to add to the draft the requirement that the SID compression scheme MUST be compatible with aggregation, i.e. it must be possible to express the reachability of a given set of SIDs (maybe in some domain or data center) using a summary prefix. Thanks and Cheers Dirk On Thu, Nov 19, 2020 at 3:21 PM Ahmed Bashand wrote: > I also agree that the requirements in Appendix A should be part of the > draft. Having of existing standard as a basis greatly simplifies the > development and deployment of any compression scheme > > > Thanks > > > Ahmed > > > > On 11/19/20 12:58 AM, Ran Pang(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E4=B8= =AD=E5=9B=BD=E8=81=94=E9=80=9A=E7=A0=94=E7=A9=B6=E9=99=A2-=E6=9C=AC=E9=83= =A8) wrote: > > Hi Weiqiang and WG, > I read the draft and agree with the requirements specified in it.I > think the requirements in Appendix A should be part of the draft in the > next version. > China Unicom is working on a network evolution plan for SRv6 now, an= d > we have done some field trials based on SRv6. In order to maintain the > continuity of the functionality, we suggest the solution based on the SR= v6 > standards. > > Best regards, > Pang Ran > > > *From:* =E7=A8=8B=E4=BC=9F=E5=BC=BA > *Date:* 2020-11-15 23:27 > *To:* spring > *CC:* srcomp ; spring-chairs@ietf.o > > *Subject:* [spring] Fw:New Version Notification for > draft-srcompdt-spring-compression-requirement-01.txt > > Hi Group, > > SR compression design team have submitted a new version of compression > requirement draft. > > Main changes as follows: > > - added 3 items about scalibility with agreement within the design team > > - added an appendix including 3 items without without unanimous consensus > within the design team > > - some minor text issue fixed > > Please review it and let us know your comments. > > > BTW: We will have 1-hour session for the design team topic on Friday and > welcome to join us. > > > B.R. > > Weiqiang on behalf of design team > > > > > ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng > ,Sander Steffann > ,SJM Steffann > > =E6=8A=84 =E9=80=81: (=E6=97=A0) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:58:57 > > =E4=B8=BB=E9=A2=98=EF=BC=9ANew Version Notification for draft-srcompdt-sp= ring-compression-requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-01.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-req= uirement-01 > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > Subject=EF=BC=9ANew Version Notification for draft-srcompdt-spring-compre= ssion-requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-01.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-req= uirement-01 > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > =E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF=E6=8E=A5=E6=94=B6=E4=BA=86= =E8=AF=A5=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9=80=9A=E8=BF=87=E7=94=B5=E5= =AD=90=E9=82=AE=E4=BB=B6=E7=AB=8B=E5=8D=B3=E9=80=9A=E7=9F=A5=E6=88=91=E4=BB= =AC=E3=80=82=E8=AF=B7=E5=9B=9E=E5=A4=8D=E9=82=AE=E4=BB=B6=E5=88=B0 hqs-spmc= @chinaunicom.cn=EF=BC=8C=E5=8D=B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD= =A4=E9=82=AE=E4=BB=B6=E3=80=82=E6=88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3= =E5=B0=86=E6=82=A8=E7=9A=84=E4=BF=A1=E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7= =9A=84=E5=8F=91=E9=80=81=E7=9B=AE=E5=BD=95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80= =82 > If you have received this email in error please notify us immediately by > e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from > this mail. We will immediately remove your information from send catalogu= e > of our. > > _______________________________________________ > spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/s= pring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000086ca1d05b477a3cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello SPRING WG,

    I have read the SRComp= design team requirements draft=C2=A0
    and would like to comment.<= /div>

    I truly believe that a SID compression scheme= MUST integrate into the=C2=A0
    existing SRv6 framework. Otherwise= it does not make much sense,=C2=A0
    or said another way, it will = not be a SID compression scheme for SRv6=C2=A0
    at all but another= animal altogether.

    SID compression should be used where the use case justifies it, i.e.=
    strict path TE inside=C2=A0a given domain. Inter-Domain usage of= SRv6,
    especially end systems in data centers, may have different= requirements
    and thus decide to use uncompressed SRv6 SIDs. It i= s important that
    a SID list that describes a service that spans a= cross=C2=A0multiple domains
    be able to contain=C2=A0both compress= ed and uncompressed SIDs.=C2=A0
    Consequently, the same CP needs t= o support both compressed and=C2=A0
    uncompressed SIDs.
    =
    I am currently working on an architecture based on SRv6 for = different=C2=A0
    domains within a carrier network. These domains h= ave different=C2=A0
    requirements and also different hardware capa= bilities that may lead=C2=A0
    to different designs for each subnet= work. But all these domains/
    subnetworks must be able to interope= rate seamlessly based on SRv6
    standards, regardless of whether SI= D compression is used or not.

    Therefore I strongly= agree that Appendix A should be part of the draft.

    I would also like to suggest another requirement:
    IMHO the sing= le biggest advantage that SRv6 has compared to=C2=A0
    MPLS is aggr= egation (route summarization), something=C2=A0that is
    absolutely = not possible with MPLS labels (SIDs).
    Aggregation (CIDR) is the v= ery technology that has enabled the Internet=C2=A0
    to scale and t= o become the worldwide internetwork that it is today.=C2=A0
    In re= trospect I believe the omission of aggregation has been the=C2=A0
    biggest design mistake in MPLS -- but back then there were a lot=C2=A0
    of other factors and the idea to use a very short tag for forwarding= .=C2=A0
    After all Tag Switching and MPLS were inspired from = ATM=C2=A0
    and within this context aggregation made no sense.

    Consequently I propose to add to the draft the require= ment that the
    SID compression scheme MUST be compatible with aggr= egation,
    i.e. it must be possible to express the reachability of = a given set of
    SIDs (maybe in some domain or data center) using a= summary prefix.

    Thanks and Cheers
    Dirk






    On Thu, Nov 19, 2020 at 3:21 PM Ahmed Bashand <abashandy.ietf@gmail.com> wrote:
    =20 =20 =20

    I also agree that the requirements in Appendix A should be part of the draft. Having of existing standard as a basis greatly simplifies the development and deployment of any compression scheme


    Thanks


    Ahmed



    On 11/19/20 12:58 AM, Ran Pang(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E4=B8=AD=E5=9B=BD=E8=81=94= =E9=80=9A=E7=A0=94=E7=A9=B6=E9=99=A2-=E6=9C=AC=E9=83=A8) wrote:
    =20 =20
    = Hi=C2=A0Weiqiang and WG,=C2=A0
    =C2=A0 =C2=A0=C2=A0I read the draft and agree with the requirements specified in it.I think the requirements in Appendix A should be part of the draft in the next version.
    =C2=A0 = =C2=A0=C2=A0China Unicom is working on a network evolution plan for SRv6 now, =C2=A0and we have done some field trials=C2=A0based on S= Rv6.=C2=A0In = order to maintain the continuity of =C2=A0the functionality, we sugges= t the solution based on the SRv6 standards.

    Best regards,
    Pang Ran
    =C2=A0
    Date:=C2=A02020-11-15=C2=A023:27
    To:=C2=A0spring
    Subject:=C2=A0[spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

    Hi Group,

    SR compression design team have submitted a new version of compression requirement draft.

    Main changes as follows:=C2=A0

    - added 3 items about scalibility=C2=A0with agreement within the design team=C2=A0

    -=C2=A0added an appendix=C2=A0including 3 items without with= out unanimous consensus within the design team

    - some minor text issue fixed

    Please review it and let us know your comments.


    BTW: We will have=C2=A01-hour session for the design team topic=C2=A0on Friday and welcom= e to join us.


    B.R.

    Weiqiang on behalf of design team


    =C2=A0

    ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----
    =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts=C2=A0<internet-draf= ts@ietf.org>
    =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang=C2=A0Cheng=C2=A0<chengweiqiang@chin= amobile.com>,Sander=C2=A0Steffann=C2=A0<sander@steffann.nl>,SJM=C2=A0Steffann= =C2=A0<sander@st= effann.nl>
    =E6=8A=84=E3=80=80=E9=80=81:=C2=A0(=E6=97=A0)
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15=C2=A0= 22:58:57
    =E4=B8=BB=E9=A2=98=EF=BC=9ANew=C2=A0Version=C2=A0Notification=C2=A0for=C2= =A0draft-srcompdt-spring-compression-requirement-01.txt


    A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-srcompdt-spring-compre= ssion-requirement-01.txt
    has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Weiqiang=C2=A0C= heng=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
    IETF=C2=A0repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed=C2=A0SRv6=C2=A0SID=C2=A0List=C2=A0Requireme= nts
    Document=C2=A0date: 2020-11-13
    Group: Individual=C2=A0Submission
    Pages: 13
    URL:=C2=A0https://www.ietf.org/arch= ive/id/draft-srcompdt-spring-compression-requirement-01.txt
    Status:=C2=A0https://datatracker.ietf.or= g/doc/draft-srcompdt-spring-compression-requirement/
    Htmlized:=C2=A0https://datatracker.i= etf.org/doc/html/draft-srcompdt-spring-compression-requirement
    Htmlized:=C2=A0https://tools.ietf.org/html/= draft-srcompdt-spring-compression-requirement-01
    Diff:=C2=A0https://www.ietf.org/rfc= diff?url2=3Ddraft-srcompdt-spring-compression-requirement-01

    Abstract:
    =C2=A0This=C2=A0document=C2=A0specifies=C2=A0requirements=C2=A0for=C2=A0sol= utions=C2=A0to=C2=A0compress=C2=A0SRv6
    =C2=A0SID=C2=A0lists.

    =C2=A0


    Please=C2=A0note=C2=A0that=C2=A0it=C2=A0may=C2=A0take=C2=A0a=C2=A0couple=C2= =A0of=C2=A0minutes=C2=A0from=C2=A0the=C2=A0time=C2=A0of=C2=A0submission
    until=C2=A0the=C2=A0htmlized=C2=A0version=C2=A0and=C2=A0diff=C2=A0are=C2=A0= available=C2=A0at=C2=A0= tools.ietf.org.

    The=C2=A0IETF=C2=A0Secretariat



    Subject=EF=BC=9ANew=C2=A0Version=C2=A0Notification=C2=A0for=C2=A0draft-srco= mpdt-spring-compression-requirement-01.txt


    A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-srcompdt-spring-compre= ssion-requirement-01.txt
    has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Weiqiang=C2=A0C= heng=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
    IETF=C2=A0repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed=C2=A0SRv6=C2=A0SID=C2=A0List=C2=A0Requireme= nts
    Document=C2=A0date: 2020-11-13
    Group: Individual=C2=A0Submission
    Pages: 13
    URL:=C2=A0https://www.ietf.org/arch= ive/id/draft-srcompdt-spring-compression-requirement-01.txt
    Status:=C2=A0https://datatracker.ietf.or= g/doc/draft-srcompdt-spring-compression-requirement/
    Htmlized:=C2=A0https://datatracker.i= etf.org/doc/html/draft-srcompdt-spring-compression-requirement
    Htmlized:=C2=A0https://tools.ietf.org/html/= draft-srcompdt-spring-compression-requirement-01
    Diff:=C2=A0https://www.ietf.org/rfc= diff?url2=3Ddraft-srcompdt-spring-compression-requirement-01

    Abstract:
    =C2=A0This=C2=A0document=C2=A0specifies=C2=A0requirements=C2=A0for=C2=A0sol= utions=C2=A0to=C2=A0compress=C2=A0SRv6
    =C2=A0SID=C2=A0lists.

    =C2=A0


    Please=C2=A0note=C2=A0that=C2=A0it=C2=A0may=C2=A0take=C2=A0a=C2=A0couple=C2= =A0of=C2=A0minutes=C2=A0from=C2=A0the=C2=A0time=C2=A0of=C2=A0submission
    until=C2=A0the=C2=A0htmlized=C2=A0version=C2=A0and=C2=A0diff=C2=A0are=C2=A0= available=C2=A0at=C2=A0= tools.ietf.org.

    The=C2=A0IETF=C2=A0Secretariat



    =E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF=E6=8E=A5=E6=94=B6=E4=BA=86=E8= =AF=A5=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9=80=9A=E8=BF=87=E7=94=B5=E5=AD= =90=E9=82=AE=E4=BB=B6=E7=AB=8B=E5=8D=B3=E9=80=9A=E7=9F=A5=E6=88=91=E4=BB=AC= =E3=80=82=E8=AF=B7=E5=9B=9E=E5=A4=8D=E9=82=AE=E4=BB=B6=E5=88=B0=C2=A0hqs-spmc@chinaunicom= .cn=EF=BC=8C=E5=8D=B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD=A4=E9= =82=AE=E4=BB=B6=E3=80=82=E6=88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3=E5=B0= =86=E6=82=A8=E7=9A=84=E4=BF=A1=E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7=9A=84= =E5=8F=91=E9=80=81=E7=9B=AE=E5=BD=95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80=82 If you have received this email in error please notify us immediately by e-mail. Please reply to=C2=A0= hqs-spmc@chinaunicom.cn=C2=A0,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our. 
    _______________________________________________
spring mailing list
spring@ietf.org
=
https://www.ietf.org/mailman/listinfo/spring
    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --00000000000086ca1d05b477a3cc-- From nobody Thu Nov 19 09:27:31 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68C3A0E03; Thu, 19 Nov 2020 09:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ROddZKMdprKy; Thu, 19 Nov 2020 09:27:26 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31143A0DD7; Thu, 19 Nov 2020 09:27:25 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id r17so7104141ljg.5; Thu, 19 Nov 2020 09:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZnP7348Kh8NS+4IT/McEZqG8bBA4TNZPHAytyrFuzU=; b=DZj3G9CfarAHGeEXjX0M9L2d1bBAUdkOHoqAyZLRWfHH6jvhFSBJFHiUPuJFlTQteX 2bbBVNU49jPhKpi37qpVmcGC590eCy32lB6yIBMVBX4hhD+vHEt8OLfP/x+cXYP07vI/ VbPTyt4yhaBP7imP+bEyWF8RbBjB0idzCV9/hIi2umstBv9K3ch5a7nFkUVufh3ztyX7 GJ1AR652T9koLhALzdxH2owFJjciLu9lq0YuBXC4b/0Cxc62Ee25IjEP7Qnxvq7KKZnx bPniQOC0Te73NphQr1mVips4Zfekvrg1fei9BoTBqBKNubby9Wituv1Sx7WZm956A0qr WdlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZnP7348Kh8NS+4IT/McEZqG8bBA4TNZPHAytyrFuzU=; b=EAAqnZxQudqAzt+trpN+cJfJqExElhtigO4eXHACqxK7bd1yhJK4AWskeg1z/oLEa5 ueO8NueKp2wkaxm5y90fI81huk0Uui2U8oPI591ekxHk2N4UsYAiIabCKYP6ofnPXIfI HIsmcIyDCtMgP5oOlk3dO5MSCzd0zkrrcRtY6/HFbPyYQp5r3ZFNod93iv4E6cE0sBrY F9ViyiG8Tj0W9k3QryNtf3wsQJ/7Inuke60wAO5MNOqWQlha767aKgQve+2uMh4z/tdX wfNjEEHpko6K5v2mp8p64IO5cPpKf1MRO0GDtqjNkj6d5LnsXlWpZc0ht4EYiMRUG4aO D9Kw== X-Gm-Message-State: AOAM530k3Ifc2715wHh1t8/Aum/wPpsHCFgN/2dM4XCO9QKvCMSJ6Dos pam39qd2lFTr/r47QcqWeJS8Nce64+D0OXTkOZHyVyRToVPOrQ== X-Google-Smtp-Source: ABdhPJw/cxrDuFLThIgG67N4+osxuGgONfL2rHeIEuB7PGG0Lx7hSPNtznhQBp30ezqRsPjcGp5iPJwhbdV2QiJSkpg= X-Received: by 2002:a05:651c:207:: with SMTP id y7mr6665803ljn.428.1605806843994; Thu, 19 Nov 2020 09:27:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 19 Nov 2020 09:27:11 -0800 Message-ID: To: Mach Chen Cc: Tianran Zhou , "Rakesh Gandhi (rgandhi)" , spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="00000000000083a84c05b4790a92" Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 17:27:31 -0000 --00000000000083a84c05b4790a92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mach, thank you for your email. I've added my understanding of what has been proposed in-line tagged GIM>>. Regards, Greg On Wed, Nov 18, 2020 at 11:41 PM Mach Chen wrote: > Hi Tianran, Rakesh and Greg, > > > > Please see some responses inline with [Mach]=E2=80=A6 > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Tianran Zhou > *Sent:* Thursday, November 19, 2020 1:33 PM > *To:* Rakesh Gandhi (rgandhi) ; Gre= g > Mirsky > *Cc:* spring ; IPPM Chairs ; > spring-chairs@ietf.org; Tommy Pauly = ; > IETF IPPM WG (ippm@ietf.org) > *Subject:* Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > > > Hi Rakesh and Greg, > > > > I may not very clear about the context. Please allow me to jump in. > > It seems both of you make some valid point. > > Please see in line with . > > > > Cheers, > > Tianran > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *Rakesh Gandhi (rgandhi) > *Sent:* Wednesday, November 18, 2020 7:41 AM > *To:* Greg Mirsky > *Cc:* spring ; IPPM Chairs ; > spring-chairs@ietf.org; Tommy Pauly = ; > IETF IPPM WG (ippm@ietf.org) > *Subject:* Re: [spring] [ippm] Call for adoption: > draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm > > > > Hi Greg, > > > > Thank you for your review and discussions on the drafts. This will help > improve the work on this important work. > > Please see replies inline with .. > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, November 17, 2020 at 5:27 PM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Tommy Pauly , IPPM Chairs < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG (ippm@ietf.org) , spring > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Hi Rakesh, WG Chairs, and All, > > I've read the responses to my detailed comments. I don't think that only > adding references will solve the problems with the documents. If authors > are interested in addressing my comments, we can start working on > solving them one by one. > > > > As mentioned in previous replies, we can add references for the > well-known terms =E2=80=9CLinks=E2=80=9D, =E2=80=9CCongruent Paths=E2=80= =9D, =E2=80=9CSR Path=E2=80=9D. If you prefer, we > can define them here. For Zero checksum field, we can add a reference for > the RFC 6936 in Security section and also add some text for it. Will be > happy to work with you to address these. > > > > But I am very much concerned with the technical value of these drafts. An= d > here's why I feel that the proposed documents don't provide a sound > technical solution to the task of direct loss measurement. Please find my > reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm: > > - What is being proposed in these drafts? > > Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support > direct packet loss measurements. Note, that RFC 6374 includes a method fo= r > direct loss measurement in MPLS networks that is applicable to the SR-MPL= S > environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension = to > RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et > loss measurement. STAMP and all its extensions are applicable in IPv6 > networks and, thus, can be used in the SRv6 domain. > > > > As mentioned in previous replies, both RFC 6374 (in Section 4.2) and > ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX > and RX counters for direct-mode loss measurement. TWAMP/STAMP messages > defined in the drafts are equivalent of them that take advantage of the > widely deployed TWAMP protocol and as well this same protocol can be > deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks. > > > > I think RFC6374 for MPLS and Y.1731 make some noise here. The point > is if we need a new direct packet loss measurement for STAMP, when STAMP > already defined a Direct Measurement TLV ( > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If > current Direct Measurement TLV cannot fulfill some use case requirement, > then how about proposing a new TLV. > > > > [Mach] Given that TWAMP does not support TLV, I assume that the > discussions are mainly about draft*-stamp-srpm. > GIM>> You've brought a very good question on how the return path, in case required by the Sender Control Code, introduced in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC 5357 does not use TLV extensions. Should I assume that the return path, if required, provisioned through the management plane? I think that that requires clarification. > > > [Mach] In the case of direct packet loss measurement, > draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which c= an > address the packet out-ordering issue) is used, hence the block number is > introduced. The block number is used to correlate the counters from the > sender and reflector. The current direct loss measurement TLV may just > apply to the scenario without packet out-ordering. > GIM>> I agree with your observation on the purpose of the Block Number field in both TWAMP-Light and STAMP documents. In my understanding, the new protocol may be also used to collect counters generated by methods other than Alternate Marking. In that case, I assume, the value of Block Number may not convey any information. > > > [Mach] In addition, whether to keep it as current design or to define a > new TLV for direct loss measurement can be debatable. > GIM>> I agree with you. And that what I am proposing - review the requirements, agree on requirements, and review the proposed solution based on these requirements. > > > How the proposed method of direct packet loss is related to TWAMP light > and STAMP? > > There's no apparent technical relationship between *-twamp-srpm and TWAMP > Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use t= he > basic mechanisms defined for TWAMP-Test and/or STAMP in their respective > specifications. Rather than that, drafts introduce a new query-response > mode and new formats of test packets that are decisively different from t= he > formats defined in respective specifications. As a result, the new > protocols are required to use different from used by TWAMP Light tr STAMP > test session UDP port numbers on the responder. And that is another clear > indication that the proposed mechanism represents a new protocol, neither > extends TWAMP Light and/or STAMP nor updates their specifications. > > > > As mentioned in previous replies, other than timestamp vs. counter > and it=E2=80=99s format, the messages and processing of them are the same= for delay > and direct-mode loss measurement. > > - Is there any advantage in introducing a dedicated packet format for > the direct packet loss in STAMP comparing to using the Direct Measurem= ent > TLV extension? > > Though it appears the using a dedicated packet format instead of TLV is > more efficient, but the dedicated for the direct loss measurement format = is > likely to precede one or even two TLVs, Node Address TLV and Path TLV, > defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the n= ew > packet with TLVs is unlikely to be more efficient and reduce the processi= ng > delay, than if using the Direct Measurement TLV as defined in > draft-ietf-ippm-stamp-option-tlv. > > > > As mentioned in previous replies, this is explained in Section 1 of > the draft-gandhi-spring-stamp-srpm > . For > link loss measurement (direct-mode), there is no TLV required for example= . > For direct-mode loss measurement in SR networks, it would *typically* be > forward direction packet loss measurement (and not bidirectional). > > > > > > =C2=B7 What are the potential benefits of specifying the return p= ath > in the new test packet's Sender Control Code? > > Using the Sender Control Code may require the use of the additional TLV > that carries the return path information, Path TLV. If the ability to > control the return path is required that can be achieved by augmenting th= e > STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including > the Path TLV in each test packet. Hence, there seem no technical > requirements to introduce the Sender Control Code field in the Base STAMP > format defined in RFC 8762. > > > > Per session basis between different sender nodes and this reflector > node, some senders will request the replies in-band (e.g. for two-way > mode). Sessions are provisioned on the Sender nodes and reflector simply > reflects based on the received test-packet (e.g. for a bidirectional SR > path). This is also similar to as described Section 3.1 in RFC 6374, top = of > page 22. There is no need to create a such state for each session on the > reflector node and create a scale limitation. Recall that we are trying t= o > avoid the scale limitation by eliminating the Control protocol signaling. > > > > I find some value to include the path TLV in wire. As Rakesh > mentioned, this can reduce the reflector configuration. But I am not > convinced to introduce the sender control code field. It seems to me, the > presence of path TLV indicates the bidirectional congruent path. Vise > versa. > > > > [Mach] Regarding how to specify the return path, the draft defines two > ways to achieve that, one is to use control code to direct whether the > reflected Test should be along the reverse path of a bidirectional path, > this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same tim= e, > in the case of STAMP, it also defines the return path TLV to explicitly > specify the return path, which bring more options to specify the return > path. Therefore, I see benefit of the two ways. > GIM>> I think you've pointed to some vagueness in the definition of a mechanism used to define the return path. My understanding is that if a response required, the Return Path TLV must be present in a test packet. But, if TLVs are not used for TWAMP-like direct loss measurement, why not use the same method to control the return path? I believe that consistency is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single protocol only presented as different entities). > > > > > Best regards, > > Mach > > > > What is the relationship between the *-srpm drafts and BFD? > > Some text in the *-srpm drafts suggest that the proposed method can be > used to monitor for the loss of a path continuity. That may be viewed as = an > alternative to the BFD protocol method for the detection of a network > failure. If the discussion of Loopback mode and monitoring of liveness > remain in the drafts, it seems logical that the BFD WG and BFD WG's Chair= s > be made aware of the proposals. I didn't take the liberty of adding BFD W= G > or its Chairs. I believe that decision to be made by the Chairs of IPPM A= nd > SPRING WGs. > > > > As mentioned in previous replies, STAMP/TWAMP test messages are also > used today for *synthetic* packet loss measurement which can be also used > to detect/monitor connection loss (performance metric). The draft simply > highlights this obvious metric. This is also very similar to what is > described in ITU Y.1731, Section 7.1. > > > > Thanks, > > Rakesh > > > > Regards, > > > > > > On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: > > Hi Rakesh, > > thank you for your prompt response, much appreciated. I'll carefully read > your responses. Looking forward to the continued discussion. > > > > Regards, > > Greg > > > > On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com> wrote: > > Hi Greg, > > > > Thank you for your review comments. As mentioned in the IPPM session > today, the email response was sent as attachments, see archive blow: > > https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ > > > > I am attaching them in word documents for the convenience. We can address > your comments below in the next revision of the document. > > > > Thanks, > > Rakesh > > > > > > *From: *Greg Mirsky > *Date: *Friday, November 13, 2020 at 10:09 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Tommy Pauly , IPPM Chairs < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG (ippm@ietf.org) > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Hi Rakesh, > > thank you for your response to my review. Please find my follow-up notes > in-lined below under the GIM>> tag. > > I hope you've found more detailed comments in the attachments (re-attache= d > for your convenience). I'm looking forward to reading your responses to t= he > detailed comments of all four drafts. > > > > Regards, > > Greg > > > > On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. Attached please find the email replies to your > review sent earlier. The replies are copied inline below for convenience= , > tagged with . > > > > > > *From: *ippm > *Date: *Monday, November 9, 2020 at 11:48 AM > *To: *Tommy Pauly > *Cc: *IPPM Chairs , spring-chairs@ietf.org < > spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Dear WG Chairs, Authors, and IPPM WG community, > > I've reviewed these drafts and have some comments to share. Below, please > find my thoughts on whether these drafts can be adopted. More specific > comments on each pair of drafts (TWAMP-related and STAMP-related draft an= d > its accompanying draft targetted to the SPRING WG) are in the attached > documents. > > > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > =C2=B7 Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFCs > 4656/5357 and RFC 8762, and introduce their own terminology for > Session-Sender and Session-Reflector. Also, many terms, e.g., Links, > "congruent paths", are used in the documents without proper definitions. > Other than that both drafts are readable and reasonably well-written. > > > > We can change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. > > There are many existing RFCs that use term Link (e.g. RFC 5613, > 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. From the definition of "congruent" as "two figures or object= s > are congruent if they have the same shape and size, or if one has the sam= e > shape and size as the mirror image of the other", path A-B-G-H-E-F is > congruent to the SR tunnel. But a packet of an active OAM intended to > monitor a flow over the SR tunnel is out-of-band and will not produce any > meaningful measurement. Of course, for the case of the extensions in > drafts, direct loss measurement can be performed, as information collecte= d > from node F. So, this example, in my opinion, illustrates two of my > concerns: > > - using a congruent path for an active OAM protocol may produce > information that does not reflect the condition experienced by the > monitored flow. It seems that the terminology should reflect the > fundamental requirement for using active OAM to maintain the test pack= ets > in-band with the monitored flow. > - there are no technical requirements to justify using in-band active > OAM protocol for direct packet loss measurement. As demonstrated in th= is > example, direct packet loss can be performed using an out-of-band > mechanism, e.g., SNMP queries, Netconf notifications based on YANG dat= a > model. > > > > =C2=B7 Does the document solve a real problem? > > No, it appears that both TWAMP and STAMP drafts define a new > performance measurement protocol for the purpose of combining OWAMP/TWAMP > and STAMP functionality in the respective drafts, and adding the ability = to > collect counters of "in-profile" packets. I couldn't find sufficient > technical arguments for using a PM protocol instead of, for example, > extending the existing OAM mechanisms like ICMP multi-part message > extension per RFC 4884. > > > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direct > packet loss measurement. > > > > =C2=B7 Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocols on network security, to comprehensively evaluate the > proposed solutions. > > > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for STAMP or TWAMP Light. Other than this, = I > did not find any other security related issue in your review. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > > > Thanks, > > Rakesh > > > > > > Regards, > > Greg > > > > > > > > > > On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > > Hello IPPM, > > > > For the past few meetings, we=E2=80=99ve had updates on the work in the S= PRING WG > that was using STAMP and TWAMP. Since those documents ended up making > extensions to the base protocols, the chairs of SPRING and IPPM decided > that it would be best to split the documents and track the IPPM extension > work in the IPPM WG. > > > > As such, we are starting a Working Group call for adoption > for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. > > > > The documents are here: > > https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 > > https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 > > > The related SPRING documents are here: > > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 > > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > > > Please provide your feedback on these documents, and state whether or not > you believe the IPPM WG should adopt this work by replying to this email. > Please provide your feedback by the start of the IETF 109 meeting week, o= n *Monday, > November 16*. > > > > Best, > > Tommy & Ian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --00000000000083a84c05b4790a92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Mach,
    thank you for your=C2=A0email. I&#= 39;ve added my understanding of what has been proposed in-line tagged GIM&g= t;>.

    Regards,
    Greg

    On Wed, Nov 18, 202= 0 at 11:41 PM Mach Chen <mach.ch= en@huawei.com> wrote:

    Hi Tianran, Rakesh and Greg,

    =C2=A0

    Please see some responses inline with [Mach]=E2=80=A6

    =C2=A0

    From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org>; G= reg Mirsky <g= regimirsky@gmail.com>
    Cc: spring <= spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf.org>; spring-chairs@ietf.org; Tommy Pa= uly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    =C2=A0

    = Hi Rakesh and Greg,

    = =C2=A0

    = I may not very clear about the context. Please allow me to jump in.

    = It seems both of you make some valid point.

    = Please see in line with <ZTR>.

    = =C2=A0

    = Cheers,

    = Tianran

    = =C2=A0

    =C2=A0

    = Hi Greg,

    = =C2=A0

    = Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work.

    = Please see replies inline with <RG>..

    = =C2=A0

    =C2=A0

    From: Greg M= irsky <gregim= irsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM = Chairs <ippm-c= hairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,<= u>

    I've read the responses to = my detailed comments. I don't think that only adding references will so= lve the problems with the documents. If authors are interested in addressin= g my comments, we can start working on solving=C2=A0them one by one.

    =C2=A0

    = <RG> As mentioned in previous replies, we can add references for the = well-known terms =E2=80=9CLinks=E2=80=9D, =E2=80=9CCongruent Paths=E2=80=9D= , =E2=80=9CSR Path=E2=80=9D. If you prefer, we can define them here. For Ze= ro checksum field, we can add a reference for the RFC 6936 in Security section and also add some tex= t for it. Will be happy to work with you to address these.

    = =C2=A0

    But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the = proposed documents don't provide a sound technical solution to the task= of direct loss measurement.=C2=A0Please find my reasoning explaining=C2=A0my opinion of the *-twamp-srpm and *-stamp-srpm:=

    • What is being proposed in these drafts?<= /span>

    Drafts *-twamp-srpm and *-stamp= -srpm propose a new protocol to support direct packet loss measurements. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

    =C2=A0

    = <RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2)= and ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting= TX and RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.<= /u>

    =C2=A0

    <ZTR> I think RFC6374 for= MPLS and Y.1731 make some noise here. The point is if we need a new direct= packet loss measurement for STAMP, when STAMP already defined a Direct Mea= surement TLV (https://datatracker.ietf.org/doc/draft-i= etf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

    =C2=A0

    [Mach] Given that TWAMP does not support TLV, I assume tha= t the discussions are mainly about draft*-stamp-srpm.

    GIM>> You've brought a very good questio= n on how the return path, in case required by the Sender Control Code, intr= oduced in=C2=A0draft-gandhi-ippm-twamp-srpm, is specified? As you've po= inted out, RFC 5357 does not use TLV extensions. Should I assume that the r= eturn path, if required, provisioned through the management plane? I think = that that requires clarification.

    =C2=A0

    [Mach] In the case of direct packet loss measurement, draf= t-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can add= ress the packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlat= e the counters from the sender and reflector. The current direct loss measu= rement TLV may just apply to the scenario without packet out-ordering.

    GIM>> I agree with your obs= ervation on the purpose of the Block Number field in both TWAMP-Light and S= TAMP documents. In my understanding, the new protocol may be also used to c= ollect counters generated by methods other than Alternate=C2=A0Marking. In = that case, I assume, the value of Block Number may not convey any informati= on.

    =C2=A0

    [Mach] In addition, whether to keep it as current design o= r to define a new TLV for direct loss measurement can be debatable. =C2=A0<= /span>

    GIM>> I agree with you.= And that what I am proposing - review the requirements, agree on requireme= nts, and review the proposed solution based on these requirements.=C2=A0

    =C2=A0

    How the proposed method of dire= ct packet loss is related to TWAMP light and STAMP?

    There's no apparent technic= al relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm draft= s and STAMP. Drafts do not extend or re-use the basic mechanisms defined fo= r=C2=A0 TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats defined in respective specifications. As a result, the new protocols= are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

    =C2=A0

    = <RG> As mentioned in previous replies, other than timestamp vs. count= er and it=E2=80=99s format, the messages and processing of them are the sam= e for delay and direct-mode loss measurement.

    • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

    Though it appears the using a d= edicated packet format instead of TLV is more efficient, but the dedicated = for the direct loss measurement format is likely to precede one or even two= TLVs, Node Address TLV and Path TLV, defined in=C2=A0draft-gandhi-ippm-stamp-srpm. As a result, processing of t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

    =C2=A0

    = <RG> As mentioned in previous replies, this is explained in Section 1= of the draft-gandhi-sprin= g-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

    =C2=A0

    =C2=A0

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 What are the potential ben= efits of specifying the return path in the new test packet's Sender Con= trol Code?

    Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

    =C2=A0

    = <RG> Per session basis between different sender nodes and this reflec= tor node, some senders will request the replies in-band (e.g. for two-way m= ode). Sessions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for = a bidirectional SR path). This is also similar to as described Section 3.1 = in RFC 6374, top of page 22. There is no need to create a such state for ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

    =C2=A0

    <ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

    =C2=A0

    [Mach] Regarding how to specify the return path, the draft= defines two ways to achieve that, one is to use control code to direct whe= ther the reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanism= s) and STAMP. At the same time, in the case of STAMP, it also defines the r= eturn path TLV to explicitly specify the return path, which bring more opti= ons to specify the return path. Therefore, I see benefit of the two ways.

    GIM>> I think you've pointed to some vagueness in t= he definition of a mechanism used to define the return path. My understandi= ng is that if a response required, the Return Path TLV must be present in a= test packet. But, if TLVs are not used for TWAMP-like direct loss measurem= ent, why not use the same method to control the return path? I believe that= consistency is a good quality of a protocol (yes, I see *-twamp-srpm and *= -stmp-srpm as a single protocol only presented as different entities).

    =C2=A0

    =C2=A0

    Best regards,

    Mach

    =C2=A0

    What is the relationship betwee= n the *-srpm drafts and BFD?

    Some text in the *-srpm drafts = suggest that the proposed method can be used=C2=A0to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs= be made aware of the proposals. I didn't take the liberty of adding BF= D WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

    =C2=A0

    = <RG> As mentioned in previous replies, STAMP/TWAMP test messages are = also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

    = =C2=A0

    = Thanks,

    = Rakesh

    =C2=A0

    Re= gards,

    =C2=A0

    =C2=A0

    On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,=

    thank you for your prompt respo= nse,=C2=A0much appreciated. I'll carefully read your responses. Looking= forward to the continued discussion.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    Thank you for your review comme= nts. As mentioned in the IPPM session today, the email response was sent as= attachments, see archive blow:

    http= s://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/<= /u>

    =C2=A0

    I am attaching them in word doc= uments for the convenience. We can address your comments below in the next = revision of the document.

    =C2=A0

    Thanks,

    Rakesh

    =C2=A0

    =C2=A0

    From: Greg M= irsky <gregim= irsky@gmail.com>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm    <= /span>

    Hi Rakesh,=

    thank you for your response to = my review. Please find my follow-up notes in-lined below under the GIM>&= gt; tag.

    I hope you've found more de= tailed comments in the attachments (re-attached for your convenience). I= 9;m looking forward to reading your responses=C2=A0to the detailed comments of all four drafts.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Nov 10, 2020 at 8:11 AM= Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    = Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments.=C2=A0 Attached please find the email replies to your review sent earlier.=C2=A0 The replies are copied inline below for= convenience, tagged with <RG00>.<= u>

    = =C2=A0

    =C2=A0

    From: ippm &= lt;ippm-bounces@= ietf.org>
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm    <= /span>

    Dear WG Chairs, Authors, and IP= PM WG community,

    I've reviewed these drafts = and have some comments to share. Below, please find my thoughts on whether = these drafts can be adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying= =C2=A0draft targetted=C2=A0to the SPRING WG) are in the attached documents.=

    =C2=A0

    Usually, the bar for the adoption o= f a document can be evaluated=C2=A0by answers to these three questions:

    =C2=B7=C2=A0 Is the document(s) reasonably well-written

    I've got surprised that the dra= fts don't use the terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. = Also, many terms, e.g., Links, "congruent paths", are used in the= documents without proper definitions. Other than that both drafts are read= able and reasonably well-written.=

    =C2=A0

    = <RG00> We can change Sender to Session-Sender and Reflector to Sessio= n-Reflector if it helps.=C2=A0

    GIM>> I believe that the = consistency in terminology between the core RFC and what is intended as its= extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.

    = <RG00> There are many existing RFCs that use term Link (e.g. RFC 5613= , 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having = said that, we can add a reference for them if it helps.

    GIM>> Thank you for listi= ng these RFCs. I think I need to clarify my questions. While a reference to= any of RFCs you've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced RFCs used the lower case form for the term "link". Can = these be used interchangeably? Do they refer to the same network object?=

    Now I'll try to illustrate = my concern with using the term "congruent path" in these drafts (= using ASCII-art):

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 A----B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to= F that traverses the network as A-B-C-D-E-F. From the definition of "= congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the= mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts, direct loss measurement can be performed, as information collected f= rom node F. So, this example, in my opinion, illustrates two of my concerns= :

    • using a congruent path for an active OAM protocol may = produce information that does not reflect the condition experienced by the = monitored flow. It seems that the terminology should reflect the fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.
      • <= /ul>

    =C2=A0

    =C2=B7=C2=A0 Does the document solve a real problem?

    No, it appears that=C2=A0 both TWAMP and STAMP drafts=C2=A0define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't f= ind sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

    =C2=A0

    = <RG00> There is a requirement to measure performance delay as well as= synthetic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

    GIM>> I agree with the=C2= =A0requirements you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason=C2=A0t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement.=C2=A0=

    =C2=A0

    =C2=B7=C2=A0 Is the proposed solution technically viable?=

    There are too many unaddressed aspe= cts, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

    =C2=A0<= u>

    = <RG00> About your comment on zero checksum, this is described in Secu= rity section in RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

    GIM>> I don't think t= hat a mere reference sufficiently explains why the use of zero UDP checksum= in IPv6 header is not decremental, does not create a security risk for the protocol.

    = =C2=A0

    = Thanks,

    = Rakesh

    =C2=A0

    =C2=A0

    Regards,

    Greg=

    =C2=A0<= /p>

    =C2=A0

    =C2=A0<= /p>

    =C2=A0

    On Fri, Oct 30, 2020 at 11:35 A= M Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

    =C2=A0

    For the past few meetings, we= =E2=80=99ve had updates on the work in the SPRING WG that was using STAMP a= nd TWAMP. Since those documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be= best to split the documents and track the IPPM extension work in the IPPM = WG.

    =C2=A0

    As such, we are starting a Work= ing Group call for adoption for=C2=A0draft-gandhi-ippm-twamp-srpm and draft= -gandhi-ippm-stamp-srpm.

    =C2=A0

    Please provide your feedback on= these documents, and state whether or not you believe the IPPM WG should a= dopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, Nov= ember 16.

    =C2=A0

    Best,

    Tommy & Ian

    _______________________________= ________________
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --00000000000083a84c05b4790a92-- From nobody Thu Nov 19 17:28:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764363A14B6; Thu, 19 Nov 2020 17:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UhQ9m6OeQMLn; Thu, 19 Nov 2020 17:28:07 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061913A14AE; Thu, 19 Nov 2020 17:28:06 -0800 (PST) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ccf4m1PHcz67Ctd; Fri, 20 Nov 2020 09:25:44 +0800 (CST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 20 Nov 2020 02:28:02 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 20 Nov 2020 09:28:00 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 20 Nov 2020 09:28:00 +0800 From: Tianran Zhou To: "Rakesh Gandhi (rgandhi)" , Mach Chen , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutyzmWv/eapkkq7mEvT+f83ham/jAuAgAGIKYCABKWmAIAEH64AgAAA6ACAAqNCgIAAFHgAgAJz+6D//6SbgIAAfuoAgAEsbKA= Date: Fri, 20 Nov 2020 01:28:00 +0000 Message-ID: <02323949c3d9479a92c674a676f366ae@huawei.com> References: , , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_02323949c3d9479a92c674a676f366aehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 01:28:12 -0000 --_000_02323949c3d9479a92c674a676f366aehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach and Rakesh, Thanks for your reply. I am now much more clear. But I really think the draft should add more text on the motivation and use= case. It would be very helpful for the audience to understand. For example, one of my question about the new direct measurement. There is rare word on how to use it, how it's different from existing stamp= direct measurement tlv. Anyway, I find some valuable extensions in these two drafts. I would like t= o support the adoption and help to improve this document. Best, Tianran From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Thursday, November 19, 2020 11:15 PM To: Mach Chen ; Tianran Zhou = ; Greg Mirsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM WG (ippm@ietf.org)= Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Thank you Mach and Tianran for your review comments. Please see inline reply with ... From: Mach Chen > Date: Thursday, November 19, 2020 at 2:41 AM To: Tianran Zhou >, R= akesh Gandhi (rgandhi) >, Greg = Mirsky > Cc: spring >, IPPM Chairs >, spring-chairs@ietf.org >, Tommy Pauly >, IETF IPPM WG = (ippm@ietf.org) > Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]... From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) >; Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms "Links", "Congruent Paths", "SR Path". If you prefer, we can def= ine them here. For Zero checksum field, we can add a reference for the RFC = 6936 in Security section and also add some text for it. Will be happy to wo= rk with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussions= are mainly about draft*-stamp-srpm. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. To further add to this, as TWAMP Light does not have a TLV, we need = to define a stand-alone message for direct-mode LM. STAMP is just the same = message but fixed length, so this way both can interoperate and also we can= leverage the message for both of these protocols. For STAMP direct-mode LM TLV approach, some technical details are in the dr= aft as well: The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization for one-way delay). Furthermore, for hardware-based cou= nter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. How the proposed method of direct packet loss is related to TWAMP light and= STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it's format, the messages and processing of them are the same for delay an= d direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in = the new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. To further add to this, the IPPM draft simply defines protocol extens= ions. The use-cases are there in the corresponding spring drafts. For examp= le, for links, no return Path TLV is used, etc. In other words, the use-cas= es are different for the two, and there is no TLV in TWAMP anyways. Thanks, Rakesh Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. * Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we've had updates on the work in the SPRING WG t= hat was using STAMP and TWAMP. Since those documents ended up making extens= ions to the base protocols, the chairs of SPRING and IPPM decided that it w= ould be best to split the documents and track the IPPM extension work in th= e IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_02323949c3d9479a92c674a676f366aehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Mach and Rakesh,

     

    Thanks for your reply.= I am now much more clear.

    But I really think the= draft should add more text on the motivation and use case.  It would = be very helpful for the audience to understand.  

    For example, one of my= question about the new direct measurement.

    There is rare word on = how to use it, how it’s different from existing stamp direct measurem= ent tlv.

    Anyway, I find some va= luable extensions in these two drafts. I would like to support the adoption= and help to improve this document.

     

    Best,

    Tianran

     

     

    From: Rakesh Gandhi (rgandhi) [mailto:rgandhi= @cisco.com]
    Sent: Thursday, November 19, 2020 11:15 PM
    To: Mach Chen <mach.chen@huawei.com>; Tianran Zhou <zhoutia= nran@huawei.com>; Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly@apple.com>; IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Thank y= ou Mach and Tianran for your review comments.

    Please = see inline reply with <RG2>…

     

    From: Mach= Chen <mach.chen@huawei.com&= gt;
    Date: Thursday, November 19, 2020 at 2:41 AM
    To: Tianran Zhou <zhout= ianran@huawei.com>, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>, IPPM Chairs <ippm-chairs@= ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, Tom= my Pauly <tpauly@apple.com>, = IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Ti= anran, Rakesh and Greg,

     = ;

    Pleas= e see some responses inline with [Mach]…<= o:p>

     = ;

    From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org>; Greg Mirs= ky <gregimirsky@gmail.com&g= t;
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Hi Rakesh and Greg,

     

    I may not very clear a= bout the context. Please allow me to jump in.

    It seems both of you m= ake some valid point.

    Please see in line wit= h <ZTR>.

     

    Cheers,

    Tianran

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimi= rsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     

    Hi Greg= ,

     <= /span>

    Thank y= ou for your review and discussions on the drafts. This will help improve th= e work on this important work.

    Please = see replies inline with <RG>..=

     <= /span>

     

    From: Greg= Mirsky <gregimirsky@gmail.com<= /a>>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <    rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,<= o:p>

    I've read the responses to my d= etailed comments. I don't think that only adding references will solve the = problems with the documents. If authors are interested in addressing my com= ments, we can start working on solving them one by one.

     

    <RG&= gt; As mentioned in previous replies, we can add references for the well-kn= own terms “Links”, “Congruent Paths”, “SR Pat= h”. If you prefer, we can define them here. For Zero checksum field, = we can add a reference for the RFC 6936 in Security section and also add some tex= t for it. Will be happy to work with you to address these.

     <= /span>

    But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the prop= osed documents don't provide a sound technical solution to the task of dire= ct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:=

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp= -srpm propose a new protocol to support direct packet loss measurements. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

     

    <RG&= gt; As mentioned in previous replies, both RFC 6374 (in Section 4.2) and IT= U Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and= RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

     

    <ZTR> I think RFC6374 for= MPLS and Y.1731 make some noise here. The point is if we need a new direct= packet loss measurement for STAMP, when STAMP already defined a Direct Mea= surement TLV (https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-opt= ion-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

     

    [Mach] Given that TWAMP does not support TLV, I assume that the d= iscussions are mainly about draft*-stamp-srpm.<= o:p>

     

    [Mach] In the case of direct packet loss measurement, draft-gandh= i-ippm-stamp-srpm assumes that marking-based solution (which can address th= e packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlat= e the counters from the sender and reflector. The current direct loss measu= rement TLV may just apply to the scenario without packet out-ordering.

     

    <RG2= > To further add to this,  as TWAMP Light does not have a TLV, we n= eed to define a stand-alone message for direct-mode LM. STAMP is just the s= ame message but fixed length, so this way both can interoperate and also we can leverage the message for both of these protoc= ols.

     

    For STAMP direct-mode LM TLV a= pproach, some technical details are in the draft as well:=

     

       The STAMP message with a TLV for "= direct measurement" can be used for

       combined Delay + Loss measurement [= I-D= .ietf-ippm-stamp-option-tlv].

       However, in order to use only for loss = measurement purpose, it=

       requires the node to support the delay = measurement messages and

       support timestamp for these messages (w= hich may also require clock

       synchronization for one-way delay).&nbs= p; Furthermore, for hardware-based counter collection

       for direct-mode loss measurement, the o= ptional TLV based processing

       adds unnecessary overhead (as counters = are not at well-known

       locations).

     

     

     

    [Mach] In addition, whether to keep it as current design or to de= fine a new TLV for direct loss measurement can be debatable.  <= span lang=3D"EN-CA" style=3D"font-size:10.5pt">

     

     

     

    How the proposed method of dire= ct packet loss is related to TWAMP light and STAMP?

    There's no apparent technical r= elationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts an= d STAMP. Drafts do not extend or re-use the basic mechanisms defined for&nb= sp; TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats defined in respective specifications. As a result, the new protocols= are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

     

    <RG&= gt; As mentioned in previous replies, other than timestamp vs. counter and = it’s format, the messages and processing of them are the same for del= ay and direct-mode loss measurement.=

    • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

    Though it appears the using a d= edicated packet format instead of TLV is more efficient, but the dedicated = for the direct loss measurement format is likely to precede one or even two= TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

     

    <RG&= gt; As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

     

     

    ·         What are the potential = benefits of specifying the return path in the new test packet's Sender Cont= rol Code?

    Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

     

    <RG&= gt; Per session basis between different sender nodes and this reflector nod= e, some senders will request the replies in-band (e.g. for two-way mode). S= essions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for = a bidirectional SR path). This is also similar to as described Section 3.1 = in RFC 6374, top of page 22. There is no need to create a such state for ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

     

    <ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa. <= /o:p>

     

    [Mach] Regarding how to specify the return path, the draft define= s two ways to achieve that, one is to use control code to direct whether th= e reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanism= s) and STAMP. At the same time, in the case of STAMP, it also defines the r= eturn path TLV to explicitly specify the return path, which bring more opti= ons to specify the return path. Therefore, I see benefit of the two ways.

     

    <RG2= > To further add to this, the IPPM draft simply defines protocol extensi= ons. The use-cases are there in the corresponding spring drafts. For exampl= e, for links, no return Path TLV is used, etc. In other words, the use-cases are different for the two, and there is no T= LV in TWAMP anyways.

    &n= bsp;

    Thanks,=

    Rakesh<= o:p>

    &n= bsp;

     

     

    Best regards,

    Mach

     

    What is the relationship betwee= n the *-srpm drafts and BFD?

    Some text in the *-srpm drafts = suggest that the proposed method can be used to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be = made aware of the proposals. I didn't take the liberty of adding BFD WG or = its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

     

    <RG&= gt; As mentioned in previous replies, STAMP/TWAMP test messages are also us= ed today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

     <= /span>

    Thanks,=

    Rakesh<= /span>

    =  

    = Regards,

     

     

    On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,

    thank you for your prompt respo= nse, much appreciated. I'll carefully read your responses. Looking for= ward to the continued discussion.

     

    Regards,

    Greg

     

    On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Hi Greg,

     

    Thank you for your review comments. As mentio= ned in the IPPM session today, the email response was sent as attachments, = see archive blow:

    https://mailarchiv= e.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/=

     

    I am attaching them in word documents for the= convenience. We can address your comments below in the next revision of th= e document.

     

    Thanks,

    Rakesh

     

     

    From: Greg= Mirsky <greg= imirsky@gmail.com>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Ple= ase find my follow-up notes in-lined below under the GIM>> tag.<= /o:p>

    I hope you've found more detailed comments in= the attachments (re-attached for your convenience). I'm looking forward to= reading your responses to the detailed comments of all four drafts.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi= (rgandhi) <rgand= hi@cisco.com> wrote:

    Thank you Greg for ta= king time for thoroughly reviewing the documents and providing the comments= .  Attached please find the email replies to your review sent earlier.  The replies are copied inline below for= convenience, tagged with <RG00>.

     

     

    From: ippm= <ippm-bounce= s@ietf.org>
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG communit= y,

    I've reviewed these drafts and have some comm= ents to share. Below, please find my thoughts on whether these drafts can b= e adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying=  draft targetted to the SPRING WG) are in the attached documents.=

     

    Usually, the bar for the adoption of a document= can be evaluated by answers to these three questions:

    ·=   Is the document(s) reasonably well-written=

    I've got surprised that the drafts don't use th= e terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. = Also, many terms, e.g., Links, "congruent paths", are used in the= documents without proper definitions. Other than that both drafts are read= able and reasonably well-written.

     

    <RG00> We can c= hange Sender to Session-Sender and Reflector to Session-Reflector if it hel= ps. 

    GIM>> I believe that the consistency in= terminology between the core RFC and what is intended as its extension is = not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.

    <RG00> There ar= e many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) a= nd term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having = said that, we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs.= I think I need to clarify my questions. While a reference to any of RFCs y= ou've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced RFCs used the lower case form for the term "link". Can = these be used interchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with us= ing the term "congruent path" in these drafts (using ASCII-art):<= o:p>

                &nb= sp;          C---------D

                &nb= sp;        /            &= nbsp;    \

                A--= --B                   E--= ---F

                &nb= sp;        \            &= nbsp;     /

                &nb= sp;        G------------H

    Consider an SR tunnel from A to F that traver= ses the network as A-B-C-D-E-F. From the definition of "congruent"= ; as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the= mirror image of the other", path A-B-G-H-E-F is congruent to the SR t= unnel. But a packet of an active OAM intended to monitor a flow over the SR= tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts, direct loss measurement can be performed, as information collected f= rom node F. So, this example, in my opinion, illustrates two of my concerns= :

    • using a congruent path for an active OAM protocol may = produce information that does not reflect the condition experienced by the = monitored flow. It seems that the terminology should reflect the fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.

     

    ·=   Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     

    <RG00> There is= a requirement to measure performance delay as well as synthetic and direct= -mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

    GIM>> I agree with the requirement= s you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3= 3; years ago). I believe that there's no sufficient technical reason t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. =

     

    ·=   Is the proposed solution technically viable?

    There are too many unaddressed aspects, particu= larly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     

    <RG00> About yo= ur comment on zero checksum, this is described in Security section in RFC 6= 936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

    GIM>> I don't think that a mere referen= ce sufficiently explains why the use of zero UDP checksum in IPv6 header is= not decremental, does not create a security risk for the protocol.

     

    Thanks,

    Rakesh

     

     

    Regards,=

    Greg

     

     

     

     

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

     

    For the past few meetings, we’ve had up= dates on the work in the SPRING WG that was using STAMP and TWAMP. Since th= ose documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be= best to split the documents and track the IPPM extension work in the IPPM = WG.

     

    As such, we are starting a Working Group call= for adoption for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-s= tamp-srpm.

     

    Please provide your feedback on these documen= ts, and state whether or not you believe the IPPM WG should adopt this work= by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, Nov= ember 16.

     

    Best,

    Tommy & Ian

    _____________________________________________= __
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_02323949c3d9479a92c674a676f366aehuaweicom_-- From nobody Thu Nov 19 18:32:46 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A103A169C; Thu, 19 Nov 2020 18:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FHoDlTIZ65KK; Thu, 19 Nov 2020 18:32:43 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4FBC23A169A; Thu, 19 Nov 2020 18:32:43 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id u19so11298582lfr.7; Thu, 19 Nov 2020 18:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hBBQC1vlYpQwT4+Cke71Eq+DzLBjD/8q92f0Yh4mzpY=; b=NAGibAjAAwZWVArhUcmIg1pZenhA1AivKE08g/C4z+pprL9CMB1rjABt6crnU5Hf2e wmZfoNGUWqWdPzgZJR5ZVRsicwQK2nGmqTGqO15v6XeDtNVXC8+IJWxaukzwUab7N5kd 0Fi801kIPm3747Zhz63WPmOBA/G5wHYvDKkMD9ePNAzqwvMdx1euJBgyJa9shtQQVc5J q9HK2fTCVqCR9L80kzlTTOxkYtHILBEqj8x18K+FAeWLarsmsmQtUjlVEyCkNwYf3MXI 4jgaWPj04y3qGF15/1GFWRJg5P04DIGM5FQQyez9VLyn2KcNCpkECrXThJjF0ngcxso+ aWLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hBBQC1vlYpQwT4+Cke71Eq+DzLBjD/8q92f0Yh4mzpY=; b=lZaNP/yKaB+Y8pDEFZwEkzE4CTv9AYZ+r33MzQciE6EBMNt9Uuj13cmB7rvhogXTfP PLwYmPS3/pSbNgVL2DO/rmjx+MLOwXwVymXkz+C20kP4Hnu69crF3+mR0rQ0nXzWW4mn RnlPavfR/zhcevkbNA16r5IvhkPEGBVCR9ecz1qFSgtyfanuuKbA0bODWdIXdDo9Wcm9 avdkWBCZjoWky92yJp0kFYs8JNXKHgmP37uM2XDghCJJ529OJGDWhh2fp31zRvrROgok nWoLHZSozUVQBzxaio+e5R6OL2MKQSk2ytUh6qBmwlpsXDcCqQbWtlbdOjnl7zdvpwmw KyCg== X-Gm-Message-State: AOAM530umR31zQ0ichLw9yW29t1si76pbx05bU+OY2NB/8ytGG1ODFKI 8eA0oxO3n0N95AszAnvzl+Myeen7TNrQJwRd5OBcexavr2YCsQ== X-Google-Smtp-Source: ABdhPJxXluhRMXeTDgkDXwYaiTXFhFRylH1iO61MFODKK+2Kfik2kKFn6+WdtlauYA2dw1GAt+zU7qsOs9+OLxDFPQE= X-Received: by 2002:a19:f243:: with SMTP id d3mr6360499lfk.534.1605839561162; Thu, 19 Nov 2020 18:32:41 -0800 (PST) MIME-Version: 1.0 References: <08c001d6b8d3$010d08d0$03271a70$@com> In-Reply-To: <08c001d6b8d3$010d08d0$03271a70$@com> From: Greg Mirsky Date: Thu, 19 Nov 2020 18:32:30 -0800 Message-ID: To: Weiqiang Cheng Cc: spring , srcomp , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009c080305b480a814" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 02:32:46 -0000 --0000000000009c080305b480a814 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Weiqiang, members of the DT, thank you for volunteering your time and expertise to this important for the further development of the SR project. Please find my notes and questions below: - my first question is on the intended scope of the document. As I can understand from the title, abstract, the scope is "the requirements for solutions to compress SRv6 SID lists". When I compare that with what was= in the charter of the DT in the announcement by our chairs : ... the requirements for solutions to compressing segment routing information for use over IPv6. Though the difference in texts might seems as small, the scopes they identify differ significantly. To me, it seems as the scope of the draft is targeted to only one possible solution to provide SR over IPv6 functionality, the SRH. Does the DT plan to expand the scope of the draft to match it to its charter? - It appears that in order to qualify whether a proposed compression method complies with the requirement in 3.1.2 an agreement b= y the WG on the benchmarking method is required because metrics listed, in= my view, are platform-dependent. - Though I can appreciate your consideration and using SHOULD in requirement 3.1.3, I don't find it particularly important to be included= in the list. After all, it is a matter of the art of implementation. - I think I cannot agree the SID summarization is the only viable technique for the interdomain SR. Replacing MUST with SHOULD might be reasonable, And preferably adding an informative text to describe alternative methods to support the interdomain SR. - I think I understand the intention of the requirement in Section 4.2.1 but I may propose expressing it differently: A path traversed using a list of compressed SIDs MUST always be the same as the path traversed using the list of uncompressed SIDs if no compression was applied. - I think that the use of MUST in requirement 5.1 is too strong. Firstly, such compatibility is not essential in a greenfield scenario. Secondly, the control plane based solution might be envisioned to coordinate the interworking between SR domains using SRv6 and not using = the SRv6 technique. And in the conclusion, once again, many thanks to all the members of the Design Team for the job well done. Regards, Greg On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng < chengweiqiang@chinamobile.com> wrote: > Hi Group, > As you know, the SPRING Working Group set up an SR compression design tea= m > prior to IETF108. > The design team is to produce (rough) consensus (of the DT) outputs to th= e > WG on two related topics: > 1) What are the requirements for solutions to compressing segment routing > information for use over IPv6; > 2) A comparison of proposed approaches to compressing segment routing > information for use over IPv6. > > With great effort of design team members, DT have finished the version -0= 0 > of the requirements document and have submitted it to datatracker. > > Please review it and let's know your comments. > > B.R. > Weiqiang Cheng > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 = 16:32 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Chen= g > =E4=B8=BB=E9=A2=98: New Version Notification for > draft-srcompdt-spring-compression-requirement-00.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-00.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 00 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-10-30 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-00.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -00 > > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > 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 > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000009c080305b480a814 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Weiqiang, members of the DT,
    thank you for volunt= eering your time and expertise to this important for the further developmen= t of the SR project. Please find my notes and questions below:
    • my first question is on the intended scope of the document. As I = can understand from the title, abstract, the scope is "the requirement= s for solutions to compress SRv6 SID lists". When I compare that with = what was in the charter of the DT in the announcement by our cha= irs:
    =C2=A0... the requirements for solutions to compressing s= egment routing information for use over IPv6.
    Though the differ= ence in texts might seems as small, the scopes they identify differ signifi= cantly. To me, it seems as the scope of the draft is targeted to only one p= ossible solution to provide SR over IPv6 functionality, the SRH. Does the D= T plan to expand the scope of the draft to match it to its charter?
    • It appears that in order to qualify whether a proposed c= ompression=C2=A0method complies with the requirement in 3.1.2 an agreement = by the WG on the benchmarking method is required because metrics listed, in= my view, are platform-dependent.
    • Though I can appreciate your cons= ideration and using SHOULD in requirement 3.1.3, I don't find it partic= ularly important to be included in the list. After all, it is a matter of t= he art of implementation.
    • I think I cannot agree the SID summarizat= ion is the only viable technique for the interdomain SR. Replacing MUST wit= h SHOULD might be reasonable, And preferably adding an informative text to = describe alternative methods to support the interdomain SR.
    • I think= I understand the intention of the requirement in Section 4.2.1 but I may p= ropose expressing it differently:
    A path traversed using a list of compressed= SIDs MUST always be the same as the path traversed using the list of uncom= pressed SIDs if no compression was applied.
    • I think= that the use of MUST in requirement 5.1 is too strong. Firstly, such compa= tibility is not essential in a greenfield scenario. Secondly, the control p= lane based solution might be envisioned to coordinate the interworking betw= een SR domains using SRv6 and not using the SRv6 technique.
    And in= the conclusion, once again, many thanks to all the members of the Design T= eam for the job well done.

    Regards,
    Greg
    =

    = On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng <chengweiqiang@chinamobile.com> wrote:
    Hi Group,
    As you know, the SPRING Working Group set up an SR compression design team = prior to IETF108.
    The design team is to produce (rough) consensus (of the DT) outputs to the = WG on two related topics:
    1) What are the requirements for solutions to compressing segment routing i= nformation for use over IPv6;
    2) A comparison of proposed approaches to compressing segment routing infor= mation for use over IPv6.

    With great effort of design team members, DT have finished the version -00 = of the requirements document and have submitted it to datatracker.

    Please review it and let's know your comments.

    B.R.
    Weiqiang Cheng


    -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
    =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 16= :32
    =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Cheng<= br> =E4=B8=BB=E9=A2=98: New Version Notification for draft-srcompdt-spring-comp= ression-requirement-00.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt<= br> has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-srcompdt-spring-compres= sion-requirement
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Compressed SRv6 SID List Requireme= nts
    Document date:=C2=A0 2020-10-30
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-srcompd= t-spring-compression-requirement-00.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-srcompdt-spring-= compression-requirement/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-srcompdt-spr= ing-compression-requirement
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-srcompdt-spring-compression-r= equirement-00


    Abstract:
    =C2=A0 =C2=A0This document specifies requirements for solutions to compress= SRv6
    =C2=A0 =C2=A0SID lists.




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

    The IETF Secretariat





    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --0000000000009c080305b480a814-- From nobody Thu Nov 19 21:10:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635443A1785; Thu, 19 Nov 2020 21:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=g2yQHYgR; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=QibX1MNM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqlptkh7Sjhy; Thu, 19 Nov 2020 21:10:01 -0800 (PST) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.22]) (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 C825A3A177F; Thu, 19 Nov 2020 21:09:59 -0800 (PST) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 0AK59PJY006243; Fri, 20 Nov 2020 06:09:31 +0100 Received: from [192.168.1.89] (93-36-192-249.ip61.fastwebnet.it [93.36.192.249]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 64BF41212B5; Fri, 20 Nov 2020 06:09:20 +0100 (CET) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1605848960; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t09CT7xaifU/NfYb6t4/L6/pkoSGHose1NPTSP/KR0Q=; b=g2yQHYgRK8IHKxRXQky0CRtW9+b5NJS40L/Ol24b99y/sHgXx7rTkrtpbSPQDPSx+rfOTw WFlPbS7Iv6g1gTDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1605848960; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t09CT7xaifU/NfYb6t4/L6/pkoSGHose1NPTSP/KR0Q=; b=QibX1MNMDcTqXPZR+RltUWCsNMSkKwU6wbjGEVuvA9heyZtgvlZElGrWIk02TH53q9Zys+ NLLSF2ww3RW6Aarf0IiQ32nVBJjnTCrhWLSSXGiqv1WK/AODwId48OP4zXYxUROm7ThyD6 zr5Kce/jW9WqIoTnyv2JAUjB2PCmDncg/8apj7HeuIJDcp1Ewo02IScp9eWvH0D+YNUh1Y mSKZaUar+6Rfg2Yj6abRohYoXORf/yT42e9fzxNPDdSvWPdR1/vyjXm5LT9ud+hFtkkHdn d8gnhUVVFPAUQEH3/5y6SLazrUiabceAzuh0U6w2SeZ1pfKDcZZ8i5pl9ZF4nA== To: =?UTF-8?B?56iL5Lyf5by6?= , spring Cc: srcomp , "spring-chairs@ietf.o" References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> From: Stefano Salsano Message-ID: Date: Fri, 20 Nov 2020 06:09:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 05:10:04 -0000 Il 2020-11-15 16:27, 程伟强 ha scritto: > Hi Group, > > SR compression design team have submitted a new version of compression > requirement draft. > > Main changes as follows: > > - added 3 items about scalibility with agreement within the design team > > - added an appendix including 3 items without without unanimous > consensus within the design team Hi all, the the appendix A of latest draft version includes three items that should be taken into consideration, in particular: Requirement A.2.1. SRv6 Based Requirement A.2.2. SRv6 Functionality "A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane" and "A solution to compress an SRv6 SID list MUST support the functionality of SRv6" I've been working in the last 4 years on the open source ecosystem supporting SRv6, including the support of SRv6 in the Linux kernel (see https://netgroup.github.io/rose/) a lot of effort has been spent in this ecosystem that now offers a feature set comparable to vendors' implementation of SRv6 it is very important for the research community to have such ecosystem and it will be painful to rebuild the support for a new solution outside of the current SRv6 architecture... one of the problem of the MPLS architecture (from the research comunity point of wiew) was that the support in Linux has never been comparable to vendors's solution (e.g. for the control plane), for this reason the research work diverged a lot from production solutions, I really would like to avoid such gap again Requirement A.2.3. Heterogeneous SID lists "The compression proposal SHOULD support a combination of compressed and non-compressed segments in a single path." We have been working a lot on Service Function Chaining supported by SRv6, and we have use cases that require non-compressed segments to include arbitrary functions in the chain and provide them the needed information. It is very important to have the possibility to combine SFC with other features (e.g. traffic engineered paths) requiring compressed segments in a single "end-to-end" perspective. This would support end-to-end scenarios combining for example IoT at the edge, 5G access, metro/wan interconnection, SFC in the metro/wan, SFC in datacenter. This is only possible if compressed and non-compressed segments are combined. ciao Stefano > > - some minor text issue fixed > > Please review it and let us know your comments. > > > BTW: We will have 1-hour session for the design team topic on Friday and > welcome to join us. > > > B.R. > > Weiqiang on behalf of design team > > > ----邮件原文---- > å‘件人：internet-drafts  > 收件 > 人：Weiqiang Cheng ,Sander Steffann ,SJM Steffann  > 抄　é€: (æ— ) > å‘é€æ—¶é—´ï¼š2020-11-15 22:58:57 > 主题：New Version Notification for draft-srcompdt-spring-compression- > requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt > Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement > Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01 > > Abstract: >  This document specifies requirements for solutions to compress SRv6 >  SID lists. > > > > > 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 > > > > Subject：New Version Notification for draft-srcompdt-spring-compression- > requirement-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt > Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement > Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01 > > Abstract: >  This document specifies requirements for solutions to compress SRv6 >  SID lists. > > > > > 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 > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Thu Nov 19 21:48:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771143A18BE; Thu, 19 Nov 2020 21:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 AvgwAHKKKRAL; Thu, 19 Nov 2020 21:48:39 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 6FD653A18BD; Thu, 19 Nov 2020 21:48:39 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 6A9614DE038720F16AB9; Fri, 20 Nov 2020 13:48:36 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 47A7A7ECF8EBD11D5A6A; Fri, 20 Nov 2020 13:48:36 +0800 (CST) Received: from kjyxapp01.zte.com.cn ([10.30.12.200]) by mse-fl2.zte.com.cn with SMTP id 0AK5mZGk038589; Fri, 20 Nov 2020 13:48:35 +0800 (GMT-8) (envelope-from liu.aihua@zte.com.cn) Received: from mapi (kjyxapp01[null]) by mapi (Zmail) with MAPI id mid13; Fri, 20 Nov 2020 13:49:25 +0800 (CST) Date: Fri, 20 Nov 2020 13:49:25 +0800 (CST) X-Zmail-TransId: 2b035fb758e51b741bc6 X-Mailer: Zmail v1.0 Message-ID: <202011201349259850397@zte.com.cn> In-Reply-To: <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> References: 160545233786.30631.15366800831645495687@ietfa.amsl.com, 2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 0AK5mZGk038589 Archived-At: Subject: Re: [spring] =?utf-8?q?Fw=3ANew_Version_Notification_for_draft-srcom?= =?utf-8?q?pdt-spring-compression-requirement-01=2Etxt?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 05:48:42 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgV2VpcWlhbmcsDQoNCg0KVGhhbmtzIGZvciB5b3VyIG5ldyB2ZXJzaW9uIGRyYWZ0IGFuZCBo YXJkIHdvcmsgb24gRFQuDQoNCg0KDQpJIHRoaW5rIHRoZSBTUnY2IGNvbXByZXNzaW9uIGlzIHZl cnkgaW1wb3J0YW50IGVzcGVjaWFsbHkgZm9yIFNSdjYtVEUgd2l0aCBoZWF2eSBvdmVyaGVhZC4g DQoNCg0KQXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIEctU1J2NiBkcmFmdCwgSSB0aGluayB3ZSBz aG91bGQgZm9jdXMgb24gdGhpcyBTUnY2IHJlcXVpcmVtZW50cyBmb3IgY29uc2Vuc3VzIEFTQVAu IFRoYXQgd2lsbCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIHRoZSBuZXh0IHBoYXNlIHdvcmssIGluY2x1 ZGluZyBjb21wYXJpbmcgY3VycmVudCBzb2x1dGlvbnMgYW5kIGV4cGxvcmluZyB0aGlzIG1lY2hl bmlzbSBmb3IgbW9yZSBzY2VuZXJpb3MgYW5kIGFwcGxpY2F0aW9ucy4NCg0KDQoNCg0KDQoNClJl Z2FyZCwNCg0KDQpBaWh1YQ0KDQoNCg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7 tuS6uu+8mueoi+S8n+W8ug0K5pS25Lu25Lq677yac3ByaW5nOw0K5oqE6YCB5Lq677yac3Jjb21w O3NwcmluZy1jaGFpcnNAaWV0Zi5vOw0K5pelIOacnyDvvJoyMDIw5bm0MTHmnIgxNeaXpSAyMzoy OA0K5Li7IOmimCDvvJpbc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1h aWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0KDQpIaSBHcm91cCwNCg0KU1IgY29tcHJlc3Npb24gZGVzaWduIHRl YW0gaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBjb21wcmVzc2lvbiByZXF1aXJlbWVu dCBkcmFmdC4NCg0KTWFpbiBjaGFuZ2VzIGFzIGZvbGxvd3M6IA0KDQotIGFkZGVkIDMgaXRlbXMg YWJvdXQgc2NhbGliaWxpdHkgd2l0aCBhZ3JlZW1lbnQgd2l0aGluIHRoZSBkZXNpZ24gdGVhbSAN Cg0KLSBhZGRlZCBhbiBhcHBlbmRpeCBpbmNsdWRpbmcgMyBpdGVtcyB3aXRob3V0IHdpdGhvdXQg dW5hbmltb3VzIGNvbnNlbnN1cyB3aXRoaW4gdGhlIGRlc2lnbiB0ZWFtDQoNCi0gc29tZSBtaW5v ciB0ZXh0IGlzc3VlIGZpeGVkDQoNClBsZWFzZSByZXZpZXcgaXQgYW5kIGxldCB1cyBrbm93IHlv dXIgY29tbWVudHMuDQoNCg0KDQoNCkJUVzogV2Ugd2lsbCBoYXZlIDEtaG91ciBzZXNzaW9uIGZv ciB0aGUgZGVzaWduIHRlYW0gdG9waWMgb24gRnJpZGF5IGFuZCB3ZWxjb21lIHRvIGpvaW4gdXMu DQoNCg0KDQoNCkIuUi4NCg0KV2VpcWlhbmcgb24gYmVoYWxmIG9mIGRlc2lnbiB0ZWFtDQoNCg0K DQoNCiAtLS0t6YKu5Lu25Y6f5paHLS0tLQ0K5Y+R5Lu25Lq677yaaW50ZXJuZXQtZHJhZnRzIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQrmlLbku7bkurrvvJpXZWlxaWFuZyBDaGVuZyA8Y2hl bmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+LFNhbmRlciBTdGVmZmFubiA8c2FuZGVyQHN0ZWZm YW5uLm5sPixTSk0gU3RlZmZhbm4gPHNhbmRlckBzdGVmZmFubi5ubD4NCuaKhOOAgOmAgTogKOaX oCkNCuWPkemAgeaXtumXtO+8mjIwMjAtMTEtMTUgMjI6NTg6NTcNCuS4u+mimO+8mk5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJl cXVpcmVtZW50LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFdlaXFpYW5nIENoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24t cmVxdWlyZW1lbnQNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlDb21wcmVzc2VkIFNSdjYgU0lEIExp c3QgUmVxdWlyZW1lbnRzDQpEb2N1bWVudCBkYXRlOgkyMDIwLTExLTEzDQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0w MS50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lw0KSHRtbGl6ZWQ6IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50DQpIdG1saXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KRGlmZjog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KDQpBYnN0cmFjdDoNCiBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBjb21wcmVzcyBTUnY2DQogU0lE IGxpc3RzLg0KDQogDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNClN1YmplY3TvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBXZWlxaWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpS ZXZpc2lvbjoJMDENClRpdGxlOgkJQ29tcHJlc3NlZCBTUnY2IFNJRCBMaXN0IFJlcXVpcmVtZW50 cw0KRG9jdW1lbnQgZGF0ZToJMjAyMC0xMS0xMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJMTMNClVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQpTdGF0dXM6 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC8NCkh0bWxpemVkOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJl bWVudA0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDENCkRpZmY6IGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVx dWlyZW1lbnQtMDENCg0KQWJzdHJhY3Q6DQogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWly ZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3MgU1J2Ng0KIFNJRCBsaXN0cy4NCg0KIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0 --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkhp IFdlaXFpYW5nLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v 6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPlRoYW5rcyBmb3IgeW91ciBuZXcgdmVyc2lvbiBkcmFm dCBhbmQgaGFyZCB3b3JrIG9uIERULjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNnB4O2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij5JIHRoaW5rIHRoZSBTUnY2 IGNvbXByZXNzaW9uIGlzIHZlcnkgaW1wb3J0YW50IGVzcGVjaWFsbHkgZm9yIFNSdjYtVEUgd2l0 aCBoZWF2eSBvdmVyaGVhZC4mbmJzcDs8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNnB4O2ZvbnQt ZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij5BcyBvbmUgb2YgdGhlIGF1dGhv cnMgb2YgRy1TUnY2IGRyYWZ0LCBJIHRoaW5rIHdlIHNob3VsZCBmb2N1cyBvbiB0aGlzIFNSdjYg cmVxdWlyZW1lbnRzIGZvciBjb25zZW5zdXMgQVNBUC4gVGhhdCB3aWxsIGJlIHZlcnkgaGVscGZ1 bCBmb3IgdGhlIG5leHQgcGhhc2Ugd29yaywgaW5jbHVkaW5nIGNvbXBhcmluZyBjdXJyZW50IHNv bHV0aW9ucyBhbmQgZXhwbG9yaW5nIHRoaXMgbWVjaGVuaXNtJm5ic3A7Zm9yIG1vcmUgc2NlbmVy aW9zIGFuZCBhcHBsaWNhdGlvbnMuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPlJl Z2FyZCw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7 kSxNaWNyb3NvZnQgWWFIZWk7Ij5BaWh1YTwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9u dC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPjxicj48L3A+PGRpdj48ZGl2 IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9Inpo aXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6 IDI4cHg7IGJhY2tncm91bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFs aWduOiBjZW50ZXI7IiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8 L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9s LWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0i cGFkZGluZzogOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFu IGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj7nqIvkvJ/lvLo8Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmls ZS5jb20+PC9jaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbT48L3NwYW4+PC9kaXY+PGRpdj48 c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlUT1R4dCI+5pS25Lu25Lq677yaPC9zdHJvbmc+ PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5zcHJp bmc8c3ByaW5nQGlldGYub3JnPjs8L3NwcmluZ0BpZXRmLm9yZz48L3NwYW4+PC9kaXY+PGRpdj48 c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+ PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5zcmNv bXA8c3Jjb21wQGlldGYub3JnPjs8L3NyY29tcEBpZXRmLm9yZz48L3NwYW4+PHNwYW4gY2xhc3M9 InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5zcHJpbmctY2hhaXJzQGll dGYubzxzcHJpbmctY2hhaXJzQGlldGYub3JnPjs8L3NwcmluZy1jaGFpcnNAaWV0Zi5vcmc+PC9z cGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pel IOacnyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MTHmnIgxNeaXpSAyMzoyODwv c3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQi PuS4uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+W3Nw cmluZ10gRnc6TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJp bmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PC9zdHJvbmc+PC9zcGFuPjwvZGl2Pjwv ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGRpdj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5zcHJpbmcmbmJzcDttYWlsaW5nJm5ic3A7 bGlzdDxicj5zcHJpbmdAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmc8YnI+PGJyPjxwPkhpIEdyb3VwLDwvcD48cD5TUiBjb21wcmVzc2lvbiBk ZXNpZ24gdGVhbSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGNvbXByZXNzaW9uIHJl cXVpcmVtZW50IGRyYWZ0LjwvcD48cD5NYWluIGNoYW5nZXMgYXMgZm9sbG93czombmJzcDs8L3A+ PHA+LSBhZGRlZCAzIGl0ZW1zIGFib3V0IHNjYWxpYmlsaXR5Jm5ic3A7d2l0aCBhZ3JlZW1lbnQg d2l0aGluIHRoZSBkZXNpZ24gdGVhbSZuYnNwOzwvcD48cD4tJm5ic3A7YWRkZWQgYW4gYXBwZW5k aXgmbmJzcDtpbmNsdWRpbmcgMyBpdGVtcyB3aXRob3V0IHdpdGhvdXQgdW5hbmltb3VzIGNvbnNl bnN1cyB3aXRoaW4gdGhlIGRlc2lnbiB0ZWFtPC9wPjxwPi0gc29tZSBtaW5vciB0ZXh0IGlzc3Vl IGZpeGVkPC9wPjxwPlBsZWFzZSByZXZpZXcgaXQgYW5kIGxldCB1cyBrbm93IHlvdXIgY29tbWVu dHMuPC9wPjxwPjxicj48L3A+PHA+QlRXOiBXZSB3aWxsIGhhdmU8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7Ij4mbmJzcDsxLWhvdXIg c2Vzc2lvbiBmb3IgdGhlIGRlc2lnbiB0ZWFtIHRvcGljPC9zcGFuPjwvc3Bhbj4mbmJzcDtvbiBG cmlkYXkgYW5kIHdlbGNvbWUgdG8gam9pbiB1cy48L3A+PHA+PGJyPjwvcD48cD5CLlIuPC9wPjxw PldlaXFpYW5nIG9uIGJlaGFsZiBvZiBkZXNpZ24gdGVhbTwvcD48cD48YnI+PC9wPiZuYnNwOzxw Pi0tLS3pgq7ku7bljp/mloctLS0tPGJyPuWPkeS7tuS6uu+8mmludGVybmV0LWRyYWZ0cyZuYnNw OyZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7PGJyPuaUtuS7tuS6uu+8mldlaXFpYW5n Jm5ic3A7Q2hlbmcmbmJzcDsmbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7LFNh bmRlciZuYnNwO1N0ZWZmYW5uJm5ic3A7Jmx0O3NhbmRlckBzdGVmZmFubi5ubCZndDssU0pNJm5i c3A7U3RlZmZhbm4mbmJzcDsmbHQ7c2FuZGVyQHN0ZWZmYW5uLm5sJmd0Ozxicj7mioTjgIDpgIE6 Jm5ic3A7KOaXoCk8YnI+5Y+R6YCB5pe26Ze077yaMjAyMC0xMS0xNSZuYnNwOzIyOjU4OjU3PGJy PuS4u+mimO+8mk5ldyZuYnNwO1ZlcnNpb24mbmJzcDtOb3RpZmljYXRpb24mbmJzcDtmb3ImbmJz cDtkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJy Pjxicj48YnI+QSZuYnNwO25ldyZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO0ktRCwmbmJzcDtk cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPmhh cyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQmbmJzcDtieSZuYnNw O1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJzcDtwb3N0ZWQmbmJzcDt0byZuYnNwO3Ro ZTxicj5JRVRGJm5ic3A7cmVwb3NpdG9yeS48YnI+PGJyPk5hbWU6CQlkcmFmdC1zcmNvbXBkdC1z cHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQ8YnI+UmV2aXNpb246CTAxPGJyPlRpdGxlOgkJ Q29tcHJlc3NlZCZuYnNwO1NSdjYmbmJzcDtTSUQmbmJzcDtMaXN0Jm5ic3A7UmVxdWlyZW1lbnRz PGJyPkRvY3VtZW50Jm5ic3A7ZGF0ZToJMjAyMC0xMS0xMzxicj5Hcm91cDoJCUluZGl2aWR1YWwm bmJzcDtTdWJtaXNzaW9uPGJyPlBhZ2VzOgkJMTM8YnI+VVJMOiZuYnNwO2h0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50LTAxLnR4dDxicj5TdGF0dXM6Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lzxicj5I dG1saXplZDombmJzcDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDxicj5IdG1saXplZDombmJz cDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50LTAxPGJyPkRpZmY6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVu dC0wMTxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwO1RoaXMmbmJzcDtkb2N1bWVudCZuYnNwO3Nw ZWNpZmllcyZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO2ZvciZuYnNwO3NvbHV0aW9ucyZuYnNwO3Rv Jm5ic3A7Y29tcHJlc3MmbmJzcDtTUnY2PGJyPiZuYnNwO1NJRCZuYnNwO2xpc3RzLjxicj48YnI+ Jm5ic3A7PGJyPjxicj48YnI+UGxlYXNlJm5ic3A7bm90ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNw O21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxlJm5ic3A7b2YmbmJzcDttaW51dGVzJm5i c3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtvZiZuYnNwO3N1Ym1pc3Npb248YnI+dW50 aWwmbmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZm Jm5ic3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48YnI+ PGJyPlRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDxicj48YnI+PGJyPjxicj5TdWJqZWN0 77yaTmV3Jm5ic3A7VmVyc2lvbiZuYnNwO05vdGlmaWNhdGlvbiZuYnNwO2ZvciZuYnNwO2RyYWZ0 LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8YnI+PGJyPjxi cj5BJm5ic3A7bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LXNy Y29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8YnI+aGFzJm5ic3A7 YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7V2VpcWlh bmcmbmJzcDtDaGVuZyZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZuYnNwO3RvJm5ic3A7dGhlPGJyPklF VEYmbmJzcDtyZXBvc2l0b3J5Ljxicj48YnI+TmFtZToJCWRyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudDxicj5SZXZpc2lvbjoJMDE8YnI+VGl0bGU6CQlDb21wcmVz c2VkJm5ic3A7U1J2NiZuYnNwO1NJRCZuYnNwO0xpc3QmbmJzcDtSZXF1aXJlbWVudHM8YnI+RG9j dW1lbnQmbmJzcDtkYXRlOgkyMDIwLTExLTEzPGJyPkdyb3VwOgkJSW5kaXZpZHVhbCZuYnNwO1N1 Ym1pc3Npb248YnI+UGFnZXM6CQkxMzxicj5VUkw6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQt MDEudHh0PGJyPlN0YXR1czombmJzcDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQvPGJyPkh0bWxpemVk OiZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21w ZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PGJyPkh0bWxpemVkOiZuYnNwO2h0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24t cmVxdWlyZW1lbnQtMDE8YnI+RGlmZjombmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxPGJy Pjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7c3BlY2lmaWVz Jm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7Zm9yJm5ic3A7c29sdXRpb25zJm5ic3A7dG8mbmJzcDtj b21wcmVzcyZuYnNwO1NSdjY8YnI+Jm5ic3A7U0lEJm5ic3A7bGlzdHMuPGJyPjxicj4mbmJzcDs8 YnI+PGJyPjxicj5QbGVhc2UmbmJzcDtub3RlJm5ic3A7dGhhdCZuYnNwO2l0Jm5ic3A7bWF5Jm5i c3A7dGFrZSZuYnNwO2EmbmJzcDtjb3VwbGUmbmJzcDtvZiZuYnNwO21pbnV0ZXMmbmJzcDtmcm9t Jm5ic3A7dGhlJm5ic3A7dGltZSZuYnNwO29mJm5ic3A7c3VibWlzc2lvbjxicj51bnRpbCZuYnNw O3RoZSZuYnNwO2h0bWxpemVkJm5ic3A7dmVyc2lvbiZuYnNwO2FuZCZuYnNwO2RpZmYmbmJzcDth cmUmbmJzcDthdmFpbGFibGUmbmJzcDthdCZuYnNwO3Rvb2xzLmlldGYub3JnLjxicj48YnI+VGhl Jm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0PGJyPjxicj48YnI+PGJyPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Thu Nov 19 21:49:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B43A18BD; Thu, 19 Nov 2020 21:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A0SaBSrxehEr; Thu, 19 Nov 2020 21:48:57 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 244013A191C; Thu, 19 Nov 2020 21:48:54 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id q28so6391326pgk.1; Thu, 19 Nov 2020 21:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:message-id:date :to:cc; bh=I5o9oOLokiwtPJclGhdIQFimTRgggEhndWv8Wjx70Yg=; b=tUQs+R0EKOyZU1r8cpmmw83sFWyjaUez3KF8Ypz9+JiKzEIv977ZpZzCUtvRARq9Ls c4sZX1Vp7JEaTI9WYJV98Ivy9QG1IaXCo1hxyxUjMKoLMj7rTQnDV3ltOOdCSidk549I +vbAISxBs8kq5h7W3F0exPynaxZWm7Rkzo41N0EPbHHXfmJr/VKb71tL8LTYJUw4nBhF X5RjeErFsW/DaH0oL8YXhw1Tw3TpZUfkz3bUY7C+pWAD8ANGJni+hF5ltKo5e+2ygklo cQrQOVNK2yYf5wUb2lr63iCo3clTM2B+iHN6Mz/WxpIukX1UWOExLirVbDiQPEXZWh5t PZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:to:cc; bh=I5o9oOLokiwtPJclGhdIQFimTRgggEhndWv8Wjx70Yg=; b=ba91y7XjMZSNF/Fr2aGc+RiNK0z+2GXaiRd75L+Jxs3uIl5wVCtL9U3V8rdydKbXA1 +4yJ66fB+RjN3Xd7iVF2tu7yIpHq9B4hclHkYtbwtiKbfHhvNm//TmFxw32DnENGAFuP wV9H8YOAcTKy3HOPAr2WT3emXqnAt0YH59lJgFdBADKKaWsjZCQsresF0zlMD1NHFJiV xkTirCmScgjzF0lipaSkvDquF/qc3WF7h63FSLz8TGbYrOs0cJ9NXKqq7eWlVhn6McyU E7v8bLmQQHHSmx8Z9EIFWc9eIdQVGGA+8azYKq8di8PyzeVeKgKM0EQ8Ayz+S5y15HSK 1JrA== X-Gm-Message-State: AOAM531xrD4OkEwJ6nDNi0v3Ch1/ag+uXbr+Be+D2RWOYVWvcQZEZImJ ConnJf957zjsrckhre4Aa9hEmpFrfcU= X-Google-Smtp-Source: ABdhPJx0jVpKMCpm9pRktRqmNPnedsx+9uQW7CiKShoeb7wngE/JBRze8/yQUF77oMaTVDik3LC71g== X-Received: by 2002:a05:6a00:4d:b029:197:7198:fc37 with SMTP id i13-20020a056a00004db02901977198fc37mr11671659pfk.7.1605851333543; Thu, 19 Nov 2020 21:48:53 -0800 (PST) Received: from [192.168.86.33] (108-221-21-153.lightspeed.sntcca.sbcglobal.net. [108.221.21.153]) by smtp.gmail.com with ESMTPSA id b29sm2007124pff.194.2020.11.19.21.48.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 21:48:52 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-09E43ABB-54B0-403B-9305-E286B2148737 Content-Transfer-Encoding: 7bit From: Gaurav Dawra Mime-Version: 1.0 (1.0) Message-Id: <19F9655E-04BB-408F-A13D-342486CFAF28@gmail.com> Date: Thu, 19 Nov 2020 21:48:51 -0800 To: Dirk Steinberg Cc: spring@ietf.org, srcomp , spring-chairs@ietf.org X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 05:49:02 -0000 --Apple-Mail-09E43ABB-54B0-403B-9305-E286B2148737 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BF +1 - I agree with Dirk and others. The industry has been working on SRv6 for multiple years with technology bei= ng quite mature. The requirements listed in the appendix are fully justified from a technical= and deployment point of view. I support the requirements based on the SRv6 control plane and data plane ex= isting standards and works well with or without compression. Gaurav > On Nov 19, 2020, at 7:47 AM, Dirk Steinberg wrote: > =EF=BB=BF > Hello SPRING WG, >=20 > I have read the SRComp design team requirements draft=20 > and would like to comment. >=20 > I truly believe that a SID compression scheme MUST integrate into the=20 > existing SRv6 framework. Otherwise it does not make much sense,=20 > or said another way, it will not be a SID compression scheme for SRv6=20 > at all but another animal altogether. >=20 > SID compression should be used where the use case justifies it, i.e. > strict path TE inside a given domain. Inter-Domain usage of SRv6, > especially end systems in data centers, may have different requirements > and thus decide to use uncompressed SRv6 SIDs. It is important that > a SID list that describes a service that spans across multiple domains > be able to contain both compressed and uncompressed SIDs.=20 > Consequently, the same CP needs to support both compressed and=20 > uncompressed SIDs. >=20 > I am currently working on an architecture based on SRv6 for different=20 > domains within a carrier network. These domains have different=20 > requirements and also different hardware capabilities that may lead=20 > to different designs for each subnetwork. But all these domains/ > subnetworks must be able to interoperate seamlessly based on SRv6 > standards, regardless of whether SID compression is used or not. >=20 > Therefore I strongly agree that Appendix A should be part of the draft. >=20 > I would also like to suggest another requirement: > IMHO the single biggest advantage that SRv6 has compared to=20 > MPLS is aggregation (route summarization), something that is > absolutely not possible with MPLS labels (SIDs). > Aggregation (CIDR) is the very technology that has enabled the Internet=20= > to scale and to become the worldwide internetwork that it is today.=20 > In retrospect I believe the omission of aggregation has been the=20 > biggest design mistake in MPLS -- but back then there were a lot=20 > of other factors and the idea to use a very short tag for forwarding.=20 > After all Tag Switching and MPLS were inspired from ATM=20 > and within this context aggregation made no sense. >=20 > Consequently I propose to add to the draft the requirement that the > SID compression scheme MUST be compatible with aggregation, > i.e. it must be possible to express the reachability of a given set of > SIDs (maybe in some domain or data center) using a summary prefix. >=20 > Thanks and Cheers > Dirk >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Nov 19, 2020 at 3:21 PM Ahmed Bashand w= rote: >> I also agree that the requirements in Appendix A should be part of the dr= aft. Having of existing standard as a basis greatly simplifies the developme= nt and deployment of any compression scheme=20 >>=20 >>=20 >>=20 >> Thanks >>=20 >>=20 >> Ahmed >>=20 >>=20 >>=20 >>=20 >>=20 >> On 11/19/20 12:58 AM, Ran Pang(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E4=B8= =AD=E5=9B=BD=E8=81=94=E9=80=9A=E7=A0=94=E7=A9=B6=E9=99=A2-=E6=9C=AC=E9=83=A8= ) wrote: >>> Hi Weiqiang and WG,=20 >>> I read the draft and agree with the requirements specified in it.I t= hink the requirements in Appendix A should be part of the draft in the next v= ersion. >>> China Unicom is working on a network evolution plan for SRv6 now, a= nd we have done some field trials based on SRv6. In order to maintain the co= ntinuity of the functionality, we suggest the solution based on the SRv6 st= andards. >>>=20 >>> Best regards, >>> Pang Ran >>> =20 >>> From: =E7=A8=8B=E4=BC=9F=E5=BC=BA >>> Date: 2020-11-15 23:27 >>> To: spring >>> CC: srcomp; spring-chairs@ietf.o >>> Subject: [spring] Fw:New Version Notification for draft-srcompdt-spring-= compression-requirement-01.txt >>> Hi Group, >>>=20 >>> SR compression design team have submitted a new version of compression r= equirement draft. >>>=20 >>> Main changes as follows:=20 >>>=20 >>> - added 3 items about scalibility with agreement within the design team=20= >>>=20 >>> - added an appendix including 3 items without without unanimous consensu= s within the design team >>>=20 >>> - some minor text issue fixed >>>=20 >>> Please review it and let us know your comments. >>>=20 >>>=20 >>>=20 >>> BTW: We will have 1-hour session for the design team topic on Friday and= welcome to join us. >>>=20 >>>=20 >>>=20 >>> B.R. >>>=20 >>> Weiqiang on behalf of design team >>>=20 >>>=20 >>>=20 >>> =20 >>> ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts >>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng ,Sander Steffann ,SJM Steffann >>> =E6=8A=84=E3=80=80=E9=80=81: (=E6=97=A0) >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:58:57 >>> =E4=B8=BB=E9=A2=98=EF=BC=9ANew Version Notification for draft-srcompdt-s= pring-compression-requirement-01.txt >>>=20 >>>=20 >>> A new version of I-D, draft-srcompdt-spring-compression-requirement-01.t= xt >>> has been successfully submitted by Weiqiang Cheng and posted to the >>> IETF repository. >>>=20 >>> Name: draft-srcompdt-spring-compression-requirement >>> Revision: 01 >>> Title: Compressed SRv6 SID List Requirements >>> Document date: 2020-11-13 >>> Group: Individual Submission >>> Pages: 13 >>> URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-r= equirement-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compressi= on-requirement/ >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-co= mpression-requirement >>> Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-= requirement-01 >>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compress= ion-requirement-01 >>>=20 >>> Abstract: >>> This document specifies requirements for solutions to compress SRv6 >>> SID lists. >>>=20 >>> =20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submis= sion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>> Subject=EF=BC=9ANew Version Notification for draft-srcompdt-spring-compr= ession-requirement-01.txt >>>=20 >>>=20 >>> A new version of I-D, draft-srcompdt-spring-compression-requirement-01.t= xt >>> has been successfully submitted by Weiqiang Cheng and posted to the >>> IETF repository. >>>=20 >>> Name: draft-srcompdt-spring-compression-requirement >>> Revision: 01 >>> Title: Compressed SRv6 SID List Requirements >>> Document date: 2020-11-13 >>> Group: Individual Submission >>> Pages: 13 >>> URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-r= equirement-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compressi= on-requirement/ >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-co= mpression-requirement >>> Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-= requirement-01 >>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compress= ion-requirement-01 >>>=20 >>> Abstract: >>> This document specifies requirements for solutions to compress SRv6 >>> SID lists. >>>=20 >>> =20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submis= sion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> =E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF=E6=8E=A5=E6=94=B6=E4=BA=86= =E8=AF=A5=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9=80=9A=E8=BF=87=E7=94=B5=E5=AD= =90=E9=82=AE=E4=BB=B6=E7=AB=8B=E5=8D=B3=E9=80=9A=E7=9F=A5=E6=88=91=E4=BB=AC=E3= =80=82=E8=AF=B7=E5=9B=9E=E5=A4=8D=E9=82=AE=E4=BB=B6=E5=88=B0 hqs-spmc@chinau= nicom.cn=EF=BC=8C=E5=8D=B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD=A4=E9=82= =AE=E4=BB=B6=E3=80=82=E6=88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3=E5=B0=86=E6= =82=A8=E7=9A=84=E4=BF=A1=E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7=9A=84=E5=8F=91= =E9=80=81=E7=9B=AE=E5=BD=95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80=82 If you have r= eceived this email in error please notify us immediately by e-mail. Please r= eply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will= immediately remove your information from send catalogue of our.=20 >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-09E43ABB-54B0-403B-9305-E286B2148737 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    =EF=BB=BF

    +1 - I agree with Dirk and others.


    =

    The industry has been working on SRv6 for multiple years w= ith technology being quite mature.


    The requirements listed in the appendix are fully justified from a t= echnical and deployment point of view.


    I suppo= rt the requirements based on the SRv6 control plane and data plane exis= ting standards and works well with or without compression.



    On Nov 19,= 2020, at 7:47 AM, Dirk Steinberg <dirk@lapishills.com> wrote:

    =
    =EF=BB=BF Hello SPRING WG,

    I have read the SRComp des= ign team requirements draft 
    and would like to comment.
    =

    I truly believe that a SID compression scheme MUST i= ntegrate into the 
    existing SRv6 framework. Otherwise it does= not make much sense, 
    or said another way, it will not be a S= ID compression scheme for SRv6 
    at all but another animal alt= ogether.

    SID c= ompression should be used where the use case justifies it, i.e.
    st= rict path TE inside a given domain. Inter-Domain usage of SRv6,
    especially end systems in data centers, may have different requirements
    and thus decide to use uncompressed SRv6 SIDs. It is important that=
    a SID list that describes a service that spans across multip= le domains
    be able to contain both compressed and uncompresse= d SIDs. 
    Consequently, the same CP needs to support both comp= ressed and 
    uncompressed SIDs.

    I am c= urrently working on an architecture based on SRv6 for different 
    <= div>domains within a carrier network. These domains have different 
    requirements and also different hardware capabilities that may lead&n= bsp;
    to different designs for each subnetwork. But all these domai= ns/
    subnetworks must be able to interoperate seamlessly based on S= Rv6
    standards, regardless of whether SID compression is used or no= t.

    Therefore I strongly agree that Appendix A shoul= d be part of the draft.

    I would also like to sugges= t another requirement:
    IMHO the single biggest advantage that SRv6= has compared to 
    MPLS is aggregation (route summarization), s= omething that is
    absolutely not possible with MPLS labels (SI= Ds).
    Aggregation (CIDR) is the very technology that has enabled th= e Internet 
    to scale and to become the worldwide internetwork= that it is today. 
    In retrospect I believe the omission of a= ggregation has been the 
    biggest design mistake in MPLS -- bu= t back then there were a lot 
    of other factors and the idea t= o use a very short tag for forwarding. 
    After all Tag Sw= itching and MPLS were inspired from ATM 
    and within this cont= ext aggregation made no sense.

    Consequently I propo= se to add to the draft the requirement that the
    SID compression sc= heme MUST be compatible with aggregation,
    i.e. it must be possible= to express the reachability of a given set of
    SIDs (maybe in some= domain or data center) using a summary prefix.

    Thanks and Cheers
    Dirk


    =



    On Thu, Nov 19, 2020 at 3:21 PM Ahmed= Bashand <abashandy.ietf@gmai= l.com> wrote:

    I also agree that the requirements in Appendix A should be part o= f the draft. Having of existing standard as a basis greatly simplifies the d= evelopment and deployment of any compression scheme


    Th= anks


    Ahmed



    On 11/19/20 12:58 AM, Ran= Pang(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E4=B8=AD=E5=9B=BD=E8=81=94=E9=80=9A= =E7=A0=94=E7=A9=B6=E9=99=A2-=E6=9C=AC=E9=83=A8) wrote:
    Hi Weiqiang and WG, 
    &nb= sp;   I read the draft and agree with the requirements spec= ified in it.I t= hink the requirements in Appendix A should be part of the draft in the next v= ersion.
        China Unico= m is working on a network evolution plan for SRv6 now,  and we have don= e some field trials based on SRv6. In order to maintain the continuity of  = the functionality, we suggest the solution based on the SRv6 standards.

    Best regards,
    Pang Ran
     
    <= div>Date: 2020-11-15 23:27
    To: spring
    Subject: [spring] Fw:New Version Notification for= draft-srcompdt-spring-compression-requirement-01.txt
    =

    Hi Group,

    SR compression design team have submitted a new vers= ion of compression requirement draft.

    Main changes as follows: 

    - added 3 items about scalibility with agreement within the design= team 

    - added an appendix including 3 items without wi= thout unanimous consensus within the design team

    - some minor text iss= ue fixed

    Please review it and let us know your comments.


    BTW: We will have&n= bsp;1-hour session for the design team topic on Friday an= d welcome to join us.


    B.R.

    Weiqiang on behalf of desi= gn team


    &n= bsp;

    ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----
    =E5=8F=91=E4=BB= =B6=E4=BA=BA=EF=BC=9Ainternet-drafts <internet-drafts@ietf.org>
    =E6=94=B6= =E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng <chengweiqiang@chinamobile.com= >,Sander Steffann <sander@steffann.nl>,SJM Steffann <sander@steffann.nl><= /a>
    =E6=8A=84=E3=80=80=E9=80=81: (=E6=97=A0)
    =E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:58:57
    =E4=B8=BB=E9=A2=98=EF=BC= =9ANew Version Notification for draft-srcompdt-spring-co= mpression-requirement-01.txt


    A new version of = ;I-D, draft-srcompdt-spring-compression-requirement-01.txt
    has = been successfully submitted by Weiqiang Cheng = and posted to the
    IETF repository.

    Name: draft= -srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compresse= d SRv6 SID List Requirements
    Document date: 2020= -11-13
    Group: Individual Submission
    Pages: 13
    URL:     https://www.ietf.org/archive/id/draft-srcom= pdt-spring-compression-requirement-01.txt
    Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-c= ompression-requirement/
    Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compress= ion-requirement
    Htmlized: https:/= /tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01Diff: https://www.ietf.org/rfcd= iff?url2=3Ddraft-srcompdt-spring-compression-requirement-01

    Abstr= act:
     This document specifies requirements for&n= bsp;solutions to compress SRv6
     SID lists.
     


    Please note that it may take&nb= sp;a couple of minutes from the time of&n= bsp;submission
    until the htmlized version and di= ff are available at tools.ietf.org.

    The IETF Secretariat


    Subject=EF=BC=9ANew Version Notification for&nbs= p;draft-srcompdt-spring-compression-requirement-01.txt


    A new=  version of I-D, draft-srcompdt-spring-compression-requi= rement-01.txt
    has been successfully submitted by = ;Weiqiang Cheng and posted to the
    IETF repo= sitory.

    Name: draft-srcompdt-spring-compression-requirement
    Revisi= on: 01
    Title: Compressed SRv6 SID List RequirementsDocument date: 2020-11-13
    Group: Individual Submission
    Pag= es: 13
    URL: https://www.ietf.= org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
    S= tatus: https://datatracker.ietf.org/d= oc/draft-srcompdt-spring-compression-requirement/
    Htmlized: https://datatracker.ietf.org/doc/html/draf= t-srcompdt-spring-compression-requirement
    Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compres= sion-requirement-01
    Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requi= rement-01

    Abstract:
     This document specifies&nb= sp;requirements for solutions to compress SRv6
    &= nbsp;SID lists.

     


    Please note that&nbs= p;it may take a couple of minutes from&nb= sp;the time of submission
    until the htmlized&nbs= p;version and diff are available at tools.ietf.org.

    The&nbs= p;IETF Secretariat



    =E5=A6=82= =E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF=E6=8E=A5=E6=94=B6=E4=BA=86=E8=AF=A5=E9=82= =AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9=80=9A=E8=BF=87=E7=94=B5=E5=AD=90=E9=82=AE=E4= =BB=B6=E7=AB=8B=E5=8D=B3=E9=80=9A=E7=9F=A5=E6=88=91=E4=BB=AC=E3=80=82=E8=AF=B7= =E5=9B=9E=E5=A4=8D=E9=82=AE=E4=BB=B6=E5=88=B0 hqs-spmc@chinaunicom.cn=EF=BC=8C=E5=8D= =B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD=A4=E9=82=AE=E4=BB=B6=E3=80=82=E6= =88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3=E5=B0=86=E6=82=A8=E7=9A=84=E4=BF=A1= =E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7=9A=84=E5=8F=91=E9=80=81=E7=9B=AE=E5=BD= =95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80=82 If you have received this email in e= rror please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your= information from send catalogue of our. 
    ____=
___________________________________________
spring mailing list
spring@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/spring
    _______________________________________________
    = spring mailing list
    = spring@ietf.org
    https://www.ietf.org/mailman/listin= fo/spring
    _______________________________________________
    spring= mailing list
    spring@ietf.org
    https://www.ie= tf.org/mailman/listinfo/spring
    = --Apple-Mail-09E43ABB-54B0-403B-9305-E286B2148737-- From nobody Thu Nov 19 22:13:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD193A1913; Thu, 19 Nov 2020 22:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=FP4NE5+I; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BAM+cWbI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1BE51vK_vXO; Thu, 19 Nov 2020 22:13:26 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3E63A190D; Thu, 19 Nov 2020 22:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90704; q=dns/txt; s=iport; t=1605852806; x=1607062406; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jIF8soqIwNKbX93vfh9uXsKYH4WmeDMOKWF4u7U6BG4=; b=FP4NE5+I8jezQ53iAYW22BslOkZkbIRkG5HHTOYfT+hoZ9Ia6MHwykmE zooeW9rC/kPHUOnmuDGfzQEipvRWT8OTQe9VLOeY0Ma7qM3DBtqq4naSj 3kjsWH2wBzKhx4LeuLYjSpK6MKDagHOnAqx1QZ3wDyk1C/TJtncxxeUQ0 k=; X-IPAS-Result: =?us-ascii?q?A0CiAAC6XbdffYsNJK1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgSMvIy57WS8uCod8A41dihWOboFCgREDTwULAQEBDQEBG?= =?us-ascii?q?AEMCAIEAQGESgKCKQIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyA?= =?us-ascii?q?QEBAQMBARAIAQIjAQElBwQHAQ8CAQgQAQMBAQEhAQYHIQYLFAkIAgQBDQUID?= =?us-ascii?q?AcHgwWBflcDLgEOoiMCgTyIaHSBNIMEAQEFgTMBAwIOQYMRDQuCEAMGgTiCc?= =?us-ascii?q?4JmToFIgT6EExuBQT+BEAFDgk8+ghtCAQECAQGBIQUBEgEjBRkGBwkCgxKCL?= =?us-ascii?q?JAgAhIGDAkpgjiHW4MqmHoJL1UKgm2JEoZlhhGFNYMaiheFTI8Ak1aLAYJvj?= =?us-ascii?q?jWBToJoAgQCBAUCDgEBBYFrIWlwcBU7gjUBATJQFwINjh8MFxSDOoUUhUMBd?= =?us-ascii?q?AI1AgYKAQEDCXyMOwExXwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AB6Tb8BHpJaexgulYjdOI0J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbXZjS9P9FzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX+elTNr3z05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,355,1599523200"; d="scan'208,217";a="616890903" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2020 06:13:23 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AK6DNhg025472 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2020 06:13:23 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Nov 2020 00:13:23 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Nov 2020 01:13:22 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 20 Nov 2020 00:13:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FnkOn+82KyAVo0fUxfrjZWqFnmJ7PGJ0aBby7mFoy5pGhUqVAzEVu6Ar4b/dTXOq/ztdvqH/6Ub0uyklNvh3HRyQugQY2KjPcccwX6dSgDHpLVtDQFoZipIdIj6JS2C/pi6KwuwR7CGhUkIdrY7H1EErLgS6mG2D/dTS6GR4M92HW0NJ15ntwdxujtO543SXvVc0wZFhJGxGr0r4wDVxFQMn0rmzBazjPTHekdndZpMV43BDBFcoaPXDCpQUrRaJMbWDI+CRYTCKnDMVQcNgIQRYROaPin37PpDYlG2/nqnskzMeU0+51BorTBdz6w5mYTMTBZtNJx7FNaaWjXgb6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q68olcBhUdOYMWbdYMu7a4SZCaEz1Y1xIhImyG9bny0=; b=c5xoMw1gEBy9lwt4AGvfryClQ0zxQuamfyTvliJE4pi6E8ANThQzfFgywYEdc4pfGZ/C2ZpoFymwY5TFsa0SKqIQ6zZJVccHkBvlm1ICtZg1kPdW8FcEUeFIfqphgAQaKRIN40Pl/OsXglNx/sRm0k7MgYOcLPG+Tb73/Yxf9iDLwro+crFzwcy0YRN15+4F2xSlbMPor8RKRKFfljkBbQZodos7mmcGMb14PQOhHa117hgq49IAAnug0lzWiCcoEv9FFmbf0S+amARDpn8ao5wPcC2csOp033EyeAOSn+wjf0ZWeIjWWBGbO7JRUj6YHnkqIoI4EtRt7pd1BinYGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q68olcBhUdOYMWbdYMu7a4SZCaEz1Y1xIhImyG9bny0=; b=BAM+cWbIF5dPhwBfpdoG7ihl9AWhqLacUI9e/KUk3qEonOb5yr9ssd/AniFBWw5hdZYdlli/sh4R9HubaAvC4Z5A/hZxEkA/QN6drZr5i7tsaIPh3ODiw0d/0+umCg64TVyXSPdbKt3mZOcgPaRtYXYxKeWbnbutAJU781eNS84= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB4660.namprd11.prod.outlook.com (2603:10b6:5:2ad::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Fri, 20 Nov 2020 06:13:18 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Fri, 20 Nov 2020 06:13:18 +0000 From: "Rakesh Gandhi (rgandhi)" To: Tianran Zhou , Mach Chen , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KnAEieAgAGGXIqABKdzAIAEHsI6gAAB1ACAAqNDgIAAE4+WgAH1xICAACO6gIAAfBytgACt9QCAAE9h4Q== Date: Fri, 20 Nov 2020 06:13:18 +0000 Message-ID: References: , , , <02323949c3d9479a92c674a676f366ae@huawei.com> In-Reply-To: <02323949c3d9479a92c674a676f366ae@huawei.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f187879d-2279-44c6-984a-08d88d1b6024 x-ms-traffictypediagnostic: DM6PR11MB4660: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E8bw44JvKCt8LOENXn2JWy8E4lUdJSrIkRt/0NxARK9yVedhR98Ee1+n8I3Co6BLftfIwI1S4ofYx2w6/PRgbp/Tg4F7kdrn1y5fQkpSp0AIRAek5RNKaAeDq22NPrHPqc94mK033lKzeggoD1nhT3JlGj/UGcyu/UmU2ejc1MSiRhMaPzUTj0559r2B8RuOhiKxOFdrGaE9TjHUQFl6YUhaUoiRqlCuqk80d12f3QjTzeIkjKKy0V2H1bJa3Rifjd/gjLyoT9BH9vevGzDumYhsU6Y4pkJIrajCOfE6gRZLNM+uNyqcRndiSZfREFlLvWhivdubNQaglC69DwlJPQENOeiDkni6oTZ9cZQGw2CggyibRvbG9cX3JPhHwEN03Ew+mXZp+/oD7q04RWlmrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(376002)(396003)(346002)(86362001)(966005)(2906002)(7696005)(26005)(8676002)(30864003)(4326008)(52536014)(55016002)(9686003)(83380400001)(5660300002)(53546011)(316002)(8936002)(110136005)(66446008)(186003)(71200400001)(166002)(478600001)(66946007)(19627235002)(66476007)(66556008)(64756008)(76116006)(54906003)(91956017)(6506007)(33656002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xCWZEftGOf+xIp01SXo21cfuZwr7tK9tJrS3DcnmvQNjpEVboCJO3CPVG8IcVlTCG7ET8jBPq7eCqgRsWDMz5SEHt2TMNETT8xFlaSMERExKxjSarksA/jKlno4iFamGU4LekIoLXVkEiHA3i1MgmRndLc0Y4VZPsmlMzMe9M8xMGJ6+juo9mdpJ7wrmZ3H/vhV+TYJNEY6zdT2xzl80RQb0b7yWiRm4qVixV2AUn8eUZiwqQA64E8Sj4RQo6zIGVhxUQ/l1LPUta5qgenxOnOp+KXFnm3+xoLQbd6ITbLILNmHkYn8YRuSmNK7igotJH9GMDtYa/px00wFkwkf9dRgP93yO3Txre+mQUsm7AiebLjwLWsMM0bBMMOGNuEMrb1kFL0BGAiDYj+EVJGCQnUD0dqiCe6pBWUAikymkAIbOW5Ea+0XA4L5p/eGC8J3ZU2MM7p9Ts5Yl0kZyUD/Ivb6ZXgiwSfKEVm2ZIpX+HVPcpAlK35y9mdAH49eTGbgbtCJeg5xatpdulTk+kpv5YzoREbLjRdLECgjwtivt4JP4cpHE+veO9noJ0WZ8DlIwad+zEEyRTjFAo8Wjzu4aX7FOTg/bQeiE/1JP1E5qhz3SGGLsjCSDg0C4JgOdasB/uPL+GNl/A/0GYsy9qJs0EcZ19P+jROUcgxMkvtaNQnRW38BLdrGdcGUY3MTXCcrA/uJn3zXnOlaY0xpansj0SB0quTf91KBiS17SiMeFlfwqhfOVdwG2a1q64hQCrUuQ1xJAajg0hwmgu4Ds7Zl8B4jczTY5Ci2vYXB8AYoFChext0B0YlUcC0TbPwMxClOlQd3NJjRfyvtVWcxDtn1ijeph8aBI8T57M9/UHui+5DhD9pS41gTy7O6cWXD49qrLdfcMBzCIuS6k8UQS0M/uHw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31157E530DF68F7A1A663483BFFF0DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f187879d-2279-44c6-984a-08d88d1b6024 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 06:13:18.7917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: h74oM+lFfrSVTDrQpBqosZ5zICGhGudKi1r59kt9ffZx85/L3VOJdyQjCKjnvCFZuUUwfqr1pdxdllyE21tv8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4660 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 06:13:36 -0000 --_000_DM6PR11MB31157E530DF68F7A1A663483BFFF0DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Tianran for the review comments. We will address the comment in the = next revision of the document. Thanks, Rakesh From: Tianran Zhou Date: Thursday, November 19, 2020 at 8:28 PM To: Rakesh Gandhi (rgandhi) , Mach Chen , Greg Mirsky Cc: spring , IPPM Chairs , spring-ch= airs@ietf.org , Tommy Pauly , IET= F IPPM WG (ippm@ietf.org) Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Mach and Rakesh, Thanks for your reply. I am now much more clear. But I really think the draft should add more text on the motivation and use= case. It would be very helpful for the audience to understand. For example, one of my question about the new direct measurement. There is rare word on how to use it, how it=92s different from existing sta= mp direct measurement tlv. Anyway, I find some valuable extensions in these two drafts. I would like t= o support the adoption and help to improve this document. Best, Tianran From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Thursday, November 19, 2020 11:15 PM To: Mach Chen ; Tianran Zhou = ; Greg Mirsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM WG (ippm@ietf.org)= Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Thank you Mach and Tianran for your review comments. Please see inline reply with =85 From: Mach Chen > Date: Thursday, November 19, 2020 at 2:41 AM To: Tianran Zhou >, R= akesh Gandhi (rgandhi) >, Greg = Mirsky > Cc: spring >, IPPM Chairs >, spring-chairs@ietf.org >, Tommy Pauly >, IETF IPPM WG = (ippm@ietf.org) > Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]=85 From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) >; Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If you prefer= , we can define them here. For Zero checksum field, we can add a reference = for the RFC 6936 in Security section and also add some text for it. Will be= happy to work with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussions= are mainly about draft*-stamp-srpm. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. To further add to this, as TWAMP Light does not have a TLV, we need = to define a stand-alone message for direct-mode LM. STAMP is just the same = message but fixed length, so this way both can interoperate and also we can= leverage the message for both of these protocols. For STAMP direct-mode LM TLV approach, some technical details are in the dr= aft as well: The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization for one-way delay). Furthermore, for hardware-based cou= nter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. How the proposed method of direct packet loss is related to TWAMP light and= STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it=92s format, the messages and processing of them are the same for delay = and direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in the = new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. To further add to this, the IPPM draft simply defines protocol extens= ions. The use-cases are there in the corresponding spring drafts. For examp= le, for links, no return Path TLV is used, etc. In other words, the use-cas= es are different for the two, and there is no TLV in TWAMP anyways. Thanks, Rakesh Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: =95 Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. =95 Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. =95 Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we=92ve had updates on the work in the SPRING WG= that was using STAMP and TWAMP. Since those documents ended up making exte= nsions to the base protocols, the chairs of SPRING and IPPM decided that it= would be best to split the documents and track the IPPM extension work in = the IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_DM6PR11MB31157E530DF68F7A1A663483BFFF0DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thanks Tianran for the review comments. We will addr= ess the comment in the next revision of the document.

     

    Thanks,

    Rakesh

     

     

    From: Tianran Zhou <zh= outianran@huawei.com>
    Date: Thursday, November 19, 2020 at 8:28 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, Mach Chen <= ;mach.chen@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>, IPPM Chairs <ippm-chairs@ietf= .org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, Tommy Paul= y <tpauly@apple.com>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org&= gt;
    Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Mach and Rakesh,

     

    Thanks for your reply.= I am now much more clear.

    But I really think the= draft should add more text on the motivation and use case.  It would = be very helpful for the audience to understand.  

    For example, one of my= question about the new direct measurement.

    There is rare word on = how to use it, how it=92s different from existing stamp direct measurement = tlv.

    Anyway, I find some va= luable extensions in these two drafts. I would like to support the adoption= and help to improve this document.

     

    Best,

    Tianran

     

     

    From: Rakesh Gandhi (rgandhi) [mailto:rgandhi= @cisco.com]
    Sent: Thursday, November 19, 2020 11:15 PM
    To: Mach Chen <mach.chen@huawei.com>; Tianran Zhou <zhoutia= nran@huawei.com>; Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly@apple.com>; IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Thank you Mach and Tia= nran for your review comments.

    Please see inline repl= y with <RG2>=85

     

    From: Mach Chen <mach.chen@huawei.com>
    Date: Thursday, November 19, 2020 at 2:41 AM
    To: Tianran Zhou <zhout= ianran@huawei.com>, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>
    Cc: spring <spring@ietf.org>, IPPM Chairs <ippm-chairs@= ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, Tom= my Pauly <tpauly@apple.com>, = IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Ti= anran, Rakesh and Greg,

     = ;

    Pleas= e see some responses inline with [Mach]=85

     = ;

    From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org>; Greg Mirs= ky <gregimirsky@gmail.com&g= t;
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     

    Hi Rakesh and Greg,

     

    I may not very clear a= bout the context. Please allow me to jump in.

    It seems both of you m= ake some valid point.

    Please see in line wit= h <ZTR>.

     

    Cheers,

    Tianran

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <gregimi= rsky@gmail.com>
    Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     

    Hi Greg,

     

    Thank you for your rev= iew and discussions on the drafts. This will help improve the work on this = important work.

    Please see replies inl= ine with <RG>..

     

     

    From: Greg Mirsky <gregimirsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, and All,

    I've read the responses to my detailed comments. I d= on't think that only adding references will solve the problems with the doc= uments. If authors are interested in addressing my comments, we can start w= orking on solving them one by one.

     

    <RG> As mentione= d in previous replies, we can add references for the well-known terms =93Li= nks=94, =93Congruent Paths=94, =93SR Path=94. If you prefer, we can define = them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will b= e happy to work with you to address these.

     

    But I am very much concerned with the technical valu= e of these drafts. And here's why I feel that the proposed documents don't = provide a sound technical solution to the task of direct loss measurement.&= nbsp;Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

    • What is being proposed in these drafts?

    Drafts *-twamp-srpm and *-stamp-srpm propose a new p= rotocol to support direct packet loss measurements. Note, that RFC 6374 inc= ludes a method for direct loss measurement in MPLS networks that is applica= ble to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, t= he Direct Measurement TLV, that supports the direct packet loss measurement= . STAMP and all its extensions are applicable in IPv6 networks and, thus, c= an be used in the SRv6 domain.

     

    <RG> As mentione= d in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Se= ction 8.1) define stand-alone messages for collecting TX and RX counters fo= r direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that take advantage = of the widely deployed TWAMP protocol and as well this same protocol can be= deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

     

    <ZTR> I think RFC6374 for MPLS and Y.1731 make= some noise here. The point is if we need a new direct packet loss measurem= ent for STAMP, when STAMP already defined a Direct Measurement TLV (http= s://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

     = ;

    [Mach= ] Given that TWAMP does not support TLV, I assume that the discussions are = mainly about draft*-stamp-srpm.

     = ;

    [Mach= ] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-sr= pm assumes that marking-based solution (which can address the packet out-or= dering issue) is used, hence the block number is introduced. The block number is used to correlate the counters f= rom the sender and reflector. The current direct loss measurement TLV may j= ust apply to the scenario without packet out-ordering.

     = ;

    <RG2> To further= add to this,  as TWAMP Light does not have a TLV, we need to define a= stand-alone message for direct-mode LM. STAMP is just the same message but= fixed length, so this way both can interoperate and also we can leverage the message for both of these protocols.

     

    For STAMP direct-mode LM TLV approach, some t= echnical details are in the draft as well:

     

       The STAMP message with a TLV for "direct measurem= ent" can be used for

       combined Delay + Loss measurement [I-D.ietf-ippm-stamp-op= tion-tlv].

       However, in order to use only for loss measurement pur= pose, it

       requires the node to support the delay measurement mes= sages and

       support timestamp for these messages (which may also r= equire clock

       synchronization for one-way delay).  Furthermore,= for hardware-based counter collection

       for direct-mode loss measurement, the optional TLV bas= ed processing

       adds unnecessary overhead (as counters are not at well= -known

       locations).

     

     

     

    [Mach= ] In addition, whether to keep it as current design or to define a new TLV = for direct loss measurement can be debatable.  

     

     

     = ;

    How the proposed method of direct packet loss is rel= ated to TWAMP light and STAMP?

    There's no apparent technical relationship between *= -twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do no= t extend or re-use the basic mechanisms defined for  TWAMP-Test and/or= STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new forma= ts of test packets that are decisively different from the formats defined i= n respective specifications. As a result, the new protocols are required to= use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is= another clear indication that the proposed mechanism represents a new prot= ocol, neither extends TWAMP Light and/or STAMP nor updates their specificat= ions.

     

    <RG> As mentione= d in previous replies, other than timestamp vs. counter and it=92s format, = the messages and processing of them are the same for delay and direct-mode = loss measurement.

    • Is there any advantage in introducing a dedicated packet format for the dir= ect packet loss in STAMP comparing to using the Direct Measurement TLV exte= nsion?

    Though it appears the using a dedicated packet forma= t instead of TLV is more efficient, but the dedicated for the direct loss m= easurement format is likely to precede one or even two TLVs, Node Address T= LV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more= efficient and reduce the processing delay, than if using the Direct Measur= ement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

     

    <RG> As mentione= d in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

     

     

    • Using the Sender Control Code may require the use of= the additional TLV that carries the return path information, Path TLV. If = the ability to control the return path is required that can be achieved by = augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each te= st packet. Hence, there seem no technical requirements to introduce the Sen= der Control Code field in the Base STAMP format defined in RFC 8762.

       

      <RG> Per session= basis between different sender nodes and this reflector node, some senders= will request the replies in-band (e.g. for two-way mode). Sessions are pro= visioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectiona= l SR path). This is also similar to as described Section 3.1 in RFC 6374, t= op of page 22. There is no need to create a such state for each session on = the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation = by eliminating the Control protocol signaling.

       

      <ZTR> I find some value to include the path TL= V in wire. As Rakesh mentioned, this can reduce the reflector configuration= . But I am not convinced to introduce the sender control code field. It see= ms to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

       = ;

      [Mach= ] Regarding how to specify the return path, the draft defines two ways to a= chieve that, one is to use control code to direct whether the reflected Tes= t should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and S= TAMP. At the same time, in the case of STAMP, it also defines the return pa= th TLV to explicitly specify the return path, which bring more options to s= pecify the return path. Therefore, I see benefit of the two ways.

       

      <RG2> To further= add to this, the IPPM draft simply defines protocol extensions. The use-ca= ses are there in the corresponding spring drafts. For example, for links, n= o return Path TLV is used, etc. In other words, the use-cases are different for the two, and there is no TLV in TWAMP anyw= ays.

       

      Thanks,

      Rakesh

       

       = ;

       = ;

      Best = regards,

      Mach<= /span>

       = ;

      What is the relationship between the *-srpm drafts a= nd BFD?

      Some text in the *-srpm drafts suggest that the prop= osed method can be used to monitor for the loss of a path continuity. = That may be viewed as an alternative to the BFD protocol method for the det= ection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems= logical that the BFD WG and BFD WG's Chairs be made aware of the proposals= . I didn't take the liberty of adding BFD WG or its Chairs. I believe that = decision to be made by the Chairs of IPPM And SPRING WGs.

       

      <RG> As mentione= d in previous replies, STAMP/TWAMP test messages are also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

       

      Thanks,

      Rakesh

       

      Regards,

       

       

      On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimirsky@gmail.c= om> wrote:

      Hi Rakesh,

      thank you for your prompt response, much apprec= iated. I'll carefully read your responses. Looking forward to the continued= discussion.

       

      Regards,

      Greg

       

      On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

      Hi Greg,

       

      Thank you for your review comments. As mentioned in the IPPM sessi= on today, the email response was sent as attachments, see archive blow:

      https://mailarchive.ietf.org/arch/msg/i= ppm/J503n-B2yOxF0urcHtGQKnqCRDE/

       

      I am attaching them in word documents for the convenience. We can = address your comments below in the next revision of the document.

       

      Thanks,

      Rakesh

       

       

      From: Greg Mirsky <gregimirsky@gmail.c= om>
      Date: Friday, November 13, 2020 at 10:09 AM
      To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
      Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
      Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

      Hi Rakesh,

      thank you for your response to my review. Please find my follow-up= notes in-lined below under the GIM>> tag.

      I hope you've found more detailed comments in the attachments (re-= attached for your convenience). I'm looking forward to reading your respons= es to the detailed comments of all four drafts.

       

      Regards,

      Greg

       

      On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

      Thank you Greg for taking time for t= horoughly reviewing the documents and providing the comments.  Attache= d please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, t= agged with <RG00>.

       

       

      From: ippm <ippm-bounces@ietf.org&= gt;
      Date: Monday, November 9, 2020 at 11:48 AM
      To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
      Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
      Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

      Dear WG Chairs, Authors, and IPPM WG community,

      I've reviewed these drafts and have some comments to share. Below,= please find my thoughts on whether these drafts can be adopted. More speci= fic comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft tar= getted to the SPRING WG) are in the attached documents.

       

      Usually, the bar for the adoption of a document can be evaluat= ed by answers to these three questions:

      =B7  Is the document(s) reasonably well-written

      I've got surprised that the drafts don't use the terminology f= rom RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms= , e.g., Links, "congruent paths", are used in the documents witho= ut proper definitions. Other than that both drafts are readable and reasona= bly well-written.

       

      <RG00> We can change Sender to= Session-Sender and Reflector to Session-Reflector if it helps. 

      GIM>> I believe that the consistency in terminology between = the core RFC and what is intended as its extension is not only helpful to a= reader but, to the best of my understanding, is required for IETF specifications.

      <RG00> There are many existing= RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congrue= nt Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that= , we can add a reference for them if it helps.

      GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

      Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                        &nb= sp;    C---------D

                        &nb= sp;  /                 \<= o:p>

                  A----B    &nbs= p;              E-----F

                        &nb= sp;  \                  /=

                        &nb= sp;  G------------H

      Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. From the definition of "congruent" as "two figure= s or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the= other", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet = of an active OAM intended to monitor a flow over the SR tunnel is out-of-ba= nd and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct l= oss measurement can be performed, as information collected from node F. So,= this example, in my opinion, illustrates two of my concerns:

      • using a congruent path for an active OAM protocol may produce information t= hat does not reflect the condition experienced by the monitored flow. It se= ems that the terminology should reflect the fundamental requirement for usi= ng active OAM to maintain the test packets in-band with the monitored flow.
      • there are no technical requirements to justify using in-band active OAM pro= tocol for direct packet loss measurement. As demonstrated in this example, = direct packet loss can be performed using an out-of-band mechanism, e.g., S= NMP queries, Netconf notifications based on YANG data model.

       

      =B7  Does the document solve a real problem?

      No, it appears that  both TWAMP and STAMP drafts  d= efine a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

       

      <RG00> There is a requirement = to measure performance delay as well as synthetic and direct-mode packet lo= ss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here.

      GIM>> I agree with the requirements you've listed (thou= gh the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason to us= e OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. 

       

      =B7  Is the proposed solution technically viable?

      There are too many unaddressed aspects, particularly the risk = introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

       

      <RG00> About your comment on z= ero checksum, this is described in Security section in RFC 6936. We will ad= d reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP or TWAMP Light. Other than this, I did not= find any other security related issue in your review.

      GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

       

      Thanks,

      Rakesh

       

       

      Regards,

      Greg

       

       

       

       

      On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.= ietf.org> wrote:

      Hello IPPM,

       

      For the past few meetings, we=92ve had updates on the work in the = SPRING WG that was using STAMP and TWAMP. Since those documents ended up ma= king extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the d= ocuments and track the IPPM extension work in the IPPM WG.

       

      As such, we are starting a Working Group call for adoption for&nbs= p;draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.=

       

      Please provide your feedback on these documents, and state whether= or not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.<= o:p>

       

      Best,

      Tommy & Ian

      _______________________________________________
      ippm mailing list
      ippm@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/ippm

    --_000_DM6PR11MB31157E530DF68F7A1A663483BFFF0DM6PR11MB3115namp_-- From nobody Thu Nov 19 23:21:30 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E183A1996; Thu, 19 Nov 2020 23:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0i9dcYtjV21; Thu, 19 Nov 2020 23:21:25 -0800 (PST) Received: from ESA3-Dor.bell.ca (esa3-dor.bell.ca [204.101.223.60]) (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 CCA9A3A1998; Thu, 19 Nov 2020 23:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1605856885; x=1637392885; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Q+6532xRToyAnTyEE6RFmJMXYwor45O7jlbOCgfKms0=; b=ILXYh5rWObwgXA6xuX5ZuRRZC3nhcwPrb/Tz5DEc6qniXXbWFVGTJavi oBZ7PANSr25tHPWTGbnoc3pf7YQc2LLOGEYImHsXIrQ0NUQRo1kYQ3aZ2 fA35PdTKgLpTanso1Hsr8ur5r/3a0CBj1HU0yY9834EIyzWdE0VYIDJ2r 8sT4sMnriOZdL5Pp/4HyRET63ydZJMG4nBeTI4Fvry+pVdqOy5zWvOg+d ydz+K2lPzuFYHz3xJdYuar36W/xIgdSfFtLPMd5Ql6dTj7AXBSVzAkrjm qxxDklZ8lhtfQK6yfWEX1dE+OOiltOwxF1RSQxPEXSfu9BqdgKrm80Xi5 Q==; IronPort-SDR: Y2eKF1zLXt+xE+alsVsKEgq5EwFOp7ZvcgAjAw/iZ4kqqqgc6vv2B/pCQ27vkIt6+iedA0mzzJ O+GSt91VWy2g== Received: from dc5cmz-d00.bellca.int.bell.ca (HELO DG1MBX04-WYN.bell.corp.bce.ca) ([198.235.121.231]) by esa03corp-dor.bell.corp.bce.ca with ESMTP; 20 Nov 2020 02:21:17 -0500 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Nov 2020 02:21:17 -0500 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d5aa:97b:fe99:c46f]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d5aa:97b:fe99:c46f%22]) with mapi id 15.00.1497.006; Fri, 20 Nov 2020 02:21:17 -0500 From: "Voyer, Daniel" To: =?utf-8?B?56iL5Lyf5by6?= , spring CC: srcomp , "spring-chairs@ietf.o" Thread-Topic: [EXT][spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Thread-Index: AQHWu2PlWmzdD5upEUScA7h0ImcygKnQpK8A Date: Fri, 20 Nov 2020 07:21:17 +0000 Message-ID: References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> In-Reply-To: <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.8] Content-Type: multipart/alternative; boundary="_000_CA25534172F642D4A9F9DAD0D0592859bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 07:21:28 -0000 --_000_CA25534172F642D4A9F9DAD0D0592859bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGlzIGlzIHF1aXRlIHNvbWUgcHJvZ3Jlc3Mgd2l0aCB0aGUgYXBwZW5kaXgg QS4NCkkgYWdyZWUgd2l0aCB0aGUgY29tbWVudHMgdGhhdCBoYXMgYmVlbiBleHByZXNzZWQgYnkg b3RoZXJzIGluIHJlZ2FyZHMgb2YgYXBwZW5kaXggQSBhbmQgaXRzIHJlcXVpcmVtZW50cyBhcyB3 ZWxsIGFzIHRoZSAgYmFzZWQgYXNzdW1wdGlvbiB3aXRoIFNSdjYuDQpJIHdvdWxkIGxpa2UgdG8g c3RyZXNzIG9uIHRoZSBpbXBvcnRhbmNlIG9mIHNlY3Rpb24gNC4xLjIgU0lEIHN1bW1hcml6YXRp b24uIEFzIERpcmsgbWVudGlvbmVkLCBzdW1tYXJpemF0aW9uIGFic29sdXRlbHkgbmVlZCB0byBi ZSBjb25zaWRlcmVkIGluIHRoZSBTSUQgY29tcHJlc3Npb24gc29sdXRpb24gZm9yIHNjYWxlIHB1 cnBvc2VzLg0KDQpUaGFua3MNCmRhbg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2Yg56iL5Lyf5by6IDxjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxl LmNvbT4NCkRhdGU6IFN1bmRheSwgTm92ZW1iZXIgMTUsIDIwMjAgYXQgMTA6MjcgQU0NClRvOiBz cHJpbmcgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiBzcmNvbXAgPHNyY29tcEBpZXRmLm9yZz4sICJz cHJpbmctY2hhaXJzQGlldGYubyIgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb RVhUXVtzcHJpbmddIEZ3Ok5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21w ZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dA0KDQoNCkhpIEdyb3VwLA0K DQpTUiBjb21wcmVzc2lvbiBkZXNpZ24gdGVhbSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9u IG9mIGNvbXByZXNzaW9uIHJlcXVpcmVtZW50IGRyYWZ0Lg0KDQpNYWluIGNoYW5nZXMgYXMgZm9s bG93czoNCg0KLSBhZGRlZCAzIGl0ZW1zIGFib3V0IHNjYWxpYmlsaXR5IHdpdGggYWdyZWVtZW50 IHdpdGhpbiB0aGUgZGVzaWduIHRlYW0NCg0KLSBhZGRlZCBhbiBhcHBlbmRpeCBpbmNsdWRpbmcg MyBpdGVtcyB3aXRob3V0IHdpdGhvdXQgdW5hbmltb3VzIGNvbnNlbnN1cyB3aXRoaW4gdGhlIGRl c2lnbiB0ZWFtDQoNCi0gc29tZSBtaW5vciB0ZXh0IGlzc3VlIGZpeGVkDQoNClBsZWFzZSByZXZp ZXcgaXQgYW5kIGxldCB1cyBrbm93IHlvdXIgY29tbWVudHMuDQoNCg0KDQpCVFc6IFdlIHdpbGwg aGF2ZSAxLWhvdXIgc2Vzc2lvbiBmb3IgdGhlIGRlc2lnbiB0ZWFtIHRvcGljIG9uIEZyaWRheSBh bmQgd2VsY29tZSB0byBqb2luIHVzLg0KDQoNCg0KQi5SLg0KDQpXZWlxaWFuZyBvbiBiZWhhbGYg b2YgZGVzaWduIHRlYW0NCg0KDQoNCg0KLS0tLemCruS7tuWOn+aWhy0tLS0NCuWPkeS7tuS6uu+8 mmludGVybmV0LWRyYWZ0cyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K5pS25Lu25Lq677ya V2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPixTYW5kZXIgU3Rl ZmZhbm4gPHNhbmRlckBzdGVmZmFubi5ubD4sU0pNIFN0ZWZmYW5uIDxzYW5kZXJAc3RlZmZhbm4u bmw+DQrmioTjgIDpgIE6ICjml6ApDQrlj5HpgIHml7bpl7TvvJoyMDIwLTExLTE1IDIyOjU4OjU3 DQrkuLvpopjvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlxaWFuZyBDaGVuZyBhbmQg cG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1zcmNvbXBkdC1z cHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQNClJldmlzaW9uOiAwMQ0KVGl0bGU6IENvbXBy ZXNzZWQgU1J2NiBTSUQgTGlzdCBSZXF1aXJlbWVudHMNCkRvY3VtZW50IGRhdGU6IDIwMjAtMTEt MTMNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAxMw0KVVJMOiBodHRwczov L3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lv bi1yZXF1aXJlbWVudC0wMS50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lw0KSHRt bGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21w ZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpIdG1saXplZDogaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJl bWVudC0wMQ0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNy Y29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KDQpBYnN0cmFjdDoNCiBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBjb21w cmVzcyBTUnY2DQogU0lEIGxpc3RzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KU3ViamVjdO+8mk5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJl cXVpcmVtZW50LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFdlaXFpYW5nIENoZW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1y ZXF1aXJlbWVudA0KUmV2aXNpb246IDAxDQpUaXRsZTogQ29tcHJlc3NlZCBTUnY2IFNJRCBMaXN0 IFJlcXVpcmVtZW50cw0KRG9jdW1lbnQgZGF0ZTogMjAyMC0xMS0xMw0KR3JvdXA6IEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEzDQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4 dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQvDQpIdG1saXplZDogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Np b24tcmVxdWlyZW1lbnQNCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxDQpEaWZmOiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50LTAxDQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIHJlcXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzIFNSdjYNCiBTSUQgbGlz dHMuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0K --_000_CA25534172F642D4A9F9DAD0D0592859bellca_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAwIDAgMCAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQaW5nRmFuZyBUQyI7DQoJcGFu b3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBQaW5nRmFuZyBUQyI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAWXUgR290aGljIjsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAz IDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgcXVpdGUgc29tZSBwcm9ncmVzcyB3aXRoIHRoZSBhcHBlbmRp eCBBLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCB0 aGUgY29tbWVudHMgdGhhdCBoYXMgYmVlbiBleHByZXNzZWQgYnkgb3RoZXJzIGluIHJlZ2FyZHMg b2YgYXBwZW5kaXggQSBhbmQgaXRzIHJlcXVpcmVtZW50cyBhcyB3ZWxsIGFzIHRoZSAmbmJzcDti YXNlZCBhc3N1bXB0aW9uIHdpdGggU1J2Ni48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd291bGQgbGlrZSB0byBzdHJlc3Mgb24gdGhlIGltcG9ydGFuY2Ugb2Ygc2VjdGlv biA0LjEuMiBTSUQgc3VtbWFyaXphdGlvbi4gQXMgRGlyayBtZW50aW9uZWQsIHN1bW1hcml6YXRp b24gYWJzb2x1dGVseSBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIFNJRCBjb21wcmVzc2lv biBzb2x1dGlvbiBmb3Igc2NhbGUgcHVycG9zZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kYW48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAmbHQ7c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 Y29sb3I6YmxhY2siPueoizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+5LyfPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtZdSBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+5by6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4NCiAmbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlN1bmRheSwgTm92ZW1iZXIgMTUsIDIwMjAgYXQgMTA6MjcgQU08YnI+DQo8Yj5Ubzog PC9iPnNwcmluZyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+c3Jjb21w ICZsdDtzcmNvbXBAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzcHJpbmctY2hhaXJzQGlldGYubyZxdW90 OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0VY VF1bc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHA+SGkgR3JvdXAsPG86cD48L286cD48L3A+DQo8cD5TUiBjb21wcmVz c2lvbiBkZXNpZ24gdGVhbSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGNvbXByZXNz aW9uIHJlcXVpcmVtZW50IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHA+TWFpbiBjaGFuZ2VzIGFz IGZvbGxvd3M6Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4tIGFkZGVkIDMgaXRlbXMgYWJvdXQg c2NhbGliaWxpdHkmbmJzcDt3aXRoIGFncmVlbWVudCB3aXRoaW4gdGhlIGRlc2lnbiB0ZWFtJm5i c3A7PG86cD48L286cD48L3A+DQo8cD4tJm5ic3A7YWRkZWQgYW4gYXBwZW5kaXgmbmJzcDtpbmNs dWRpbmcgMyBpdGVtcyB3aXRob3V0IHdpdGhvdXQgdW5hbmltb3VzIGNvbnNlbnN1cyB3aXRoaW4g dGhlIGRlc2lnbiB0ZWFtPG86cD48L286cD48L3A+DQo8cD4tIHNvbWUgbWlub3IgdGV4dCBpc3N1 ZSBmaXhlZDxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHJldmlldyBpdCBhbmQgbGV0IHVzIGtu b3cgeW91ciBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHA+QlRXOiBXZSB3aWxsIGhhdmU8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj4m bmJzcDsxLWhvdXIgc2Vzc2lvbiBmb3IgdGhlIGRlc2lnbiB0ZWFtIHRvcGljPC9zcGFuPiZuYnNw O29uIEZyaWRheSBhbmQgd2VsY29tZSB0byBqb2luIHVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5CLlIuPG86cD48L286cD48L3A+DQo8cD5XZWlxaWFuZyBv biBiZWhhbGYgb2YgZGVzaWduIHRlYW08bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBpZD0iZGl2c2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPi0tLS08c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdG YW5nIFRDJnF1b3Q7LHNhbnMtc2VyaWYiPumCrjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu25Y6f5paHPC9zcGFuPi0t LS08YnI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdG YW5nIFRDJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu25Lq677yaPC9zcGFuPmlu dGVybmV0LWRyYWZ0cyZuYnNwOyZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVv dDsiPuaUtuS7tuS6uu+8mjwvc3Bhbj5XZWlxaWFuZyZuYnNwO0NoZW5nJm5ic3A7Jmx0O2NoZW5n d2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tJmd0OyxTYW5kZXImbmJzcDtTdGVmZmFubiZuYnNwOyZs dDtzYW5kZXJAc3RlZmZhbm4ubmwmZ3Q7LFNKTSZuYnNwO1N0ZWZmYW5uJm5ic3A7Jmx0O3NhbmRl ckBzdGVmZmFubi5ubCZndDs8YnI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5oqE44CA6YCBPC9zcGFuPjombmJzcDsoPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaX oDwvc3Bhbj4pPGJyPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmIj7lj5E8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAgTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1 b3Q7LHNhbnMtc2VyaWYiPuaXtumXtDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yaPC9zcGFuPjIwMjAtMTEtMTUmbmJz cDsyMjo1ODo1Nzxicj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmIj7popg8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVv dDsiPu+8mjwvc3Bhbj5OZXcmbmJzcDtWZXJzaW9uJm5ic3A7Tm90aWZpY2F0aW9uJm5ic3A7Zm9y Jm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4 dDxicj4NCjxicj4NCjxicj4NCkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJ LUQsJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAx LnR4dDxicj4NCmhhcyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQm bmJzcDtieSZuYnNwO1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJzcDtwb3N0ZWQmbmJz cDt0byZuYnNwO3RoZTxicj4NCklFVEYmbmJzcDtyZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6 IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDxicj4NClJldmlz aW9uOiAwMTxicj4NClRpdGxlOiBDb21wcmVzc2VkJm5ic3A7U1J2NiZuYnNwO1NJRCZuYnNwO0xp c3QmbmJzcDtSZXF1aXJlbWVudHM8YnI+DQpEb2N1bWVudCZuYnNwO2RhdGU6IDIwMjAtMTEtMTM8 YnI+DQpHcm91cDogSW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248YnI+DQpQYWdlczogMTM8YnI+ DQpVUkw6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPg0KU3RhdHVzOiZuYnNw O2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC88YnI+DQpIdG1saXplZDombmJzcDtodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lv bi1yZXF1aXJlbWVudDxicj4NCkh0bWxpemVkOiZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8YnI+ DQpEaWZmOiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNv bXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8YnI+DQo8YnI+DQpBYnN0cmFj dDo8YnI+DQombmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDtzcGVjaWZpZXMmbmJzcDtyZXF1 aXJlbWVudHMmbmJzcDtmb3ImbmJzcDtzb2x1dGlvbnMmbmJzcDt0byZuYnNwO2NvbXByZXNzJm5i c3A7U1J2Njxicj4NCiZuYnNwO1NJRCZuYnNwO2xpc3RzLjxicj4NCjxicj4NCiZuYnNwOzxicj4N Cjxicj4NCjxicj4NClBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQmbmJzcDttYXkm bmJzcDt0YWtlJm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRlcyZuYnNwO2Zy b20mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJyPg0KdW50aWwm bmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5i c3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48YnI+DQo8 YnI+DQpUaGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpTdWJqZWN0PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPu+8mjwvc3Bhbj5OZXcmbmJzcDtWZXJzaW9uJm5ic3A7Tm90aWZpY2F0aW9u Jm5ic3A7Zm9yJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxLnR4dDxicj4NCjxicj4NCjxicj4NCkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7 b2YmbmJzcDtJLUQsJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50LTAxLnR4dDxicj4NCmhhcyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtz dWJtaXR0ZWQmbmJzcDtieSZuYnNwO1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJzcDtw b3N0ZWQmbmJzcDt0byZuYnNwO3RoZTxicj4NCklFVEYmbmJzcDtyZXBvc2l0b3J5Ljxicj4NCjxi cj4NCk5hbWU6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDxi cj4NClJldmlzaW9uOiAwMTxicj4NClRpdGxlOiBDb21wcmVzc2VkJm5ic3A7U1J2NiZuYnNwO1NJ RCZuYnNwO0xpc3QmbmJzcDtSZXF1aXJlbWVudHM8YnI+DQpEb2N1bWVudCZuYnNwO2RhdGU6IDIw MjAtMTEtMTM8YnI+DQpHcm91cDogSW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248YnI+DQpQYWdl czogMTM8YnI+DQpVUkw6Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPg0KU3Rh dHVzOiZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC88YnI+DQpIdG1saXplZDombmJzcDtodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudDxicj4NCkh0bWxpemVkOiZuYnNwO2h0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1l bnQtMDE8YnI+DQpEaWZmOiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8YnI+DQo8YnI+ DQpBYnN0cmFjdDo8YnI+DQombmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDtzcGVjaWZpZXMm bmJzcDtyZXF1aXJlbWVudHMmbmJzcDtmb3ImbmJzcDtzb2x1dGlvbnMmbmJzcDt0byZuYnNwO2Nv bXByZXNzJm5ic3A7U1J2Njxicj4NCiZuYnNwO1NJRCZuYnNwO2xpc3RzLjxicj4NCjxicj4NCiZu YnNwOzxicj4NCjxicj4NCjxicj4NClBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQm bmJzcDttYXkmbmJzcDt0YWtlJm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRl cyZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJy Pg0KdW50aWwmbmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJz cDtkaWZmJm5ic3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9y Zy48YnI+DQo8YnI+DQpUaGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CA25534172F642D4A9F9DAD0D0592859bellca_-- From nobody Fri Nov 20 00:00:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9763A1A12 for ; Fri, 20 Nov 2020 00:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniroma1.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NY4OKUitrMO for ; Fri, 20 Nov 2020 00:00:18 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 7BD1A3A1A11 for ; Fri, 20 Nov 2020 00:00:18 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id a19so2005102ilm.3 for ; Fri, 20 Nov 2020 00:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma1.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g8QMXcGe3T0mVkDDERyUqxH7Muz6gBua2IuDBW2nAGQ=; b=diNmEq7dBAibni0YgOL6o4PramlfAaw+4+W0kvtrMsGlObWBJ7N4eftA1A0dLFdnkQ SHknJv0QQcEhx0Q/O2GcLi1TaGOMuvKxlN0eN5UarMxlpsG/mIbigulPlXKOoH8k9Okh Ewx535sc6WxLItlJoACtoXBTpljHwfVhTbbIhiutTACCdfgE8c/N8ISnzlHTLay9ZVMu 6TfXC8xBtMssDMJLPM2XcRH0/3rHe9DuUlGOOAdSXKN6mNsWJQ9T4vhePcRKCvwCk7qN yrcwJSK4pHSXZbadTL0pwLK99nqcia6LH/UOJ2EHIHYkgwbYvO0LxWOiCwQqvPnjsDdn o0NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g8QMXcGe3T0mVkDDERyUqxH7Muz6gBua2IuDBW2nAGQ=; b=fQNJ3+coVMqEuvVowmO8VMLYgD2J2Yh1XK/i2Q8KESaORy3Psutj3BTAa68jiYYiDA aIHaxDTQD+uZAdMjc7cXcFRPBc2jrIxP2cxvb9E8ReV4rRiPp+LdQ2CmCD3KCdeKVUHZ ZrTC5N3WZXR5lJwAR3/3SA8jPeJI72jO9YG55pFtvUE4UyHR7/Olov97dF561itutqX8 Onq8qU2J5S7scGAn5qsiB0RDW1432k1x03VhuJ8HWrT1X42ibq/FlFWV+FaoLVKA1u1r ljcRy6YL6Sp9GtHk1uW4Q0eshCGllNvyrrCcCNd9hGgy79diBqDLfJBDSHDvKC9rUXL1 W7Lw== X-Gm-Message-State: AOAM533bR249y7hY0Yu940gjdnbnLZ3aJOWMi1tgUSMEIJLpxnR6r/g+ UmZ0mIEkBwsrYjGHk3KqcDfgelYbPybs/x8mZToj2PRBQjPLjVECIBv7sAYJUem3zU2XniQnAez RqUguVq41FyhH62uT X-Google-Smtp-Source: ABdhPJxXOJk61IqLiWi7fOu6kVB178JlapeyxIsGC9Req1s/7bikKL5pj+PWA+K87utCFt3vJXriN3U7Ii2Eb9iQj9M= X-Received: by 2002:a92:bacb:: with SMTP id t72mr26397573ill.241.1605859217322; Fri, 20 Nov 2020 00:00:17 -0800 (PST) MIME-Version: 1.0 References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> In-Reply-To: From: Antonio Cianfrani Date: Fri, 20 Nov 2020 09:00:04 +0100 Message-ID: To: "Voyer, Daniel" Cc: =?UTF-8?B?56iL5Lyf5by6?= , spring , srcomp , "spring-chairs@ietf.o" Content-Type: multipart/alternative; boundary="000000000000354edb05b4853c70" Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:00:21 -0000 --000000000000354edb05b4853c70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, thanks for the new draft. I agree with comments on the appendix. In my opinion, the points A.2.1 and A.2.3 should be inserted in the draft. As a researcher in the field of traffic engineering, I spent the last years working on SRv6 and deploying an experimental testbed for it: starting from scratch with a differewnt control/data plane will require a lot of effort and it is not needed. Regarding point A.2.3, I believe that supporting both compressed and not compressed segments highly improve the flexibility of the SRv6 solution. Best regards, Antonio Il ven 20 nov 2020, 08:21 Voyer, Daniel ha scritto: > Hi all, > > > > This is quite some progress with the appendix A. > > I agree with the comments that has been expressed by others in regards of > appendix A and its requirements as well as the based assumption with SRv= 6. > > I would like to stress on the importance of section 4.1.2 SID > summarization. As Dirk mentioned, summarization absolutely need to be > considered in the SID compression solution for scale purposes. > > > > Thanks > > dan > > > > *From: *spring on behalf of =E7=A8=8B=E4=BC=9F= =E5=BC=BA < > chengweiqiang@chinamobile.com> > *Date: *Sunday, November 15, 2020 at 10:27 AM > *To: *spring > *Cc: *srcomp , "spring-chairs@ietf.o" < > spring-chairs@ietf.org> > *Subject: *[EXT][spring] Fw:New Version Notification for > draft-srcompdt-spring-compression-requirement-01.txt > > > > Hi Group, > > SR compression design team have submitted a new version of compression > requirement draft. > > Main changes as follows: > > - added 3 items about scalibility with agreement within the design team > > - added an appendix including 3 items without without unanimous consensus > within the design team > > - some minor text issue fixed > > Please review it and let us know your comments. > > > > BTW: We will have 1-hour session for the design team topic on Friday and > welcome to join us. > > > > B.R. > > Weiqiang on behalf of design team > > > > > > ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng ,Sander Steffann < > sander@steffann.nl>,SJM Steffann > =E6=8A=84 =E9=80=81: (=E6=97=A0) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:58:57 > =E4=B8=BB=E9=A2=98=EF=BC=9A > New Version Notification for draft-srcompdt-spring-compression-requiremen= t-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-01.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-req= uirement-01 > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > Subject=EF=BC=9A > New Version Notification for draft-srcompdt-spring-compression-requiremen= t-01.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-01.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-01.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-req= uirement-01 > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 ________________________________________________________ Le informazioni=20 contenute in questo messaggio di posta elettronica sono strettamente=20 riservate e indirizzate esclusivamente al destinatario. Si prega di non=20 leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non= =20 si =C3=A8 il legittimo destinatario dello stesso. Qualora tale messaggio si= a=20 stato ricevuto per errore, si prega di restituirlo al mittente e di=20 cancellarlo permanentemente dal proprio computer. The information contained=20 in this e mail message is strictly confidential and intended for the use of= =20 the addressee only.=C2=A0 If you are not the intended recipient, please do = not=20 read, copy, forward or store it on your computer. If you have received the= =20 message in error, please forward it back to the sender and delete it=20 permanently from your computer system. --=20 --000000000000354edb05b4853c70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi all,
    thanks for the new draft.
    <= div dir=3D"auto">I agree with comments on the appendix. In my opinion, the = points A.2.1 and A.2.3 should be inserted in the draft.
    As a researcher in the field of traffic engineering, I spent the last y= ears working on SRv6 and deploying an experimental testbed for it: starting= from scratch with a differewnt control/data plane will require a lot of ef= fort and it is not needed.
    Regarding point A.2.3, I = believe that supporting both compressed and not compressed segments highly = improve the flexibility of the SRv6 solution.

    Best regards,
    Antonio

    Il = ven 20 nov 2020, 08:21 Voyer, Daniel <daniel.voyer@bell.ca> ha = scritto:

    Hi all,

    =C2=A0

    This is quite some progress with the appendix A. =

    I agree with the comments that has been expressed by= others in regards of appendix A and its requirements as well as the =C2=A0= based assumption with SRv6.

    I would like to stress on the importance of section = 4.1.2 SID summarization. As Dirk mentioned, summarization absolutely need t= o be considered in the SID compression solution for scale purposes.

    =C2=A0

    Thanks

    dan

    =C2=A0

    From= : spring <spring-bounces@ietf.org> on behalf of =E7=A8=8B= =E4=BC=9F=E5=BC=BA <chengweiqiang@chinamobile.com>
    Date: Sunday, November 15, 2020 at 10:27 AM
    To: spring <spring@ietf.org>
    Cc: srcomp <srcomp@ietf.org>, "spring-chairs@= ietf.o" <spring-chairs@ietf.org>
    Subject: [EXT][spring] Fw:New Version Notification for draft-srcompd= t-spring-compression-requirement-01.txt

    =C2=A0

    Hi Group,

    SR compression design team have submitted a new version of compression r= equirement draft.

    Main changes as follows:=C2=A0

    - added 3 items about scalibility=C2=A0with agreement within the design = team=C2=A0

    -=C2=A0added an appendix=C2=A0including 3 items without without unanimou= s consensus within the design team

    - some minor text issue fixed

    Please review it and let us know your comments.

    =C2=A0

    BTW: We will have=C2=A01-hour session= for the design team topic=C2=A0on Friday and welcome to join us.=

    =C2=A0

    B.R.

    Weiqiang on behalf of design team

    =C2=A0

    =C2=A0

    ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87<= /span>----
    =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts=C2=A0<internet-drafts@ietf.org>
    =E6=94=B6= =E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang=C2=A0Cheng=C2=A0<chengweiqiang@chinamobile.com>,Sander=C2=A0Steffann=C2= =A0<sander@steffann.nl>,SJM=C2=A0Steffann=C2=A0<sander@steffann.nl>
    =E6=8A=84= =E3=80=80=E9=80=81:=C2=A0(=E6=97=A0)
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15=C2=A0= 22:58:57
    =E4=B8=BB<= /span>=E9=A2=98=EF=BC=9ANew=C2=A0Version=C2=A0Notification=C2=A0for= =C2=A0draft-srcompdt-spring-compression-requirement-01.txt


    A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-srcompdt-spring-compre= ssion-requirement-01.txt
    has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Weiqiang=C2=A0C= heng=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
    IETF=C2=A0repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed=C2=A0SRv6=C2=A0SID=C2=A0List=C2=A0Requirements
    Document=C2=A0date: 2020-11-13
    Group: Individual=C2=A0Submission
    Pages: 13
    URL:=C2=A0https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requ= irement-01.txt
    Status:=C2=A0https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requi= rement/
    Htmlized:=C2=A0https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compre= ssion-requirement
    Htmlized:=C2=A0https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01
    Diff:=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression= -requirement-01

    Abstract:
    =C2=A0This=C2=A0document=C2=A0specifies=C2=A0requirements=C2=A0for=C2=A0sol= utions=C2=A0to=C2=A0compress=C2=A0SRv6
    =C2=A0SID=C2=A0lists.

    =C2=A0


    Please=C2=A0note=C2=A0that=C2=A0it=C2=A0may=C2=A0take=C2=A0a=C2=A0couple=C2= =A0of=C2=A0minutes=C2=A0from=C2=A0the=C2=A0time=C2=A0of=C2=A0submission
    until=C2=A0the=C2=A0htmlized=C2=A0version=C2=A0and=C2=A0diff=C2=A0are=C2=A0= available=C2=A0at=C2=A0tools.ietf.org.

    The=C2=A0IETF=C2=A0Secretariat



    Subject=EF= =BC=9ANew=C2=A0Version=C2=A0Notification=C2=A0for=C2=A0draft-srcompd= t-spring-compression-requirement-01.txt


    A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-srcompdt-spring-compre= ssion-requirement-01.txt
    has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Weiqiang=C2=A0C= heng=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
    IETF=C2=A0repository.

    Name: draft-srcompdt-spring-compression-requirement
    Revision: 01
    Title: Compressed=C2=A0SRv6=C2=A0SID=C2=A0List=C2=A0Requirements
    Document=C2=A0date: 2020-11-13
    Group: Individual=C2=A0Submission
    Pages: 13
    URL:=C2=A0https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requ= irement-01.txt
    Status:=C2=A0https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requi= rement/
    Htmlized:=C2=A0https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compre= ssion-requirement
    Htmlized:=C2=A0https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -01
    Diff:=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression= -requirement-01

    Abstract:
    =C2=A0This=C2=A0document=C2=A0specifies=C2=A0requirements=C2=A0for=C2=A0sol= utions=C2=A0to=C2=A0compress=C2=A0SRv6
    =C2=A0SID=C2=A0lists.

    =C2=A0


    Please=C2=A0note=C2=A0that=C2=A0it=C2=A0may=C2=A0take=C2=A0a=C2=A0couple=C2= =A0of=C2=A0minutes=C2=A0from=C2=A0the=C2=A0time=C2=A0of=C2=A0submission
    until=C2=A0the=C2=A0htmlized=C2=A0version=C2=A0and=C2=A0diff=C2=A0are=C2=A0= available=C2=A0at=C2=A0tools.ietf.org.

    The=C2=A0IETF=C2=A0Secretariat


    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listi= nfo/spring

    _= _______________________________________________________<= /div>Le informazioni contenute i= n questo messaggio di posta elettronica sono strettamente riservate e indir= izzate esclusivamente al destinatario. Si prega di non leggere, fare copia,= inoltrare a terzi o conservare tale messaggio se non si =C3=A8 il legittim= o destinatario dello stesso. Qualora tale messaggio sia stato ricevuto per = errore, si prega di restituirlo al mittente e di cancellarlo permanentement= e dal proprio computer.
    The information contained in this e mail message is strictly confident= ial and intended for the use of the addressee only.=C2=A0 If you are not th= e intended recipient, please do not read, copy, forward or store it on your= computer. If you have received the message in error, please forward it bac= k to the sender and delete it permanently from your computer system.=

    --000000000000354edb05b4853c70-- From nobody Fri Nov 20 00:03:37 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215D73A1A76; Fri, 20 Nov 2020 00:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 nMt9FqD8v4QA; Fri, 20 Nov 2020 00:03:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750054.outbound.protection.outlook.com [40.107.75.54]) (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 232713A1A25; Fri, 20 Nov 2020 00:03:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CLncNPoZGO6ylHGoRf1OcwlZQ6hb1DlNGfAMMMqDwpZcUe/yDDmZs43sY2K5eqpp+t3Q5z5Q/pxpGJNy4Tmk8LZ0jk1XjaLqcWY/GcJ9BdhFuEmEziP2gdcPtXkFL/PQ7R6g3e9MEq8FAz/qYscGC6rJxmB8DxsMMFjGR00WowAO1mNhXmK+/h85DDAK6vmVg3exG2ss08PIsFhYTZoSaP55UKlz1PgM70MIohwBRNIib6YzCnIqnlACtZpsmbzl0sHKOxjf8dfjFrHQT8YsKXYBrfgpAPAJYGQIvo1TpbdfUg53dxgiKVLYsirRWYsYBiXBQi0QF3Z/VDajvxYktg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R0+GzTAvvyWJUKHuQNu2Hu7KCO6mCxukw7AtPvsQF+g=; b=MpPtPhmgz5pGXVYSJPJwPy1mjAEhIWlmO6Lp3CEK2DZQmxdR+5PDLDx+g5RPgu11S4gTor8c392u3jMM9tNtgBlINtCvsMbxOLesXAMV0qfEk8XT6lxRhxy1LfJc8sxe6MY/l6B1VL5w6/zPdnuEuT7eyUE+R0B9GHDYcYrD76owUYzNzkV5qo1NchQbGo1mx4PSQwuQy3nmAqY1grCZzowjddzXIKSunrx9gfYoSliQ1BUgRbH82RP7ayHVo8WuZlo1dEANMp9+NdPLsR4dg34JOhkkWEjwmfel6e91jUf9wOIt0Nx1GmuZH86L50M9isyh0O0ReBKL++RiNSZ07Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R0+GzTAvvyWJUKHuQNu2Hu7KCO6mCxukw7AtPvsQF+g=; b=jOsdw44ETNYbQxIyAHyCx2ntOsGasWsWrCIkfyxK4W6k+OHuXnwHCfIt04vMfAgBHDzz/OvjJ5VOBvf/ax490CmFfTBDo5LqVjvbCTN0G4W78KoXadnCzPBr5OnEfaBXLBigvfsfQP5xSDRHHafkswhZLBHavFR9fLGtil99RmQ= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2501.namprd18.prod.outlook.com (2603:10b6:a03:131::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Fri, 20 Nov 2020 08:03:23 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::781a:ed2d:9d3f:294c]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::781a:ed2d:9d3f:294c%4]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 08:03:23 +0000 From: Keyur Patel To: Ahmed Bashand , =?utf-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?utf-8?B?5pys6YOoKQ==?= , =?utf-8?B?56iL5Lyf5by6?= , "spring@ietf.org" CC: srcomp , "spring-chairs@ietf.org" Thread-Topic: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Thread-Index: AQHWu2PmH2KTYxv6GEm9cwUKExYhb6nPdu0AgACzZwA= Date: Fri, 20 Nov 2020 08:03:23 +0000 Message-ID: <82D1A302-D51B-4E4C-9F2A-B9448E1F71B4@arrcus.com> References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> <0df1b0805de34dbc8742313200c694de@M10-HQ-ML02.hq.cnc.intra> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [2601:646:9a80:180:58ff:eaeb:7dfe:c89d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8eca53eb-d3a9-4bb9-61b5-08d88d2ac09a x-ms-traffictypediagnostic: BYAPR18MB2501: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0ONWDUYSj28qiILqDJSeSpTLiXxGsf0NTgnPbo/cn5/pzc5ypeP2c2N4yO6/tt1cY+FgYK6tscVaWn8ozJ2Vdzd4t64B1s7mSf4ICfoS29TG9ddzGU2ebtaPEN8MBYDre86KyapXK8VgsSFcYkqQt7I0EXILiemh6VLvR6SJZYOusDDzDn32UBsHt28dTgLL0CyQDJcKl84T/mTqQfB1hzGLysVvUkhoK7rdT5zuSrWIeh01mcD+03G/oLpiEc4BxPcL7SAaxZjyvbosvJxkOC6YSr5iZBrdj5dZmVRqLcmbziwS4+LkY6HeZexN6KoXo+7BNN09aWMqlh+Ui9W3m2KFbzw4lmReEztllnpAgbXr+XTurZ9CMBHlpS/alOUzfrtCysCLYR4ZHYuK063Vrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(39830400003)(396003)(366004)(478600001)(71200400001)(6512007)(6486002)(36756003)(83380400001)(66476007)(4001150100001)(54906003)(66574015)(15650500001)(166002)(186003)(76116006)(4326008)(86362001)(5660300002)(110136005)(966005)(53546011)(316002)(2906002)(6506007)(66556008)(64756008)(8676002)(33656002)(66446008)(66946007)(2616005)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RERLKzhwNVB2UnhqdUNsei9iTjErWGt0dFVlWW5OakhFUXNJblNHckkrN1JF?= =?utf-8?B?dkxxUDVPUDl6dFB6SEpTRDA5ZlZDaTI5MmR3c1ZTbkU2c1NqUTZKK2RhZ3l4?= =?utf-8?B?VUczWEI3NlBla3REcmcyWGxpNElYQUZlRGVBTEJzNVBDdEFDQ1prWDUyUDVv?= =?utf-8?B?TElDZFdZd0lIN0Z4K3JYVGZJRTBZcDhOZElKUkpzOFB1QVdqSG53cVJod1pk?= =?utf-8?B?eVJaWjdLZHhyckUwUURwOVlGVmtuWXRzaHNYbWMzU2RSeFM1ZXphOUdqcFBX?= =?utf-8?B?WEowZUNnSGJtWC9DczBuZlp3dGtYVDhnMHZiWis4WkI3N1ZwYmZUeENJZ2c1?= =?utf-8?B?dlhtbTlMRGx2YVUyUC9QTlVzM2JDRC9jL0RYUlN4eWJzZkx6U1hHUFFxZzJY?= =?utf-8?B?UW0xYkxSVUljVzhQeHB0Sno1eUFZSjhJeDdjY29vY2x5R1djc0t0NEpubC9M?= =?utf-8?B?NC9LaEwrV1hoaVluTVB5NW5peWdwbWVHdFFxRkowa25xQnh3WTMzYUhVUERl?= =?utf-8?B?enQxQU1LRVNQZEt5NEhuNmo1djNveUdIbFMxbXBEMVIwdG5sL0hLYnJGWnZO?= =?utf-8?B?Ym8yYllUbDZ1c3B1WUdoSGs1cUxWLzJYZml1QzZMQ3p2dEcvc1FXRjV3MENM?= =?utf-8?B?RStGVU5GL2IxNFBxWERTTDlqaFpVb3FnSHNlT043dTN5UEdVOXhOZks1VFBw?= =?utf-8?B?ZXhpbHlaeng2d21vTlh6RzVieHJYNjJZVTdHK3FlOU8wQitxR1RPN2J4VlFW?= =?utf-8?B?bWlNSG8xRHFzaVVvUlJhRnlKOHJwaUd4MDYzK3FHeUlBT3VxUWRxOEhkSHRx?= =?utf-8?B?VXhQTGo5QmsvSTNwUkpuUWZ5RzMxcFBBME9xNzdlblgrcWVpMnJNVGtwd0kz?= =?utf-8?B?Q21oSmsvNWhjL09ITE0rVVptUWExZS9DZjBRMlR0bFZnMW9Jd1BkNXJRRDRa?= =?utf-8?B?TUJuR2J4NHU4c2xQTUR3Tm5lS25PQVNHY3ZZQW1nbWhGcHFtOGpQbmtTZmxC?= =?utf-8?B?cjhpQXc0ZkFaUktDNUdzL0Nlc0Myd2JYdHFqSzQrdTJzVXdNVzJ4WVRxYjJw?= =?utf-8?B?OFMwT2ZDV3NybEVNVDFFdXdtbDYxdm1PYW5Objh1TnZ1VkVPL3l4N1dhRXFn?= =?utf-8?B?Vk5TUEtXRjFXMlQ0d0Y4NEdrSkFGUlRqRFVtVGdGUzY5ajI1QzdFb014bUFZ?= =?utf-8?B?MjBodGtrM3ZsTkduOW1EbFVablpOcVB0QXlsNEgwdmU3ZXdDeHBJOEx2K3pU?= =?utf-8?B?NmJvOEkyNXpDUlJRRDMvK2kyMHJ5K0FwMEttc0hCam9jREQrUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_82D1A302D51B4E4C9F2AB9448E1F71B4arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8eca53eb-d3a9-4bb9-61b5-08d88d2ac09a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 08:03:23.0692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 77fPlrLtiipoOSm/0ec+hkDEbODZPukSBt2mkA6WSxXFiaBPdf0cYCdJTRdfwjkExLpk4PC366sqXb0PVMm7Gg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2501 Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:03:36 -0000 --_000_82D1A302D51B4E4C9F2AB9448E1F71B4arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gd2hhdCBBaG1lZCBzYWlkLiBXZSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMg c29sdXRpb24gYXMgd2VsbC4NCg0KUmVnYXJkcywNCktleXVyDQoNCkZyb206IHNwcmluZyA8c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBaG1lZCBCYXNoYW5kIDxhYmFzaGFu ZHkuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMTksIDIwMjAgYXQg NToyMSBBTQ0KVG86ICJSYW4gUGFuZyjogZTpgJrpm4blm6LkuK3lm73ogZTpgJrnoJTnqbbpmaIt 5pys6YOoKSIgPHBhbmdyYW5AY2hpbmF1bmljb20uY24+LCDnqIvkvJ/lvLogPGNoZW5nd2VpcWlh bmdAY2hpbmFtb2JpbGUuY29tPiwgInNwcmluZ0BpZXRmLm9yZyIgPHNwcmluZ0BpZXRmLm9yZz4N CkNjOiBzcmNvbXAgPHNyY29tcEBpZXRmLm9yZz4sICJzcHJpbmctY2hhaXJzQGlldGYub3JnIiA8 c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBGdzpOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1y ZXF1aXJlbWVudC0wMS50eHQNCg0KDQpJIGFsc28gYWdyZWUgdGhhdCB0aGUgcmVxdWlyZW1lbnRz IGluIEFwcGVuZGl4IEEgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRyYWZ0LiBIYXZpbmcgb2YgZXhp c3Rpbmcgc3RhbmRhcmQgYXMgYSBiYXNpcyBncmVhdGx5IHNpbXBsaWZpZXMgdGhlIGRldmVsb3Bt ZW50IGFuZCBkZXBsb3ltZW50IG9mIGFueSBjb21wcmVzc2lvbiBzY2hlbWUNCg0KDQoNClRoYW5r cw0KDQpBaG1lZA0KDQoNCg0KDQpPbiAxMS8xOS8yMCAxMjo1OCBBTSwgUmFuIFBhbmco6IGU6YCa 6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLeacrOmDqCkgd3JvdGU6DQpIaSBXZWlxaWFuZyBh bmQgV0csDQogICAgSSByZWFkIHRoZSBkcmFmdCBhbmQgYWdyZWUgd2l0aCB0aGUgcmVxdWlyZW1l bnRzIHNwZWNpZmllZCBpbiBpdC5JIHRoaW5rIHRoZSByZXF1aXJlbWVudHMgaW4gQXBwZW5kaXgg QSBzaG91bGQgYmUgcGFydCBvZiB0aGUgZHJhZnQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCiAgICBD aGluYSBVbmljb20gaXMgd29ya2luZyBvbiBhIG5ldHdvcmsgZXZvbHV0aW9uIHBsYW4gZm9yIFNS djYgbm93LCAgYW5kIHdlIGhhdmUgZG9uZSBzb21lIGZpZWxkIHRyaWFscyBiYXNlZCBvbiBTUnY2 LiBJbiBvcmRlciB0byBtYWludGFpbiB0aGUgY29udGludWl0eSBvZiAgdGhlIGZ1bmN0aW9uYWxp dHksIHdlIHN1Z2dlc3QgdGhlIHNvbHV0aW9uIGJhc2VkIG9uIHRoZSBTUnY2IHN0YW5kYXJkcy4N Cg0KDQpCZXN0IHJlZ2FyZHMsDQpQYW5nIFJhbg0KDQpGcm9tOiDnqIvkvJ/lvLo8bWFpbHRvOmNo ZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPg0KRGF0ZTogMjAyMC0xMS0xNSAyMzoyNw0KVG86 IHNwcmluZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KQ0M6IHNyY29tcDxtYWlsdG86c3Jjb21w QGlldGYub3JnPjsgc3ByaW5nLWNoYWlyc0BpZXRmLm88bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCg0K SGkgR3JvdXAsDQoNClNSIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIGhhdmUgc3VibWl0dGVkIGEg bmV3IHZlcnNpb24gb2YgY29tcHJlc3Npb24gcmVxdWlyZW1lbnQgZHJhZnQuDQoNCk1haW4gY2hh bmdlcyBhcyBmb2xsb3dzOg0KDQotIGFkZGVkIDMgaXRlbXMgYWJvdXQgc2NhbGliaWxpdHkgd2l0 aCBhZ3JlZW1lbnQgd2l0aGluIHRoZSBkZXNpZ24gdGVhbQ0KDQotIGFkZGVkIGFuIGFwcGVuZGl4 IGluY2x1ZGluZyAzIGl0ZW1zIHdpdGhvdXQgd2l0aG91dCB1bmFuaW1vdXMgY29uc2Vuc3VzIHdp dGhpbiB0aGUgZGVzaWduIHRlYW0NCg0KLSBzb21lIG1pbm9yIHRleHQgaXNzdWUgZml4ZWQNCg0K UGxlYXNlIHJldmlldyBpdCBhbmQgbGV0IHVzIGtub3cgeW91ciBjb21tZW50cy4NCg0KDQoNCkJU VzogV2Ugd2lsbCBoYXZlIDEtaG91ciBzZXNzaW9uIGZvciB0aGUgZGVzaWduIHRlYW0gdG9waWMg b24gRnJpZGF5IGFuZCB3ZWxjb21lIHRvIGpvaW4gdXMuDQoNCg0KDQpCLlIuDQoNCldlaXFpYW5n IG9uIGJlaGFsZiBvZiBkZXNpZ24gdGVhbQ0KDQoNCg0KDQotLS0t6YKu5Lu25Y6f5paHLS0tLQ0K 5Y+R5Lu25Lq677yaaW50ZXJuZXQtZHJhZnRzIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQrmlLbku7bkurrvvJpXZWlxaWFuZyBDaGVu ZyA8Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+PG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNo aW5hbW9iaWxlLmNvbT4sU2FuZGVyIFN0ZWZmYW5uIDxzYW5kZXJAc3RlZmZhbm4ubmw+PG1haWx0 bzpzYW5kZXJAc3RlZmZhbm4ubmw+LFNKTSBTdGVmZmFubiA8c2FuZGVyQHN0ZWZmYW5uLm5sPjxt YWlsdG86c2FuZGVyQHN0ZWZmYW5uLm5sPg0K5oqE44CA6YCBOiAo5pegKQ0K5Y+R6YCB5pe26Ze0 77yaMjAyMC0xMS0xNSAyMjo1ODo1Nw0K5Li76aKY77yaTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVz c2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgV2VpcWlhbmcgQ2hlbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpSZXZp c2lvbjogMDENClRpdGxlOiBDb21wcmVzc2VkIFNSdjYgU0lEIExpc3QgUmVxdWlyZW1lbnRzDQpE b2N1bWVudCBkYXRlOiAyMDIwLTExLTEzDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogMTMNClVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNv bXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQpTdGF0dXM6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVz c2lvbi1yZXF1aXJlbWVudC8NCkh0bWxpemVkOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudA0K SHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJp bmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDENCkRpZmY6IGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1l bnQtMDENCg0KQWJzdHJhY3Q6DQogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRz IGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3MgU1J2Ng0KIFNJRCBsaXN0cy4NCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K DQoNClN1YmplY3TvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAx LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlxaWFuZyBDaGVuZyBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQNClJldmlzaW9uOiAwMQ0KVGl0bGU6IENv bXByZXNzZWQgU1J2NiBTSUQgTGlzdCBSZXF1aXJlbWVudHMNCkRvY3VtZW50IGRhdGU6IDIwMjAt MTEtMTMNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAxMw0KVVJMOiBodHRw czovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVz c2lvbi1yZXF1aXJlbWVudC0wMS50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lw0K SHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpIdG1saXplZDogaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudC0wMQ0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KDQpBYnN0cmFjdDoN CiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBj b21wcmVzcyBTUnY2DQogU0lEIGxpc3RzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCuWmguaenOaCqOmUmeivr+aO peaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7tueri+WNs+mAmuefpeaIkeS7 rOOAguivt+WbnuWkjemCruS7tuWIsCBocXMtc3BtY0BjaGluYXVuaWNvbS5jbjxtYWlsdG86aHFz LXNwbWNAY2hpbmF1bmljb20uY24+77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR5Lus 5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk 44CCIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGlu YXVuaWNvbS5jbjxtYWlsdG86aHFzLXNwbWNAY2hpbmF1bmljb20uY24+ICx5b3UgY2FuIHVuc3Vi c2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0ZWx5IHJlbW92ZSB5b3VyIGlu Zm9ybWF0aW9uIGZyb20gc2VuZCBjYXRhbG9ndWUgb2Ygb3VyLg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnNwcmluZyBtYWlsaW5nIGxpc3QN Cg0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo= --_000_82D1A302D51B4E4C9F2AB9448E1F71B4arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <0EAEEE937118C94086352E61ADF05BC3@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAwIDAgMCAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2lt U3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlBpbmdGYW5nIFRDIjsNCglwYW5vc2UtMToyIDExIDQgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkg VUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxAUGluZ0ZhbmcgVEMiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA TVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQFl1IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAg MCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaWNyb3NvZnQgWWFIZWkgVUki O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uc3JjDQoJe21zby1zdHlsZS1uYW1lOnNyYzt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPisxIHRvIHdoYXQgQWhtZWQgc2FpZC4gV2UgaGF2ZSBhbiBp bXBsZW1lbnRhdGlvbiBvZiB0aGlzIHNvbHV0aW9uIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXl1 cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c3ByaW5nICZsdDtz cHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEFobWVkIEJhc2hhbmQgJmx0 O2FiYXNoYW5keS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXks IE5vdmVtYmVyIDE5LCAyMDIwIGF0IDU6MjEgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JhbiBQ YW5nKDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7ogZQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7O2NvbG9yOmJsYWNrIj7pgJrpm4Y8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+5ZuiPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5Lit5Zu9PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuiBlDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPumA mueglOeptumZojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuacrOmDqDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+KSZxdW90Ow0KICZsdDtwYW5ncmFuQGNoaW5h dW5pY29tLmNuJmd0OywgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+56iLPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuS8nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtZdSBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+5by6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4NCiAmbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7LCAmcXVvdDtz cHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzog PC9iPnNyY29tcCAmbHQ7c3Jjb21wQGlldGYub3JnJmd0OywgJnF1b3Q7c3ByaW5nLWNoYWlyc0Bp ZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtzcHJpbmddIEZ3Ok5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5JIGFsc28gYWdyZWUgdGhhdCB0aGUgcmVxdWly ZW1lbnRzIGluIEFwcGVuZGl4IEEgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRyYWZ0LiBIYXZpbmcg b2YgZXhpc3Rpbmcgc3RhbmRhcmQgYXMgYSBiYXNpcyBncmVhdGx5IHNpbXBsaWZpZXMgdGhlIGRl dmVsb3BtZW50IGFuZCBkZXBsb3ltZW50IG9mIGFueSBjb21wcmVzc2lvbiBzY2hlbWUNCjxvOnA+ PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGFua3M8bzpwPjwvbzpw PjwvcD4NCjxwPjxicj4NCkFobWVkPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDExLzE5LzIwIDEyOjU4IEFNLCBSYW4gUGFuZyg8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+6IGUPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAmumbhjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+ 5ZuiPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi PuS4reWbvTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMm cXVvdDssc2Fucy1zZXJpZiI+6IGUPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDsiPumAmueglOeptumZojwvc3Bhbj4tPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pys6YOoPC9zcGFuPikNCiB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9InNyYyI+SGkmbmJzcDtXZWlxaWFuZyBhbmQgV0csJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 InNyYyI+Jm5ic3A7ICZuYnNwOyZuYnNwO0kgcmVhZCB0aGUgZHJhZnQgYW5kIGFncmVlIHdpdGgg dGhlIHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4gaXQuSSB0aGluayB0aGUgcmVxdWlyZW1lbnRz IGluIEFwcGVuZGl4IEEgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRyYWZ0IGluIHRoZSBuZXh0IHZl cnNpb24uPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJzcmMiPiZuYnNwOyAmbmJzcDsmbmJzcDtD aGluYSBVbmljb20gaXMgd29ya2luZyBvbiBhIG5ldHdvcmsgZXZvbHV0aW9uIHBsYW4gZm9yIFNS djYgbm93LCAmbmJzcDthbmQgd2UgaGF2ZSBkb25lIHNvbWUgZmllbGQgdHJpYWxzJm5ic3A7YmFz ZWQgb24gU1J2Ni4mbmJzcDtJbiBvcmRlciB0byBtYWludGFpbiB0aGUgY29udGludWl0eSBvZiAm bmJzcDt0aGUgZnVuY3Rpb25hbGl0eSwgd2Ugc3VnZ2VzdCB0aGUgc29sdXRpb24gYmFzZWQgb24g dGhlIFNSdjYgc3RhbmRhcmRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxicj4NCjxicj4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1Ljc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1Ljc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGFu ZyBSYW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYuMHB0O21h cmdpbi1yaWdodDppbmhlcml0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNoZW5nd2VpcWlhbmdAY2hpbmFt b2JpbGUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7 Ij7nqIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1 b3Q7LHNhbnMtc2VyaWYiPuS8nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 WXUgR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW8ujwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RGF0ZTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzIwMjAtMTEtMTUmbmJzcDsyMzoy NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlRvOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OiNFRkVGRUYiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNDOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNyY29tcEBpZXRm Lm9yZyI+c3Jjb21wPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3Jn Ij5zcHJpbmctY2hhaXJzQGlldGYubzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7W3NwcmluZ10gRnc6TmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0w MS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwPkhpIEdyb3VwLDxvOnA+PC9vOnA+PC9wPg0KPHA+U1IgY29tcHJlc3Npb24g ZGVzaWduIHRlYW0gaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBjb21wcmVzc2lvbiBy ZXF1aXJlbWVudCBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwPk1haW4gY2hhbmdlcyBhcyBmb2xs b3dzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+LSBhZGRlZCAzIGl0ZW1zIGFib3V0IHNjYWxp YmlsaXR5Jm5ic3A7d2l0aCBhZ3JlZW1lbnQgd2l0aGluIHRoZSBkZXNpZ24gdGVhbSZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+LSZuYnNwO2FkZGVkIGFuIGFwcGVuZGl4Jm5ic3A7aW5jbHVkaW5n IDMgaXRlbXMgd2l0aG91dCB3aXRob3V0IHVuYW5pbW91cyBjb25zZW5zdXMgd2l0aGluIHRoZSBk ZXNpZ24gdGVhbTxvOnA+PC9vOnA+PC9wPg0KPHA+LSBzb21lIG1pbm9yIHRleHQgaXNzdWUgZml4 ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwPlBsZWFzZSByZXZpZXcgaXQgYW5kIGxldCB1cyBrbm93IHlv dXIgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw PkJUVzogV2Ugd2lsbCBoYXZlPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7 MS1ob3VyIHNlc3Npb24gZm9yIHRoZSBkZXNpZ24gdGVhbSB0b3BpYzwvc3Bhbj4mbmJzcDtvbiBG cmlkYXkgYW5kIHdlbGNvbWUgdG8gam9pbiB1cy48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHA+Qi5SLjxvOnA+PC9vOnA+PC9wPg0KPHA+V2VpcWlhbmcgb24gYmVo YWxmIG9mIGRlc2lnbiB0ZWFtPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgaWQ9ImRpdnNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4t LS0tPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1b3Q7LHNhbnMt c2VyaWYiPumCrjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj JnF1b3Q7Ij7ku7bljp/mloc8L3NwYW4+LS0tLTxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmIj7lj5E8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu25Lq677yaPC9zcGFuPmlu dGVybmV0LWRyYWZ0cyZuYnNwOzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciPiZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7PC9hPjxicj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6uu+8mjwvc3Bhbj5X ZWlxaWFuZyZuYnNwO0NoZW5nJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNoZW5nd2VpcWlhbmdAY2hp bmFtb2JpbGUuY29tIj4mbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7PC9hPixT YW5kZXImbmJzcDtTdGVmZmFubiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzYW5kZXJAc3RlZmZhbm4u bmwiPiZsdDtzYW5kZXJAc3RlZmZhbm4ubmwmZ3Q7PC9hPixTSk0mbmJzcDtTdGVmZmFubiZuYnNw OzxhIGhyZWY9Im1haWx0bzpzYW5kZXJAc3RlZmZhbm4ubmwiPiZsdDtzYW5kZXJAc3RlZmZhbm4u bmwmZ3Q7PC9hPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm cXVvdDsiPuaKhOOAgOmAgTwvc3Bhbj46Jm5ic3A7KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXoDwvc3Bhbj4pPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7pgIE8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BpbmdGYW5nIFRDJnF1b3Q7LHNhbnMtc2VyaWYi PuaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7Ij7vvJo8L3NwYW4+MjAyMC0xMS0xNSZuYnNwOzIyOjU4OjU3PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Li7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmIj7popg8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yaPC9z cGFuPk5ldyZuYnNwO1ZlcnNpb24mbmJzcDtOb3RpZmljYXRpb24mbmJzcDtmb3ImbmJzcDtkcmFm dC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPg0KPGJy Pg0KPGJyPg0KQSZuYnNwO25ldyZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO0ktRCwmbmJzcDtk cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0PGJyPg0K aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5i c3A7V2VpcWlhbmcmbmJzcDtDaGVuZyZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZuYnNwO3RvJm5ic3A7 dGhlPGJyPg0KSUVURiZuYnNwO3JlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PGJyPg0KUmV2aXNpb246IDAxPGJy Pg0KVGl0bGU6IENvbXByZXNzZWQmbmJzcDtTUnY2Jm5ic3A7U0lEJm5ic3A7TGlzdCZuYnNwO1Jl cXVpcmVtZW50czxicj4NCkRvY3VtZW50Jm5ic3A7ZGF0ZTogMjAyMC0xMS0xMzxicj4NCkdyb3Vw OiBJbmRpdmlkdWFsJm5ic3A7U3VibWlzc2lvbjxicj4NClBhZ2VzOiAxMzxicj4NClVSTDombmJz cDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQiPmh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxLnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQt c3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LzwvYT48YnI+DQpIdG1saXplZDombmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29t cGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWly ZW1lbnQ8L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0w MSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21w cmVzc2lvbi1yZXF1aXJlbWVudC0wMTwvYT48YnI+DQpEaWZmOiZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJl c3Npb24tcmVxdWlyZW1lbnQtMDEiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8L2E+PGJyPg0K PGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7c3BlY2lm aWVzJm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7Zm9yJm5ic3A7c29sdXRpb25zJm5ic3A7dG8mbmJz cDtjb21wcmVzcyZuYnNwO1NSdjY8YnI+DQombmJzcDtTSUQmbmJzcDtsaXN0cy48YnI+DQo8YnI+ DQombmJzcDs8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UmbmJzcDtub3RlJm5ic3A7dGhhdCZuYnNw O2l0Jm5ic3A7bWF5Jm5ic3A7dGFrZSZuYnNwO2EmbmJzcDtjb3VwbGUmbmJzcDtvZiZuYnNwO21p bnV0ZXMmbmJzcDtmcm9tJm5ic3A7dGhlJm5ic3A7dGltZSZuYnNwO29mJm5ic3A7c3VibWlzc2lv bjxicj4NCnVudGlsJm5ic3A7dGhlJm5ic3A7aHRtbGl6ZWQmbmJzcDt2ZXJzaW9uJm5ic3A7YW5k Jm5ic3A7ZGlmZiZuYnNwO2FyZSZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0Jm5ic3A7dG9vbHMuaWV0 Zi5vcmcuPGJyPg0KPGJyPg0KVGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KU3ViamVjdDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPu+8mjwvc3Bhbj5OZXcmbmJzcDtWZXJzaW9uJm5ic3A7Tm90aWZpY2F0aW9u Jm5ic3A7Zm9yJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50LTAxLnR4dDxicj4NCjxicj4NCjxicj4NCkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7 b2YmbmJzcDtJLUQsJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50LTAxLnR4dDxicj4NCmhhcyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtz dWJtaXR0ZWQmbmJzcDtieSZuYnNwO1dlaXFpYW5nJm5ic3A7Q2hlbmcmbmJzcDthbmQmbmJzcDtw b3N0ZWQmbmJzcDt0byZuYnNwO3RoZTxicj4NCklFVEYmbmJzcDtyZXBvc2l0b3J5Ljxicj4NCjxi cj4NCk5hbWU6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDxi cj4NClJldmlzaW9uOiAwMTxicj4NClRpdGxlOiBDb21wcmVzc2VkJm5ic3A7U1J2NiZuYnNwO1NJ RCZuYnNwO0xpc3QmbmJzcDtSZXF1aXJlbWVudHM8YnI+DQpEb2N1bWVudCZuYnNwO2RhdGU6IDIw MjAtMTEtMTM8YnI+DQpHcm91cDogSW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248YnI+DQpQYWdl czogMTM8YnI+DQpVUkw6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2 ZS9pZC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmlu Zy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC88L2E+PGJy Pg0KSHRtbGl6ZWQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5n LWNvbXByZXNzaW9uLXJlcXVpcmVtZW50PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJl c3Npb24tcmVxdWlyZW1lbnQtMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z cmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDE8L2E+PGJyPg0KRGlmZjom bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jj b21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAxIj5odHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVp cmVtZW50LTAxPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwO1RoaXMmbmJzcDtk b2N1bWVudCZuYnNwO3NwZWNpZmllcyZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO2ZvciZuYnNwO3Nv bHV0aW9ucyZuYnNwO3RvJm5ic3A7Y29tcHJlc3MmbmJzcDtTUnY2PGJyPg0KJm5ic3A7U0lEJm5i c3A7bGlzdHMuPGJyPg0KPGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlJm5ic3A7 bm90ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291 cGxlJm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJz cDtvZiZuYnNwO3N1Ym1pc3Npb248YnI+DQp1bnRpbCZuYnNwO3RoZSZuYnNwO2h0bWxpemVkJm5i c3A7dmVyc2lvbiZuYnNwO2FuZCZuYnNwO2RpZmYmbmJzcDthcmUmbmJzcDthdmFpbGFibGUmbmJz cDthdCZuYnNwO3Rvb2xzLmlldGYub3JnLjxicj4NCjxicj4NClRoZSZuYnNwO0lFVEYmbmJzcDtT ZWNyZXRhcmlhdDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuWmguaenOaCqDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+6ZSZ6K+v PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaO peaUtuS6hjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMm cXVvdDssc2Fucy1zZXJpZiI+6K+l6YKuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS7tu+8jDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+6K+3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAmjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+6L+H 55S1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi PuWtkDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVv dDssc2Fucy1zZXJpZiI+6YKuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDsiPuS7tueri+WNs+mAmuefpeaIkTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+5LusPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOAgjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJp ZiI+6K+3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVv dDsiPuWbnuWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0Zhbmcg VEMmcXVvdDssc2Fucy1zZXJpZiI+6YKuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS7tuWIsDwvc3Bhbj4mbmJzcDs8YSBocmVmPSJtYWlsdG86 aHFzLXNwbWNAY2hpbmF1bmljb20uY24iPmhxcy1zcG1jQGNoaW5hdW5pY29tLmNuPC9hPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPu+8jOWNs+WPr+S7pemA gDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDss c2Fucy1zZXJpZiI+6K6iPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPuatpDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGlu Z0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+6YKuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS7tuOAguaIkTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+5LusPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuWwhueri+WN s+WwhuaCqOeahOS/oeaBr+S7juaIkTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+5LusPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPueahDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+5Y+RPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAgeebrjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0ZhbmcgVEMmcXVvdDssc2Fu cy1zZXJpZiI+5b2VPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro aWMmcXVvdDsiPuS4rTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UGluZ0Zh bmcgVEMmcXVvdDssc2Fucy1zZXJpZiI+5YigPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumZpOOAgjwvc3Bhbj4NCiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkg ZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8mbmJzcDs8YSBocmVmPSJtYWlsdG86aHFzLXNwbWNAY2hp bmF1bmljb20uY24iPmhxcy1zcG1jQGNoaW5hdW5pY29tLmNuPC9hPiZuYnNwOyx5b3UgY2FuIHVu c3Vic2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0ZWx5IHJlbW92ZSB5b3Vy IGluZm9ybWF0aW9uIGZyb20gc2VuZA0KIGNhdGFsb2d1ZSBvZiBvdXIuIDxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwcmluZyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_82D1A302D51B4E4C9F2AB9448E1F71B4arrcuscom_-- From nobody Fri Nov 20 00:33:52 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2993A1A78; Fri, 20 Nov 2020 00:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 plC3LW2C5bAC; Fri, 20 Nov 2020 00:33:49 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 E3E7F3A1A70; Fri, 20 Nov 2020 00:33:48 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id w142so12274631lff.8; Fri, 20 Nov 2020 00:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mjW4YJRobalOSzFTlFHTPh04zLPtTcwJEQfF6kf9VfM=; b=h+kfGQ+Ixy+Atkwf95iByEuaL+N3V2tvgUsmodw+z5zx40mGJQXEQE86yBru4uiF2O /c81nYB5JAEK3w7DyQ6hOEFdz5GQ4/r8QGDdf4WwfmlIDIkoHjZ5H3ITev4YQSCkhWTj o/2bMCJi8Q9xJpm3sAuGrz8w3lm9PVg3i3KGzgGXR21l2t4fGKMwRhpxo3DsgRHgiOZA K68vqzJqHPILYi3LK17d+Lhny8KxMCCf94WPwmBYqUFvwImlq4+g1gilZxDpEEVt0FtD IcqYuQkrQYG0ycCaRE5zmfFQkPIxZXUKJgfKWPrAYREUrML7Nzkrk1Ai6/wYD7U+hmZ4 80Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mjW4YJRobalOSzFTlFHTPh04zLPtTcwJEQfF6kf9VfM=; b=OY1lDEoqQAy3s4XUj1U7z5eqCihYPB43diuMf01h46BM3vzra4VG62mUuy8WyP0HUw IOIoowitZJexZY3YbYx33DPIiwehOgSImcjdu8eELmqMJKB56ubWWwvpHLKf5On8p2Uq LaAN+fbsueMYaH74ElmLlHgy5o20xDEewN4e5lJH40c1dfVYuc9QAdHVBu2X6ZQfEhii BjYw9TEJWx0YHcZSjx172ePjw7sag4yO6dLpeIcMWS/b9c3VAkQdR92VcmYrJu34lwbU u8RNHf5/VS188hvLYH4hSYpdYKyTL7NHpk1c7+XPOC1JVBjXu+WJ9mNhCxYuipdnIg07 9+9g== X-Gm-Message-State: AOAM533b45EP4oCVLrHWC3egAZErQvzxw05uEO6jCzjutTo71885tcBK 2EIdwLY+z4G1zrtousCUmCcrmuWBxK/ukid2p2I= X-Google-Smtp-Source: ABdhPJyD8tUnPZp8J6KS1+UcppmxtABSC63V+/Ww4hAjvu7/LrCR+lDU8MeF4x7XKA3XmbWr8Q51Yvz82bCCPXwJX7M= X-Received: by 2002:a19:91:: with SMTP id 139mr7398255lfa.331.1605861226908; Fri, 20 Nov 2020 00:33:46 -0800 (PST) MIME-Version: 1.0 References: <08c001d6b8d3$010d08d0$03271a70$@com> In-Reply-To: From: Greg Mirsky Date: Fri, 20 Nov 2020 00:33:35 -0800 Message-ID: To: Weiqiang Cheng Cc: spring , srcomp , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000fd11b805b485b321" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:33:52 -0000 --000000000000fd11b805b485b321 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I took Joel's suggestion. So, here is what I wanted to note: - I'd appreciate Chairs' clarification on what sounded as "if the design team decides that the SRv6 compression is only required, then we have to accept that". I believe that the document the DT will produce still be viewed and processed as an individual draft. - an then to members of the DT. I would appreciate listening to the comments of those who are outside the DT. Particularly, if outsiders express their thoughts, impression that the document is leanin= g towards one scenario and seems to overlook another, do not take a defens= ive position right away, engage in a discussion instead. Regards, Greg On Thu, Nov 19, 2020 at 6:32 PM Greg Mirsky wrote: > Hi Weiqiang, members of the DT, > > thank you for volunteering your time and expertise to this important for > the further development of the SR project. Please find my notes and > questions below: > > - my first question is on the intended scope of the document. As I can > understand from the title, abstract, the scope is "the requirements fo= r > solutions to compress SRv6 SID lists". When I compare that with what w= as in > the charter of the DT in the announcement by our chairs > > : > > ... the requirements for solutions to compressing segment routing > information for use over IPv6. > > Though the difference in texts might seems as small, the scopes they > identify differ significantly. To me, it seems as the scope of the draft = is > targeted to only one possible solution to provide SR over IPv6 > functionality, the SRH. Does the DT plan to expand the scope of the draft > to match it to its charter? > > > - It appears that in order to qualify whether a proposed > compression method complies with the requirement in 3.1.2 an agreement= by > the WG on the benchmarking method is required because metrics listed, = in my > view, are platform-dependent. > - Though I can appreciate your consideration and using SHOULD in > requirement 3.1.3, I don't find it particularly important to be includ= ed in > the list. After all, it is a matter of the art of implementation. > - I think I cannot agree the SID summarization is the only viable > technique for the interdomain SR. Replacing MUST with SHOULD might be > reasonable, And preferably adding an informative text to describe > alternative methods to support the interdomain SR. > - I think I understand the intention of the requirement in Section > 4.2.1 but I may propose expressing it differently: > > A path traversed using a list of compressed SIDs MUST always be the same > as the path traversed using the list of uncompressed SIDs if no compressi= on > was applied. > > > - I think that the use of MUST in requirement 5.1 is too strong. > Firstly, such compatibility is not essential in a greenfield scenario. > Secondly, the control plane based solution might be envisioned to > coordinate the interworking between SR domains using SRv6 and not usin= g the > SRv6 technique. > > And in the conclusion, once again, many thanks to all the members of the > Design Team for the job well done. > > Regards, > Greg > > On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng < > chengweiqiang@chinamobile.com> wrote: > >> Hi Group, >> As you know, the SPRING Working Group set up an SR compression design >> team prior to IETF108. >> The design team is to produce (rough) consensus (of the DT) outputs to >> the WG on two related topics: >> 1) What are the requirements for solutions to compressing segment routin= g >> information for use over IPv6; >> 2) A comparison of proposed approaches to compressing segment routing >> information for use over IPv6. >> >> With great effort of design team members, DT have finished the version >> -00 of the requirements document and have submitted it to datatracker. >> >> Please review it and let's know your comments. >> >> B.R. >> Weiqiang Cheng >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-d= rafts@ietf.org] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5= 16:32 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Che= ng >> =E4=B8=BB=E9=A2=98: New Version Notification for >> draft-srcompdt-spring-compression-requirement-00.txt >> >> >> A new version of I-D, draft-srcompdt-spring-compression-requirement-00.t= xt >> has been successfully submitted by Weiqiang Cheng and posted to the >> IETF repository. >> >> Name: draft-srcompdt-spring-compression-requirement >> Revision: 00 >> Title: Compressed SRv6 SID List Requirements >> Document date: 2020-10-30 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requir= ement-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requi= rement/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-= requirement >> Htmlized: >> https://tools.ietf.org/html/draft-srcompdt-spring-compression-requiremen= t-00 >> >> >> Abstract: >> This document specifies requirements for solutions to compress SRv6 >> SID lists. >> >> >> >> >> 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 >> >> >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > --000000000000fd11b805b485b321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear All,
    I took Joel's suggestion. So, here is wh= at I wanted to note:
    • I'd appreciate Chairs' clari= fication on what sounded as "if the design team decides that the SRv6 = compression is only required, then we have to accept that". I believe = that the document the DT will produce still be viewed and processed as an i= ndividual draft.
    • an then=C2=A0to members of the DT. I would appreci= ate listening to the comments of those who are outside the DT. Particularly= , if outsiders=C2=A0express their thoughts, impression=C2=A0that the docume= nt is leaning towards one scenario and seems to overlook another, do not ta= ke a defensive position right away, engage in a discussion instead.
      • Regards,
    Greg

    On Thu, Nov 19, 2020 at 6:32 PM G= reg Mirsky <gregimirsky@gmail.c= om> wrote:
    Hi Weiqiang, members of the DT,
    thank you fo= r volunteering your time and expertise to this important for the further de= velopment of the SR project. Please find my notes and questions below:
    <= /div>
    • my first question is on the intended scope of the documen= t. As I can understand from the title, abstract, the scope is "the req= uirements for solutions to compress SRv6 SID lists". When I compare th= at with what was in the charter of the DT in t= he announcement by our chairs:
    =C2=A0... the requirement= s for solutions to compressing segment routing information for use over IPv= 6.
    Though the difference in texts might seems as small, t= he scopes they identify differ significantly. To me, it seems as the scope = of the draft is targeted to only one possible solution to provide SR over I= Pv6 functionality, the SRH. Does the DT plan to expand the scope of the dra= ft to match it to its charter?
    • It appears that in= order to qualify whether a proposed compression=C2=A0method complies with = the requirement in 3.1.2 an agreement by the WG on the benchmarking method = is required because metrics listed, in my view, are platform-dependent.
    • Though I can appreciate your consideration and using SHOULD in require= ment 3.1.3, I don't find it particularly important to be included in th= e list. After all, it is a matter of the art of implementation.
    • I t= hink I cannot agree the SID summarization is the only viable technique for = the interdomain SR. Replacing MUST with SHOULD might be reasonable, And pre= ferably adding an informative text to describe alternative methods to suppo= rt the interdomain SR.
    • I think I understand the intention of the re= quirement in Section 4.2.1 but I may propose expressing it differently:
    A path traversed using a list of compressed SIDs MUST always be the same a= s the path traversed using the list of uncompressed SIDs if no compression = was applied.
    • I think that the use of MUST in requir= ement 5.1 is too strong. Firstly, such compatibility is not essential in a = greenfield scenario. Secondly, the control plane based solution might be en= visioned to coordinate the interworking between SR domains using SRv6 and n= ot using the SRv6 technique.
    And in the conclusion, once again, ma= ny thanks to all the members of the Design Team for the job well done.
    =
    Regards,
    Greg

    On Thu, Nov 12, 2020 at 1:06 AM= Weiqiang Cheng <chengweiqiang@chinamobile.com> wrote:
    Hi Group,
    As you know, the SPRING Working Group set up an SR compression design team = prior to IETF108.
    The design team is to produce (rough) consensus (of the DT) outputs to the = WG on two related topics:
    1) What are the requirements for solutions to compressing segment routing i= nformation for use over IPv6;
    2) A comparison of proposed approaches to compressing segment routing infor= mation for use over IPv6.

    With great effort of design team members, DT have finished the version -00 = of the requirements document and have submitted it to datatracker.

    Please review it and let's know your comments.

    B.R.
    Weiqiang Cheng


    -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
    =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 16= :32
    =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Cheng<= br> =E4=B8=BB=E9=A2=98: New Version Notification for draft-srcompdt-spring-comp= ression-requirement-00.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt<= br> has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-srcompdt-spring-compres= sion-requirement
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Compressed SRv6 SID List Requireme= nts
    Document date:=C2=A0 2020-10-30
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-srcompd= t-spring-compression-requirement-00.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-srcompdt-spring-= compression-requirement/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-srcompdt-spr= ing-compression-requirement
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-srcompdt-spring-compression-r= equirement-00


    Abstract:
    =C2=A0 =C2=A0This document specifies requirements for solutions to compress= SRv6
    =C2=A0 =C2=A0SID lists.




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

    The IETF Secretariat





    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000fd11b805b485b321-- From nobody Fri Nov 20 00:50:07 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6F63A13CD for ; Fri, 20 Nov 2020 00:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RGlpQvTI6Ue for ; Fri, 20 Nov 2020 00:50:04 -0800 (PST) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320E73A1187 for ; Fri, 20 Nov 2020 00:50:03 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2051.outbound.protection.outlook.com [104.47.14.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-275-jTNFOEsENzKWnqZ04oWM9g-1; Fri, 20 Nov 2020 08:48:23 +0000 X-MC-Unique: jTNFOEsENzKWnqZ04oWM9g-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR0301MB2253.eurprd03.prod.outlook.com (2603:10a6:800:27::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Fri, 20 Nov 2020 08:48:20 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::fd6d:5942:84f5:3812]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::fd6d:5942:84f5:3812%3]) with mapi id 15.20.3589.022; Fri, 20 Nov 2020 08:48:19 +0000 From: Andrew Alston To: Stefano Salsano , =?utf-8?B?56iL5Lyf5by6?= , spring CC: srcomp , "spring-chairs@ietf.o" Thread-Topic: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Thread-Index: AQHWu2PuFICPFR6pS021bMx5A3Wn6KnQf8+AgAA7TzA= Date: Fri, 20 Nov 2020 08:48:19 +0000 Message-ID: References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:1:f8be:7f98:1be6:db6] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 619197b7-4399-49d3-9981-08d88d3107e3 x-ms-traffictypediagnostic: VI1PR0301MB2253: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: XOuACTtvTmOl/N/cm7fky34xkZwrm/Q1qbU0140FRKXrA+W7R9XK5/JWmbkkz6ZHEtrYV5ge7wbhlLHzx4s/s/wO/a9qCduiqpGwwqvQ6szWigJowmxs0hNjtl2nOtgxotkjMbVDKuxtBkhaM/Qczsbf91PbgLj0s61GhQ9dSnaOLesBSENTFzYInpd6fy6B8l+TEfLAFQ+boeBk/hbGednIoAC/akd9222qwKpC/z0jbosIBtCu2ny3jEk3JOWc4bOZ2xnl5LHIwbE9CfdTD96XBNlpsl1sf12JZqx3UZCTAE5yEoLxS8WDlpG8mCE1LM6t6OgK2PqYer2XwZgLSqWvnTu9aCwXM1yCqRS0zD2/N+tQ9Aaz+klN9R4XlBTcYDYYqFQuVhGpGoGp3kR1xA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(15650500001)(7696005)(52536014)(86362001)(9686003)(8676002)(55016002)(5660300002)(166002)(83380400001)(33656002)(4326008)(966005)(186003)(478600001)(6506007)(8936002)(53546011)(2906002)(316002)(76116006)(4001150100001)(66946007)(66556008)(64756008)(66476007)(66446008)(110136005)(54906003)(71200400001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata: y8QdKc7SbaaEF+KmqQV3NzKEjntcUX3hJDFKjsdgDwGDyhfGutEKTwYM63Tx4T2CB/HbSog9tSAVeo9QNqowBSjFWjyIjo9s2bwsouCSjaGfvmkAxFtSkxSKFaic2ntQer3yxSQcNv/gK8DgI8xt160WLb5cRu70TwkvgWimrtYRjwumdaqHGpd0wjXoBrldbb0BS2+fWHAXQc2GXYgcf3EmkDXawnEBquo25yUKGPaSh9Z6g8v+dl6wi9x3K0dTEVjML3EfvD8sVjWyyraqHuvIn2emjGo655Aqn2618H6CX4SNUMPSFOZyZ76ZbUSA2QrVTsgdYLp6dosdpo0CFzhk1okA2Jw+HsWj83KkxjYdzNDZ0xAn93QJhfQ7EMW/fEaAU4ukei8dAH3pOOZddzmbaiJPANgfSY58PUWf0HuSO8omnatLcZaoImYfPVcLI/MAg5Z98LYu8SzAvr9bou04aVa0IS7HA4R0UarF9t9ta9KeNGxuUh62OEU2gWJU5DRF400ugEVkXs4mT1BZHVG8wjT92YcCKn84wuQRTlmMhIphVEVyNqmUPqE5J48ccejK7Uq+NIcbK77TaNZOgvZQCgfYX3PHoneI3jbUTwcPlBa0mMqAI2d3SnG0UoSeWMje9yj13qFtzckMZqbBiMzUedJ4nQk69wFCqqi/In0ifRojf97WJQEwHMq+nZj7C3U4x1HeDeCOc+1ixjJBrQpd9mLcP2m+vK21tETodwmqmiArfcIwtZA+VFS77OKVSmMLAwJMBB5ol2wdk+szO6r0CXR9Vpb2wiO6JV78cKbT8DEZKjN32F52kB88z5B5DyeKMgtaHuOqmSX9p1Llnr28txhRkI4NxLa/Ow47H18rn0SoWMdqpZI8RWm7wNE/6Udck1XTNQXeqLmuVoEYpQPiazljYxX4cc+/NrUT3+PLBArKk6nofx1gus2okHc9 x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 619197b7-4399-49d3-9981-08d88d3107e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 08:48:19.7525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GfOT/LgmGP+o11R0oGCeFC1shAOqJtCSPN9mvl8lW3rJqbI3+gpHKbwk/5wzlvNNpXAF63cVVk2ajwDkJI5kTnLIbpszDWdkiF8uEU0eQJI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB2253 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056F05B67207E094D0DD14DEEFF0VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:50:06 -0000 --_000_VI1PR03MB5056F05B67207E094D0DD14DEEFF0VI1PR03MB5056eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBT dGVmYW5vIFNhbHNhbm8NClNlbnQ6IEZyaWRheSwgMjAgTm92ZW1iZXIgMjAyMCAwODowOQ0KVG86 IOeoi+S8n+W8uiA8Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+OyBzcHJpbmcgPHNwcmlu Z0BpZXRmLm9yZz4NCkNjOiBzcmNvbXAgPHNyY29tcEBpZXRmLm9yZz47IHNwcmluZy1jaGFpcnNA aWV0Zi5vIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEZ3 Ok5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXBy ZXNzaW9uLXJlcXVpcmVtZW50LTAxLnR4dA0KDQpJbCAyMDIwLTExLTE1IDE2OjI3LCDnqIvkvJ/l vLogaGEgc2NyaXR0bzoNCj4gSGkgR3JvdXAsDQo+DQo+IFNSIGNvbXByZXNzaW9uIGRlc2lnbiB0 ZWFtIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgY29tcHJlc3Npb24NCj4gcmVxdWly ZW1lbnQgZHJhZnQuDQo+DQo+IE1haW4gY2hhbmdlcyBhcyBmb2xsb3dzOg0KPg0KPiAtIGFkZGVk IDMgaXRlbXMgYWJvdXQgc2NhbGliaWxpdHkgd2l0aCBhZ3JlZW1lbnQgd2l0aGluIHRoZSBkZXNp Z24gdGVhbQ0KPg0KPiAtIGFkZGVkIGFuIGFwcGVuZGl4IGluY2x1ZGluZyAzIGl0ZW1zIHdpdGhv dXQgd2l0aG91dCB1bmFuaW1vdXMNCj4gY29uc2Vuc3VzIHdpdGhpbiB0aGUgZGVzaWduIHRlYW0N Cg0KSGkgYWxsLA0KDQp0aGUgdGhlIGFwcGVuZGl4IEEgb2YgbGF0ZXN0IGRyYWZ0IHZlcnNpb24g aW5jbHVkZXMgdGhyZWUgaXRlbXMgdGhhdA0Kc2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJh dGlvbiwgaW4gcGFydGljdWxhcjoNCg0KUmVxdWlyZW1lbnQgQS4yLjEuIFNSdjYgQmFzZWQNClJl cXVpcmVtZW50IEEuMi4yLiBTUnY2IEZ1bmN0aW9uYWxpdHkNCg0KIkEgc29sdXRpb24gdG8gY29t cHJlc3MgU1J2NiBTSUQgTGlzdHMgU0hPVUxEIGJlIGJhc2VkIG9uIHRoZSBTUnY2DQphcmNoaXRl Y3R1cmUsIGNvbnRyb2wgcGxhbmUgYW5kIGRhdGEgcGxhbmUiIGFuZCAiQSBzb2x1dGlvbiB0byBj b21wcmVzcw0KYW4gU1J2NiBTSUQgbGlzdCBNVVNUIHN1cHBvcnQgdGhlIGZ1bmN0aW9uYWxpdHkg b2YgU1J2NiINCg0KSSd2ZSBiZWVuIHdvcmtpbmcgaW4gdGhlIGxhc3QgNCB5ZWFycyBvbiB0aGUg b3BlbiBzb3VyY2UgZWNvc3lzdGVtDQpzdXBwb3J0aW5nIFNSdjYsIGluY2x1ZGluZyB0aGUgc3Vw cG9ydCBvZiBTUnY2IGluIHRoZSBMaW51eCBrZXJuZWwNCihzZWUgaHR0cHM6Ly9uZXRncm91cC5n aXRodWIuaW8vcm9zZS88aHR0cHM6Ly9uZXRncm91cC5naXRodWIuaW8vcm9zZT4pDQoNCmEgbG90 IG9mIGVmZm9ydCBoYXMgYmVlbiBzcGVudCBpbiB0aGlzIGVjb3N5c3RlbSB0aGF0IG5vdyBvZmZl cnMgYQ0KZmVhdHVyZSBzZXQgY29tcGFyYWJsZSB0byB2ZW5kb3JzJyBpbXBsZW1lbnRhdGlvbiBv ZiBTUnY2DQoNCml0IGlzIHZlcnkgaW1wb3J0YW50IGZvciB0aGUgcmVzZWFyY2ggY29tbXVuaXR5 IHRvIGhhdmUgc3VjaCBlY29zeXN0ZW0NCmFuZCBpdCB3aWxsIGJlIHBhaW5mdWwgdG8gcmVidWls ZCB0aGUgc3VwcG9ydCBmb3IgYSBuZXcgc29sdXRpb24gb3V0c2lkZQ0Kb2YgdGhlIGN1cnJlbnQg U1J2NiBhcmNoaXRlY3R1cmUuLi4gb25lIG9mIHRoZSBwcm9ibGVtIG9mIHRoZSBNUExTDQphcmNo aXRlY3R1cmUgKGZyb20gdGhlIHJlc2VhcmNoIGNvbXVuaXR5IHBvaW50IG9mIHdpZXcpIHdhcyB0 aGF0IHRoZQ0Kc3VwcG9ydCBpbiBMaW51eCBoYXMgbmV2ZXIgYmVlbiBjb21wYXJhYmxlIHRvIHZl bmRvcnMncyBzb2x1dGlvbiAoZS5nLg0KZm9yIHRoZSBjb250cm9sIHBsYW5lKSwgZm9yIHRoaXMg cmVhc29uIHRoZSByZXNlYXJjaCB3b3JrIGRpdmVyZ2VkIGEgbG90DQpmcm9tIHByb2R1Y3Rpb24g c29sdXRpb25zLCBJIHJlYWxseSB3b3VsZCBsaWtlIHRvIGF2b2lkIHN1Y2ggZ2FwIGFnYWluDQoN Cg0KTXkgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQgdGhlcmUgYXJlIG9wZXJhdG9ycyDigJMgd2hv IGhhdmUgcmVxdWlyZW1lbnRzIHRvZGF5IOKAkyB0aGF0IGVuY29tcGFzcyBhIHNvbHV0aW9uIHRo YXQgaGFzIGFscmVhZHkgc2hpcHBlZCDigJMgcmVxdWlyZW1lbnRzIHRoYXQgYXJlIGJ1aWx0IG9u IHNvbWV0aGluZyBlbnRpcmVseSBvdXRzaWRlIG9mIHRoZSBTUkgg4oCTIGFuZCBJIGZhaWwgdG8g c2VlIHdoeSBzdWNoIGEgc29sdXRpb24gc2hvdWxkIG5vdCBiZSBjYXRlcmVkIGZvciDigJMgb3Ig YWx0ZXJuYXRpdmVseSDigJMgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGVudGlyZWx5IG91dHNp ZGUgb2YgdGhlIHNjb3BlIG9mIHNwcmluZyAod2hpY2ggd291bGQgYmUganVzdCBmaW5lIGJ5IG1l KSBzbyB0aGF0IHRoZSB3b3JrIGNhbiBwcm9jZWVkIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUg SUVURiDigJMgcmF0aGVyIHRoYW4gZm9yY2luZyBpdCBvdXRzaWRlIG9mIHRoZSBJRVRGIGJlY2F1 c2Ugb2Ygc3RhbGxpbmcgYW5kIHRoaXMgdmlldyB0aGF0IHNvbWUgaG93IHRoZXJlIGNhbiBvbmx5 IGJlIG9uZSBzb2x1dGlvbiB0byBldmVyeSBwcm9ibGVtLiAgQnkgdGhlIHRpbWUgd2UgZ2V0IGFu eXRoaW5nIGRvbmUgaGVyZSwgd2Ugd2lsbCBiZSAxMCBtb250aHMgaW50byB0aGlzIOKAkyBhbmQg SSBwb2ludCBvdXQgdGhhdCBpbiB0aGUgbWVldGluZyBJIHN0YXRlZCA2IG1vbnRocyBhbmQgaXQg d2FzIGRpc3B1dGVkLiAgVGhlIGRlc2lnbiB0ZWFtIHdhcyBmaXJzdCBtdXRlZCBpbiBNYXkg4oCT IGl0IHRvb2sgMiBtb250aHMgdG8gZ2V0IGdvaW5nIOKAkyBidXQgdGhpcyBoYXMgYWN0dWFsbHkg YmVlbiA2IG1vbnRocywgYW5kIG5vdyB3ZSBhcmUgbG9va2luZyBhdCBhbm90aGVyIDQgbW9udGhz IGJlZm9yZSB3ZSBtZWV0IGFnYWluLg0KDQpUaGlzIGlzIG9uIHRvcCBvZiB0aGUgc3RhbGxpbmcg dGhhdCBoYXMgdGFrZW4gcGxhY2Ugc2luY2UgSUVURiAxMDYgb24gbW92aW5nIGZvcndhcmQgb24g YW55dGhpbmcgdGhhdCB0aGUgc3J2NiBwdW5kaXRzIHNlZW0gdG8gdmlldyBhcyBzb21lIGtpbmRh IGNvbXBldGl0aW9uIHRvIHRoZW0uICBUaGlzIGlzIGhhdmluZyB2ZXJ5IHJlYWwgd29ybGQgY29u c2VxdWVuY2VzIGZvciBjZXJ0YWluIG9wZXJhdG9ycyDigJMgYW5kIEkgY2FuIGFsc28gc3RhdGUg ZmxhdGx5LCB0aGlzIGlzIGJlZ2lubmluZyB0byBpbXBhY3Qgb24gbXkgZGVjaXNpb25zIGFzIHJl Z2FyZHMgdG8gdmVuZG9yIHB1cmNoYXNpbmcg4oCTIGFuZCB0aGF0IGlzIGFsc28gdGhlIG1lc3Nh Z2UgSSB3aWxsIGJlIHRha2luZyB0byB0aGUgb3BlcmF0b3JzIEkgd29yayB3aXRoIOKAkyB0aGF0 IHRoZXJlIGFyZSBjb21wZXRpbmcgc29sdXRpb25zIHRvIGNlcnRhaW4gdmVyeSBzcGVjaWZpYyBw cm9ibGVtcyDigJMgb25lIG9mIHRob3NlIHNvbHV0aW9ucyBpcyBzaGlwcGluZyBpbiBjb2RlIHRv ZGF5IOKAkyBpdCB3YXMgZGV2ZWxvcGVkIG91dHNpZGUgb2YgSUVURiBhZG9wdGlvbiBiZWNhdXNl IHRoZXJlIHdhcyBubyBhbHRlcm5hdGl2ZSB0byB0aGF0IOKAkyB3ZSBob3BlIG9uZSBkYXkgdG8g Z2V0IHRoZSBJRVRGIHRvIGJlIHdpbGxpbmcgdG8gd29yayBvbiB0aGlzIHRvIHJlZmluZSBpdCBh bmQgdGFrZSBpdCBmb3J3YXJkIOKAkyBidXQgdW50aWwgdGhlbiDigJMgaWYgeW91IHdhbnQgaXQg 4oCTIHRoaXMgaXMgd2hhdCB5b3UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gYnV5Lg0KDQpBbmRyZXcN Cg0K --_000_VI1PR03MB5056F05B67207E094D0DD14DEEFF0VI1PR03MB5056eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTWljcm9zb2Z0IEpoZW5nSGVpIjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1pY3Jvc29mdCBKaGVuZ0hl aSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJl bi1LRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJlbi1LRSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJlbi1LRSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNwcmluZyAmbHQ7c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN0ZWZhbm8gU2Fs c2Fubzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIDIwIE5vdmVtYmVyIDIwMjAgMDg6MDk8YnI+ DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij7nqIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBKaGVuZ0hlaSZxdW90OyxzYW5zLXNlcmlmIj7kvJ/lvLo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPiAmbHQ7Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7OyBzcHJpbmcgJmx0 O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHNyY29tcCAmbHQ7c3Jjb21wQGll dGYub3JnJmd0Ozsgc3ByaW5nLWNoYWlyc0BpZXRmLm8gJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBGdzpOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJl bWVudC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J bCAyMDIwLTExLTE1IDE2OjI3LCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij4NCueoizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPuS8n+W8ujwvc3Bhbj4gaGEgc2NyaXR0 bzo8YnI+DQomZ3Q7IEhpIEdyb3VwLDxicj4NCiZndDsgPGJyPg0KJmd0OyBTUiBjb21wcmVzc2lv biBkZXNpZ24gdGVhbSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGNvbXByZXNzaW9u IDxicj4NCiZndDsgcmVxdWlyZW1lbnQgZHJhZnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1haW4g Y2hhbmdlcyBhcyBmb2xsb3dzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAtIGFkZGVkIDMgaXRlbXMg YWJvdXQgc2NhbGliaWxpdHkmbmJzcDt3aXRoIGFncmVlbWVudCB3aXRoaW4gdGhlIGRlc2lnbiB0 ZWFtPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0mbmJzcDthZGRlZCBhbiBhcHBlbmRpeCZuYnNwO2lu Y2x1ZGluZyAzIGl0ZW1zIHdpdGhvdXQgd2l0aG91dCB1bmFuaW1vdXMgPGJyPg0KJmd0OyBjb25z ZW5zdXMgd2l0aGluIHRoZSBkZXNpZ24gdGVhbTxicj4NCjxicj4NCkhpIGFsbCw8YnI+DQo8YnI+ DQp0aGUgdGhlIGFwcGVuZGl4IEEgb2YgbGF0ZXN0IGRyYWZ0IHZlcnNpb24gaW5jbHVkZXMgdGhy ZWUgaXRlbXMgdGhhdCA8YnI+DQpzaG91bGQgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLCBp biBwYXJ0aWN1bGFyOjxicj4NCjxicj4NClJlcXVpcmVtZW50IEEuMi4xLiBTUnY2IEJhc2VkPGJy Pg0KUmVxdWlyZW1lbnQgQS4yLjIuIFNSdjYgRnVuY3Rpb25hbGl0eTxicj4NCjxicj4NCiZxdW90 O0Egc29sdXRpb24gdG8gY29tcHJlc3MgU1J2NiBTSUQgTGlzdHMgU0hPVUxEIGJlIGJhc2VkIG9u IHRoZSBTUnY2IDxicj4NCmFyY2hpdGVjdHVyZSwgY29udHJvbCBwbGFuZSBhbmQgZGF0YSBwbGFu ZSZxdW90OyBhbmQgJnF1b3Q7QSBzb2x1dGlvbiB0byBjb21wcmVzcyA8YnI+DQphbiBTUnY2IFNJ RCBsaXN0IE1VU1Qgc3VwcG9ydCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBTUnY2JnF1b3Q7PGJyPg0K PGJyPg0KSSd2ZSBiZWVuIHdvcmtpbmcgaW4gdGhlIGxhc3QgNCB5ZWFycyBvbiB0aGUgb3BlbiBz b3VyY2UgZWNvc3lzdGVtIDxicj4NCnN1cHBvcnRpbmcgU1J2NiwgaW5jbHVkaW5nIHRoZSBzdXBw b3J0IG9mIFNSdjYgaW4gdGhlIExpbnV4IGtlcm5lbDxicj4NCihzZWUgPGEgaHJlZj0iaHR0cHM6 Ly9uZXRncm91cC5naXRodWIuaW8vcm9zZSI+DQpodHRwczovL25ldGdyb3VwLmdpdGh1Yi5pby9y b3NlLzwvYT4pPGJyPg0KPGJyPg0KYSBsb3Qgb2YgZWZmb3J0IGhhcyBiZWVuIHNwZW50IGluIHRo aXMgZWNvc3lzdGVtIHRoYXQgbm93IG9mZmVycyBhIDxicj4NCmZlYXR1cmUgc2V0IGNvbXBhcmFi bGUgdG8gdmVuZG9ycycgaW1wbGVtZW50YXRpb24gb2YgU1J2Njxicj4NCjxicj4NCml0IGlzIHZl cnkgaW1wb3J0YW50IGZvciB0aGUgcmVzZWFyY2ggY29tbXVuaXR5IHRvIGhhdmUgc3VjaCBlY29z eXN0ZW0gPGJyPg0KYW5kIGl0IHdpbGwgYmUgcGFpbmZ1bCB0byByZWJ1aWxkIHRoZSBzdXBwb3J0 IGZvciBhIG5ldyBzb2x1dGlvbiBvdXRzaWRlIDxicj4NCm9mIHRoZSBjdXJyZW50IFNSdjYgYXJj aGl0ZWN0dXJlLi4uIG9uZSBvZiB0aGUgcHJvYmxlbSBvZiB0aGUgTVBMUyA8YnI+DQphcmNoaXRl Y3R1cmUgKGZyb20gdGhlIHJlc2VhcmNoIGNvbXVuaXR5IHBvaW50IG9mIHdpZXcpIHdhcyB0aGF0 IHRoZSA8YnI+DQpzdXBwb3J0IGluIExpbnV4IGhhcyBuZXZlciBiZWVuIGNvbXBhcmFibGUgdG8g dmVuZG9ycydzIHNvbHV0aW9uIChlLmcuIDxicj4NCmZvciB0aGUgY29udHJvbCBwbGFuZSksIGZv ciB0aGlzIHJlYXNvbiB0aGUgcmVzZWFyY2ggd29yayBkaXZlcmdlZCBhIGxvdCA8YnI+DQpmcm9t IHByb2R1Y3Rpb24gc29sdXRpb25zLCBJIHJlYWxseSB3b3VsZCBsaWtlIHRvIGF2b2lkIHN1Y2gg Z2FwIGFnYWluPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5NeSBpc3N1ZSB3aXRoIHRoaXMgaXMgdGhhdCB0aGVyZSBhcmUgb3BlcmF0b3JzIOKA kyB3aG8gaGF2ZSByZXF1aXJlbWVudHMgdG9kYXkg4oCTIHRoYXQgZW5jb21wYXNzIGEgc29sdXRp b24gdGhhdCBoYXMgYWxyZWFkeSBzaGlwcGVkIOKAkyByZXF1aXJlbWVudHMgdGhhdCBhcmUgYnVp bHQgb24gc29tZXRoaW5nIGVudGlyZWx5IG91dHNpZGUgb2YgdGhlIFNSSCDigJMgYW5kIEkgZmFp bCB0bw0KIHNlZSB3aHkgc3VjaCBhIHNvbHV0aW9uIHNob3VsZCBub3QgYmUgY2F0ZXJlZCBmb3Ig 4oCTIG9yIGFsdGVybmF0aXZlbHkg4oCTIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBlbnRpcmVs eSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBzcHJpbmcgKHdoaWNoIHdvdWxkIGJlIGp1c3QgZmlu ZSBieSBtZSkgc28gdGhhdCB0aGUgd29yayBjYW4gcHJvY2VlZCB3aXRoaW4gdGhlIGNvbnRleHQg b2YgdGhlIElFVEYg4oCTIHJhdGhlciB0aGFuIGZvcmNpbmcgaXQgb3V0c2lkZQ0KIG9mIHRoZSBJ RVRGIGJlY2F1c2Ugb2Ygc3RhbGxpbmcgYW5kIHRoaXMgdmlldyB0aGF0IHNvbWUgaG93IHRoZXJl IGNhbiBvbmx5IGJlIG9uZSBzb2x1dGlvbiB0byBldmVyeSBwcm9ibGVtLiZuYnNwOyBCeSB0aGUg dGltZSB3ZSBnZXQgYW55dGhpbmcgZG9uZSBoZXJlLCB3ZSB3aWxsIGJlIDEwIG1vbnRocyBpbnRv IHRoaXMg4oCTIGFuZCBJIHBvaW50IG91dCB0aGF0IGluIHRoZSBtZWV0aW5nIEkgc3RhdGVkIDYg bW9udGhzIGFuZCBpdCB3YXMgZGlzcHV0ZWQuJm5ic3A7DQogVGhlIGRlc2lnbiB0ZWFtIHdhcyBm aXJzdCBtdXRlZCBpbiBNYXkg4oCTIGl0IHRvb2sgMiBtb250aHMgdG8gZ2V0IGdvaW5nIOKAkyBi dXQgdGhpcyBoYXMgYWN0dWFsbHkgYmVlbiA2IG1vbnRocywgYW5kIG5vdyB3ZSBhcmUgbG9va2lu ZyBhdCBhbm90aGVyIDQgbW9udGhzIGJlZm9yZSB3ZSBtZWV0IGFnYWluLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhpcyBpcyBvbiB0b3Agb2YgdGhlIHN0YWxsaW5nIHRoYXQgaGFzIHRha2VuIHBsYWNl IHNpbmNlIElFVEYgMTA2IG9uIG1vdmluZyBmb3J3YXJkIG9uIGFueXRoaW5nIHRoYXQgdGhlIHNy djYgcHVuZGl0cyBzZWVtIHRvIHZpZXcgYXMgc29tZSBraW5kYSBjb21wZXRpdGlvbiB0byB0aGVt LiZuYnNwOyBUaGlzIGlzIGhhdmluZyB2ZXJ5IHJlYWwgd29ybGQgY29uc2VxdWVuY2VzIGZvciBj ZXJ0YWluDQogb3BlcmF0b3JzIOKAkyBhbmQgSSBjYW4gYWxzbyBzdGF0ZSBmbGF0bHksIHRoaXMg aXMgYmVnaW5uaW5nIHRvIGltcGFjdCBvbiBteSBkZWNpc2lvbnMgYXMgcmVnYXJkcyB0byB2ZW5k b3IgcHVyY2hhc2luZyDigJMgYW5kIHRoYXQgaXMgYWxzbyB0aGUgbWVzc2FnZSBJIHdpbGwgYmUg dGFraW5nIHRvIHRoZSBvcGVyYXRvcnMgSSB3b3JrIHdpdGgg4oCTIHRoYXQgdGhlcmUgYXJlIGNv bXBldGluZyBzb2x1dGlvbnMgdG8gY2VydGFpbiB2ZXJ5IHNwZWNpZmljDQogcHJvYmxlbXMg4oCT IG9uZSBvZiB0aG9zZSBzb2x1dGlvbnMgaXMgc2hpcHBpbmcgaW4gY29kZSB0b2RheSDigJMgaXQg d2FzIGRldmVsb3BlZCBvdXRzaWRlIG9mIElFVEYgYWRvcHRpb24gYmVjYXVzZSB0aGVyZSB3YXMg bm8gYWx0ZXJuYXRpdmUgdG8gdGhhdCDigJMgd2UgaG9wZSBvbmUgZGF5IHRvIGdldCB0aGUgSUVU RiB0byBiZSB3aWxsaW5nIHRvIHdvcmsgb24gdGhpcyB0byByZWZpbmUgaXQgYW5kIHRha2UgaXQg Zm9yd2FyZCDigJMgYnV0IHVudGlsIHRoZW4NCiDigJMgaWYgeW91IHdhbnQgaXQg4oCTIHRoaXMg aXMgd2hhdCB5b3UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gYnV5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_VI1PR03MB5056F05B67207E094D0DD14DEEFF0VI1PR03MB5056eurp_-- From nobody Fri Nov 20 13:11:06 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6933A03FA; Fri, 20 Nov 2020 13:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 OMKalITUndVT; Fri, 20 Nov 2020 13:10:44 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 15F5B3A03F8; Fri, 20 Nov 2020 13:10:43 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id t37so8288433pga.7; Fri, 20 Nov 2020 13:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HVqPPl4GuzSQxU7gwyD0TqLs2eYORVqviHayiFj0arY=; b=ZvFfHichZ+LAoNwtkXuT2vfjPEHWZPHCosuDJyXeQZQZP0g5dNRxQnCmK4bU5pcQIy +N7aM10+5a6mBIpWgPaNhL8pfyQgIxiG3yNQF/Pv3uwaubEFR+br+DKO5Bjt6nWkpFcG 0IwWfZ/vxuIBvujmwHWam0md2zy8yPAOvEMbubqn77V+ExyoH4U6VA0vVcnNBcVFexcE dttpjp4z9EhOMX5YbL93tArm+7KxB+nCUc4O3yYrXaaT3mqLGG9899zDW3sOfwXSt1/N u6xIxoPkcuN0VCcj2RiUmFsgB1I4ulmeDv7IV4KeAiJMwUj60xq6/0DbqiyqZeCLlDR1 KhFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HVqPPl4GuzSQxU7gwyD0TqLs2eYORVqviHayiFj0arY=; b=gtLzEDwYJdrwVY8S9MSdaTNxONzrdstxkAle9pCvp+vXvhNlh6JWQ+TbgmFPyXem0E vBBS+ACs13i1YmZfBoEnfJW9SKUFbw7Wqx6P1SvO1ABb/V2g0293gQ1PWYqJaOqP3+DG sxs4nIdRYyC1LxXcHOTINZi5Pb5rfImkTfz1KrneoBd36X10glhKB3rnpOh0saS0pOHH nnxkxxL18flNcmqMSfhNtCZjbr8K4KzLXG3fSQ+jD7F3aLXB3dMc/Z8Cq1cvaGXCxme9 ioSsR2kwo4B18VQs+R03AzawQEbf+3iUNO4iiJOs3Xuf8TkrnUhts1U3f8nXCsGM26hq QTcg== X-Gm-Message-State: AOAM531DmGVjWmp/KAO6HtOcAP4Jn9VBXiy0q2p6vNguPR7GQUyZRgJf ThaAU9UOGjROpuKygdqopMb/ODZaM3xxsUeovyNqmQCZwNk= X-Google-Smtp-Source: ABdhPJzwwWXkS/rFf4J7op5wJTVaMEuWkqOiHnwKeT7TGJ7y8e2meuT9G8SMb/AbeNls1rACgw1goGDcVdfL/wIZITQ= X-Received: by 2002:a65:56c8:: with SMTP id w8mr18687502pgs.383.1605906643271; Fri, 20 Nov 2020 13:10:43 -0800 (PST) MIME-Version: 1.0 References: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk> In-Reply-To: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk> From: Gyan Mishra Date: Fri, 20 Nov 2020 16:10:32 -0500 Message-ID: To: adrian@olddog.co.uk Cc: BESS , BIER WG , IDR List , SPRING WG , TEAS WG , lsr , pce@ietf.org Content-Type: multipart/alternative; boundary="00000000000003c42c05b490476d" Archived-At: Subject: Re: [spring] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 21:10:48 -0000 --00000000000003c42c05b490476d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, In line Kind Regards Gyan On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel wrote: > Hi Gyan, > > > > Sorry, I missed this (got caught on a filter cos it was a bit spammed to = a > lot of lists :-). > > > > > I have noticed that after reviewing many drafts across many WGs it seem= s > in the > > > industry that the lines seem to be blurred between a PCE controller, OD= L > or > > > Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X > > > provisioning. > > > > Yes, blurriness our speciality. > > Gyan> :) > > You my find RFC 7491 useful in this respect, although it is a little > dated. And, of course, RFC 8283 is a good starting point. > > Gyan> Thanks > > As this is a software sitting on a server you can have a swiss army knife > server that > > > does everything from PCE path computation to Netconf/Yang ZTP & Day N > > > provisioning as well as any SDN Controller ODL or Openflow controller > type > > > functions as well. > > > > Yes, and this is one of the risks of PCE as a shiny thing: that it be > converted from a useful toolkit into some form of god-box. I pontificated > on this way back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf > > Gyan> My sentiments exactly - With that power at your fingertips comes > responsibility. > > How this comes into play and realization of the lines being blurred is > the use of > > > BGP-LS in building the IGP topological graph of the network which was > designed > > > for PCEP and PCE & PCC active & passive off line path computation for > both > > > RSVP-TE or SR-TE path instantiation. > > > > In some senses, BGP-LS didn=E2=80=99t add anything because a PCE could ha= ve > snooped on the IGP. But BGP-LS provides an export mechanism and important= ly > adds to that some policy filters to determine what is exported thus givin= g > the network some control over what is exported. > > Gyan> Agreed > > FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > proposes using PCEP for the same function. The argument in favor is that = a > PCE has to implement PCEP anyway, so why not include the LS export as wel= l. > The argument against is that BGP-LS has wider applicability and that it > will typically be exported from an ASBR which already supports BGP. > > Gyan> Makes sense and in some ways cuts out the middle man BGP-LS > overloading burden on BGP. Great idea. I like it. Another very valuabl= e > tool in the operators toolbox. > > > However now BGP-LS can also be used for other functions now such as > usage as > > > I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use > BGP-LS to > > > gather the elements internals within BIER using the same BGP-LS data > structures > > > to populate with BIER specific information to graph the BIER topology. > So here > > > we are not doing any path computations as we are using in this use case > for > > > NMS type function to gather data for ZTP & Day N provisioning. > > > > > > Similarly other use cases such as with TEAS TS-Transport slice and bein= g > able > > > to provision TS and capturing the TS Enhanced VPN RT & resource > information > > > and leveraging BGP-LS to do the same data gathering & ZTP like > controller style > > > provisioning. > > > > Is there a fundamental difference between ZTP & Day N provisioning and > path computation for traffic engineering provisioning? It=E2=80=99s all d= etermining > how to configure the network to best carry traffic. > > > Gyan> In my mind the fundamental difference would be TE - control plane TEDs and forwarding plane routing action path computation and instantiation of path action as compare to a NMS type Netconf/Yang configuration snippet push function not routing or TE related. > > It does seem as though BGP-LS as its a means of "data gathering" "dump > truck" > > > of anything with the kitchen sink included to build any type of > topological graph > > > of literally anything under the sun. > > > > Remembering Yakov Rekhter saying you could use BGP to transport > Shakespeare. > > This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets > added, further use gets made. > > Gyan> Understood > > BGP-LS was intended to export routing information =E2=80=9Cnorthbound=E2= =80=9D from the > network. > > Gyan> Understood > > > I see that is a nice to leverage but it does in fact blur the lines of > NMS Netconf/Yang > > > Controller based functionality and PCE path computation functionality > and SDN > > > controller based ZTP functionality into a single ubiquitous server that > can do all of > > > the above and use BGP-LS to accomplish the "kitchen sink" tasks. It > does however > > > transform BGP to be an NMS tool but a "tool" and not just the original > function > > > which it was intended NLRI network reachability. > > > > Not sure that BGP-LS is BGP. But I agree that BGP-LS is =E2=80=9Can NMS t= ool=E2=80=9D. > > I might argue that BGP distributing policies from installation on PEs is > an NMS protocol. > > Gyan> Agreed. One way to look at it is that as BGP primary function is > routing, however there many code points that are not necessarily routing > related , and BGP provides the ability to have each code point or SAFI or > parameters as a discrete container - to be enabled as desired, however wi= th > that flexibility not all containers have to be used by the operator. So > the operator can custom tailor what SAFI, codepoint or parameters are > required for the implementation per design requirements and only enable > those that are necessary. So that would of course be the case for BGP-LS= . > So in that case BGP can be utilized for routing or as an NMS tool extendi= ng > Netconf/Yang via BGP-LS or any other function that requires import of dat= a > structures. And that=E2=80=99s Ok. > > Am I off base and please let me know as its BGP-LS is being way over > leveraged. > > > There are pros & cons to everything but I thought I would bring up to > the WG as > > > an important discussion point. > > > > Who are we to argue with real implementations? Assuming that there is a > push for implementation and deployment, then the thing to look for is > =E2=80=9Charm=E2=80=9D. Does this use of BGP-LS cause harm, sow confusion= , risk > destabilising the network? Should it use a different code point to be > distinguishable? > > Gyan> Completely agree. I agree negative impact if any exist. See my > comments above. As BGP has the ability to compartmentalize SAFI, > codepoints and parameters into containers to be used discretely for > specific use cases tailored to the operators need. So it may feel that we > are throwing the kitchen sink at BGP and as that may not have been the > intention way back but as BGP is customizable BGP can truly be a ubiquito= us > tool in the operators toolbox. > > I think the argument that =E2=80=9Cthere is already another protocol for = doing > this=E2=80=9D is worth examining. But we have to be careful that it doesn= =E2=80=99t get us > stuck, or force everyone to do something they don=E2=80=99t want to do. A= fter all, > we could carry any protocol message using Netconf/YANG, but we don=E2=80= =99t do > =E2=80=9CRSVP-TE over Netconf=E2=80=9D. > Gyan> Agreed Many thanks for your feedback! > > > Best, > > Adrian > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000003c42c05b490476d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Adrian,

    In line=C2=A0

    Kind Regards=C2=A0

    Gyan
    On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
    =

    Hi Gyan,

    =C2=A0

    Sorry, I missed this (got caught on a filter cos it was a bit spammed to a= lot of lists :-).

    = =C2=A0

    > I have no= ticed that after reviewing many drafts across many WGs it seems in the

    > industry that the lines seem to be= blurred between a PCE controller, ODL or

    > Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP &= amp; Day X

    > provisioning.

    =C2=A0

    Yes, blurriness our speciality.

    =C2=A0Gyan> :)

    = You my find RFC 7491 useful in this respect, although it is a little dated.= And, of course, RFC 8283 is a good starting point.

    =C2=A0Gyan> Thanks=C2=A0

    <= /div>

    <= u>

    > As this is a software sitt= ing on a server you can have a swiss army knife server that

    > does everything from PCE path computation to= =C2=A0 Netconf/Yang ZTP & Day N

    > provisioning as well as any SDN Controller ODL or Openflow controlle= r type

    > functions as well.

    =C2=A0

    Yes, and this is one of the risks of PCE as a shiny thing: that it = be converted from a useful toolkit into some form of god-box. I pontificate= d on this way back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf<= u>

    =C2=A0Gyan> = My sentiments exactly - With that power at your fingertips comes responsibi= lity. =C2=A0

    > How= this comes into play and realization of the lines being blurred is the use= of

    > BGP-LS in building the IGP= topological graph of the network which was designed

    > for PCEP and PCE & PCC active & passive off = line path computation for both

    >= RSVP-TE or SR-TE path instantiation.=C2=A0=C2=A0

    =C2=A0

    In some sense= s, BGP-LS didn=E2=80=99t add anything because a PCE could have snooped on t= he IGP. But BGP-LS provides an export mechanism and importantly adds to tha= t some policy filters to determine what is exported thus giving the network= some control over what is exported.

    =C2=A0Gyan> Agreed=C2=A0

    FWIW, https://datatracker.ietf.org/doc/draft-dhodyl= ee-pce-pcep-ls/ proposes using PCEP for the same function. The argument= in favor is that a PCE has to implement PCEP anyway, so why not include th= e LS export as well. The argument against is that BGP-LS has wider applicab= ility and that it will typically be exported from an ASBR which already sup= ports BGP.

    =C2= =A0Gyan> Makes sense and in some ways cuts out the middle man BGP-LS ove= rloading burden on BGP.=C2=A0 Great idea.=C2=A0 I like it.=C2=A0 Another ve= ry valuable tool in the operators toolbox.

    > However now BGP-LS can also be used for other functions no= w such as usage as

    > I am a Shep= herd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to=

    > gather the elements internals within BI= ER using the same BGP-LS data structures

    > to populate with BIER specific information to graph the BIER top= ology.=C2=A0 So here

    > we are no= t doing any path computations as we are using in this use case=C2=A0 for=

    > NMS type function to gather data= for ZTP & Day N provisioning.

    >=C2=A0

    &g= t; Similarly other use cases such as with TEAS TS-Transport slice and being= able

    > to provision TS and capt= uring the TS Enhanced VPN RT & resource information

    > and leveraging BGP-LS to do the same data gatheri= ng & ZTP like controller style

    = > provisioning.=C2=A0

    =C2=A0

    Is there a fundamental diff= erence between ZTP & Day N provisioning and path computation for traffi= c engineering provisioning? It=E2=80=99s all determining how to configure t= he network to best carry traffic.

    <= u>=C2=A0

    =C2= =A0 =C2=A0Gyan> In my mind the fundamental difference would be TE - cont= rol plane TEDs and forwarding plane routing action path computation and ins= tantiation of path action as compare to a NMS type Netconf/Yang configurati= on snippet push function not routing or TE related.
    =

    &g= t; It does seem as though BGP-LS as its a means of "data gathering&quo= t; "dump truck"

    > of a= nything with the kitchen sink included to build any type of topological gra= ph

    > of literally anything under= the sun.

    =C2=A0

    <= p class=3D"MsoNormal">Remembering Yakov Rekhter saying you could use BGP to= transport Shakespeare.

    This is a = tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, furthe= r use gets made.

    =C2=A0Gyan> Understood=C2=A0

    BGP-LS w= as intended to export routing information =E2=80=9Cnorthbound=E2=80=9D from= the network.

    = =C2=A0Gyan> Understood=C2=A0

    >=C2=A0= I see that is a nice to leverage but it does in fact blur the lines of NMS = Netconf/Yang

    > Controller based = functionality and=C2=A0 PCE path computation functionality and SDN

    > controller based ZTP functionality int= o a single ubiquitous server that can do all of

    > the above and use BGP-LS to accomplish the "kitche= n sink" tasks.=C2=A0 It does however

    > transform BGP to be an NMS tool but a "tool" and not = just the original function

    > whi= ch it was intended NLRI network reachability.

    =C2=A0

    Not sure that BGP= -LS is BGP. But I agree that BGP-LS is =E2=80=9Can NMS tool=E2=80=9D.

    I might argue that BGP distributing poli= cies from installation on PEs is an NMS protocol.

    =C2=A0Gyan> Agreed.= =C2=A0 One way to look at it is that as BGP primary function is routing, ho= wever there many code points that are not necessarily routing related , and= BGP provides the ability to have each code point or SAFI or parameters as = a discrete container - to be enabled as desired, however with that flexibil= ity not all containers have to be used by the operator.=C2=A0 So the operat= or can custom tailor what SAFI, codepoint or parameters are required for th= e implementation per design requirements and only enable those that are nec= essary.=C2=A0 So that would of course be the case for BGP-LS.=C2=A0 So in t= hat case BGP can be utilized for routing or as an NMS tool extending Netcon= f/Yang via BGP-LS or any other function that requires import of data struct= ures. =C2=A0 And that=E2=80=99s Ok.=C2=A0

    =

    > Am I off base and please let me know a= s its BGP-LS is being way over leveraged.=C2=A0

    > There are pros & cons to everything but I thought I= would bring up to the WG as

    > a= n important discussion point.

    =C2=A0

    Who are we to argue with real imp= lementations? Assuming that there is a push for implementation and deployme= nt, then the thing to look for is =E2=80=9Charm=E2=80=9D. Does this use of = BGP-LS cause harm, sow confusion, risk destabilising the network? Should it= use a different code point to be distinguishable?

    Gyan> Completely agree.=C2=A0 I agre= e negative impact if any exist.=C2=A0 See my comments above.=C2=A0 As BGP h= as the ability to compartmentalize SAFI, codepoints and parameters into con= tainers to be used discretely for specific use cases tailored to the operat= ors need. So it may feel that we are throwing the kitchen sink at BGP and a= s that may not have been the intention way back but as BGP is customizable = BGP can truly be a ubiquitous tool in the operators toolbox.

    I think the argument that =E2=80=9Cthere is already anot= her protocol for doing this=E2=80=9D is worth examining. But we have to be = careful that it doesn=E2=80=99t get us stuck, or force everyone to do somet= hing they don=E2=80=99t want to do. After all, we could carry any protocol = message using Netconf/YANG, but we don=E2=80=99t do =E2=80=9CRSVP-TE over N= etconf=E2=80=9D.


    =C2=A0 =C2=A0Gyan> Agreed

    Many thanks for your feedback!
    =
    =

    =C2=A0

    Best,

    Adrian

    =C2=A0

    <= /div>
    --


    Gyan Mishra

    Network Solutions Architect=C2=A0

    <= i>M 301 502-1347
    13101 Columbia Pike=C2=A0=
    Silver Spring, MD


    =
    --00000000000003c42c05b490476d-- From nobody Sat Nov 21 07:15:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF3F3A0D85; Sat, 21 Nov 2020 07:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iH1iN1XOLbts; Sat, 21 Nov 2020 07:15:35 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58D93A0D84; Sat, 21 Nov 2020 07:15:34 -0800 (PST) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CdcPp5sS9z67G1f; Sat, 21 Nov 2020 23:13:50 +0800 (CST) Received: from fraeml703-chm.china.huawei.com (10.206.15.52) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Sat, 21 Nov 2020 16:15:29 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Sat, 21 Nov 2020 16:15:29 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.152]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Sat, 21 Nov 2020 23:15:26 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: Meeting minutes for the SPRING sessions @IETF109 Thread-Index: AdbAGRfGMzWYxb4KQLio+b88ZU92fA== Date: Sat, 21 Nov 2020 15:15:26 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE19616F3A@dggeml512-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.184.143] Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE19616F3Adggeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Meeting minutes for the SPRING sessions @IETF109 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 15:15:39 -0000 --_000_4278D47A901B3041A737953BAA078ADE19616F3Adggeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Please find the meeting minutes for the two SPRING sessions @IETF109. https://codimd.ietf.org/notes-ietf-109-spring?edit Please check and correct. e.g. , your name and your comments. Thank you! Cheers! Best regards, Shuping --_000_4278D47A901B3041A737953BAA078ADE19616F3Adggeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Folks,

     

    Please find the meeting minutes= for the two SPRING sessions @IETF109.

    https://codimd.ietf.org/notes-ietf-109-spri= ng?edit

     

    Please check and correct. e.g. = , your name and your comments. Thank you!

     

    Cheers!

     

    Best regards,

    Shuping

     

     

    --_000_4278D47A901B3041A737953BAA078ADE19616F3Adggeml512mbxchi_-- From nobody Sat Nov 21 07:47:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE063A0DED; Sat, 21 Nov 2020 07:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 7a_VHaktI76Q; Sat, 21 Nov 2020 07:47:03 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 9599A3A0E33; Sat, 21 Nov 2020 07:46:58 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ALFkssH025045; Sat, 21 Nov 2020 15:46:55 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C2BF62203A; Sat, 21 Nov 2020 15:46:54 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id AD19722032; Sat, 21 Nov 2020 15:46:54 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.90]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ALFkroZ020064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Nov 2020 15:46:54 GMT Reply-To: From: "Adrian Farrel" To: "'Gyan Mishra'" Cc: "'BESS'" , "'BIER WG'" , "'IDR List'" , "'SPRING WG'" , "'TEAS WG'" , "'lsr'" , References: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk> In-Reply-To: Date: Sat, 21 Nov 2020 15:46:53 -0000 Organization: Old Dog Consulting Message-ID: <039401d6c01d$893ded90$9bb9c8b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0395_01D6C01D.893E62C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF9YbXHIOSWBk8yeY9fu/naMBX0BwJnuPwTAbmwFjqqZGg3wA== Content-Language: en-gb X-Originating-IP: 195.166.134.90 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25804.001 X-TM-AS-Result: No--19.728-10.0-31-10 X-imss-scan-details: No--19.728-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25804.001 X-TMASE-Result: 10--19.728200-10.000000 X-TMASE-MatchedRID: TmlY9+XBoTmx4Q5iE/G4VXFPUrVDm6jth4A8KRmrGe2qvcIF1TcLYEwi cw3eWSo0YLQ3+9wW9SYaHpAEsECl+h0HHInBeaK9JOMhINYq80wHgh3sKJBzP8pj/9aYiP+h3SZ uwROk0qHmLM5grIF7CSLuZAk1qAxOehY/DCk+INGecgASc+pqBczdhaN37iAM5lhx0mBJyPEcUn IIyt02Sa9sD66wAjsxf6x5zoWNtEgpNfI+R65HNc50DGuIExk9fiA7Y+GFqDOsaBVGMabQl+//v bMLiEkVS23jFwoI7b1+1uW3cIJ1vBWVVkGuW6Jr3zSg/bkXzGmOz/LLJUcaHsmqrXFLFjsW6aX8 TYIrj1uFZCZln65Hjpt6E4YKOIuohfUatHkEWNT4Wr1WT+bU2pkShYcLpGH9dPj9LUBj/ks8Pun 5tcXDXI0id0pIhqxT48CdlKt5w6+7Cjv/4LgPYmhQCsqhuTNihlL5/PVMMhK+vSKPcZwFluCfwd Xr9Uztu7C4hieFwVKAMuqetGVettLvsKjhs0lda9+JVKonO7eLZAVphLW/bXkguuQorcgMg5IQ3 dbS17M+Pal/bipFlwhigbA7cP7I6E96vWKSeR9+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [spring] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 15:47:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0395_01D6C01D.893E62C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi again Gyan, =20 I think we=E2=80=99re narrowing down and getting somewhat esoteric for = the mailing lists we=E2=80=99re spamming. > Similarly other use cases such as with TEAS TS-Transport slice and = being able > to provision TS and capturing the TS Enhanced VPN RT & resource = information > and leveraging BGP-LS to do the same data gathering & ZTP like = controller style > provisioning.=20 Is there a fundamental difference between ZTP & Day N provisioning and = path computation for traffic engineering provisioning? It=E2=80=99s all = determining how to configure the network to best carry traffic.=20 Gyan> In my mind the fundamental difference would be TE - control plane = TEDs and forwarding plane routing action path computation and instantiation of = path action as compare to a NMS type Netconf/Yang configuration snippet push = function not routing or TE related. =20 [Adrian] I think it depends. The protocols are just tools. You could = have a centralised TE system with a PCE to preform computations, but you = can use any combinations of protocols to extract information from the = network (IGPs, BGP-LS, PCEP-LS, Netconf, =E2=80=A6) and any combination = of protocols to program the network devices to install TE paths, reserve = resources, and configure traffic forwarding rules (PCEP, RSVP-TE, = Netconf, =E2=80=A6). =20 Cheers, Adrian ------=_NextPart_000_0395_01D6C01D.893E62C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Hi again = Gyan,

     

    I think = we=E2=80=99re narrowing down and getting somewhat esoteric for the = mailing lists we=E2=80=99re = spamming.

    > = Similarly other use cases such as with TEAS TS-Transport slice and being = able
    > to provision TS and capturing the TS Enhanced VPN RT & = resource information
    > and leveraging BGP-LS to do the same data = gathering & ZTP like controller style
    > = provisioning. 

    Is there a = fundamental difference between ZTP & Day N provisioning and path = computation for traffic engineering provisioning? It=E2=80=99s all = determining how to configure the network to best carry = traffic. 

    Gyan> In my mind the fundamental difference would = be TE - control plane TEDs and
    forwarding plane routing action path = computation and instantiation of path action
    as compare to a NMS type = Netconf/Yang configuration snippet push function not
    routing or TE = related.

     

    [Adrian] I think it depends. The protocols are just = tools. You could have a centralised TE system with a PCE to preform = computations, but you can use any combinations of protocols to extract = information from the network (IGPs, BGP-LS, PCEP-LS, Netconf, =E2=80=A6) = and any combination of protocols to program the network devices to = install TE paths, reserve resources, and configure traffic forwarding = rules (PCEP, RSVP-TE, Netconf, =E2=80=A6).

     

    Cheers,

    Adrian

    ------=_NextPart_000_0395_01D6C01D.893E62C0-- From nobody Sun Nov 22 12:24:28 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0AD3A0C7C; Sun, 22 Nov 2020 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 C5VO2DDlyEzG; Sun, 22 Nov 2020 12:24:25 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 5DACB3A0C7A; Sun, 22 Nov 2020 12:24:25 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id w24so15478103wmi.0; Sun, 22 Nov 2020 12:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ursvV4Ce1kWQMhZLZNe3Vbe7YjJ1sr9KTvGqxByZm14=; b=PKqf8ZxzgZEldnG6IM71JpdrbqOLU0iY5X5RUPuE9a6OmbnLEBGPfEUUUhVZ6LWhaf RPY1YQGJppDA12vKAx/sZQxbGSeFj07fDCune9VUAqJXdDTLom/v0WsiCmz24x1SUw4Q jwAt2f1WFmV1Hh0CQoXs9AjjCWHqcZgwe8k4urS2nEFjP4RQJBmUvBbW3nxj1K+AKPd+ od4uyF+YZMNvfwIyvilOyb13Iy5Dix6EKuvJ9ynWQhJQZW4oSDvfKfif+PQItxx8ZL1T u31hUSr7+Wz3KowKqFx5nRaqpQbDcIgCK1tH0rPVFZmUAkSuDx89ZWsv6uP3PUwoXDTf dN2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ursvV4Ce1kWQMhZLZNe3Vbe7YjJ1sr9KTvGqxByZm14=; b=AdSSpebhaFcbQQKextvYW8RRgnSg9BWYW4k7WCufWShmfctb49U/zdBhCZEDYOvzsp Z1bQCnDhf7aJrw5SXZSuF49jSxckSp6gowbRgGRkC0TEc69oDgEA3vv9BL1+YaK7akjf 6HdtstlAoX+Y2G4da5VjvH7MNvFkYNmueWzs1NUpMXE4ghtYTVSeZVPZjEVgCAJvUr5C 1cEUArQbKO/itHKDmNpCBIYj6VBP3dkeKWIXodV9giN4fJpk7gdxhEQ92C/VphZcWJR+ fE5nYHIeqasg8lkC1zw4AsjdUnoSDvYsXe+AUhgTGnIzfj2q/36ZgAv8Q4flDfQyzjfc 0zyA== X-Gm-Message-State: AOAM532kmqwifzfiErpaPc9FG9CdnPdY+2KjKaIQuLyZKPMWppM2RqYy xkbPHspUbwOrMuk6qSq8rho= X-Google-Smtp-Source: ABdhPJxRZcupNsjdoYK32ZulduVmousudBRY5cZjL0Y6X8q80EL7sIhdiKr41CIAwjAJQR0sXrgD6A== X-Received: by 2002:a05:600c:4101:: with SMTP id j1mr19990394wmi.35.1606076663571; Sun, 22 Nov 2020 12:24:23 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:25e9:ce3:685c:a8b6? ([2601:647:5a00:ef0b:25e9:ce3:685c:a8b6]) by smtp.gmail.com with ESMTPSA id n11sm14724211wru.38.2020.11.22.12.24.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Nov 2020 12:24:22 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4118B7F8-E4CA-4740-9C62-2F6EB44EEF18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Bob Hinden X-Priority: 3 In-Reply-To: <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> Date: Sun, 22 Nov 2020 12:24:17 -0800 Cc: Bob Hinden , spring , srcomp , "spring-chairs@ietf.o" Message-Id: References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> To: =?utf-8?B?56iL5Lyf5by6?= X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [spring] New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 20:24:28 -0000 --Apple-Mail=_4118B7F8-E4CA-4740-9C62-2F6EB44EEF18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I noticed that the title of Appendix A does not match the text. It = says: Appendix A. Proposed Requirements This appendix contains requirements that the design team discussed but could not be agreed upon. Please change the title to something like =E2=80=9CRequirement with no = Consensus=E2=80=9D or similar. Bob > On Nov 15, 2020, at 7:27 AM, =E7=A8=8B=E4=BC=9F=E5=BC=BA = wrote: >=20 > Hi Group, >=20 > SR compression design team have submitted a new version of compression = requirement draft. >=20 > Main changes as follows: >=20 > - added 3 items about scalibility with agreement within the design = team >=20 > - added an appendix including 3 items without without unanimous = consensus within the design team >=20 > - some minor text issue fixed >=20 > Please review it and let us know your comments. >=20 >=20 >=20 > BTW: We will have 1-hour session for the design team topic on Friday = and welcome to join us. >=20 >=20 >=20 > B.R. >=20 > Weiqiang on behalf of design team >=20 >=20 >=20 >=20 > ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts = > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AWeiqiang Cheng = ,Sander Steffann ,SJM = Steffann > =E6=8A=84=E3=80=80=E9=80=81: (=E6=97=A0) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2020-11-15 22:58:57 > =E4=B8=BB=E9=A2=98=EF=BC=9ANew Version Notification for = draft-srcompdt-spring-compression-requirement-01.txt >=20 >=20 > A new version of I-D, = draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. >=20 > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: = https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirem= ent-01.txt > Status: = https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-require= ment/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-re= quirement > Htmlized: = https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-= 01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requ= irement-01 >=20 > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. >=20 >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 >=20 >=20 > Subject=EF=BC=9ANew Version Notification for = draft-srcompdt-spring-compression-requirement-01.txt >=20 >=20 > A new version of I-D, = draft-srcompdt-spring-compression-requirement-01.txt > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. >=20 > Name: draft-srcompdt-spring-compression-requirement > Revision: 01 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-11-13 > Group: Individual Submission > Pages: 13 > URL: = https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirem= ent-01.txt > Status: = https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-require= ment/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-re= quirement > Htmlized: = https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-= 01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-srcompdt-spring-compression-requ= irement-01 >=20 > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. >=20 >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_4118B7F8-E4CA-4740-9C62-2F6EB44EEF18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+6yPEACgkQrut0EXfn u6gW3Af/YnXYdyQsR2PN4/U4jqL5512S1JmN3WJHk3Je7y3ZkDbN35CPpeDnC6il /HM0hwtOEaO08w8wLFRVNbtnLlZ9AeXR4wcO+8m86vsVrv2Ffo4lC0JKbS6NhWO4 o3Cl5kEM5XBVHd+JSM4Z2rvi8Ij4rjDTLL4WhfsurWTH7UOpiot+2z9KK9q/IOPz 5wLRBrfIfEHK8GbJGD2xV3DldihybnAsOOkWpOK/OT0+nBKKVD13WKNbwJQ5RTDN arGklFcaky6uKgH/fh5AdCNBtwAytAXvTsMh/F8WVRbaT7APTa5/O8pPo6PJcKwn u1FPmvkDZQX0MAyKDN7Sn5Hmsx0n+g== =GWu7 -----END PGP SIGNATURE----- --Apple-Mail=_4118B7F8-E4CA-4740-9C62-2F6EB44EEF18-- From nobody Mon Nov 23 09:27:55 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C3C3A098A; Mon, 23 Nov 2020 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=g4YBUa3q; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=whNwOo+4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyhSKp2bSGn8; Mon, 23 Nov 2020 09:27:43 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850E43A08C0; Mon, 23 Nov 2020 09:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6926; q=dns/txt; s=iport; t=1606152463; x=1607362063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+lvEWiaW+pMKbhIH91B1ZWkRJ9XvceOtRMpnDQf2L4I=; b=g4YBUa3q2+E7qqZVXQrLc3SFlXzsquvT8WTaWpnCUtdtay1iA16RtCvk M6XGVVDLPidt0UVZwzejPjvOemb3kUFt/Uf727CugqEyzsBpXpDeaFU86 lxnzXUNHDJoeZt7BoXi7jucdb6/ZNSd7xxbhc7oD6/kMLshngxHVpQSqb I=; X-IPAS-Result: =?us-ascii?q?A0DiCADV77tffZNdJa1iHgEBCxIMQIMhUXtZLy4KhDODS?= =?us-ascii?q?QONWZkEglMDVAsBAQENAQEYCwoCBAEBhEoCF4IUAiU4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBhjwMhXMBAQEDAQEQEREMAQEsCwEPAgEIGAICHwcCAgIlC?= =?us-ascii?q?xUQAgQBDQUigwQBglUDLgEOpHkCgTyIaHaBMoMEAQEFgUdBgxkYghADBoEOK?= =?us-ascii?q?oJzg3aGVxuCAIERJxyCTz6CXQEBAwGBFR4/gwAzgiyTcYdInREKgm6JE5ILA?= =?us-ascii?q?x+DGooZlFIdkz+LBJVcAgQCBAUCDgEBBYFrIYFZcBUaISoBgj5QFwINjh8MF?= =?us-ascii?q?xSDOoUUhUR0NwIGAQkBAQMJfIsHgTQBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3ASZmFXRL8vXDv58kL29mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv68/hkPCWoPd5vlYzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX0e1bVpHu/5iJUER?= =?us-ascii?q?L6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,364,1599523200"; d="scan'208";a="634966063" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2020 17:27:42 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ANHRgRl028961 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2020 17:27:42 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 11:27:42 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 11:27:41 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 23 Nov 2020 11:27:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3njAVUbXmvwaRRXPNLS4dETK6Vo5zgN2UKz848MUL2Kwxp9tDJGriUXP3EfAuBPXEHnqco3Ol8KCol8+CfPYoXSLngbi3VnGgRSDmO24X6t4zZcOCDcktQTTC7hPnEXnlT7jKhrB4i5GkhgPOgAcNhMKhZWXEOMR7EojKjREv76c1QkzLayBBazLZOkm/5b5LZ79GBB751edMQ+touf1CumcgvUpeBbd8AM3nZD5tFUPfB0xwZPCWS4JBDf7H6N+qTjWfwMrlC8UjDeDMAeIwbojp4pVTmwuoj9vALJil+GbF6chLT/CYZh2hE3UQ4u0H4zYw4R6EyQKBn5OL6QYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lvEWiaW+pMKbhIH91B1ZWkRJ9XvceOtRMpnDQf2L4I=; b=M1QjDrc/zoBx23ig1j8X32McJUzKyNkN4S02JS+aTB2HX+83ZibPxwdIK+zeX034vC6XJbCofp193MwU6jAyHSsC7Ebl6uqRaA6FqEgCDcAOqMsg8/eNub9H2dTZt3iy0IAWm6OSDeATAqHbRUYQdXmH1wgqK3ZZcQgejlumEzspca0NJGXhj8TaPpGDrpt282+m7LbII0pQOB/h4dnmN8BEWt+uacjhw6jkPVa5HhrcIlI2QRN7a2eRh04xUhLDo6y1Bsg2fd2HFO3LtaESsFvBJAAqOv9oFIxPeDhng6HU/NcUTLVAfx4RJxvG3WzW2AkA22uJOh/dLAODsGPwxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lvEWiaW+pMKbhIH91B1ZWkRJ9XvceOtRMpnDQf2L4I=; b=whNwOo+4xqid2VYqxddGNovyS5FMMfYN6F4wVQWd6BCD4H0Sh8QzXOONqBQglIyuVO3ZjfPJkSqpJ7RotOlFjwgz7LKXQA7fbkSSZUbQd/KAaMopTUiqq5cTPmyM+hgeERT1LbgLA+G390SXHP65N6S4vaGRIl0+7sSWxmMYttU= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5152.namprd11.prod.outlook.com (2603:10b6:a03:2ae::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 17:27:40 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Mon, 23 Nov 2020 17:27:40 +0000 From: "Acee Lindem (acee)" To: tom petch , "last-call@ietf.org" CC: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" Thread-Topic: Last Call: (YANG Data Model for Segment Routing) to Proposed Standard Thread-Index: AQHWvE9TnHz4xC0KAECDY9QT1Wf1oanN1wuAgAfYZQA= Date: Mon, 23 Nov 2020 17:27:40 +0000 Message-ID: References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> In-Reply-To: <5FB515F7.1020306@btconnect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d776592-51ea-4799-8dc2-08d88fd5147e x-ms-traffictypediagnostic: SJ0PR11MB5152: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: modGgmSIXrpAdTV25xP6nq8S74nQuT49AXYWpfgh0H/M40pcIlPijyGcJzK2oxhueArgLyYVk7HQyCNFGNNqofRtDm+BA79HgdNRltFp78qCO7y0xsY+zjOL6CS1v0uF8n9V4HQ9oBjcJg7JiQ6b7u7Aj3y2BRnD/fq9KlYwQAj6y8wA8eOCmZkT5jNK72/9u7lo6EAh6RcijLjvqAG5/JYvssiN+ertH03CZxITmte+ATsKNruJvVvSXrKx9LdjNd+2jUBUjFrd5IUOpEwtctxiDlGLduVwhE+eEQwY0ebXYODo86saXNmGVoeFdRXDPsENsULPmE6uNAINRvrHEWINs60Bsu5X5XhhaXdaLUq5qCB0L61smP4HtemCq6p9fSQLdfZ6mbb6ysl61ovTiw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(366004)(396003)(6512007)(71200400001)(76116006)(36756003)(5660300002)(66946007)(6486002)(4001150100001)(33656002)(966005)(8936002)(64756008)(66476007)(8676002)(478600001)(66446008)(4326008)(66556008)(2906002)(296002)(2616005)(86362001)(316002)(54906003)(6506007)(66574015)(186003)(110136005)(83380400001)(26005)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qJ04vQkVt24qvaFv4UYlULepNGmgkdEPW83d56EkORx7AY5XJNOgCIjp9t/iYEFHKvxfucrrS+cW0MUxI1JEmmK5fvhnBuIFqaSrUcORTowYKU0dVR5ar0vv/FP5s2/MTcrtVCSsyEcPlEaj+6vury1Gh6tLgcrEdTBDXI7m82P99aP/aI9Sr9cuxqJEQR4WiNqOSMQYzGWUlGD5NZ0agxU1PuS7XtDQ2JlzjSSeQ7Oee3WeajYP50MEGM8OrY4+/MCPqq0q3vhdt1KH6YbpaAsqv34qUhgWqFZGxI6vrNnw0ddQObLo8kC9v9wW8YfBT09E1zLhEP+pSDL52tUmkIzos7esUF3mAjIYQdn67UI5ZE5ljBX84RgvWX9lhIAhYi6qKiUhJX5nVXmIjQdWf0GLySRIZ51yhc76a/nz6adP8VsQJvqMd448V9LxnLS2o08nTpYAHwmLBY3ySu5w9eaYXkgKQQOgArw6I0HCwvJfRdBwxjGxC8TEbyYi4nUafh9We9NsCy3qJ/hB10+QUPYjUMgCy1BZdUOpyqTckZNxTeIzUsWDMAeZzK4hY+EY/JrpGUm2S2RlVDeRwfDMvQkJnd/TMUSB5hA4yNSMnMXEjkjNrXOCVXWzsls+hA88XAie24IW2twgilswmFTDwQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d776592-51ea-4799-8dc2-08d88fd5147e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 17:27:40.6290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NyTz0MP8mMCVaJ5ubMBZO517O0nSBc4H1WjGghRbfBmGIBeeryVTyuJapq1En02s X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5152 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:27:50 -0000 SGkgVG9tLCANCg0KU2VlIGEgY291cGxlIHJlc3BvbnNlcyBpbmxpbmUgZW5jbG9zZWQgaW4gPGFj ZWU+IGFuZCA8L2FjZWU+LiBXZSBhcmUgYWRkcmVzc2luZyB0aGUgcmVzdCBvZiB5b3VyIGNvbW1l bnRzLiANCg0K77u/T24gMTEvMTgvMjAsIDc6MzkgQU0sICJ0b20gcGV0Y2giIDxkYWVkdWx1c0Bi dGNvbm5lY3QuY29tPiB3cm90ZToNCg0KICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgZG9lcyBub3Qg cmVnaXN0ZXIgdGhlIG1vZHVsZSBuYW1lcyB1c2VkIGluIHRoZSBtb2R1bGVzDQoNCjxhY2VlPg0K VGhpcyBpcyBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucy4uLiANCg0KICAgVGhpcyBkb2N1bWVu dCByZWdpc3RlcnMgYSBZQU5HIG1vZHVsZSBpbiB0aGUgWUFORyBNb2R1bGUgTmFtZXMNCiAgIHJl Z2lzdHJ5IFtSRkM2MDIwXS4NCg0KICAgICAgbmFtZTogaWV0Zi1zZWdtZW50LXJvdXRpbmctY29t bW9uDQogICAgICBuYW1lc3BhY2U6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXNl Z21lbnQtcm91dGluZy1jb21tb24NCiAgICAgIHByZWZpeDogc3ItY21uDQogICAgICByZWZlcmVu Y2U6IFJGQyBYWFhYDQoNCiAgICAgIG5hbWU6IGlldGYtc2VnbWVudC1yb3V0aW5nDQogICAgICBu YW1lc3BhY2U6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXNlZ21lbnQtcm91dGlu Zw0KICAgICAgcHJlZml4OiBzcg0KICAgICAgcmVmZXJlbmNlOiBSRkMgWFhYWA0KDQogICAgICBu YW1lOiBpZXRmLXNlZ21lbnQtcm91dGluZw0KICAgICAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi1zZWdtZW50LXJvdXRpbmctbXBscw0KICAgICAgcHJlZml4OiBz ci1tcGxzDQogICAgICByZWZlcmVuY2U6IFJGQyBYWFhYDQo8L2FjZWU+DQoNCiAgICBFeGFtcGxl cyBhcmUgSVB2NCBvbmx5LCBJUHY2IHdvdWxkIGJlIGdvb2QNCg0KICAgIEJHUCBpcyBpbmNsdWRl ZCB3aGVuIGl0IGNvbWVzIHRvIGRlZmluaW5nIGEgcm91dGVyLWlkIGJ1dCBpcyBpZ25vcmVkIA0K ICAgIGV2ZXJ5d2hlcmUgZWxzZSwgc3VjaCBhcyBzaWduYWxsaW5nIE1TRCwgcHJvdG9jb2wgZXh0 ZW5zaW9ucyBldGMNCg0KICAgIHJlZmVyZW5jZSAiUkZDIFhYWFgiIHdvdWxkIGJlIGltcHJvdmVk IGJ5IGluY2x1ZGluZyB0aGUgdGl0bGUgaW4gYWxsIA0KICAgIGNhc2VzIG5vdCBqdXN0IHNvbWUN Cg0KICAgIHRoZSBzY2hlbWUgaHR0cDogYXBwZWFycyBpbiBtYW55IHBsYWNlcy4gIEl0IHdvdWxk IGJlIGxvdmVseSBpZiB0aGlzIA0KICAgIHJlYWxseSB3YXMgdGhlIHNjaGVtZSBidXQgSSBmZWFy IHRoYXQgaXQgaXMgbm90DQo8YWNlZT4NClRoaXMgaXMgZGlyZWN0bHkgZnJvbSB0aGUgUkZDIDg0 MDcgdGVtcGxhdGUgaW4gQXBwZW5kaXggQi4gV2hhdCB3b3VsZCB5b3Ugc3VnZ2VzdD8gDQo8L2Fj ZWU+DQoNCiAgICBtb2R1bGUgc3JjbW4NCiAgICAgIHRoZSB1cHBlciBib3VuZCBtdXN0IGJlIGxh cmdlcg0KICAgICAgdGhlIHZhbHVlIG11c3QgYmUgZ3JlYXRlcg0KICAgIGNvbnNpc3RlbmN5IGlz IGdvb2QgLSBJIHRoaW5rIGdyZWF0ZXIgaXMgYmV0dGVyDQoNCiAgICA4LjMNCiAgICBvcGVyYXRp b24gc3RhdGVzDQogICAgdXN1YWxseSBvcGVyYXRpb25hbA0KDQogICAgdHdvIGltcG9ydHMgbGFj ayByZWZlcmVuY2VzDQoNCiAgICB0eXBlZGVmIHJvdXRlci1pZA0KICAgIHRoaXMgaXMgYSB3ZWxs IGtub3duIHR5cGUgZnJvbSBSRkM4Mzk0OyBpdCBzZWVtcyBsaWtlbHkgdG8gY29uZnVzZSB0byAN CiAgICByZWRlZmluZSBpdCB3aXRoIGEgcmVsYXRlZCBidXQgZGlmZmVyZW50IG1lYW5pbmcNCg0K ICAgIGxlYWYgZW5hYmxlZA0KICAgIGVuYWJsZXMgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KICAgIHdo aWNoIHByb3RvY29scz8NCg0KICAgIGxlYWYgcHJvdGVjdGVkDQogICAgaXQgaXMgdXNlZCB0byBw cm90ZWN0DQogICAgaG93IGRvZXMgaXQgZG8gdGhhdDotKQ0KDQogICAgZW51bSBkdWFsDQogICAg Li4uIEluIHRoaXMgY2FzZSB3aWxsIGJlIGFkdmVydGlzZWQgd2l0aCBiYWNrdXAgZmxhZyBzZXQN CiAgICBXaGF0IGlzIHRoZSBiYWNrdXAgZmxhZz8gIEl0IGRvZXMgbm90IGZlYXR1cmUgaW4gUkZD ODY2MC4gIE5lZWRzIGFuIA0KICAgIGV4cGxhbmF0aW9uIGFuZCByZWZlcmVuY2UNCg0KICAgIGNv bnRhaW5lciBsaW5rLW1zZA0KICAgICAgbGlzdCBsaW5rLW1zZHMNCiAgICAgICAgbGVhZiBtc2QN CiAgICBUaGUgdXN1YWwgWUFORyBjb252ZW50aW9uIGlzIGZvciBhIGxpc3QgdG8gYmUgcGx1cmFs IGFuZCB0aGUgbGVhZiANCiAgICBzaW5ndWxhci4gIFlvdSBoYXZlIHRoZSBwbHVyYWwgbGlzdCBi dXQgbm90IHRoZSBsZWFmLiANCjxhY2VlPiANClNvIHlvdSBhcmUgYXNraW5nIGZvciBhIGNoYW5n ZSBmcm9tICJsZWFmIG1zZCIgdG8gImxlYWYgbGluay1tc2QiPyANCjwvYWNlZT4NCg0KDQogQW5k IHdobyBuZWVkcyB0aGUgDQogICAgY29udGFpbmVyPyAgVGhpcyBpcyBtcGxzIG5vdCBhIGNvbW1v biBtb2R1bGUgdGhhdCBtaWdodCBiZSBhdWdtZW50ZWQgc28gDQogICAgd2hhdCBkb2VzIHRoZSBj b250YWluZXIgZ2l2ZSBhcGFydCBmcm9tIGNvbXBsZXhpdHk/DQoNCiAgICBsaXN0IHBvbGljeQ0K ICAgICAgbGVhZiBzdHJpbmcNCiAgICBZQU5HIHN0cmluZyBjYXRlcnMgZm9yIHZlcnkgbGFyZ2Ug aXRlbXMgb2YgdmVyeSBjb21wbGV4IGNoYXJhY3RlciBzZXRzLiANCiAgICAgIElzIHRoYXQgZGVz aXJhYmxlPw0KPGFjZWU+DQpJRVRGIG1vZGVscyBub3JtYWxseSBkbyBub3QgbGltaXQgaWRlbnRp ZmllcnMuIEFuIGluZGl2aWR1YWwgaW1wbGVtZW50YXRpb24gY291bGQgZG8gdGhpcyB3aXRoIGEg ZGV2aWF0aW9uLiANCjwvYWNlZT4gDQoNClRoYW5rcywNCkFjZWUNCg0KICAgIGxlYWYgdXNlZA0K ICAgIHdpbGwgdXNlZCBwbHVzIGZyZWUgZXF1YWwgc2l6ZT8NCg0KICAgIEluZGljYXRlcyBpZiB0 aGUgYmluZGluZyBpcyAvaW5zdGFsL2luc3RhbGxlZC8NCg0KICAgIG5vdGlmaWNhdGlvbi1zZWdt ZW50LXJvdXRpbmctZ2xvYmFsLXNyZ2ItY29sbGlzaW9uDQogICAgYSBtaXggb2YgY29uZmxpY3Qg YW5kIGNvbGxpc2lvbjsgIGNvbnNpc3RlbmN5IGlzIGdvb2QgYW5kIEkgcHJlZmVyIHRoZSANCiAg ICBsYXR0ZXIgd2hpY2ggaXMgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbg0KDQogICAgY29u dGFpbmluZyAvcy9hLyBtYXBwaW5nDQoNCiAgICAuLi4gc2lkIGNvbGxpc2lvbg0KICAgIGFnYWlu IGNvbnNpc3RlbmN5IGdvb2QsIHByZWZlciBjb2xsaXNpb24gdG8gY29uZmxpY3RpbmcNCg0KICAg IHMuOQ0KICAgIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoZSBzcmdiIHdvcnRoeSBvZiBtZW50aW9u IHVuZGVyIHNlbnNpdGl2ZSBub2Rlcw0KDQogICAgVG9tIFBldGNoDQoNCg0KICAgIE9uIDE2LzEx LzIwMjAgMTk6MzIsIFRoZSBJRVNHIHdyb3RlOg0KICAgID4NCiAgICA+IFRoZSBJRVNHIGhhcyBy ZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdv cmtpbmcNCiAgICA+IFdHIChzcHJpbmcpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1l bnQ6IC0gJ1lBTkcgRGF0YSBNb2RlbCBmb3INCiAgICA+IFNlZ21lbnQgUm91dGluZycNCiAgICA+ ICAgIDxkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nLTIzLnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRh cmQNCiAgICA+DQogICAgPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhl IG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwNCiAgICA+IGNvbW1lbnRzIG9uIHRo aXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCiAgICA+ IGxhc3QtY2FsbEBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMjAtMTEtMzAuIEV4Y2VwdGlv bmFsbHksIGNvbW1lbnRzIG1heQ0KICAgID4gYmUgc2VudCB0byBpZXNnQGlldGYub3JnIGluc3Rl YWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBiZWdpbm5pbmcNCiAgICA+IG9m IHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQogICAgPg0KICAg ID4gQWJzdHJhY3QNCiAgICA+DQogICAgPg0KICAgID4gICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIFlBTkcgZGF0YSBtb2RlbCBmb3Igc2VnbWVudCByb3V0aW5nDQogICAgPiAgICAgY29uZmln dXJhdGlvbiBhbmQgb3BlcmF0aW9uLCB3aGljaCBpcyB0byBiZSBhdWdtZW50ZWQgYnkgZGlmZmVy ZW50DQogICAgPiAgICAgc2VnbWVudCByb3V0aW5nIGRhdGEgcGxhbmVzLiAgVGhlIGRvY3VtZW50 IGFsc28gZGVmaW5lcyBhIFlBTkcgbW9kZWwNCiAgICA+ICAgICB0aGF0IGlzIGludGVuZGVkIHRv IGJlIHVzZWQgb24gbmV0d29yayBlbGVtZW50cyB0byBjb25maWd1cmUgb3INCiAgICA+ICAgICBv cGVyYXRlIHNlZ21lbnQgcm91dGluZyBNUExTIGRhdGEgcGxhbmUsIGFzIHdlbGwgYXMgc29tZSBn ZW5lcmljDQogICAgPiAgICAgY29udGFpbmVycyB0byBiZSByZXVzZWQgYnkgSUdQIHByb3RvY29s IG1vZHVsZXMgdG8gc3VwcG9ydCBzZWdtZW50DQogICAgPiAgICAgcm91dGluZy4NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+DQogICAgPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQog ICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1z ci15YW5nLw0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gTm8gSVBSIGRlY2xhcmF0aW9ucyBo YXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KICAgID4NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4gSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICA+ IElFVEYtQW5ub3VuY2VAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZQ0KICAgID4gLg0KICAgID4NCg0K From nobody Mon Nov 23 10:16:11 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CD53A0621; Mon, 23 Nov 2020 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiaZ0OWet8g4; Mon, 23 Nov 2020 10:16:08 -0800 (PST) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 B9D9F3A0639; Mon, 23 Nov 2020 10:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1606155368; x=1637691368; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=LiOEIjMjCYp4Ld/1+58ocbDihGOgbK3VQxUYRHd8Jpg=; b=e0mcndLwcCZTcg2NosTFJq+P/6ff+UTacQy3eA4tJjanuWysFEpZmhWo OyHXZE9qkVdfq/g69chajXqKmjGkg6Rd6csmLVeD5VGzVsQBf3a+3PT2y LjnTKdq7Y2f+arAJBOmuEzFKR27DU5aq2zVFzW4nvpUIfyx1t2mi5JQHb O3vJlvIs3HavjeplR+F6k1IzK63BH10kzZXAZT2MHbmjUtD6AQ19IgAqu HqXFRIMECajorZTDwOiyB2Tr1Rhws2VP2YtryQLYS8OhD2o3GvpVurTy1 ZHfoHvFeUvrz/cqGDmHhRIXuZEN6b+0ARDu87qtbLYxiDVj08Ux5kFXTb g==; IronPort-SDR: 2f/59UhtBUBvhJMyAaMQKCM7la9smDFb4ERY2kmahzW4kgFgjBfrsdXk4zUV25ZEEfZzJaTriy KRNmBbrMIyNw== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 23 Nov 2020 13:16:05 -0500 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 13:16:05 -0500 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d5aa:97b:fe99:c46f]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d5aa:97b:fe99:c46f%22]) with mapi id 15.00.1497.006; Mon, 23 Nov 2020 13:16:05 -0500 From: "Voyer, Daniel" To: Bob Hinden , =?utf-8?B?56iL5Lyf5by6?= CC: "spring-chairs@ietf.o" , srcomp , spring Thread-Topic: [EXT]Re: [spring] New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Thread-Index: AQHWwQ196mmPI74EFUmTHlGTFobD4anWB0+A Date: Mon, 23 Nov 2020 18:16:05 +0000 Message-ID: References: <160545233786.30631.15366800831645495687@ietfa.amsl.com> <2afc5fb1438eaff-00007.Richmail.00005040942471314941@chinamobile.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.92.6] Content-Type: text/plain; charset="utf-8" Content-ID: <608FB6C7373F7D48A0B3DDBC3D6DBADB@exchange.bell.ca> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:16:10 -0000 SGksDQpJbiB0aGUgaW50cm9kdWN0aW9uLCBsYXN0IHBhcmEgc2F5czoNCiJBcHBlbmRpeCBBIGNv bnRhaW5zIGEgc3Vic2V0IG9mIHJlcXVpcmVtZW50cyB3aXRob3V0IHVuYW5pbW91cyBjb25zZW5z dXMuIiBJIHRob3VnaHQgdGhpcyB3YXMgZW5vdWdoIG9yIHdlIGNvdWxkIHByb3Bvc2U6DQoNCiJS ZXF1aXJlbWVudCB3aXRoIHJvdWdoIENvbnNlbnN1cyIuDQoNCkFmdGVyIGFsbCwgaXQncyBwYXJ0 IGlmIHRoZSBtYW5kYXRlOiAiIFRoZSBkZXNpZ24gdGVhbSBpcyB0byBwcm9kdWNlIChyb3VnaCkg Y29uc2Vuc3VzIChvZiB0aGUgRFQpIG91dHB1dHMgdG8gdGhlIFdHIC4uLiINCg0KZGFuDQoNCu+7 v09uIDIwMjAtMTEtMjIsIDM6MjQgUE0sICJzcHJpbmcgb24gYmVoYWxmIG9mIEJvYiBIaW5kZW4i IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYm9iLmhpbmRlbkBnbWFpbC5j b20+IHdyb3RlOg0KDQogICAgSGksDQoNCiAgICBJIG5vdGljZWQgdGhhdCB0aGUgdGl0bGUgb2Yg QXBwZW5kaXggQSBkb2VzIG5vdCBtYXRjaCB0aGUgdGV4dC4gIEl0IHNheXM6DQoNCiAgICAgICBB cHBlbmRpeCBBLiAgUHJvcG9zZWQgUmVxdWlyZW1lbnRzDQoNCiAgICAgICBUaGlzIGFwcGVuZGl4 IGNvbnRhaW5zIHJlcXVpcmVtZW50cyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBkaXNjdXNzZWQNCiAg ICAgICBidXQgY291bGQgbm90IGJlIGFncmVlZCB1cG9uLg0KDQogICAgUGxlYXNlIGNoYW5nZSB0 aGUgdGl0bGUgdG8gc29tZXRoaW5nIGxpa2Ug4oCcUmVxdWlyZW1lbnQgd2l0aCBubyBDb25zZW5z dXPigJ0gIG9yIHNpbWlsYXIuDQoNCiAgICBCb2INCg0KDQogICAgPiBPbiBOb3YgMTUsIDIwMjAs IGF0IDc6MjcgQU0sIOeoi+S8n+W8uiA8Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+IHdy b3RlOg0KICAgID4gDQogICAgPiBIaSBHcm91cCwNCiAgICA+IA0KICAgID4gU1IgY29tcHJlc3Np b24gZGVzaWduIHRlYW0gaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBjb21wcmVzc2lv biByZXF1aXJlbWVudCBkcmFmdC4NCiAgICA+IA0KICAgID4gTWFpbiBjaGFuZ2VzIGFzIGZvbGxv d3M6DQogICAgPiANCiAgICA+IC0gYWRkZWQgMyBpdGVtcyBhYm91dCBzY2FsaWJpbGl0eSB3aXRo IGFncmVlbWVudCB3aXRoaW4gdGhlIGRlc2lnbiB0ZWFtDQogICAgPiANCiAgICA+IC0gYWRkZWQg YW4gYXBwZW5kaXggaW5jbHVkaW5nIDMgaXRlbXMgd2l0aG91dCB3aXRob3V0IHVuYW5pbW91cyBj b25zZW5zdXMgd2l0aGluIHRoZSBkZXNpZ24gdGVhbQ0KICAgID4gDQogICAgPiAtIHNvbWUgbWlu b3IgdGV4dCBpc3N1ZSBmaXhlZA0KICAgID4gDQogICAgPiBQbGVhc2UgcmV2aWV3IGl0IGFuZCBs ZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4g QlRXOiBXZSB3aWxsIGhhdmUgMS1ob3VyIHNlc3Npb24gZm9yIHRoZSBkZXNpZ24gdGVhbSB0b3Bp YyBvbiBGcmlkYXkgYW5kIHdlbGNvbWUgdG8gam9pbiB1cy4NCiAgICA+IA0KICAgID4gDQogICAg PiANCiAgICA+IEIuUi4NCiAgICA+IA0KICAgID4gV2VpcWlhbmcgb24gYmVoYWxmIG9mIGRlc2ln biB0ZWFtDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IC0tLS3pgq7ku7bl jp/mloctLS0tDQogICAgPiDlj5Hku7bkurrvvJppbnRlcm5ldC1kcmFmdHMgPGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4NCiAgICA+IOaUtuS7tuS6uu+8mldlaXFpYW5nIENoZW5nIDxjaGVuZ3dl aXFpYW5nQGNoaW5hbW9iaWxlLmNvbT4sU2FuZGVyIFN0ZWZmYW5uIDxzYW5kZXJAc3RlZmZhbm4u bmw+LFNKTSBTdGVmZmFubiA8c2FuZGVyQHN0ZWZmYW5uLm5sPg0KICAgID4g5oqE44CA6YCBOiAo 5pegKQ0KICAgID4g5Y+R6YCB5pe26Ze077yaMjAyMC0xMS0xNSAyMjo1ODo1Nw0KICAgID4g5Li7 6aKY77yaTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmct Y29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQogICAgPiANCiAgICA+IA0KICAgID4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudC0wMS50eHQNCiAgICA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg V2VpcWlhbmcgQ2hlbmcgYW5kIHBvc3RlZCB0byB0aGUNCiAgICA+IElFVEYgcmVwb3NpdG9yeS4N CiAgICA+IA0KICAgID4gTmFtZToJZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJl cXVpcmVtZW50DQogICAgPiBSZXZpc2lvbjoJMDENCiAgICA+IFRpdGxlOglDb21wcmVzc2VkIFNS djYgU0lEIExpc3QgUmVxdWlyZW1lbnRzDQogICAgPiBEb2N1bWVudCBkYXRlOgkyMDIwLTExLTEz DQogICAgPiBHcm91cDoJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgPiBQYWdlczoJMTMNCiAg ICA+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBkdC1z cHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDEudHh0DQogICAgPiBTdGF0dXM6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVz c2lvbi1yZXF1aXJlbWVudC8NCiAgICA+IEh0bWxpemVkOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJl bWVudA0KICAgID4gSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z cmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDENCiAgICA+IERpZmY6IGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29t cHJlc3Npb24tcmVxdWlyZW1lbnQtMDENCiAgICA+IA0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8gY29t cHJlc3MgU1J2Ng0KICAgID4gIFNJRCBsaXN0cy4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+ IA0KICAgID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICA+IA0KICAgID4gDQogICAgPiANCiAg ICA+IFN1YmplY3TvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCiAgICA+IA0KICAgID4gDQog ICAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNz aW9uLXJlcXVpcmVtZW50LTAxLnR4dA0KICAgID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBXZWlxaWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgID4gSUVURiByZXBv c2l0b3J5Lg0KICAgID4gDQogICAgPiBOYW1lOglkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJl c3Npb24tcmVxdWlyZW1lbnQNCiAgICA+IFJldmlzaW9uOgkwMQ0KICAgID4gVGl0bGU6CUNvbXBy ZXNzZWQgU1J2NiBTSUQgTGlzdCBSZXF1aXJlbWVudHMNCiAgICA+IERvY3VtZW50IGRhdGU6CTIw MjAtMTEtMTMNCiAgICA+IEdyb3VwOglJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICA+IFBhZ2Vz OgkxMw0KICAgID4gVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNy Y29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMS50eHQNCiAgICA+IFN0YXR1 czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5n LWNvbXByZXNzaW9uLXJlcXVpcmVtZW50Lw0KICAgID4gSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9u LXJlcXVpcmVtZW50DQogICAgPiBIdG1saXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KICAgID4g RGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMQ0KICAgID4gDQogICAgPiBBYnN0cmFjdDoN CiAgICA+ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9u cyB0byBjb21wcmVzcyBTUnY2DQogICAgPiAgU0lEIGxpc3RzLg0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KICAgID4gDQogICAgPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgID4gc3ByaW5nQGlldGYu b3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K DQoNCg== From nobody Tue Nov 24 01:34:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733863A1271; Tue, 24 Nov 2020 01:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 tYlHp6wIFlwQ; Tue, 24 Nov 2020 01:34:20 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60092.outbound.protection.outlook.com [40.107.6.92]) (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 E44513A125F; Tue, 24 Nov 2020 01:34:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqqFsQY873ZOPzrvwu6XHohvlB78z0YSVwWCNWzJ325rtQK3lSMPH8ONjBC0DlAJuhlW/9r6IV2W+9AoYoJQ/ijrOsydD5ut75G3z+JYdxFw56n3bWU+KjUJjdzCGqPpcWJ7Fs19B55fslyHk3ZaQUSsgtNA9NVOaA0cAgzqlX/1GY2+kHx3c4kR4hsgjrQqsfCE8lyDjJC6RhpFl4SJqw832MynedO+Jf+s6xdedvyjbjVXZfQfXweO1gaOZkh4uM1mxYXJQmbZmejGLtOCS/p8WpAqeFXYn4AAY7AY76hszVukc7BET1zRxBrz1HXHargPL34eM/qTt+sUn3hOzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ptLaf/+tz/KUTcrDXPzNHxzAkA+kiUSemOUqu5+R9r0=; b=g+G8aBcWbTh4f4JlIYU7DJP8lYbBMzgctJX6tJjcLac/91AeIYTCzWIiYn7FiWYmLEDcjBT01VY1dcDKQB8A65froAgCKfKGwiflvRQO4uyyBRk/5GAhYJ2Om5ZTibYW6G9RGbix2k9UzZ6cEEvctse2UToLcGZ+b4KJaPx/5Sm34xMKmB4xDA8Bmxc/4AbtiPRe8krEPsObm36FKdvhMOLx2UcBpvK5gMbSepvD3AtD+05oXjXEp5sq97NfzaYuts1UwSgNhsAOqPetT8+Lk2Ojlzk11SIYdWshj+MnlXaIxD6fqQunGb0VG68QyC4wAiaodKY1gBUHEPVsbnxovA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ptLaf/+tz/KUTcrDXPzNHxzAkA+kiUSemOUqu5+R9r0=; b=mrEO3FBR6/Jf96XK1WpF+DJ9agMTLTuidl2N8uqe1XKNyVsrNEcCot8wwSqtC3X7luxizOgDzHI6Yz0kwJ582DQdG+o/K66q81Q70iYYd8VmPpAEBRicQ1RsqtwgwmWW3OiXIxByv4BLfw6VYyKiECpqjw7FmZuXwYWMW1hwn8c= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB7037.eurprd07.prod.outlook.com (2603:10a6:800:195::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.14; Tue, 24 Nov 2020 09:34:17 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3611.020; Tue, 24 Nov 2020 09:34:17 +0000 To: "Acee Lindem (acee)" , "last-call@ietf.org" References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> Cc: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" From: tom petch Message-ID: <5FBCD392.3050706@btconnect.com> Date: Tue, 24 Nov 2020 09:34:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::33) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 09:34:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bce85ad0-6775-40ed-bb7f-08d8905c1cdf X-MS-TrafficTypeDiagnostic: VI1PR0701MB7037: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3513; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lWlJljam27eQfTzBWiHvUBTpGpVFXcmv/ztPSO/NGe0edsmuJvNSsNMEA+We0S3paraVDEQ/b+/s696MLLuW0xSr5kRRDywY/VTmBNbsz3Glmk8nKUlHH115qsxOBkqp2vpCr5eCD4zw62YVBpSnW/TGniWlxL8G4Jbb9BXgTZ/t9Nezk0xK/uLGEdrunxOiW5ErXDzgq3+vlUmnzig0JNXqyVdRBKUze9d3seJLFoge+70NVAqRsL9p+WUQBoYjsqRE2fhJ9CcLgHWk64hkIYmSsU+COKSdwuBkhRa7r2zwkb10l5RlEI4znatKRR99lLMhw0ga9cp7xXVoZyOjew== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(366004)(346002)(396003)(83380400001)(2906002)(4326008)(478600001)(6666004)(33656002)(6486002)(5660300002)(66556008)(66476007)(66946007)(66574015)(8676002)(8936002)(26005)(2616005)(956004)(16576012)(36756003)(316002)(52116002)(53546011)(110136005)(86362001)(16526019)(186003)(87266011)(54906003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: qBITdvzGmTQ6pefgQqgvYye7iG26jo6m++VtY9967PyGYmmOZEoz115vByRknYm4jnJPB1ogBZYpC/1WgZVbQv7a+CsRsAuTnfS9Y6vYtsAgs8mMUkOCf4ftx1ZD47+0uXJBLASUqk9RK64Fvtz5ZDp9ZCIr4mOs654gVpbBBLwuSfkyMoeBWV9u8eM1cS52XyiI9I+ylln3z6j8c89g/BLS9iBOhuVQCJFj+HDeQ1Zt5PhNh7EBUFou/I7/uFPEW6CmXKOlqyuCNVQv6gLdxC4gNqeFNaxbZeJAbllWhyhsqeV8he84s6FrYgEYINHtWOyXIRsihUWHMM2mxqG1JU6e87l5BDJxzY2nDZcEzY2qZhshXuzTQjGLTnSxyWLWIIPhluVScPkBZT7PiHEiDZHGwRq7PaVITRxZpD9c2v2UrrIVs7iB+IJELK3hCzeqSQnAFdF9+T5LhBOEv7htEkJ0PRA/AuJgaLu2oX6sXrdIAw8zKI0K6uHG5GTmsWQkw7fjoTafv+BDnzq1zU6pAw+24Z5nfEJfrlu84h/QiU8MnVnhuEtpNJPaDZo3ToNBVPZs7TRzbgqFINLwoOXrCKxQz78F4SNzzBljrQ66XpgnbsTA5+eO3zzAIciH9wNeEDQq4dnfJ1ubWZdYIoiFKjFUILIkeKuy047I/wc+hEzX+1Jo4s9GEFvw+cNtfLvC5v6vjljsU/AFvBxVfrC1Jr3LIHjh+XUwJ9DYMcF9RhiPUTd9KkrugQ1eTK1CKKpDsn77jtOQuhGYKmVU6yqzAeOd2LD2asFfn9OEESe/WDMWZnmFV2lGNlz3LpCBqZ28V/wqs7rMvEoHiyfiDY3Gsv/AuPEaGczzXCG5u9qow1HEuwPbu2nx4JQmdEXhTT+Bg6GkDLN9cuZuh8HGRTKUkg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: bce85ad0-6775-40ed-bb7f-08d8905c1cdf X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 09:34:17.4704 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: evd5/Yd+6hoLj927n9pvpPPilu1k/cilSWcr3csnKdeOFCQ2E7EcIHfyfz1bQ079/pcDIbutN1raYz3kBk6GLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7037 Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 09:34:23 -0000 On 23/11/2020 17:27, Acee Lindem (acee) wrote: > Hi Tom, > > See a couple responses inline enclosed in and . We are addressing the rest of your comments. > > On 11/18/20, 7:39 AM, "tom petch" wrote: > > IANA Considerations does not register the module names used in the modules > > > This is in the IANA considerations... Indeed; I do not see a registration of ietf-segment-routing-mpls! > This document registers a YANG module in the YANG Module Names > registry [RFC6020]. > > name: ietf-segment-routing-common > namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common > prefix: sr-cmn > reference: RFC XXXX > > name: ietf-segment-routing > namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing > prefix: sr > reference: RFC XXXX > > name: ietf-segment-routing > namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls > prefix: sr-mpls > reference: RFC XXXX > > > Examples are IPv4 only, IPv6 would be good > > BGP is included when it comes to defining a router-id but is ignored > everywhere else, such as signalling MSD, protocol extensions etc > > reference "RFC XXXX" would be improved by including the title in all > cases not just some > > the scheme http: appears in many places. It would be lovely if this > really was the scheme but I fear that it is not > > This is directly from the RFC 8407 template in Appendix B. What would you suggest? Many I-D do now specify https: since that is now the only option supported by the IETF; I have seen this called for by an AD. > > > module srcmn > the upper bound must be larger > the value must be greater > consistency is good - I think greater is better > > 8.3 > operation states > usually operational > > two imports lack references > > typedef router-id > this is a well known type from RFC8394; it seems likely to confuse to > redefine it with a related but different meaning > > leaf enabled > enables protocol extensions > which protocols? > > leaf protected > it is used to protect > how does it do that:-) > > enum dual > ... In this case will be advertised with backup flag set > What is the backup flag? It does not feature in RFC8660. Needs an > explanation and reference > > container link-msd > list link-msds > leaf msd > The usual YANG convention is for a list to be plural and the leaf > singular. You have the plural list but not the leaf. > > So you are asking for a change from "leaf msd" to "leaf link-msd"? Yes I would especially given node-msd. I wish that YANG Guidelines said more about container names. I think that having the same identifier for container, for list, for leaf (which I have seen in another I-D) will lead to mistakes so having a convention for list and leaf will reduce mistakes but having another for container would be even better. That said, I have yet to think of a good convention In passing, must link-msd be >= node-msd? > > > > And who needs the > container? This is mpls not a common module that might be augmented so > what does the container give apart from complexity? > > list policy > leaf string > YANG string caters for very large items of very complex character sets. > Is that desirable? > > IETF models normally do not limit identifiers. An individual implementation could do this with a deviation. I know - I did see an AD challenge that, I think in IESG review, not long ago. SMI was better at this! Tom Petch > > > Thanks, > Acee > > leaf used > will used plus free equal size? > > Indicates if the binding is /instal/installed/ > > notification-segment-routing-global-srgb-collision > a mix of conflict and collision; consistency is good and I prefer the > latter which is the name of the notification > > containing /s/a/ mapping > > ... sid collision > again consistency good, prefer collision to conflicting > > s.9 > I would have thought the srgb worthy of mention under sensitive nodes > > Tom Petch > > > On 16/11/2020 19:32, The IESG wrote: > > > > The IESG has received a request from the Source Packet Routing in Networking From nobody Tue Nov 24 06:48:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755993A0EF6; Tue, 24 Nov 2020 06:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.72 X-Spam-Level: X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=kxAaO69A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BX9shoJ1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpP8W5hBFVDS; Tue, 24 Nov 2020 06:48:40 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBB83A0EF5; Tue, 24 Nov 2020 06:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7940; q=dns/txt; s=iport; t=1606229320; x=1607438920; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=kxAaO69AZWQDLb7nYD2UoanTMMgtnX3TtdYOsH9CmGhj9KZkbC5OydNn MnMBXXOkSLqxm84K8VQ9hdtGGoJn11yTR3cNlug7RqR4mcwBjc0jm+B0I /LWW7xgk/0Gn+J+m8LU4hvDT2qwIVg/XHCmVm7Byj+WdS3jHtuw12nEqX E=; X-IPAS-Result: =?us-ascii?q?A0BUEACqGr1f/5JdJa1iHgEBCxIMQIMhTgMHdFkvLgqEM?= =?us-ascii?q?4NJA401JpkEglMDVAsBAQENAQEtAgQBAYRKAheCFQIlOBMCAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBHGFYQyFcgEBAQECARIREQwBATcBDwIBCBgCAh8HAgICMBUQA?= =?us-ascii?q?gQBDQUigwQBglUDDiABozICgTyIaHaBMoMEAQEFhRsYghAJgQ4qgnODdoZXG?= =?us-ascii?q?4IAgREnDBCCTz6DeB4/gwAzgiyTcYdJnRMKgm6bIAMfogYdk0CgYwIEAgQFA?= =?us-ascii?q?g4BAQWBayOBV3AVGiEqAYI+UBcCDY4fDBcUgzqKWHQ3AgYBCQEBAwl8jQWBN?= =?us-ascii?q?AGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A9vaAFxQV7Y0ufZN7l9zHnRGqdNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9+J4e5PjOzQvqv8H2cH5MXJvHMDdclKUB?= =?us-ascii?q?kIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry648TUVHB?= =?us-ascii?q?PyPhYzLePwScbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,366,1599523200"; d="scan'208";a="591932035" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 14:48:38 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AOEmcF9016488 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2020 14:48:38 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:48:38 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:48:37 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 09:48:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=le/w6c41KJcfJ0eujp36NR0xFDvM0eDf4Zr6yOyFGtN3rYvSc3CT9+w+HX5ruQMnBGej+AaOg1IC7FD7g8MHVZa16MfvJpLunbIPNwwpyqBKJEmjS87wiZlauItAslXhMOiOIeWzYWhzU9SwTQyaTpYfguPfLBPYDocCB4Xd4Rf45pnK5VkiXFporyENXndNEigiUJT1HGH7I00nsgjZSeRI6AhVPndryT/M//Ixn7zVl58Bl0/tJMatcsEkFm4fIPfxEu175ErdADnVmUTlJBlfRxrwhOzibI8DyMI1MZoBsNdy1Oi+bkS69mTTJ3MNnzKfkmUK3/8unSpDiUFBJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=ZD3TlM3uVOX0CwL+GPx1Y7I/a5Z1Lv4SxuxstF2om5/NsGDFlaPNEtYjJCAO/Hdze7R8Vr7OdoKXfuD7T6xHim9O2R/vNIWJtqwtmGWBLrAwsLXA9hpRT9BhzrNFQva9cqWWBUEyeTSIDzuCww0PzVzT98j4MOZJrGIG7wKxau6WvPDxED1zXI0TkJOvYNQxErEpxlwZkHwdHnrlQ6E7TDS9HrOw4PIIoKEFUMLBKRxcT06MDckoBXW8USHXcWJLIrxpzqoEXOtlzQjQupsfWEdVUg1S51MfgEajsaheZ9hac2WsupNmq4Vfloqcl39xJyJ8dp4bUhkRtxAFSBbERg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=BX9shoJ128u2bU+9QHyzBOLAI0fBERupxzCVeSMDPkeJVZbUffSCQkP/XKFDXiEu4aaCenDwlt0JkZxCKs107OOJ5iUVfLnrXVzzhVLGMH7BgUyZz5vuOwDXgTUyz7cilrX/X3i5e70IHO+mSBgzne3lnKYWI/XUBKW/fJaLTlk= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4483.namprd11.prod.outlook.com (2603:10b6:a03:1bc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Tue, 24 Nov 2020 14:48:36 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Tue, 24 Nov 2020 14:48:36 +0000 From: "Acee Lindem (acee)" To: tom petch , "last-call@ietf.org" CC: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" Thread-Topic: Last Call: (YANG Data Model for Segment Routing) to Proposed Standard Thread-Index: AQHWvE9TnHz4xC0KAECDY9QT1Wf1oanN1wuAgAfYZQCAAWHdAIAABAYA Date: Tue, 24 Nov 2020 14:48:36 +0000 Message-ID: <88A25442-527C-4558-95F4-0E9DE0A79C63@cisco.com> References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <5FBCD392.3050706@btconnect.com> In-Reply-To: <5FBCD392.3050706@btconnect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ae3dbbd-0e7f-4aa8-31e5-08d890880643 x-ms-traffictypediagnostic: BY5PR11MB4483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3QqR/6G3FYYWBjJRgb4obzkNkWyEBz6HJaVx0J2yg/4bl7L411biE0DjUVjCVFmHsUNyiY3Tb25+q+hvz053Hux4CDi6jPyzLe9k3vtaCwY0vufN4nIPdN51A9FO0CRSoBJ3MLawRkOSwIT9TLMWhJmAIYRA0JO5OwkFp6xDVRWl+wQpVkYL7ITJUhibwRDGm3fMXnAzOUo0ThEa+e6f7HxixT/48tMSEJ7VkkqRBZsqV/PXNI9wO+zwEpJjsopmEx5rktQvlxscWOcdar9gsmg6WKC9eutco4W07GIsBpwPCDcgG2ZqmHBZiu1LOT0RGlnt50ykNK/MpgTmVzZelQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(136003)(366004)(39860400002)(5660300002)(54906003)(83380400001)(33656002)(66574015)(6486002)(316002)(2616005)(110136005)(186003)(4326008)(26005)(296002)(6506007)(53546011)(66446008)(64756008)(66556008)(71200400001)(66476007)(478600001)(8936002)(2906002)(66946007)(86362001)(76116006)(36756003)(8676002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: h3crXKkl+r3jcrQDAQ2QV5zy7OrY2y6peshKDW2Lx6FzLQXpiKIxZ+5PrX9YpDa6qrDwDapFjPIwvyM4VdBMJ5/oqggFoLzsaA5l+xwVZ2N0LmQqcfsMzExOWvZ8fGsqL3FLCCab/M79A/VOKLxA+9nrlF4qFAuiQLiDXSbiFjZmikJVSsPXVAjaQUf7s8IArBwOaPyRdwquNbEHrT092DlqToMSos9+c+cGYnqXmP03SODkZKkve6YjuChMbqnf9SKW/yfkiAz/1dFmCARPTrnBpeXvDDR68ArB1vcTDSYVoilTOjr1ZWZF196vtf0IhJUFox7hS29gdSXI1bO4yOu0yw4lzlHnyZmQwnxyvpkINt906y1W/K0fYt2mAjIkUEFq3xERir8wvYoimAbuNdLzo5VQ/kIVWAuRNRhpgjVmyaR6U2rlgBcuRXLowO6CEqn1V+46//UqOlhVzRUzKunJLcJLNlKzsHtS3YLTH1q+hnJC3uGYGTYaUaJBSCqyTvd8PzpJeVRCeNYXD06tyl+RR50Ii4RvwvKRVSiOl/pIluRQaKIhD0ej8F8vZEiQ8sRskstTQmeENs47Lv//PBD5NtlJJyINFrItQWeGeo7gWM/ShzpZyBuZ8j178VTsaV8O+t2wy4ZIx2oAkXubKPA5K+FksgbJJKAgmm3yu2OeFbvYWZLUBV1S0p1HfMZ1HCsAL2ivtjoZKR9DVX41rbQHeGLAdUbAP0xDmyCR90p8umlSbdUCHtY8MhgOc4CaEVXWuMRpfBoSykaSi+StgzSPOdlYyjy31TIvuY+l8m7bIsaYi6D2ufkpafX3b+LHiitsqWu9iN2chY4R/sYerpb+k37X9lsjBXNSst6IAVpZeFNdEB6L97zbyElx/OyyvWCp1fSFjWrzljD2bfZWww== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <10043C1763DEA743A8558AC52DC826D5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ae3dbbd-0e7f-4aa8-31e5-08d890880643 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 14:48:36.5405 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xxzkDr5D5wQpyRaVwWfFseCFo7Ize1KrL0dT/qhXaJ0JmETO50JVyn+fpNXu1LFm X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4483 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 14:48:44 -0000 SGkgVG9tLCANCg0K77u/T24gMTEvMjQvMjAsIDQ6MzQgQU0sICJ0b20gcGV0Y2giIDxkYWVkdWx1 c0BidGNvbm5lY3QuY29tPiB3cm90ZToNCg0KICAgIE9uIDIzLzExLzIwMjAgMTc6MjcsIEFjZWUg TGluZGVtIChhY2VlKSB3cm90ZToNCiAgICA+IEhpIFRvbSwNCiAgICA+DQogICAgPiBTZWUgYSBj b3VwbGUgcmVzcG9uc2VzIGlubGluZSBlbmNsb3NlZCBpbiA8YWNlZT4gYW5kIDwvYWNlZT4uIFdl IGFyZSBhZGRyZXNzaW5nIHRoZSByZXN0IG9mIHlvdXIgY29tbWVudHMuDQogICAgPg0KICAgID4g T24gMTEvMTgvMjAsIDc6MzkgQU0sICJ0b20gcGV0Y2giIDxkYWVkdWx1c0BidGNvbm5lY3QuY29t PiB3cm90ZToNCiAgICA+DQogICAgPiAgICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgZG9lcyBub3Qg cmVnaXN0ZXIgdGhlIG1vZHVsZSBuYW1lcyB1c2VkIGluIHRoZSBtb2R1bGVzDQogICAgPg0KICAg ID4gPGFjZWU+DQogICAgPiBUaGlzIGlzIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zLi4uDQoN CiAgICA8dHA+DQogICAgSW5kZWVkOyBJIGRvIG5vdCBzZWUgYSByZWdpc3RyYXRpb24gb2YgaWV0 Zi1zZWdtZW50LXJvdXRpbmctbXBscyENCg0KWWVzIC0gSSBzZWUgdGhlIHR5cG8gbm93IHRoYXQg eW91IHBvaW50ZWQgb3V0IHdoaWNoIG9uZS4gDQoNCiAgICA+ICAgICBUaGlzIGRvY3VtZW50IHJl Z2lzdGVycyBhIFlBTkcgbW9kdWxlIGluIHRoZSBZQU5HIE1vZHVsZSBOYW1lcw0KICAgID4gICAg IHJlZ2lzdHJ5IFtSRkM2MDIwXS4NCiAgICA+DQogICAgPiAgICAgICAgbmFtZTogaWV0Zi1zZWdt ZW50LXJvdXRpbmctY29tbW9uDQogICAgPiAgICAgICAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi1zZWdtZW50LXJvdXRpbmctY29tbW9uDQogICAgPiAgICAgICAg cHJlZml4OiBzci1jbW4NCiAgICA+ICAgICAgICByZWZlcmVuY2U6IFJGQyBYWFhYDQogICAgPg0K ICAgID4gICAgICAgIG5hbWU6IGlldGYtc2VnbWVudC1yb3V0aW5nDQogICAgPiAgICAgICAgbmFt ZXNwYWNlOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zZWdtZW50LXJvdXRpbmcN CiAgICA+ICAgICAgICBwcmVmaXg6IHNyDQogICAgPiAgICAgICAgcmVmZXJlbmNlOiBSRkMgWFhY WA0KICAgID4NCiAgICA+ICAgICAgICBuYW1lOiBpZXRmLXNlZ21lbnQtcm91dGluZw0KICAgID4g ICAgICAgIG5hbWVzcGFjZTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtc2VnbWVu dC1yb3V0aW5nLW1wbHMNCiAgICA+ICAgICAgICBwcmVmaXg6IHNyLW1wbHMNCiAgICA+ICAgICAg ICByZWZlcmVuY2U6IFJGQyBYWFhYDQogICAgPiA8L2FjZWU+DQogICAgPg0KICAgID4gICAgICBF eGFtcGxlcyBhcmUgSVB2NCBvbmx5LCBJUHY2IHdvdWxkIGJlIGdvb2QNCiAgICA+DQogICAgPiAg ICAgIEJHUCBpcyBpbmNsdWRlZCB3aGVuIGl0IGNvbWVzIHRvIGRlZmluaW5nIGEgcm91dGVyLWlk IGJ1dCBpcyBpZ25vcmVkDQogICAgPiAgICAgIGV2ZXJ5d2hlcmUgZWxzZSwgc3VjaCBhcyBzaWdu YWxsaW5nIE1TRCwgcHJvdG9jb2wgZXh0ZW5zaW9ucyBldGMNCiAgICA+DQogICAgPiAgICAgIHJl ZmVyZW5jZSAiUkZDIFhYWFgiIHdvdWxkIGJlIGltcHJvdmVkIGJ5IGluY2x1ZGluZyB0aGUgdGl0 bGUgaW4gYWxsDQogICAgPiAgICAgIGNhc2VzIG5vdCBqdXN0IHNvbWUNCiAgICA+DQogICAgPiAg ICAgIHRoZSBzY2hlbWUgaHR0cDogYXBwZWFycyBpbiBtYW55IHBsYWNlcy4gIEl0IHdvdWxkIGJl IGxvdmVseSBpZiB0aGlzDQogICAgPiAgICAgIHJlYWxseSB3YXMgdGhlIHNjaGVtZSBidXQgSSBm ZWFyIHRoYXQgaXQgaXMgbm90DQogICAgPiA8YWNlZT4NCiAgICA+IFRoaXMgaXMgZGlyZWN0bHkg ZnJvbSB0aGUgUkZDIDg0MDcgdGVtcGxhdGUgaW4gQXBwZW5kaXggQi4gV2hhdCB3b3VsZCB5b3Ug c3VnZ2VzdD8NCg0KICAgIDx0cD4NCiAgICBNYW55IEktRCBkbyBub3cgc3BlY2lmeSBodHRwczog c2luY2UgdGhhdCBpcyBub3cgdGhlIG9ubHkgb3B0aW9uIA0KICAgIHN1cHBvcnRlZCBieSB0aGUg SUVURjsgSSBoYXZlIHNlZW4gdGhpcyBjYWxsZWQgZm9yIGJ5IGFuIEFELg0KDQpBcyBsb25nIGFz IHRoZSBVUkxzIHdvcmssIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGVpdGhlci4gDQoNCg0K ICAgID4gPC9hY2VlPg0KICAgID4NCiAgICA+ICAgICAgbW9kdWxlIHNyY21uDQogICAgPiAgICAg ICAgdGhlIHVwcGVyIGJvdW5kIG11c3QgYmUgbGFyZ2VyDQogICAgPiAgICAgICAgdGhlIHZhbHVl IG11c3QgYmUgZ3JlYXRlcg0KICAgID4gICAgICBjb25zaXN0ZW5jeSBpcyBnb29kIC0gSSB0aGlu ayBncmVhdGVyIGlzIGJldHRlcg0KICAgID4NCiAgICA+ICAgICAgOC4zDQogICAgPiAgICAgIG9w ZXJhdGlvbiBzdGF0ZXMNCiAgICA+ICAgICAgdXN1YWxseSBvcGVyYXRpb25hbA0KICAgID4NCiAg ICA+ICAgICAgdHdvIGltcG9ydHMgbGFjayByZWZlcmVuY2VzDQogICAgPg0KICAgID4gICAgICB0 eXBlZGVmIHJvdXRlci1pZA0KICAgID4gICAgICB0aGlzIGlzIGEgd2VsbCBrbm93biB0eXBlIGZy b20gUkZDODM5NDsgaXQgc2VlbXMgbGlrZWx5IHRvIGNvbmZ1c2UgdG8NCiAgICA+ICAgICAgcmVk ZWZpbmUgaXQgd2l0aCBhIHJlbGF0ZWQgYnV0IGRpZmZlcmVudCBtZWFuaW5nDQogICAgPg0KICAg ID4gICAgICBsZWFmIGVuYWJsZWQNCiAgICA+ICAgICAgZW5hYmxlcyBwcm90b2NvbCBleHRlbnNp b25zDQogICAgPiAgICAgIHdoaWNoIHByb3RvY29scz8NCiAgICA+DQogICAgPiAgICAgIGxlYWYg cHJvdGVjdGVkDQogICAgPiAgICAgIGl0IGlzIHVzZWQgdG8gcHJvdGVjdA0KICAgID4gICAgICBo b3cgZG9lcyBpdCBkbyB0aGF0Oi0pDQogICAgPg0KICAgID4gICAgICBlbnVtIGR1YWwNCiAgICA+ ICAgICAgLi4uIEluIHRoaXMgY2FzZSB3aWxsIGJlIGFkdmVydGlzZWQgd2l0aCBiYWNrdXAgZmxh ZyBzZXQNCiAgICA+ICAgICAgV2hhdCBpcyB0aGUgYmFja3VwIGZsYWc/ICBJdCBkb2VzIG5vdCBm ZWF0dXJlIGluIFJGQzg2NjAuICBOZWVkcyBhbg0KICAgID4gICAgICBleHBsYW5hdGlvbiBhbmQg cmVmZXJlbmNlDQogICAgPg0KICAgID4gICAgICBjb250YWluZXIgbGluay1tc2QNCiAgICA+ICAg ICAgICBsaXN0IGxpbmstbXNkcw0KICAgID4gICAgICAgICAgbGVhZiBtc2QNCiAgICA+ICAgICAg VGhlIHVzdWFsIFlBTkcgY29udmVudGlvbiBpcyBmb3IgYSBsaXN0IHRvIGJlIHBsdXJhbCBhbmQg dGhlIGxlYWYNCiAgICA+ICAgICAgc2luZ3VsYXIuICBZb3UgaGF2ZSB0aGUgcGx1cmFsIGxpc3Qg YnV0IG5vdCB0aGUgbGVhZi4NCiAgICA+IDxhY2VlPg0KICAgID4gU28geW91IGFyZSBhc2tpbmcg Zm9yIGEgY2hhbmdlIGZyb20gImxlYWYgbXNkIiB0byAibGVhZiBsaW5rLW1zZCI/DQoNCiAgICA8 dHA+DQogICAgWWVzIEkgd291bGQgZXNwZWNpYWxseSBnaXZlbiBub2RlLW1zZC4gIEkgd2lzaCB0 aGF0IFlBTkcgR3VpZGVsaW5lcyBzYWlkIA0KICAgIG1vcmUgYWJvdXQgY29udGFpbmVyIG5hbWVz LiAgSSB0aGluayB0aGF0IGhhdmluZyB0aGUgc2FtZSBpZGVudGlmaWVyIGZvciANCiAgICBjb250 YWluZXIsIGZvciBsaXN0LCBmb3IgbGVhZiAod2hpY2ggSSBoYXZlIHNlZW4gaW4gYW5vdGhlciBJ LUQpDQogICAgd2lsbCBsZWFkIHRvIG1pc3Rha2VzIHNvIGhhdmluZyBhIGNvbnZlbnRpb24gZm9y IGxpc3QgYW5kIGxlYWYgd2lsbCANCiAgICByZWR1Y2UgbWlzdGFrZXMgYnV0IGhhdmluZyBhbm90 aGVyIGZvciBjb250YWluZXIgd291bGQgYmUgZXZlbiBiZXR0ZXIuIA0KICAgIFRoYXQgc2FpZCwg SSBoYXZlIHlldCB0byB0aGluayBvZiBhIGdvb2QgY29udmVudGlvbg0KTGlrZSB5b3Ugc2FpZCwg dGhpcyB3b3VsZCBiZSB0aGUgdGhpcmQgdGltZSBmb3IgbGluay1tc2QocykuIEknbGwgc2VlIHdo YXQgbXkgY28tYXV0aG9ycyB0aGluay4gDQoNCg0KICAgIEluIHBhc3NpbmcsIG11c3QgbGluay1t c2QgYmUgPj0gbm9kZS1tc2Q/DQpZZXMgLSB0aGlzIGlzIGNsZWFyIGluIHRoZSBhc3NvY2lhdGVk IE1TRCBwcm90b2NvbCBkcmFmdHMuIA0KDQogICAgPiA8L2FjZWU+DQogICAgPg0KICAgID4NCiAg ICA+ICAgQW5kIHdobyBuZWVkcyB0aGUNCiAgICA+ICAgICAgY29udGFpbmVyPyAgVGhpcyBpcyBt cGxzIG5vdCBhIGNvbW1vbiBtb2R1bGUgdGhhdCBtaWdodCBiZSBhdWdtZW50ZWQgc28NCiAgICA+ ICAgICAgd2hhdCBkb2VzIHRoZSBjb250YWluZXIgZ2l2ZSBhcGFydCBmcm9tIGNvbXBsZXhpdHk/ DQogICAgPg0KICAgID4gICAgICBsaXN0IHBvbGljeQ0KICAgID4gICAgICAgIGxlYWYgc3RyaW5n DQogICAgPiAgICAgIFlBTkcgc3RyaW5nIGNhdGVycyBmb3IgdmVyeSBsYXJnZSBpdGVtcyBvZiB2 ZXJ5IGNvbXBsZXggY2hhcmFjdGVyIHNldHMuDQogICAgPiAgICAgICAgSXMgdGhhdCBkZXNpcmFi bGU/DQogICAgPiA8YWNlZT4NCiAgICA+IElFVEYgbW9kZWxzIG5vcm1hbGx5IGRvIG5vdCBsaW1p dCBpZGVudGlmaWVycy4gQW4gaW5kaXZpZHVhbCBpbXBsZW1lbnRhdGlvbiBjb3VsZCBkbyB0aGlz IHdpdGggYSBkZXZpYXRpb24uDQoNCiAgICA8dHA+DQogICAgSSBrbm93IC0gSSBkaWQgc2VlIGFu IEFEIGNoYWxsZW5nZSB0aGF0LCBJIHRoaW5rIGluIElFU0cgcmV2aWV3LCBub3QgDQogICAgbG9u ZyBhZ28uICBTTUkgd2FzIGJldHRlciBhdCB0aGlzIQ0KDQpTaW5jZSB3ZSBoYXZlIHN0YW5kYXJk aXplZCBvbiBhIG1heGltdW0gbGVuZ3RoIGZvciBpZGVudGlmaWVycyBvciBldmVuIHBvbGljeSBp ZGVudGlmaWVycywgSSdtIG5vdCBnb2luZyB0byBwaWNrIG9uZSBzcGVjaWZpYyB0byB0aGlzIGRy YWZ0LiBJdCBnb2VzIHdpdGhvdXQgc2F5aW5nIHRoYXQgaW1wbGVtZW50YXRpb25zIHdpbGwgaGF2 ZSBhIGxpbWl0LiANCg0KVGhhbmtzLA0KQWNlZQ0KDQogICAgVG9tIFBldGNoDQoNCiAgICA+IDwv YWNlZT4NCiAgICA+DQogICAgPiBUaGFua3MsDQogICAgPiBBY2VlDQogICAgPg0KICAgID4gICAg ICBsZWFmIHVzZWQNCiAgICA+ICAgICAgd2lsbCB1c2VkIHBsdXMgZnJlZSBlcXVhbCBzaXplPw0K ICAgID4NCiAgICA+ICAgICAgSW5kaWNhdGVzIGlmIHRoZSBiaW5kaW5nIGlzIC9pbnN0YWwvaW5z dGFsbGVkLw0KICAgID4NCiAgICA+ICAgICAgbm90aWZpY2F0aW9uLXNlZ21lbnQtcm91dGluZy1n bG9iYWwtc3JnYi1jb2xsaXNpb24NCiAgICA+ICAgICAgYSBtaXggb2YgY29uZmxpY3QgYW5kIGNv bGxpc2lvbjsgIGNvbnNpc3RlbmN5IGlzIGdvb2QgYW5kIEkgcHJlZmVyIHRoZQ0KICAgID4gICAg ICBsYXR0ZXIgd2hpY2ggaXMgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbg0KICAgID4NCiAg ICA+ICAgICAgY29udGFpbmluZyAvcy9hLyBtYXBwaW5nDQogICAgPg0KICAgID4gICAgICAuLi4g c2lkIGNvbGxpc2lvbg0KICAgID4gICAgICBhZ2FpbiBjb25zaXN0ZW5jeSBnb29kLCBwcmVmZXIg Y29sbGlzaW9uIHRvIGNvbmZsaWN0aW5nDQogICAgPg0KICAgID4gICAgICBzLjkNCiAgICA+ICAg ICAgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhlIHNyZ2Igd29ydGh5IG9mIG1lbnRpb24gdW5kZXIg c2Vuc2l0aXZlIG5vZGVzDQogICAgPg0KICAgID4gICAgICBUb20gUGV0Y2gNCiAgICA+DQogICAg Pg0KICAgID4gICAgICBPbiAxNi8xMS8yMDIwIDE5OjMyLCBUaGUgSUVTRyB3cm90ZToNCiAgICA+ ICAgICAgPg0KICAgID4gICAgICA+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJv bSB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGluIE5ldHdvcmtpbmcNCg0K From nobody Tue Nov 24 06:57:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68EB3A107D; Tue, 24 Nov 2020 06:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 9NeslhMPftfT; Tue, 24 Nov 2020 06:57:09 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2131.outbound.protection.outlook.com [40.107.243.131]) (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 6D5923A107B; Tue, 24 Nov 2020 06:57:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SO8TovRz1N/3dJ3d7s1y+Ebt3ZdwSFB/6vLEy4OCl3trtIYWeIhE6fQPF1r+UyUfdoIxW5XIWw8gFLRcHFAF+/Gps37zxp03RzX6wQ6MiKAwL0SA6KeCYqqFpiCBehRCUY+4fXMxXFyRkVqdmv2l5MuNteYhlpb3pT/J1bjm9bBzI8wBNT8t+z5HBkaBPDbSZsie0dNgVpjYbB+J2EgJMuar17oYuglR57MhU07JP3XF65zYe550MLm2MX8R/7wdhaiQfekVK2aQW/ApWKyRXuJrqRzU7PyweSGSBOSDnplYP534DfbO/inGLH1leRQbkP6ikUvP9NmciaKHe5uT5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lCBVwgHerM6EmgcyK3m3vK5lusoWCLfibk0WBRVlE7c=; b=IiEOfsvK1UyrzyJOAXQC2G978QqYbF8j36oT1IzdWiHxsd5wNtR6kYM+vIwyOFtSnrWVwChTz3zmhicpKB9A343BaMW5Mub8C0ejnZNXt8nbrMz53i4MF3vXj5Q6yvci6nM9azH7AGXhWpl2zChPozEGr4JZHijaXciopdvQO3/SqtV7yLpFLBZe4Q45dlGlh54r8t1nLL5OlVRJ0cDR7HbEORtFGF24sPIK/EewKs3s4vEPPhTF1R069htNs556QOnp+LnB7RFGKtDddgjilRDh8PhMr+CT+plcDwNY7ZyjvaGYwe2/7nTzc1GUUkJoe14jke6GxWwuvQ/Ogm66YA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lCBVwgHerM6EmgcyK3m3vK5lusoWCLfibk0WBRVlE7c=; b=exrfEq+/+BFVbLFQ1jAjgXBvh2b1mmkkpUQxNfNEMRykByhN5e71AzLqPWfEjmKkHmlnvO2lWwpZxrk31smTeiMtSVvSz5Ee+PlAHvaZ6Lh+fPi7t4IU/J1r2X3VCDebiA2AQBD7mEuU95gD33eQH4gWySHv9uRknMtrkaV4tTs= Received: from DM6PR13MB3066.namprd13.prod.outlook.com (2603:10b6:5:19d::18) by DM5PR13MB1851.namprd13.prod.outlook.com (2603:10b6:3:139::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 24 Nov 2020 14:57:06 +0000 Received: from DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::48cf:ff39:2972:7a65]) by DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::48cf:ff39:2972:7a65%6]) with mapi id 15.20.3611.018; Tue, 24 Nov 2020 14:57:06 +0000 From: James Guichard To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 Thread-Index: AdbCa21c1PFQQWUVQJOg9p9otl0vog== Date: Tue, 24 Nov 2020 14:57:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2600:6c64:497f:d3ca:99c1:e9c0:d60c:53b7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6b2c8c1-ad1a-4973-4dae-08d890893630 x-ms-traffictypediagnostic: DM5PR13MB1851: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Spf83tE3Uii24aVKJ/xD40wo+Ny1DWNvu/a7Ve+DiPyEYLHb9yL2ygacks85+ne97atTf5aSKu/fByfia0CuvTjQ1g1tOQqFQgWn3oYRQoCfS3sEzPGStSj8dECJYWRkTVE3aw55E3flDYrxUp590uN7twx6hF+YuzEYoXcdh61pWo+WO/ZCFAyVqEvIeWthGNcr7imAXojFJ6vAq/7eEgzlv8gdyrAKhCjpksvfL9OonYJ9on5p3twuT0/N7eQzqflEmO/qX7aMOCgrCwXLBwxLYvXbj/PKGdfBvTjcn4Gy5wCA8hbNrZTb9m5ZY9v9pFKeZNtB+l7BxyxbDAbxjq1KIpa0yRGzqEBBUhPXa6zzG4DdY4g1ZMOBb91psoucGR9DD8+OzCUDPp+faBlSgg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB3066.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(39850400004)(376002)(346002)(136003)(5660300002)(83380400001)(55016002)(7696005)(6506007)(8676002)(316002)(8936002)(52536014)(71200400001)(966005)(76116006)(86362001)(64756008)(66446008)(4744005)(66476007)(186003)(66556008)(66946007)(33656002)(4326008)(2906002)(6916009)(9686003)(166002)(478600001)(450100002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?E5Xkj/PLel6alMLocg/KEug1v1mrYKMgh3rlUU5Wg8DcwuK+OZRV+D8x1/Sm?= =?us-ascii?Q?yN+jdtb70fGG3uTrnSNhO9XSD3t3z3Vu96T2zlNK/6mIP876+skasTldXNzS?= =?us-ascii?Q?v0bfBHuhvAIrW9AdjriQIhS9jY+u0GK4ymyskjwZjNMeeMMmr0cxHSxEXo5W?= =?us-ascii?Q?gBPskMXQ9XwQWnZVdU4U3Z8c1qwnqRKcmPtggMyCj5/c/YtX6VnBbjQRRPQW?= =?us-ascii?Q?2g/zba9FSVJZO2Dz6LbJbIkLKHiv2fG1flPs/uBYcC474FjJKDSzaQDXEVQ0?= =?us-ascii?Q?6cUljZL0di0p1R/SHiTeHOaHxBYu5LwNuQwh3HALKuTsvY/yeJ9f1HSEwWWl?= =?us-ascii?Q?SYkMq40jKUBjLBAHfveUIg0feaHQoeb1Yt7NCjENQP1IUrFsnyx+yxLwQ8IA?= =?us-ascii?Q?kRf927p4LjidJQlNIiqXsaHcXroX7D4+c5jYBTv5NxQ1oyQmm6BoQieLUUAQ?= =?us-ascii?Q?vRUM+9wdmCwPmEr/z9Kq7Z8GLSnZN/6sn8ln7G8udIQ+ssjYsJKcu8hXwqkk?= =?us-ascii?Q?y2XIGlFg/sdN7XZfxTkEVNUwQcddf2DisZopLQ7kQL9YM8deCs+OUSh96vj1?= =?us-ascii?Q?qfCX4vXCtmSPM6JRD3JGBn93z4TLSkQ21ag2sOc+NajpZpnpKLRlzrmSPoUH?= =?us-ascii?Q?7GDRyDh3HXDe58RrnpOGT27272/ve/mtNUUKVdTlHSIUe3rUHiM0VL+sut6T?= =?us-ascii?Q?UUF7R4L+pX19+xfSSPF5d6Fxr5x2tN+k229dbcjJY6/msrUn5upAIaRMdtzA?= =?us-ascii?Q?bA8yR3NVTbWsnq2V2TLTlZLE91no94t1QVTPpwixhMT6U/X1tzlkniyYjLbV?= =?us-ascii?Q?6f7oCTFh7QYEZsvXXm7sovqSgyQ17A82ikCup+g9+3LFgcTzBoh4GL3KWbcs?= =?us-ascii?Q?MCpYIoymUXgDhAPTMa/jNCZs6x2bAfSXFLaB5vXjElGnkC4aSHFNzAk+WaqB?= =?us-ascii?Q?BrfBFcSLUk2o2No0gbeMwA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB30664C1E64599AF0D4306475D2FB0DM6PR13MB3066namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB3066.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6b2c8c1-ad1a-4973-4dae-08d890893630 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 14:57:06.6220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iRrN+WaFvxcQnuN1dYkeYb8QIt2V/Ge21XFiPioiUagv3r0B+ENJllSiTcyHk0NfuXjBrYws8k2YoISNVbXXAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR13MB1851 Archived-At: Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 14:57:11 -0000 --_000_DM6PR13MB30664C1E64599AF0D4306475D2FB0DM6PR13MB3066namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-= spring-srv6-path-segment-07 has just concluded and the chairs agree that en= ough support was received to approve this adoption. Authors, please resubmit a new document as draft-ietf-spring-srv6-path-segm= ent-00. In addition, please indicate whether you are aware of any IPR discl= osures for this document. Thanks! Jim, Joel & Bruno --_000_DM6PR13MB30664C1E64599AF0D4306475D2FB0DM6PR13MB3066namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear WG:

     

    The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has ju= st concluded and the chairs agree that enough support was received to appro= ve this adoption.

     

    Authors, please resubmit a new document as draft-iet= f-spring-srv6-path-segment-00. In addition, please indicate whether you are= aware of any IPR disclosures for this document.

     

    Thanks!

     

    Jim, Joel & Bruno

     

     

    --_000_DM6PR13MB30664C1E64599AF0D4306475D2FB0DM6PR13MB3066namp_-- From nobody Tue Nov 24 17:13:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8443A0D97; Tue, 24 Nov 2020 17:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Y2yT9pI08_Yp; Tue, 24 Nov 2020 17:13:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5CBF73A0E5B; Tue, 24 Nov 2020 17:13:30 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AP1DEwv021288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Nov 2020 20:13:18 -0500 Date: Tue, 24 Nov 2020 17:13:13 -0800 From: Benjamin Kaduk To: "Pablo Camarillo (pcamaril)" Cc: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Message-ID: <20201125011313.GH39170@kduck.mit.edu> References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 01:13:42 -0000 Hi Pablo, I must apologize twice over: first for the delay in responding, and second for the number of points in my discuss ballot that are not actual problems. I recently had the time to go over the document again, with benefit of your responses here, and now have a better understanding of some aspects that were confusing to me during my first reading. I still have a few things I want to take another look at, but I can respond to your comments now -- the good news is that these discuss points all look to be resolved. More inline... On Fri, Sep 25, 2020 at 06:31:52PM +0000, Pablo Camarillo (pcamaril) wrote: > Hi Benjamin, >=20 > Thank you for your time and review. Please see inline with [PC]. >=20 > Regards, > Pablo. >=20 > -----Original Message----- > From: Benjamin Kaduk via Datatracker =20 > Sent: jueves, 24 de septiembre de 2020 9:52 > To: The IESG > Cc: draft-ietf-spring-srv6-network-programming@ietf.org; spring-chairs@ie= tf.org; spring@ietf.org; Bruno Decraene ; Joel H= alpern ; jmh@joelhalpern.com > Subject: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-progr= amming-20: (with DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-spring-srv6-network-programming-20: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programmi= ng/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > [edited to remove nonsensical point that had crept in about the SRH being= a new extension header; it's "just" a routing header] >=20 > The current requirement that IANA-assigned SRv6 Endpoint Behavior codepoi= nts are used, with no range reserved for local assignment, seems to be invi= ting codepoint squatting from the nominally reserved range. > Why is there an absolute requirement for registration (even FCFS) without= ranges for local or experimental use? (What are the various reserved rang= es reserved for?) > [PC] I agree with you that a range for local use would come useful. Hence= , we=E2=80=99ve carved 2k entries of the registry for Private Use. > The Reserved range (half of the 65k registry) is for future allocation by= IETF. Future RFCs might decide how to use that. Sounds good; thanks! > The (normative) pseudocode does not seem to handle the case when the SRH = is omitted for the degenerate case where there is only a single segment, or= for the PSP flavor. > [PC] Each one of the pseudocodes provides the SRH processing and the Uppe= r-Layer processing. If there is no SRH, then the SRH processing is not exec= uted, but the Upper-layer Header processing is. This is the same as in RFC8= 754. To expand a bit more on how I was confused here, I was looking particularly at the End, End.X, and End.T cases (though I guess it also applies to the Encaps cases). In the normal flavor, upper-layer processing gets shunted over to section 4.1.1 that doesn't really do much -- in particular, there is no interconnect for End.X and no table lookup for End.T! But this really is the right behavior, since the SRH is only absent when this SID is the final destination of the packet, and in that case we really must act as an endpoint and not a router. If we did send the packet onward it would most likely just get looped back to us until the hop limit expires (or get some other error), so generating a local ICMP error is the right thing to do in the general case, unless there is local configuration for that upper-layer protocol. > The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext L= en is measured in units of 8 octets, and does not include the first 8 octet= s of the extension header, but Payload Length is measured in octets. Liter= ally decreasing the Payload Length by the Hdr Ext Len value will produce a = malformed IPv6 packet. > [PC] Indeed. Fixed. >=20 > If "PSP operation is deterministically controlled by the SR Source Node",= why do we need to define behavior codepoints that (for example) use both P= SP and USP? I don't see how there is full determinism in this case while b= eing different from the "PSP only" flavor. > [PC] In order for the PSP behavior to be executed there must happen two t= hings. First, the SR Source Node must instruct it wants to use the PSP beha= vior. This is done by using an SRv6 SID associated with a behavior that sup= port the PSP flavor (either End with PSP alone, or End with PSP in combinat= ion of other). Then, the second thing is that the received packet at the no= de it must have a SL value of 1, that during processing is decremented to 0= =2E (In other words, it must be the penultimate segment). If both condition= s are given, then lines S14.2-S14.4 of the pseudocode are executed. I understand now; thanks for explaining it again. (To reiterate: any given SID can appear "anywhere" in the segment list, so USP is relevant when it is last and PSP is relevant when it appears second-to-last. The USP/PSP flavor doesn't need to be the same for all SIDs in the path, so marking a single SID with both can be relevant for different paths.) > There are numerous factual errors and un/under-specified protocol behavio= r (see COMMENT), including: how to set the outer Hop Limit (multiple instan= ces), the order of segments in the SRH, specification of headend behavior b= y reference to informal example, L2 frame en/decapsulation procedures, and = the "Opaque" note for endpoint behavior 65535. > [PC] I=E2=80=99ll comment on each point in the comment. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I note that this document references > draft-filsfils-spring-srv6-net-pgm-illustration, which uses the IPv4 CIDR= 20/8 in examples instead of addresses from the RFC 5737 range. It would b= e disappointing to have a PS refer to a draft that squats on the IPv4 names= pace in such a manner. > [PC] Ack. I=E2=80=99ve updated draft-filsfils-spring-srv6-net-pgm-illustr= ation to correct that. Thank you! > Abstract, Introduction >=20 > This document defines the SRv6 Network Programming concept and > specifies the base set of SRv6 behaviors that enables the creation of > interoperable overlays with underlay optimization (Service Level > Agreements). >=20 > I don't understand what the parenthetical is intending to convey. > [PC] I=E2=80=99ve removed the parenthesis. Its unneeded. >=20 > Section 2 >=20 > The following terms used within this document are defined in > [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 > SID, SR Policy, Prefix SID, and Adjacency SID. >=20 > [RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.] > [PC] Fixed in rev21. >=20 > Section 3 >=20 > The text allegedly reproduced from RFC 8754 =C2=A74.3 differs in case and= hyphenation. > [PC] Fixed in rev21. >=20 > Section 3.1 >=20 > This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, > where a locator (LOC) is encoded in the L most significant bits of > the SID, followed by F bits of function (FUNCT) and A bits of > arguments (ARG). L, the locator length, is flexible, and an operator > is free to use the locator length of their choice. F and A may be > any value as long as L+F+A <=3D 128. When L+F+A is less than 128 then > the remaining bits of the SID MUST be zero. >=20 > Why does A have to be a fixed value; can't it safely be a function of F (= even if we exclude things like huffman coding for F)? > [PC] Can you please re-state your point? The text above does not suggest = that A is a fixed value, hence I=E2=80=99m not sure I fully understand what= you mean. It's true that there is no specific statement "A is a constant across ". However, there is also not a specific statement "the value of A can depend on ", so the reader has to make an interpretation. We do say that L is flexible and the operator can choose that length; I interpreted this to mean that the operator makes the choice once, and that L is fixed for the entire SR domain. With that in my head, it was also natural to infer that F and A are also fixed for the entire SR domain. (Is L allowed to vary even within the domain?) If we do want to allow F and A to vary at a (e.g.) per-LOC scope, we should probably make some statement about being able to decode them properly on receipt; this could be done in many ways, including a strict lookup table and a self-deliniating length-encoding scheme, but there cannot be ambiguity about how to partition a given IP address into LOC:FUNCT:ARG. > An SRv6 Segment Endpoint Behavior may require additional information > for its processing (e.g. related to the flow or service). This > information may be encoded in the ARG bits of the SID. >=20 > (Assuming that it can be sufficiently compactly encoded?) > [PC] Correct >=20 > The ARG value of a routed SID SHOULD remain constant among packets in > a given flow. Varying ARG values among packets in a flow may result >=20 > (Thus limiting the type of information that can be represented in the > ARG?) > [PC] This text provides a SHOULD, and a reason for it. If other behaviors= defined in future documents would like to have ARG value varying for packe= ts belonging to the same flow, it is important that they take this into con= sideration. >=20 > Section 3.2 >=20 > SIDs. The provider historically deployed IPv6 and assigned > infrastructure addresses from a portion of the fc00::/7 prefix. They > further subdivided the prefix into three /48 prefixes (Country X, > Country Y, Country Z) to support their SRv6 infrastructure. From > those /48 prefixes each router is assigned a /64 prefix from which > all SIDs of that router are allocated. >=20 > This is not the language I would have expected for use of the ULA address= range. It looks like this may be related to Erik Kline's Discuss point... > [PC] Indeed related. Erik Kline has suggested text. Ill use Erik=E2=80=99= s text as provided. >=20 > IPv6 address consumption in both these examples is minimal, > representing one billionth and one millionth of the assigned address > space, respectively. >=20 > I'm not sure I understand the calculation that produced these values. > [PC] If the operator got assigned a /20 by the RIR, then they have 2^28 /= 48 prefixes available. Thus, if they are only using a few /48 prefixes, the= n they are using less than a millionth of the available /48 prefixes. Apparently I didn't take notes on my initial calculations that left me confused. Assuming I have it right this time... # Use 3 /48s in the whole ULA /40 >>> 3./2**40 2.7284841053187847e-12 # Use "a few" 3 /48s from the assigned /20 >>> 3./2**28 1.1175870895385742e-08 This seems to be well less than a billionth and a millionth, respectively, so I'm not sure if I am doing the math as intended. > An SR Source Node cannot infer the behavior by examination of the > FUNCT value of a SID. >=20 > Therefore, the SRv6 Endpoint Behavior codepoint is advertised along > with the SID in the control plane. >=20 > These two sentences feel a little out of place in this spot, occurring af= ter previous discussion that the endpoint behavior codepoint is advertised = in the control plane. > [PC] Other ADs have expressed the value of precisely those two sentences. I agree that these sentences are valuable. I was proposing to move them two paragraphs earlier, so we transition directly from "advertises the SID =2E.. in the control plane" to (paraphrasing) "cannot infer behavior by examining FUNCT" and "behavior codepoint is advertised along with SID". > o At Router 3, within the locator 2001:db8:bbbb:3::/64, network > operator or the router performs dynamic assignment for: >=20 > nit: missing article ("the network operator"). > [PC] Ack. Fixed in rev21. >=20 > * Function 100 associated with the behavior End.X (Endpoint with > cross-connect) between router 3 and its connected neighbor > router, for example Router 4. This function is encoded as > 16-bit value and has no arguments. >=20 > Please clarify that "function 100" is a hex literal. > [PC] Ack. Fixed in rev21. >=20 > I also suggest noting clearly at the start of the example that F is 16 an= d A is 0. > [PC] Ack. Added for each SID in rev21. >=20 > * Function 101 associated with the behavior End.X (Endpoint with > cross-connect) between router 3 and its connected neighbor > router, for example Router 2. This function is encoded as > 16-bit value and has no arguments. >=20 > F is a constant for the SR domain; saying it at each SID assignment is mi= sleading. > [PC] Function is the bits in the SID instantiated by the router. Can you = please explain what text gives the impression that F is a constant? FUNCT is instantiated by the router, yes, and it is F bits long. This ties in to my previous comment about L, F, and A (maybe) being constants across the SR domain, or clarifying at which scope they can vary. > [same note about hex for 101] > [PC] Ack. Added for each SID in rev21. >=20 > Section 4 >=20 > The list is not exhaustive. In practice, any function can be > attached to a local SID: e.g. a node N can bind a SID to a local VM > or container which can apply any complex processing on the packet. >=20 > Yes, but it can't advertise the behavior corresponding to that function w= ithout a codepoint. > [PC] This is intended to be an introductory paragraph to the behaviors. B= ut you are absolutely right: for any new behavior you need to write a new I= -D (as its currently happening in other SPRING WG docs), and then -once RFC= ed- get an SRv6 Endpoint Behavior codepoint for it. Maybe we could add at the end ", provided there is a behavior codepoint allocated for that processing" or some similar edit? (We don't have to; the decision is up to you.) > Section 4.1.1 >=20 > When processing the Upper-layer Header of a packet matching a FIB > entry locally instantiated as an SRv6 End SID, if Upper-layer Header > processing is allowed by local configuration (e.g. ICMPv6), then >=20 > nit: the parenthetical is placed so as to apply to "local configuration",= which doesn't really make sense; I presume the intent is to say that upper= -layer header processing is allowed *for that upper-layer protocol*. Also,= comma after "e.g.". > [PC] Agreed, but see next point. >=20 > problem message to the Source Address and discard the packet. Error > code 4 (SR Upper-layer Header Error) and Pointer set to the offset of > the upper-layer header. >=20 > nit: this is not a complete sentence. > [PC] We have been asked to change the entire 4.1.1 to a pseudocode. Pleas= e review the pseudocode in revision 21 and let me know your feedback. Yes, this pseudocode looks much better -- thank you! That said, I am not sure that I understand why it is only RECOMMENDED (not REQUIRED) to only allow upper-layer processing when that does not result in the packet being forwarded. Are there cases when this would be useful and not result in a packet loop? > Section 4.2 >=20 > It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is > required to express any traffic-engineering policy. >=20 > This text reads as if End.X specifically is required for TE, which does n= ot seem correct to me. > [PC] Fixed. > OLD: and it is required to express any traffic-engineering policy. > NEW: and its main use is for traffic-engineering policies. >=20 > Section 4.4, 4.5 >=20 > This is equivalent to the per-CE > VPN label in MPLS [RFC4364]. >=20 > The phrase "per-CE VPN" does not appear in RFC 4364. > [PC] Added to the terminology section. >=20 > Section 4.5 >=20 > S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then > one entry of the array is selected based on the hash of the packet's > header Section 7. >=20 > nit: I suggest "(see Section 7)" to match section 4.4. > [PC] Indeed. Fixed. >=20 > Section 4.6, 4.7 >=20 > is required. This is equivalent to the per-VRF VPN label in MPLS > [RFC4364]. >=20 > The phrase "per-VRF VPN" does not appear in RFC 4364. > (A similar comment applies to Section 4.8 as well.) > [PC] Added to the terminology section of the document. >=20 > Note that an End.DT6 may be defined for the main IPv6 table in which > case and End.DT6 supports the equivalent of an IPv6inIPv6 >=20 > nit: s/and/an/ > [PC] Thanks. Fixed. >=20 > Section 4.7 >=20 > The "Endpoint with decapsulation and specific IPv4 table lookup" > behavior (End.DT4 for short) is a variant of the End behavior. >=20 > nit: variant of End.T, just like End.DT6, no? > [PC] Correct, fixed. >=20 > Section 4.9 >=20 > S04. An End.DX2 behavior could be customized to expect a specific > IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header > before forwarding on the outgoing interface. >=20 > Would this customized behavior require a new codepoint? > Similarly for End.DX2V (Section 4.10) > [PC] No, that customization is local config to the node. That is surprising to me (it seems like an important part of the behavior that should be signalled explicitly), but I am not familiar enough with this domain in order to argue about it any further. > Section 4.10 >=20 > S04. Remove the outer IPv6 Header with all its extension headers, > lookup the exposed VLANs in L2 table T, and forward > via the matched table entry. >=20 > Just to check my understanding: the "exposed VLANs" (plural?!) are in the= Ethernet header of the packet that we are left with after removing the out= er IPv6 header, right? > [PC] Correct. And multiple tags in case of Q-in-Q. >=20 > S01. IANA has allocated the Internet Protocol number 143 to Ethernet > (see Section 10.1). >=20 > This seems like a copy/paste leftover from End.DX2 -- we don't mention > 143 in this section. > [PC] Indeed. I added by mistake on rev20 to address an AD comment and I h= ave just removed in rev21 again. >=20 > Section 4.12 >=20 > Two of the applications of the End.DT2M behavior are the EVPN > Bridging of broadcast, unknown and multicast (BUM) traffic with > Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use- > cases. >=20 > Are there references for either/both of these? > [PC] Added in rev21. Thanks! > S04. Remove the IPv6 header and all its extension headers >=20 > nit: the rest of the document uses "Remove the outer IPv6 header with all= its extension headers". > [PC] Fixed. Thanks. >=20 > S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 >=20 > nit: s/one/ones/ > [PC] Fixed. Thanks. >=20 > Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits > represent a list of up to k OIFs, each identified with an x-bit > value. Values k and x are defined on a per End.DT2M SID basis. The > interface identifier 0 indicates an empty entry in the interface > list. >=20 > (editorial) rather than have to come up with the concept of an "empty ent= ry" in the interface list, I would probably just say that the identifier 0 = is reserved and is ignored when doing the exclusion of OIFs. >=20 > I also think we need to say that the order and identifier assignment of e= lements of the interface list (that is, what the x-bit values index > into) is under the local control of N, but has to remain stable as long a= s SIDs are advertised that list members of the list in ARG. (There is othe= rwise a great deal of freedom in assignment since the values are only consu= med by the node that advertises them.) > [PC] This text is updated as part of Alvaro=E2=80=99s comment. Can you pl= ease check the current text in rev21? I think the new text is doing the right thing -- the structure of the value is entirely local to the SR Endpoint advertising it. I will have an editorial comment in my updated ballot position about the "signaling of the argument to other nodes..." clause, though. > Section 4.13 >=20 > It's probably worth calling out the MTU considerations of pushing the new= IPv6 header+SRH and tunneling the packets. (I know we reference > 2473 already, but the MTU is pretty important.) > [PC] MTU considerations are covered in RFC8754. >=20 > S17. The Payload Length, Traffic Class and Next-Header fields are > set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. >=20 > How is the Hop Limit set for the outer header? > (I assume =C2=A76.3 of RFC 2473, but given that you provide a reference f= or all the other fields, it seems like an omission to not mention Hop Limit= as well.) > [PC] Sure, added. [Thanks. I'll note some similar reference nits regarding =C2=A75.1 in my up= dated comments] > Section 4.14 >=20 > The SRH MAY be omitted when the SRv6 Policy only contains one segment > and there is no need to use any flag, tag or TLV. >=20 > If this is the case does it matter if I use End.B6.Encaps or End.B6.Encap= s.Red? > [PC] If you only have a single segment, then it does not matter. However = when you have more than one segment the change is significant. >=20 > Section 4.16 >=20 > I don't think I understand what it would mean for a specific SID to suppo= rt the multiple flavors "in combinations". > [PC] Convoluted sentence indeed. > > For each of these > behaviors these flavors MAY be supported for a SID either > individually or in combinations. > > > The End, End.X or End.T behaviors could support these flavors either indi= vidually or in combination. > Much better; thanks! It may be less relevant now that we are assigning behavior codepoints for each flavor combination, but IMO the USD flavor fits more naturally into being "part of the main behavior". E.g., we have End.DT46 already, and I'm not sure how that (behavior codepoint 20) differs =66rom End.T with USD (behavior codepoint 36). I think it's generally a bad idea to have multiple ways of expressing the same behavior. > Section 4.16.1.2 >=20 > A penultimate SR Segment Endpoint Node is one that, as part of the > SID processing, copies the last SID from the SRH into the IPv6 > Destination Address and decrements Segments Left value from one to > zero. >=20 > I think technically it copies the first SID from the SRH (SRH.Segment Lis= t[0]), which is the last SID from the SR Policy. > [PC] RFC8754 uses the term =E2=80=9Clast SID=E2=80=9D to refer to SRH.Seg= mentList[0]. Please refer RFC8754 Sec 6.1 for details. > Also, nit: "the" for "the Segments Left value". > [PC] Ack. Corrected. >=20 > S14.2. Update the Next Header field in the preceding header to the > Next Header value of the SRH >=20 > nit: personally, I would write "from the SRH", since "next header value o= f the SRH" is very close to "next header value of SRH", i.e., 43. > [PC] Reads better indeed. Corrected. >=20 > As a reminder, [RFC8754] defines in section 5 the SR Deployment Model > within the SR Domain [RFC8402]. Within this framework, the > Authentication Header (AH) is not used to secure the SRH as described > in Section 7.5 of [RFC8754]. >=20 > I strongly recommend adding another sentence clarifying why this is relev= ant to discussion of removing an extension header from the packet. > [PC] I suggest that is not relevant to the discussion of PSP since AH is = not defined for the SRH. We should explain why we are saying anything at all about AH. Right now it sounds like an irrelevant piece of information that should have been edited out of the document, but it actually is quite important in attempting to justify the design decision of allowing PSP! > Section 5 >=20 > This list can be expanded in case any new functionality requires it. >=20 > How? By an RFC that Updates: this one? > [PC] New functionality would have to be introduced via a new document but= it does not have to update this one since it is not modifying what is in t= his document but adding something new.=20 > We have updated the text as s/This list can be expanded in case any new f= unctionality requires it/This list is not exhaustive and future documents m= ay define additional behaviors. Thanks. > Section 5.x >=20 > I agree with the directorate reviewer that the protocol behavior should b= e written out explicitly, without reference to the handling of example pack= et(s). > [PC] There is already pseudocode and descriptions in these sections that = describes the behavior. Examples are to help understanding. Can you clarify= what more is required? The pseudocode hardcodes that the segment list is (S3, S2, S1; SL=3D2), whi= ch is just an example of what the SRH could be. It's not truly generic pseudocode. Also, I think it would be great if 5.2, 5.3, and 5.4 could do the sort of thing we did for the endpoitn behaviors where it replaces the definition of one or more of the numbered pseudocode steps. (I don't think we can, right now, since the numbered pseudocode doesn't cover all the relevant parts that are changing, and I didn't think about how hard it would be to change the pseudocode to make that the case. > Section 5.1 >=20 > S03. Set outer payload length, traffic class and flow label >=20 > What about the outer Hop Limit? > [PC] Added. >=20 > S03: As described in [RFC6437] (IPv6 Flow Label Specification) >=20 > Why is this all the way at the bottom of the section instead of included = with the corresponding content? > [PC] Ack. Brought up. >=20 > Section 5.3 >=20 > The encapsulating node MUST remove the preamble or frame check > sequence (FCS) from the Ethernet frame upon encapsulation and the > decapsulating node MUST regenerate the preamble or FCS before > forwarding Ethernet frame. >=20 > "or"? I get to choose one or the other? It's okay to only put back a pr= eamble but no FCS (or vice versa)? > [PC] Good catch. s/or/and; also preamble removed only if present >=20 > Section 6 >=20 > traffic that matched that SID and was processed correctly. The > retrieval of these counters via MIB, NETCONF/YANG or any other means > is outside the scope of this document. >=20 > (editorial) a MIB is an abstract data structure (likewise a YANG module);= information might be retrieved *from* it but not *via* it. For *via*, tha= t would be SNMP, NETCONF, and/or RESTCONF. > [PC] Fixed. >=20 > Section 8.1 >=20 > Does it make sense to reference RFCs 8491, 8476, 8841, etc. for advertisi= ng MSD via IGP? > [PC] I would leave that up to the srv6 control plane drafts; but no stron= g preference. >=20 > In particular, the SR source (e.g., H.Encaps), intermediate endpoint > (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) > behaviors. [...] >=20 > This is not a complete sentence, and I really have no idea what verb was = intended. > [PC] Indeed, fixed in rev21. >=20 > Section 8.2, 8.3 >=20 > Can we get references for the BGP variants here and their usage for signa= ling SRv6 capabilities and (SID,behavior codepoint) pairs? > [PC] The references to the BGP features have already been provided in the= respective sections where these behaviors are specified. There are WG draf= ts in progress for SRv6 extensions to routing protocols (not just BGP) that= normatively reference this document. There used to be informative referenc= es the other way around from this document which were removed during WGLC b= ased on feedback. We can add them back if that makes sense for the IESG. I think that those informative references would be helpful, but I also don't know how strong the WG consensus was to remove them (or what reasoning was offered for doing so). > Section 9 >=20 > I would really like to have a stronger reference to Section 5 of RFC > 8754 where the conceptual model of a SR Domain as a single system, where = all packets in the domain are encapsulated using IPv6 headers [with SIDs as= SA/DA]. The part in brackets is not spelled out very clearly and could we= ll be expounded upon in this document. I can write up some (very ad hoc) i= deas for what I had in mind, which you are welcome to adopt but expected to= wordsmith/edit appropriately: >=20 > % Section 5 of [RFC8754] describes the SR deployment model and the % base= line requirements for securing the SR Domain. In many ways the SR % Domain= is analogous to an MPLS domain -- it's a tightly controlled % system where= packet processing is controlled by a list (or stack) of % opaque identifie= rs that, by and large, only have defined semantics in % the context of the = node that receives and processes the packet when % that identifier is "topm= ost" or "current". Experience in securing and % operating MPLS domains sho= uld be readily transferrable to SRv6 % domains, in ensuring that all traffi= c within the network is tightly % controlled, with all external inputs bein= g properly encapsulated (for % SRv6, by an IPv6 header usually with SRH; fo= r MPLS, by the label % stack). The dedicated format for the MPLS label sta= ck and label % identifiers makes a clear mechanical separation between "int= ernal" and % "external" identifiers. In contrast, SRv6 uses SIDs for the in= ternal % identifiers, which have format and operation of IPv6 addresses. W= hile % this lets SRv6 benefit from IP longest-prefix routing and thus the %= structure of SID values, it also means that there is not a crisp % mechani= cal separation between "internal" and "external" identifiers. > % As such, care and rigor in annotating which IPv6 addresses/headers are = % internal vs external is required in order to maintain the integrity % and= security of the SRv6 domain. >=20 > [PC] Thanks for your suggestions. Indeed we should update the draft with = something along those lines. > The comparison or equivalence to MPLS is likely going to be confusing and= hence we avoid going down that path. We were thinking on something like th= e following. > Please let me know of what you think. (I have not pushed this into the dr= aft yet). >=20 > [re-wrapped for ease of inline commenting] That said, I am just offering editorial suggestions; I really like what you came up with -- thank you! > The security considerations for Segment Routing are discussed in > [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model and > the requirements for securing the SR Domain. The security > considerations of [RFC8754] also cover aspects such as attack vectors nit: I'd consider s/aspects/topics/ but it's a bit of a judgment call > and their mitigation mechanisms that also apply to the behaviors > introduced in this document. Together, they describe the required > security mechanisms that allow establishment of an SR domain of trust I would end the sentence here, after "SR domain of trust". Then we could continue on as "Having such a well-defined trust boundary is necessary in order to operate [...]" > to operate SRv6-based services for internal traffic while preventing > any external traffic from accessing or exploiting the SRv6-based > services. Care and rigor in IPv6 address allocation for use for SRv6 > SID allocations and network infrastructure addresses to be separate > from IPv6 addresses allocated for end-users/systems (as illustrated in > Section 5.1 of [RFC8754]) help differentiate internal vs external > address space that is required to maintain the integrity and security > of the SRv6 Domain. Additionally, [RFC8754] defines an HMAC TLV This sentence got a bit convoluted and maybe a bit long. I propose (only helping with the "convoluted" but not the "long" part): % Care and rigor in IPv6 address allocation for use for SRv6 SID % allocations and network infrastructure addresses, as distinct from IPv6 % addresses allocated for end-users/systems (as illustrated in Section 5.1 % of [RFC8754]), can provide the clear distinction between internal and % external address space that is required to maintain the integrity and % security of the SRv6 Domain. > permitting SR Endpoint Nodes in the SR domain to verify that the SRH > applied to a packet was selected by an authorized party and to ensure > that the segment list is not modified after generation, regardless of > the number of segments in the segment list. When enabled by local > configuration, HMAC processing occurs at the beginning of SRH > processing as defined in [RFC8754] Section 2.1.2.1. > > This document introduces SRv6 Endpoint and SR Policy Headend behaviors > for implementation on SRv6 capable nodes in the network. As such, this > document does not introduce any new security considerations. > I'm less sure that we want to keep the "no new security considerations" text. I have a few notes staged in my updated ballot comments, but one noteworthy thing that comes to mind is that PSP prevents the egress node =66rom validating the HMAC TLV. > There might also be room for discussion (in the main body of the > document) of how the various decapsulation procedures occur precisely whe= n the packet is leaving the SR Domain. > [PC] The sections 4.4 through 4.12 do describe these procedures for the d= ecapsulation behaviors specified in this document. Yes, the decapsulation procedures themselves are covered well. I am suggesting to mention that the act of decapsulation (generally) signals that the packet is leaving the SR domain, where we describe the procedures themselves. > Having the ARG structure specified as part of the behavior codepoint regi= stration means that a node that can apply that SID can also spoof the ARG t= o force a different (e.g.) outgoing interface list. > Specifically, it gives the attacker a degree of freedom greater than just= the SID behaviors that the node advertises. The HMAC TLV would mitigate t= his to the extent that it limits what SIDs the node in question is allowed = to apply and what changes can be made on-path. > [PC] The processing of ARG is specific to a behavior defined and not gene= ric. Please refer to the updated text in Sec 4.12 for End.DT2M (which is cu= rrently the only specified behavior that accepts ARGs). Since the ARG bits = are part of the SID there are no other considerations for them apart from t= he ones that apply to the SID as a whole. Even though the ARG bits are specific to a behavior (a function, really, IIUC), if there is a need to have ARG bits then there is going to be more than one valid value for the ARG bits. Now that we have removed a description for the structure of the ARG bits, it becomes a little harder to spoof them, but only a little bit. Given the L+F+A<128 constraint, A may very well be something small, on the order of 10; an exhaustive search over the 2**10 possible values for ARG to see which are valid and what they do would be fairly easy to do. An attacker in a position to do that exhaustive search (admittedly, one would be violating the "trusted SR domain" assumption to get there) could be able to observe the different behaviors provided by the different ARG values and select what behavior they wanted by spoofing ARG. If A was larger, like 64 or 128, this search and guessing would be much less practical, but we don't really have that many bits lying around. So, I think this is a new security consideration introduced by the presence of the ARG bits in the SID, and we should mention it. (We would also mention that the risk is largely mitigated by the assumption that the SR domain is trusted, of course.) > services. Additionally, [RFC8754] defines an HMAC TLV permitting SR > Endpoint Nodes in the SR domain to verify that the SRH applied to a > packet was selected by an authorized party and to ensure that the > segment list is not modified after generation, regardless of the > number of segments in the segment list. When enabled by local >=20 > I suggest adding a sentence similar to "(This does, however, require that= the segment list, and thus, the SRH is present in the packet; the optional= ability to elide the SRH when there is only a single segment and no flags,= tags, or TLVs needed inherently excludes the protection of the HMAC TLV.)" > [PC] All the SR Policy Headend (i.e. the SR Source Node) behaviors define= d in Sec 5 state: > > The push of the SRH MAY be omitted when the SRv6 Policy only contains = one segment and there is no need to use any flag, tag or TLV. > So, it follows that if HMAC protection is required, then SRH has to be us= ed even with a single segment. Ah, I see your point, yes. Sorry for missing that. (But I think my earlier comment about PSP still applies.) > Section 10.1 >=20 > definition: The value 143 in the Next Header field of an IPv6 header > or any extension header indicates that the payload is an Ethernet > [IEEE.802.3_2018]. >=20 > nit: is there a missing word here ("frame"?)? > [PC] Ack, fixed. >=20 > Many thanks for your time. Thank you for yours as well, and the updates already present and queued. Sorry again for taking so long to get back to you. -Ben From nobody Tue Nov 24 22:13:30 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680EC3A105B; Tue, 24 Nov 2020 22:13:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160628480237.28598.23308092846321742@ietfa.amsl.com> Date: Tue, 24 Nov 2020 22:13:22 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-24.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 06:13:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-24.txt Pages : 38 Date : 2020-11-24 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-24 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-24 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 Nov 24 22:26:34 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1FE3A1078; Tue, 24 Nov 2020 22:26:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160628558818.8972.5562093679458469775@ietfa.amsl.com> Date: Tue, 24 Nov 2020 22:26:28 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-25.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 06:26:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-25.txt Pages : 38 Date : 2020-11-24 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-25 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-25 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 Nov 24 23:39:39 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F23A117B; Tue, 24 Nov 2020 23:39:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160628997787.4673.488361825432021066@ietfa.amsl.com> Date: Tue, 24 Nov 2020 23:39:37 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-path-segment-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 07:39:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Path Segment for SRv6 (Segment Routing in IPv6) Authors : Cheng Li Weiqiang Cheng Mach(Guoyi) Chen Dhruv Dhody Rakesh Gandhi Filename : draft-ietf-spring-srv6-path-segment-00.txt Pages : 11 Date : 2020-11-24 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment has been defined to identify an SR path in SR-MPLS networks, and is used for various use-cases such as end-to- end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the Path Segment to identify an SRv6 path in an IPv6 network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-path-segment-00 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 24 23:49:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FFE3A1195; Tue, 24 Nov 2020 23:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WgdgbLmPBY0I; Tue, 24 Nov 2020 23:49:06 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFDE3A1193; Tue, 24 Nov 2020 23:49:05 -0800 (PST) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CgtJj3mQLz67HPJ; Wed, 25 Nov 2020 15:47:17 +0800 (CST) Received: from fraeml702-chm.china.huawei.com (10.206.15.51) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 25 Nov 2020 08:49:01 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Wed, 25 Nov 2020 08:49:01 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.134]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Wed, 25 Nov 2020 15:48:55 +0800 From: "Chengli (Cheng Li)" To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 Thread-Index: AdbCa21c1PFQQWUVQJOg9p9otl0vogAk+KLw Date: Wed, 25 Nov 2020 07:48:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02CF18B6dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 07:49:11 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02CF18B6dggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks for Chairs! I am not aware of any IPR disclosures for this doc= ument. Thanks, Cheng From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Tuesday, November 24, 2020 10:57 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-= segment-07 Dear WG: The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-= spring-srv6-path-segment-07 has just concluded and the chairs agree that en= ough support was received to approve this adoption. Authors, please resubmit a new document as draft-ietf-spring-srv6-path-segm= ent-00. In addition, please indicate whether you are aware of any IPR discl= osures for this document. Thanks! Jim, Joel & Bruno --_000_C7C2E1C43D652C4E9E49FE7517C236CB02CF18B6dggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Many  thanks for = Chairs! I am not aware of any IPR disclosures for this document.=

     

    Thanks,
    Cheng

     

     

    From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of James Guichard
    Sent: Tuesday, November 24, 2020 10:57 PM
    To: spring@ietf.org
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv= 6-path-segment-07

     

    Dear WG:

     

    The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has ju= st concluded and the chairs agree that enough support was received to appro= ve this adoption.

     

    Authors, please resubmit a new document as draft-iet= f-spring-srv6-path-segment-00. In addition, please indicate whether you are= aware of any IPR disclosures for this document.

     

    Thanks!

     

    Jim, Joel & Bruno

     

     

    --_000_C7C2E1C43D652C4E9E49FE7517C236CB02CF18B6dggeml529mbxchi_-- From nobody Wed Nov 25 02:08:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDFE3A0A4F; Wed, 25 Nov 2020 02:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6L-NMpEt4oEq; Wed, 25 Nov 2020 02:08:44 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 434A13A0A4E; Wed, 25 Nov 2020 02:08:44 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id z14so1573547ilm.10; Wed, 25 Nov 2020 02:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BWfAKIXEeIA3eFyaAyoHiRoEJN069aLpmH2Q8Y0MAyY=; b=JAx1kcWbou3OPA7kMcgbuoys53xCtBygg1vYKbEqyB40Q1Afa6g5Ug27VkegZkm8mR 40dnXNH0fDgc2xPLT9g9Ftn/OZUE2gU7o/Ujj/9SEk4Snfj8OtzqRTQrXGmUfcog209E KZf9PWr9Oi7vqLn9WpiU8iib2tOhhVRSfyZQglIFTA/KBDoo2lYxmXTG/oI980ksTleX vszMKxKmzlDW1589ncEOxF02XXjavBx3AiqOJBpRgiyjYNUx8kTDJ07y3B05wGS+5PTZ LPxMk5X+1xTtM+rczOfx67SeCYB8z19SIeCcwRZkLS0zxqlTUYtNE0vf3u+n6e5nhAvB /8/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BWfAKIXEeIA3eFyaAyoHiRoEJN069aLpmH2Q8Y0MAyY=; b=r+LQrKjaSR9NuCyKGhb86WMV/MGlGpPsbq9hqqNfPVMESI/pgB5hn8T4kfiBFq6HLf DlVtEJ6AWQ9fh5IElFE49JEfB3Tf9oOMQVyNvXYAKT2JSFrLoDwkNg3LQYXjppyr2mn1 r6R1d7aPAwH/B9QJgckOQOZigBPWI20FApIMlOst0isYtzg1P52zqeslHc/6oA2Rj3Kn WBOv4zs1wW+IPFygCDZcRK/fiePEW3juCUZH8MjbvIGSu2VlgnBLbI26cU9qXYdiE0fP DD4koaKWH2B42b4YDv/YOsCIfTUGXk8Nhe6W18cnRrWvQx1NRZ88r7RNOWNGlXIr/l0s b6EA== X-Gm-Message-State: AOAM532HVzjVRWl/fUaCc2z1GMwO5SeJQS4xCtDjLuA1qb50A9NlK2F9 +Qn6U5U+nCWp4uzfZBYBcGYP/+RBuHvu/a1rvFs= X-Google-Smtp-Source: ABdhPJxXluRxm2l8zTX/TYgxLyMjpxz7XIzFsfw3JlxQqB4B13xwLwmfQ4gBLlD2J/xC6Lus/hWypKVb6rarEbHQtak= X-Received: by 2002:a92:cc52:: with SMTP id t18mr2205467ilq.124.1606298923422; Wed, 25 Nov 2020 02:08:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Wed, 25 Nov 2020 15:38:07 +0530 Message-ID: To: "Chengli (Cheng Li)" Cc: James Guichard , "spring@ietf.org" , "spring-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 10:08:46 -0000 Hi, I am also unaware of any IPR that needs to be disclosed for this draft. Thanks! Dhruv On Wed, Nov 25, 2020 at 1:19 PM Chengli (Cheng Li) wrote: > > Many thanks for Chairs! I am not aware of any IPR disclosures for this document. > > > > Thanks, > Cheng > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard > Sent: Tuesday, November 24, 2020 10:57 PM > To: spring@ietf.org > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 > > > > Dear WG: > > > > The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has just concluded and the chairs agree that enough support was received to approve this adoption. > > > > Authors, please resubmit a new document as draft-ietf-spring-srv6-path-segment-00. In addition, please indicate whether you are aware of any IPR disclosures for this document. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Nov 25 09:34:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7E23A1AE2; Wed, 25 Nov 2020 09:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 v-2DEWAegrr1; Wed, 25 Nov 2020 09:34:26 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 B495A3A1ADE; Wed, 25 Nov 2020 09:34:26 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id x15so1459965pll.2; Wed, 25 Nov 2020 09:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KPy8+kTlwg8e8rFQZ9WyURpAqGPmEKR+hFUtOSQ3gKc=; b=AOsQD3777JtEKyK3AvMNe7bpCEh4R2Bq0Yl9EbUmagGrW3nFYwKqKluWNOm4Lr374t O/6N7QnEXm7yuBxssLqdVR3G24uubJBC/q7WdGU1LLMknbGksSPSd/DjCx2jwo2kXkcc MKh92tU9AarTZ0w4MoEfKgJxqvllM3lwcT/AqwSwWj+yU+D71USGHU+x71SjGXeiL2W2 NEDuK68xKXDScqVF14qMHTkyt+LM5yEPHGxl8aN/K8HsRIqHJki29icn0aCzxdIlQp+k Fkof0f7fodESrlBBhxJOwL1SDwrWzpq9EhfuG+9POBf6gj6kJH0kf0FxtLUUghr4DmJV NEAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KPy8+kTlwg8e8rFQZ9WyURpAqGPmEKR+hFUtOSQ3gKc=; b=eTw8tKuMb3rcAFxVxWi9CUoajPcnZ2zPGpzxbcmc/DlQFZ7q5OKBykkHOjdCMZ0AkA DK5p2p8I0l/4aTU6loZTVcLqvZm4bE8t+Bo99+ylBQt/yQTXNnA2nKeF8XDUIzHcOw8+ 7AjiDZjejum/6I7hDpqB656iv0w/JRCn78qSgC3ZRRiwxj67f/WBLgzP8cKBueDRdies AzQVbfQOQR1kmeJU6ysB1zij5SsEisie4e2H+VBBfRDH14qNjtvrns7cJw7UreaNIDjJ tDIAfCfgOJE8/9spawybW2AdZWGt6lUx4/PKk9Byxoltcfp0zPYFC4lFv+OpJAsat3ec 0R2w== X-Gm-Message-State: AOAM533cfUJGNuC+5esHpx1RVNVkMcPaiznW6TmY7ja4XPrcGtF2aSdF VyAtRZcXdrBmKTrtXUgomTZt3lolGopVJeAP3d0= X-Google-Smtp-Source: ABdhPJwLZipusepfwbTCrS42S+H1QfihbWUtXGfSY7PSXYUtgSRgaD5aq58djZMEqngZIF1wRWqFJBp349W0F9vtv6c= X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr648821pll.22.1606325665785; Wed, 25 Nov 2020 09:34:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Wed, 25 Nov 2020 12:34:14 -0500 Message-ID: To: Greg Mirsky Cc: IETF IPPM WG , James Guichard , "Rakesh Gandhi (rgandhi)" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3ea7005b4f1d675" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 17:34:32 -0000 --000000000000b3ea7005b4f1d675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh I have been following this thread and to help progress the discussion I would like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > Greg > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > >> Thank you Greg for taking time for thoroughly reviewing the documents an= d >> providing the comments. >> >> Please see replies inline with =E2=80=A6 >> >> >> >> *From: *ippm >> *Date: *Friday, November 6, 2020 at 11:18 AM >> *To: *James Guichard >> *Cc: *spring@ietf.org , ippm-chairs@ietf.org < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> IETF IPPM WG >> *Subject: *Re: [ippm] [spring] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Dear Chairs of the SPRING and IPPM WGs, Authors, et al., >> >> I've found myself in the situation when two related drafts are in the WG >> APs in the SPRING and IPPM WG (with the possibility that expertise from = the >> third WG, BFD WG, might be desirable to review the "liveness monitoring"= ). >> Because these drafts are closely related, I've decided to combine my >> questions and comments in a single thread. I hope that would be acceptab= le >> and considered by the SPRING WG as well as IPPM WG. >> >> Usually, the bar for the adoption of a document can be evaluated by >> answers to these three questions: >> >> - Is the document(s) reasonably well-written >> >> I've got surprised that the drafts don't use the terminology from RFC >> 4656 and 5357 and introduce their own terminology for Session-Sender and >> Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are >> used in the documents without proper definitions. Other than that both >> drafts are readable and reasonably well-written. >> >> >> >> We are ok to change Sender to Session-Sender and Reflector to >> Session-Reflector if it helps. >> > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > Gyan> I am in complete agreement with Greg about terminology and consistency. The problem with inconsistency is that that you are not following well known normative references required to understand the specification leading to confusion and misunderstanding of the specification. The goal should be clear and concise in terminology and verbiage. > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, >> 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 59= 21, 6669) without >> defining them. I suspect it is because these are well-known terms. Havin= g >> said that, we can add a reference for them if it helps. >> > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > C---------D > / \ > A----B E-----F > \ / > G------------H > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > - using a congruent path for active performance measurement, e.g., > TWAMP or TWAMP Light, may produce information that does not reflect th= e > condition experienced by the monitored flow. It seems that the termino= logy > should reflect the fundamental requirement of ensuring that active OAM= test > packets are in-band with the monitored flow. > - there are no technical requirements to justify using in-band test > packets for direct packet loss measurement. In fact, using the in-band > method for collecting in-profile counters leads to a waste of bandwidt= h, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet= loss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > >> >> - Does the document solve a real problem? >> >> No, it appears that these drafts define a new performance measurement >> protocol for the purpose of combining OWAMP and TWAMP functionality and >> adding the ability to collect counters of "in-profile" packets. I couldn= 't >> find sufficient technical arguments for using a PM protocol instead of, = for >> example, extending the existing OAM mechanisms like ICMP. >> >> Gyan> This may sound basic but is a very critical subject going down >> the same lines of clarity in verbiage so their is no misunderstanding. >> =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and = if you super >> imposed two objects on top of each other they fit perfectly and the edge= s >> coincide identically. The problem with congruent is that it is based on >> the shape and that shape could be a mirror image or reflection which may >> not be exact. So when referring to a SR-TE path taken this could lead t= o >> confusion as to path taken if it=E2=80=99s the same path or congruent wh= ich is >> vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here the= re is criticality >> as to the path being referenced in terms of in-band versus out-of-band. = I >> agree that for direct in band packet loss measurement can be done via >> existing OAM mechanisme via ICMP. >> >> There is a requirement to measure performance delay as well as >> synthetic and direct-mode packet loss in segment-routing networks. OWAMP >> and TWAMP protocols are widely deployed for performance delay and synthe= tic >> packet loss measurement today. I am not sure extending ICMP for LM is a >> good option here. >> > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > Gyan> Agreed > >> - Is the proposed solution technically viable? >> >> There are too many unaddressed aspects, particularly the risk introduced >> by the protocol on network security, to comprehensively evaluate the >> proposed solution. >> >> About your comment on zero checksum, this is described in Security >> section in RFC 6936. We will add reference to this RFC in our Security >> Section as well. This is only specific to the UDP port locally provision= ed >> in the domain by the operator for TWAMP. Other than this, I did not find >> any other security related issue in your review below. >> > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough vetting of RFC 6936. > > To summarize my review of these two drafts: >> >> - these propose a new protocol, not an update or enhancement of the >> TWAMP-like protocol; >> >> The probe and response messages defined in [RFC 5357] are used for >> delay measurement and synthetic packet loss. The direct-mode packet loss >> messages are defined in draft-gandhi-ippm-twamp-srpm >> that >> match these delay measurement messages. As stated, >> draft-gandhi-ippm-twamp-srpm >> defines >> =E2=80=9Cextensions=E2=80=9D for TWAMP Light. >> > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC = 5357 > >> - several parts of the proposed protocol, e.g., Zero UDP checksum in >> IPv6, require detailed security analysis, which is currently absent; >> >> Gyan> Agreed > This is specified in RFC 6936 Security Section. We will add referenc= e >> to this RFC in our Security Section as well. This is only specific to th= e >> UDP port locally provisioned in the domain by the operator for TWAMP. >> > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > Gyan> Completely Agree > >> - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on >> the Informational track even though it is essential to the new protoc= ol as >> it defines its key elements >> >> This was to address your previous comment quoted as: >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS. >> > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. > Could you point to the definition, for example, of the Authenticated mode > in TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > Gyan> Agreed > >> - I believe that draft-gandhi-spring-twamp-srpm should be anchored at >> IPPM WG as it does introduce the new PM protocol. >> >> The TWAMP Light extension draft-gandhi-ippm-twamp-srpm >> is >> already in IPPM WG. The SPRING draft only defines SR PM procedures. >> >> >> >> Below, please find my detailed comments, questions on these drafts: >> >> - draft-gandhi-spring-twamp-srpm >> >> I have several questions about the relationships between this draft and >> Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has >> been mentioned. The nature of the TWAMP Light and what is required to ma= ke >> it a standard is well-explained in Section 4 of RFC 8545 >> (apologies for the long >> quote): >> >> "TWAMP Light" is an idea described in Appendix I ("TWAMP Light >> (Informative)") of [RFC5357]; TWAMP Light includes an unspecified >> control protocol combined with the TWAMP-Test protocol. In >> [RFC5357], the TWAMP Light idea was relegated to Appendix I because >> TWAMP Light failed to meet the requirements for IETF protocols (there >> are no specifications for negotiating this form of operation and no >> specifications for mandatory-to-implement security features), as >> described in Appendix A of this memo. See also [LarsAD] and >> [TimDISCUSS]. >> >> Since the idea of TWAMP Light clearly includes the TWAMP-Test >> component of TWAMP, it is considered reasonable for future systems to >> use the TWAMP-Test well-known UDP port (whose reallocated assignment >> is specified in this document). Clearly, the TWAMP Light idea >> envisions many components and communication capabilities beyond >> TWAMP-Test (implementing the security requirements, for example); >> otherwise, Appendix I of [RFC5357] would be one sentence long >> (equating TWAMP Light with TWAMP-Test only). >> >> >> >> Since we don't have an IETF document that addressed these open questions= , >> I don't think we can have a draft that proposes extensions to a >> non-standard mechanism (Appendix is for Informational material, as I >> understand it) on the Standard track. >> >> Gyan> Agreed >> >> This was to address your previous comment quoted as >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS as you mentioned above. >> >> BTW, despite only difference of fixed vs. variable length payload i= n >> STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and= it >> uses the same approach of provisioning as defined in this draft). Hence= , >> security considerations for STAMP and TWAMP Light are not different. Not= e >> that both STAMP and TWAMP Light have authenticated messages defined for >> Security purpose. >> > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > Now a number of more specific questions. >> >> draft-gandhi-spring-twamp-srpm: >> >> - In the Introduction it is stated that: >> >> The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides >> simplified mechanisms for active performance measurement in Customer >> IP networks by provisioning UDP paths and eliminates the need for >> control-channel signaling. >> >> I can not find where, either Appendix I or TR-390, "eliminated the need >> for control-channel signaling". Also, could you point where the referenc= ed >> documents describe "provisioning UDP paths"? >> >> >> >> The Appendix I of RFC 5357 has following text. We can reword and ma= tch the exact text if you prefer. >> >> >> >> =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol= , and >> >> assumes that the Session-Reflector is configured=E2=80=9D >> >> GIM>> I think that the text you're proposing is even more confusing. It > is not clear which example the sentence is referring to. Also, what is th= e > basis for such an assumption? > >> >> - It appears that the last paragraph in the Introduction describes >> the relationship with Appendix I of RFC 5357: >> >> The procedure uses the mechanisms defined in [RFC5357] >> (TWAMP Light) and its extensions for Performance Measurement. >> >> I think that the reference must be to Appendix I, not RFC 5357. Also, >> could you please specify which extensions of TWAMP Light have been used = in >> this draft? >> >> We can add the Appendix I as reference in the next revision. >> Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this >> reference. >> > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > >> >> - In Section 2.3 describing the reference model is noted: >> >> The probe response message is typically sent to the sender node R1. >> >> In which scenarios the reflector acts differently? How such behavior is >> related to the behavior of a TWAMP Session-Reflector, as defined in RFC >> 5357? >> >> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the senten= ce? >> > GIM>> If that fits into the operational model of the new protocol you're > defining. > >> >> - Also in Section 2.3 a Link is mentioned as an element directly >> connecting nodes in the presented reference model. Could you clarify = what >> is a Link? Is it always a physical connection between two systems or = a >> virtual? >> >> Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well know= n term used in >> many existing RFCs (please see RFC 5613, 5340, 8330). >> > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > >> >> - In Section 3 behavior of the reflector described as >> >> ... no PM state for delay or loss measurement need to be created on t= he >> reflector node R5. >> >> That is in contradiction to the behavior of a TWAMP Session-Reflector as >> defined in RFC 5357. Could you provide a reference to an IETF standard >> where this behavior is defined? Also, how, without creating a state at t= he >> Session-Reflector, to achieve one-way delay and synthetic loss measureme= nt >> on a bidirectional SR tunnel? >> >> Gyan> Valid point >> >> Quoting the text from Appendix I in RFC 5357. We can quote the text >> as is. >> >> =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not nece= ssarily have knowledge of the session state. =E2=80=9C >> >> GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > >> >> >> - Further, in Section 3 the selection of UDP port explained as the >> following: >> >> As specified in [RFC8545], the reflector >> supports the destination UDP port 862 for delay measurement probe >> messages by default. This UDP port however, is not used for loss >> measurement probe messages. >> >> To the best of my understanding, as one of the contributors and Editors >> of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP >> Session-Reflector without excluding any type of measurement. Besides, in >> TWAMP delay and packet loss are measured in the same test session, using >> the same flow of TWAMP-Test packets. >> >> Gyan> Agreed >> >> The packet loss in existing RFC 5357 refers to synthetic loss as >> there is no support for direct-mode loss in RFC 5357. We can change the >> text to clarify as =E2=80=9CThis UDP port however, is not used for direc= t-mode >> loss measurement probe messages.=E2=80=9D >> > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > >> >> - Then the draft states that >> >> The sender uses the UDP port number following the guidelines specified i= n >> Section 6 in [RFC6335]. >> >> Could you point to the guidelines that a user can use when selecting a >> UDP port number of a test session? >> >> Gyan> Good point >> >> Please see section 6 in [RFC6335]. We can cite the range which will >> be the same as used in [RFC8762]. This was also discussed earlier. >> >> https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ >> > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > >> >> >> - At the closing of the paragraph, we read that >> >> The number of UDP ports with PM functionality needs to be minimized du= e >> to limited hardware resources. >> >> Does a UDP port number pose PM functionality? How it is assigned to the >> port number? >> >> UDP ports are user configured for delay and direct-mode loss PM as >> described in Section 3.1. >> > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > >> >> - Following the above-quoted text, in Section 3 is noted: >> >> For Performance Measurement, probe query and response messages are >> sent as following: >> >> Could you clarify if the listed further procedures deviate from >> OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for >> Session-Sender and Session-Reflector respectively? >> >> Probe messages follow the same procedure as defined in RFC 4656 and >> RFC 5357. >> > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > >> >> - for both delay and loss measurements draft requires test packet be >> transmitted on a congruent path: >> >> the probe messages are sent on the >> congruent path of the data traffic by the sender node >> >> It is not clear what "the congruent path" means. The definition >> of congruency in geometry tells us that an object B is congruent to obje= ct >> A if it has the same shape and size, but is allowed to flip, slide or tu= rn. >> How a path can be congruent to another path? >> > Gyan> Agreed. The use of congruent in the context of pathing is confusing as the path being addressed may not be reflected accurately by the term congruent. > There are many existing RFCs that use term Congruent Path (e.g. RFC >> 5921, 6669) without defining them. I suspect it is because it is well-kn= own >> term. Having said that, we can add a reference for it if it helps reader= . >> > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > >> >> - The last paragraph in Section 3 refers to work on iOAM: >> >> The In-Situ Operations, Administration, and Maintenance (IOAM) >> mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for >> SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM >> information such as timestamp in-band as part of the data packets, >> and are outside the scope of this document. >> >> Is iOAM in the scope of this specification? What are the relationships >> between iOAM and draft-gandhi-spring-twamp-srpm? >> >> As mentioned in the draft, IOAM is outside the scope. >> > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > >> >> - Section 3.1 presents an example of the provisioning model but puts >> the definition of the provisioning model outside the scope. Is there = an >> accompanying specification that defines the provisioning model that c= an be >> used in multi-vendor deployment? Could that be YANG data model? What = is the >> relationship with draft-ietf-ippm-twamp-yang >> ? Would >> the TWAMP YANG data model be augmented? >> >> Yes, this can be Yang model. We can review >> draft-ietf-ippm-twamp-yang >> and add any >> missing items in a separate draft. We can also add a reference in this >> draft. >> > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > >> >> - Section 4.1 states that a new message is introduced to perform the >> Loss Measurement in this protocol Why the capability of TWAMP to meas= ure >> the loss in one-way and two-way is not sufficient? >> >> Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80= =9D loss >> measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to cla= rify. >> > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf. > >> >> - Section 4.1.1 requires that >> >> The Destination UDP port cannot be used as Source port, since >> the message does not have any indication to distinguish between the >> query and response message. >> >> Does that imply that the Destination UDP port used for the Delay >> measurement is unique throughout the particular domain? >> > Gyan> Good question > This is user-defined and is up to the user what UDP port to provisio= n >> in a domain. >> > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > >> >> - Section 4.1.2 of RFC 5357 does not define "the delay measurement >> message" but refers to the definition of the Session-Sender's test pa= cket >> in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test >> packet format to perform both delay and packet loss measurement. >> >> Ok, we can update the text in the next revision to indicate exact >> name from the RFC 4656. We can also add text to include synthetic packet >> loss. >> > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > >> >> - Can you explain how "the DM probe query message contains the >> payload format defined in Section 4.2.1 of [RFC5357]" when the refere= nced >> section of RFC 5357 defines the format of a Session-Reflector's test = packet? >> >> We can update the text in the next revision to indicate query forma= t >> name from RFC 5357. >> > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > >> >> - Can clarify the applicability of RFC 6038 and the symmetrical >> packet size? Is it required? Can it be non-symmetrical? >> >> Yes. Please see section 4.1.1 and quoted below: >> >> =E2=80=9CFor symmetrical size query and response messages as defined in = [RFC6038],=E2=80=9D >> >> GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > >> >> - Can you clarify the use of the timestamp format, NTP or PTPv2? It >> is not clear which is the default, mandatory or optional. >> >> This is same as TWAMP. There is no change. >> > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > >> >> - Also, is "hardware support in Segment Routing networks" of the >> PTPv2 format required, guaranteed, or something else? >> >> Hardware timestamps are recommended for SR use-cases. We can change >> the sentence. >> > GIM>> Perhaps you can propose some text, that would be helpful. > >> >> - Section 4.1.1.1 stated that >> >> A separate user-configured >> destination UDP port is used for the delay measurement in >> authentication mode due to the different probe message format. >> >> Can that be interpreted that there could be concurrent authenticated and >> unauthenticated test sessions using this protocol? Would different >> authentication methods require using unique destination UDP port numbers= ? >> >> >> >> Yes, and Yes, and these are based on provisioning. >> > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > >> >> - Section 4.1.2 by introducing the dedicated Loss measurement packet >> format, effectively modifies the behavior defined in RFC 5357 for >> Session-Sender and Session-Reflector. But the document does not state= that. >> Can you clarify whether this specification changes the behavior of a >> Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5= 357 >> respectively for the support of packet loss measurement? >> >> The direct-mode loss defines new procedure for sender/reflector to >> collect traffic counters, as opposed to timestamp. The rest is the same = as >> RFC 4656 and 5357. >> > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > >> >> - And a similar question about the use of the separate UDP port >> number for the authenticated of the packet loss measurement. >> - A couple of question to the following text in Section 4.1.3: >> >> The local and remote IP >> addresses of the link are used as Source and Destination Addresses. >> They can also be IPv6 link local address as probe messages are pre- >> routed. >> >> - What are the addresses of a link? >> >> I am assuming this well-known (e.g. RFC 2328). >> > GIM>> I am not familiar with the term "pre-routed". What does it mean? > >> >> - In which scenarios an IPv6 LLA can be used? >> >> I am assuming this is well-known (e.g. RFC 5613). >> > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > >> >> - Also, could the use of a routable destination IP address be used as >> a DDOS attack vector? Consider the scenario when an attacker gener= ates >> SR-encapsulated packets with the destination IP address other than= any of >> the SR-terminating nodes. Such a packet will be routed, correct? T= hat does >> appear as a security threat, would you agree? >> >> Absolutely do not agree. It is no different than IP routed TWAMP >> packet as defined in [RFC5357]. >> > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > >> >> - Section 4.1.4.2 references Figure 5 that, as I understand it, >> displays the format of a probe query message. In figure two reference= s to >> RFC 5357 are provided - a section that references RFC 4656 OWAMP defi= nition >> of the Session-Sender test packet, and a section that defines the >> Session-Reflector's reflected packet. Which of the two is used for th= e >> delay measurement in the proposed protocol? >> >> The probe query packet in the Session-Sender text packet. We can >> update the name. >> >> - Section 4.2.1 states that >> >> In one-way measurement mode, the probe response message as defined in >> Figure 6 is sent back out-of-band to the sender node ... >> >> Could you clarify how the responder controls that the response packet is >> sent not in-band but out-of-band? >> >> >> >> Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This >> is existing behaviour for out-of-band. >> > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > >> >> - How's the method described in Section 4.2.3 is different from the >> method described in RFC 8403 ? >> What is distinctly unique about the loopback mode proposed in the sec= tion? >> >> There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 840= 3. >> > GIM>> So, you believe that proposing to use the method described in RFC > 8403 for the TWAMP packet is innovation? And what are the benefits of usi= ng > the TWAMP test packet format in the Loopback mode? > >> >> - What is the rationale for setting TTL/Hop Limit fields always to >> 255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)? >> >> This is as defined in Section 4.2 of RFC 5357 (Bullet 4). >> > GIM>> I believe you've misunderstood the text in RFC 5357. This bullet > specifies the behavior of a Session-Reflector. It is to try to read TTL > value of the received TWAMP test packet and copy the value in Sender TTL > field of the reflected packet. If the Session-Reflector cannot access the > TTL field, it MUST write 255 in the Sender TTL field. So, I think that my > questions still remains. > >> >> - Section 4.3.3 states that a zero-value UDP checksum may be used in >> some scenarios. RFC 8085 allows that but in very specific cases that = are >> documented in detail in Section 3.4.1. Do you believe that the case o= f this >> protocol checks all the requirements for allowing the use of Zero UDP >> checksum as specified in RFC 8085? Also, I believe that allowing the = use of >> Zero UDP checksum in some scenarios, this protocol introduces a secur= ity >> threat that must be thoroughly analyzed in the Security Consideration= s >> section. >> >> This is described in RFC 6936. It will be very specific to the UDP >> port provisioned for TWAMP. We will add reference to RFC 6936 in Securit= y >> Section. >> > GIM>> I don't think that the reference is sufficient for the > Securit Consideration. I'd expect some extended discussion on why using > zero UDP header checksum is not a security threat for *twamp-srpm protoc= ol. > >> >> - Section 8 refers to "liveness monitoring of Links and SR Paths". >> This appears as the replication of functionality provided by BFD/S-BF= D >> protocols. Is such comparison accurate? If it is, shouldn't the propo= sal be >> also reviewed by the BFD WG? >> >> TWAMP probe messages are used today for synthetic packet loss whic= h >> can also be used to detect connection loss (performance metric). The >> section simply highlights this obvious metric. >> > GIM>> Can you point to a document that has defined "TWAMP probe messages > are used today for synthetic packet loss"? Also, which document defines > loss of connectivity as a performance metric? Does *twamp-srpm proposes t= o > use the new protocol to detect the loss of path continuity? > >> >> - I found the Security Section of the proposed protocol inadequately >> terse and missing very important threats that this protocol introduce= s in >> the network. >> >> Other than referring RFC 6936 for zero checksum what else is >> missing? Otherwise it is no different than RFC 8762 (STAMP). >> > GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The us= e > of source IP addresses, as mentioned above, appears to be another securit= y > risk introduced by *-twamp-srpm drafts. > >> >> - draft-gandhi-ippm-twamp-srpm >> >> As I understand it, the motivation for the Loss Measurement mode defined >> in this specification is to collect "in-profile" counters. Is that corre= ct? >> Do you see as essential for this mode that the query messages are in-ban= d >> with the flow being profiled? In your opinion, how using an out-of-band >> method of collecting these counters, e.g., by using ICMP multi-part mess= age >> extension per RFC 4884, could affect the accuracy comparing with the met= hod >> in this protocol? How the impact changes if extended ICMP messages are >> in-band with the profiled flow? >> >> >> >> As mentioned earlier, I am not sure extending ICMP to do PM is a >> good option here. Both TWAMP and OWAMP are widely deployed today for del= ay >> and synthetic loss measurement. >> > GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend > RFC 4656 OWAMP as well? Also, what you see as the connection between usin= g > active measurement methods to measure packet delay and packet loss, on on= e > hand, and collecting packet counters? > >> >> - Section 3.1 introduces the new field, Sender Control Code. The >> format of the packet, as I understand it, is presented in Figure 1. W= hen >> comparing with the format of Session-Sender's test packet defined in = RFC >> 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields= . Are >> these introduced by your proposal? >> >> It shows the partial message that has new field. We can update it t= o >> show the full message to avoid such confusion. >> >> - Also, it appears that the Sequence Number field in TWAMP >> Session-Sender's test packet is absent in Figure 1. Is that intention= al? >> >> It shows the partial message that has new field. We can update it t= o >> show the full message to avoid such confusion. >> >> Thanks, >> >> Rakesh >> >> >> >> Regards, >> >> Greg >> >> Thanks >> > Gyan > >> >> On Thu, Oct 22, 2020 at 5:51 AM James Guichard < >> james.n.guichard@futurewei.com> wrote: >> >> Dear WG: >> >> >> >> This message starts a 3 week WG adoption call for document >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending >> November 12th 2020. Please note that this document has several changes >> from v-10 that were requested by the SPRING and IPPM chairs. For this >> reason, the chairs have extended the adoption call for an additional wee= k >> to allow the WG enough time to review these changes before deciding on W= G >> adoption. >> >> >> >> Some background: >> >> >> >> Several review comments were received previously for document >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The >> SPRING and IPPM chairs considered those comments, and upon review of thi= s >> version of the document, determined the following: >> >> >> >> - The SPRING document should describe only the procedures relevant to >> SPRING with pointers to non-SPRING document/s that define any extensi= ons. >> Several extensions including* Control Code Field Extension for TWAMP >> Light Messages*, *Loss Measurement Query Message Extensions*, and *Lo= ss >> Measurement Response Message Extensions *were included in >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and >> should be removed from the SPRING document. >> - The TWAMP extensions included in >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should >> be described in a new document published in the IPPM WG. >> >> >> >> These conclusions were discussed with the authors of >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result >> of which is the publication of the following two documents: >> >> >> >> - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The >> subject of this WG adoption call. >> - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This >> document will be progressed (if determined by the WG) within the IPPM= WG. >> >> >> >> After review of the SPRING document please indicate support (or not) for >> WG adoption to the mailing list. Please also provide comments/reasons >> for that support (or lack thereof) as silence will not be considered as >> consent. >> >> >> >> Finally, the chairs would like to thank the authors for their efforts in >> this matter. >> >> >> >> Thanks! >> >> >> >> Jim, Bruno, & Joel >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000b3ea7005b4f1d675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Rakesh=C2=A0
    I have been following this thread and to help prog= ress the discussion I would like to provide some comments in-line Gyan>= =C2=A0

    Thanks=C2=A0

    Gyan

    On Sun, Nov 15, 202= 0 at 7:08 PM Greg Mirsky <gregi= mirsky@gmail.com> wrote:
    =
    Hi Rakesh,
    thank you for the response to my comments.= =C2=A0Please find my follow-up notes in-lined below under the GIM>> t= ag.

    Regards,
    Greg

    On Tue, Nov 10, 2= 020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

    Please see replies inline with <RG&= gt;=E2=80=A6

    =C2=A0

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, i= ppm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, = IETF IPPM WG <ippm@ie= tf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review th= e "liveness monitoring"). Because these drafts are closely related, I've decided to combine my questions and c= omments in a single thread. I hope that would be acceptable and considered = by the SPRING WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, &= quot;congruent paths", are used in the documents without proper definitions. Other than that both drafts are readable and r= easonably well-written.

    =C2=A0

    <RG> We are ok to change Sender = to Session-Sender and Reflector to Session-Reflector if it helps.

    GIM>> I believe that= the consistency in terminology between the core RFC and what is intended a= s its extension is not only helpful to a reader but, to the best of my unde= rstanding, is required for IETF specifications. But I don't think that = switching the terminology will fix the fundamental issue with the proposal.= The operation that is required from the remote entity, whether it is refer= red to as responder or Session-Reflector, is not defined in Appendix I of R= FC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior requi= red, as described in the draft, cannot be characterized as an extension of = OWAMP, TWAMP, or TWAMP Light but presents a completely new protocol that, i= f there's a need in the new PM OAM protocol, must be properly defined.<= /div>

    =C2=A0 =C2=A0Gyan> I am in complete agreement with Greg about terminolo= gy and consistency.=C2=A0 The problem with inconsistency is that that you a= re not following well known normative references required to understand the= specification leading to confusion and misunderstanding of the specificati= on.=C2=A0 The goal should be clear and concise in terminology and verbiage.=

    <RG> There are many existing RFC= s that use term =E2=80=9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) an= d term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 5921, 6669) without defin= ing them. I suspect it is because these are well-known terms. Having said t= hat, we can add a reference for them if it helps.

    <= /div>
    GIM>> Thank you for listing these RFCs. = I think I need to clarify my questions. While a reference to any of RFCs yo= u've mentioned, I don't think that will address my concern. In revi= ewed documents, "Link" is capitalized while referenced RFCs used = the lower case form for the term "link". Can these be used interc= hangeably? Do they refer to the same network object?
    Now I'll= try to illustrate my concern with using the term "congruent path"= ; in these drafts (using ASCII-art):
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G-----= -------H
    Consider an SR tunnel from A to F that traverses the net= work as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of= "congruent" as "two figures or objects are congruent if the= y have the same shape and size, or if one has the same shape and size as th= e mirror image of the other", it looks as the path A-B-G-H-E-F is cong= ruent to that SR tunnel. But a packet of an active OAM intended to monitor = a flow over the SR tunnel is out-of-band relative to that flow and will not= produce any meaningful measurement. Of course, for the case of the extensi= ons in drafts *-twamp-srpm, direct loss measurement can be performed, as in= formation collected from node F and packets that collect the counters are n= ot required to be in-band with the monitored flow. So, this example, in my = opinion, illustrates two of my concerns:
    • using a congruent path for active performance measurement, e.g.,= TWAMP or TWAMP Light, may produce information that does not reflect the co= ndition experienced by the monitored flow. It seems that the terminology sh= ould reflect the fundamental requirement of ensuring that active OAM test p= ackets are in-band with the monitored flow.
    • there are no technical requirements to justify using in-band test packe= ts for direct packet loss measurement. In fact, using the in-band method fo= r collecting in-profile counters leads to a waste of bandwidth, which may h= ave a negative impact on services that require low-latency and/or low packe= t loss. As demonstrated in this example, direct packet loss can be performe= d using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications= based on YANG data model.
    =C2=A0

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile&q= uot; packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the e= xisting OAM mechanisms like ICMP.

    =C2=A0Gyan> =C2=A0This may so= und basic but is a very critical subject going down the same lines of clari= ty in verbiage so their is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2= =80=9D by definition means shape of an object and if you super imposed two = objects on top of each other they fit perfectly and the edges coincide iden= tically.=C2=A0 The problem with congruent is that it is based on the shape = and that shape could be a mirror image or reflection which may not be exact= .=C2=A0 So when referring to a SR-TE path taken this could lead to confusio= n as to path taken if it=E2=80=99s the same path or congruent which is vagu= e as to =E2=80=9Cexactly=E2=80=9D which path is taken where here there is c= riticality as to the path being referenced in terms of in-band versus out-o= f-band.=C2=A0 I agree that for direct in band packet loss measurement can b= e done via existing OAM mechanisme via ICMP.

    <RG> There is a requirement to m= easure performance delay as well as synthetic and direct-mode packet loss i= n segment-routing networks. OWAMP and TWAMP protocols are widely deployed f= or performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for LM is a good option he= re.

    GIM>> I= agree with the=C2=A0requirements you've listed (though the=C2=A0SPRING WG OAM requirements document=C2=A0has been aban= doned and expired 3+ years ago). I believe that there's no sufficient t= echnical reason=C2=A0to use OWAMP/TWAMP for exclusive direct packet loss me= asurement.=C2=A0=C2=A0

    =
    =C2=A0 =C2=A0 Gyan> Agreed

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    <= /div>
    GIM>> I don't think that a mere refe= rence sufficiently explains why the use of zero UDP checksum in IPv6 header= is not decremental, does not create a security risk for the protocol.
    =C2=A0
    =C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA security threats and tha= t you need to thorough vetting of RFC 6936.

    To summarize my review of=C2=A0these two drafts:<= /u>

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurem= ent messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

    GIM>> I cannot find where RFC = 5357 defines "the probe and response messages". Could you give a = more specific reference or provide the text that, in your opinion, defines = such messages? But I'm more concerned with the direction of "exten= ding" non-protocol referred to as "TWAMP Light". As a contri= butor to BBF's=C2=A0TR-390, I'm have learned how different are exis= ting implementations of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interoperability 2019 whi= te paper. The status of TWAMP Light is explained in RFC 8545 and I cann= ot see that it can be used as a foundation of any standard.

    =C2=A0 =C2=A0 = Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC 5= 357

    =

    • several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, re= quire detailed security analysis, which is currently absent;<= /li>


    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2= =A0

    <RG> This is specif= ied in RFC 6936 Security Section. We will add reference to this RFC in our = Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I&#= 39;ve noted above that a simple reference does not sufficiently explains wh= y the use of zero UDP checksum in IPv6 header is not decremental, does not = create a security risk for the protocol. I believe that the proposal to use= zero UDP header checksum requires extensive analysis, using the analysis p= rovided in RFC 6936.

    =C2=A0 =C2=A0 Gyan> Completely Agree

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address=
 your previous comment quoted as:
     =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0 track is more appropriate for th= is specification.=E2=80=9D=

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS.

    =
    GIM>> As explained in RFC 8545 "TWAMP Li= ght is an idea", not a protocol. If anyone is interested in standardiz= ing an "extension", I'd expect that they first define the bas= e specification to which the extension applies. I might have missed the def= inition of TWAMP Light protocol in the draft. Could you point to the defini= tion, for example, of the Authenticated mode in TWAMP Light in the=C2=A0dra= ft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan>= ; Agreed=C2=A0

    <= /p>

    • I believe that=C2=A0draft-gandhi-spring-twamp-srpm should be anchored at IP= PM WG as it does introduce the new PM protocol.

    =C2=A0 =C2=A0=C2=A0

    <RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only defines SR PM procedures= .

    =C2=A0

    Below, please find my detailed=C2=A0comments, questi= ons on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is= required to make it a standard is well-explained in Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long= quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0

    Since we don't have an IETF document that addres= sed these open questions, I don't think we can have a draft that propos= es extensions to a non-standard mechanism (Appendix is for Informational ma= terial, as I understand it) on the Standard track.

    =C2=A0Gyan> Agreed=C2=A0

    <RG> This was to address=
 your previous comment quoted as
     =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

    <RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5= 357 mentioned TWAMP Light as an unauthenticated, and thus the light, simple= r, version of TWAMP-Test component of TWAMP protocol. I cannot find in=C2= =A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of T= WAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light.

    <= span style=3D"color:rgb(0,112,192)">

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UD= P paths"?

    =C2=A0

    <RG> The Appendix I of R=
FC 5357 has following text. We can reword and match the exact text if you p=
refer.
    <=
/u>=C2=A0
    =E2=80=9CThis example eliminates the need for the TWAM=
P-Control protocol, and
    =C2=A0=C2=A0 assumes that the Session-Reflector is con=
figured=E2=80=9D
    GIM>> I think that the text you're proposing is even more confu= sing. It is not clear which example the sentence is referring to. Also, wha= t is the basis for such an assumption?=C2=A0
    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I a= s reference in the next revision. Extensions are defined in draft-gandhi-ip= pm-twamp-srpm, we can add this reference.

    GIM>> The problem, in my view, is that Appen= dix I of RFC 5357 must be a normative reference while it is, by its nature,= an Informational document.=C2=A0

    <= u>

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2= =80=9Ctypically=E2=80=9D from the sentence?

    GIM>> If that fits into the operational mo= del of the new protocol you're defining.=C2=A0
    =

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the refer= ences. I couldn't find a definition of an object "Link" (capi= talized) but only "link" (lower case). Hence, since the draft con= sistently uses the capitalized form, I consider it to be something else, so= mething different from a link.=C2=A0

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creatin= g a state at the Session-Reflector, to achieve one-way delay and synthetic loss measurement on a bidirectional= SR tunnel?

    =C2=A0Gyan> Valid point=C2=A0=

    <RG> Quoting the text from Appen= dix I in RFC 5357. We can quote the text as is.

    =E2=80=9CIn the case of TWAMP Light, the Session-Refle=
ctor does not necessarily have knowledge of the session state. =E2=80=9C
    GIM>> By th= e informational nature of Appendix I, the text is not normative. I am famil= iar with the implementation of TWAMP Light which does maintain the session = state and thus supports one-way packet loss measurement. If you require tha= t the remote node does not maintain the state, the draft must define that a= s part of the specifying the behavior of the protocol.
    

    =C2=A0
    

      

    • 
Further, in Section 3 the selection of UDP port explained as the following:=

    

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto=
r
    
=C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr=
obe
    
=C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used =
for loss
    
=C2=A0 =C2=A0measurement probe messages.
    

    To the best of my understanding, as one of the contr=
ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use =
by a TWAMP Session-Reflector without excluding any type of measurement. Bes=
ides, in TWAMP delay and packet loss are
 measured in the same test session, using the same flow of TWAMP-Test packe=
ts.
    

    =C2=A0Gyan> Agreed=C2=A0
    

    <RG> The =
packet loss in existing RFC 5357 refers to synthetic loss as there is no su=
pport for direct-mode loss in RFC 5357. We can change the text to clarify a=
s =E2=80=9CThis UDP port
 however, is not used for direct-mode loss measurement probe messages.=E2=
=80=9D
    GIM>>= ; I've found that there's some misconception in the draft. RFC 8545= re-assigned UDP port 862 not for "delay measurement probe messages&qu= ot; but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports pac= ket delay, packet loss, reordering (RFC 4737 defines packet reordering metr= ic), and packet duplication measurement.

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    Gyan> Good point =C2=A0

    <RG> Please see section 6 in [RF= C6335]. We can cite the range which will be the same as used in [RFC8762]. = This was also discussed earlier.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 bu= t I don't find anything specifically applicable to this draft we're= discussing. If the protocol to use UDP port numbers from the Dynamic ports= range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

    =C2=A0

    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

    GIM= >> Can UDP port 862 be used? Also, requiring that the direct-loss mea= surement uses port number different from the one used by a TWAMP-Test packe= t, in my opinion, is another indication that this is the definition of a di= fferent from TWAMP Light PM OAM protocol.

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the s= ame procedure as defined in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Tes= t packets as well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2= =A0

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" = means. The definition of=C2=A0congruency in geometry tells us that an objec= t B is congruent=C2=A0to object A if it has the same shape and size, but is= allowed to flip, slide or turn. How a path can be congruent to another path?


    =C2=A0 =C2=A0 = =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 The use of congruent in the context of = pathing is confusing as the path being addressed may not be reflected accur= ately by the term congruent.
    <= div>

    <RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Havi= ng said that, we can add a reference for it if it helps reader.

    GI= M>> I cannot assume what was the context of these RFCs. I've sket= ched a network diagram above to illustrate=C2=A0that a "congruent path= " may well lead to out-of-band path. Is that the intention of the auth= ors of the draft to use this protocol out-of-band?
    =

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, = IOAM is outside the scope.

    GIM>> Yes, but it appears that references to the two IOAM-r= elated drafts have some purpose. What is it? How are these drafts related t= o=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some = discussion on how the new protocol is configured. If TWAMP YANG data model = can be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ip= pm-twamp-srpm. But I couldn't find anything about the configuration of = the protocol.=C2=A0

    <= u>

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

    GIM>> True, d= irect loss measurement, in fact, is not active measurement and thus is outs= ide the scope of Two-Way Active Measurement Protocol (TWAMP). The direct-lo= ss measurement is, by the definition of RFC 7799, passive measurement metho= d and fetching counters can be done using numerous methods, e.g., SNMP, Net= conf.

    <= /p>

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used f= or the Delay measurement is unique throughout the particular domain?


    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> G= ood question=C2=A0

    <RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

    GIM>> S= o, can user configure a port number from the User Ports range? Or, can the = same port number be used on the same system for a number of test sessions? = I find the use of UDP port numbers being underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.

    GIM>> I think that m= aking it explicit would help. Also, that will highlight what is being intro= duced by *twamp-srpm drafts is, in fact, a new protocol to perform syntheti= c packet loss measurement.=C2=A0
    =

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

    GIM>= > I cannot find any reference to a query format in RFCs 4656/5357. Could= you please quote from any of these documents?

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see sec=
tion 4.1.1 and quoted below:
    =E2=80=9CFor symmetrical size query and response messages as de=
fined in [RFC6038],=E2=80=9D
    GIM>> RFC 6038 defines an extension to RFC 5357 for OPT= IONAL use of the symmetrical test packets. Since *-twamp-srpm proposals do = not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing = about that either (in part because RFC 6038 came later), I don't see th= at there's any certainty in what is the sze of a test packet used in th= e direct-loss measurement.=C2=A0
    =
    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This= is same as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format.= Is that the case for *-twamp-srpm?=C2=A0

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

    GIM>> Pe= rhaps you can propose some text, that would be helpful.=C2=A0

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP po= rt numbers?

    =C2=A0

    <RG> Yes,= and Yes, and these are based on provisioning.

    =
    GIM>> But that requirement is far outsi= de the TWAMP, as defined in RFC 5357.

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and= 5357.

    GIM>>= ; I cannot agree with your statement " The rest is the same as RFC 4656 and 5357" because the sender's di= rect-loss format does not have Error Estimate field, Thus, a reflected pack= et does not have Sender's Error Estimate, nor Error Estimate of the ref= lector. And that, in my opinion, is another clear indication that *twamp-sr= pm drafts define a new protocol, separate from OWAMP/TWAMP.

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am= assuming this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "= ;pre-routed". What does it mean?=C2=A0

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am= assuming this is well-known (e.g. RFC 5613).

    <= /div>
    GIM>> So, LLA may be used as the source = and destination addresses when testing an SR tunnel?=C2=A0

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

    GIM>> You don't agree that the processing described cannot happe= n because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    =C2=A0

    <RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does not speci= fy that it defines another new protocol OWAMP Light. And it is not clear wh= at you reference as "this is existing behavior". Is it to referen= ce behavior of TWAMP test packet? But the behavior of the TWAMP-Test protoc= ol by itself is neither in-band, nor out-of-band. It is the encapsulation o= f the TWAMP test packet that makes it either in-band or out-of-band.=C2=A0<= /div>

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

    GIM>> I don'= ;t think that the reference is sufficient for the Securit=C2=A0Consideratio= n. I'd expect some extended discussion on why using zero UDP header che= cksum is not a security threat for *twamp-srpm=C2=A0 protocol.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

    <RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

    <= /div>
    GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the = loss of path continuity?

    =

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant= to *twamp-srpm drafts. The use of source IP addresses, as mentioned above,= appears to be another security risk introduced by *-twamp-srpm drafts.=C2= =A0

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that = the query messages are in-band with the flow being profiled? In your opinion, how using an out-of-band method of collec= ting these counters, e.g., by using ICMP multi-part=C2=A0message extension = per RFC 4884, could affect the accuracy comparing with the method in this p= rotocol? How the impact changes if extended ICMP messages are in-band with the profiled flow?

    =C2=A0

    <RG> As m= entioned earlier, I am not sure extending ICMP to do PM = is a good option here. Both TWAMP and OWAMP are widely deployed today for d= elay and synthetic loss measurement.

    GIM>> What is the reason mentioning OWAMP? Are dr= afts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as the = connection between using active measurement methods to measure packet delay= and packet loss, on one hand, and collecting packet counters?
    <= /div>

    • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP i= n Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender'= ;s test packet is absent in Figure 1. Is that intentional?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    Thanks,<= u>

    Rakesh

    =C2=A0

    Regards,

    Greg

    =C2=A0Thanks=C2=A0


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gyan=C2=A0<= /div>

    =C2=A0

    On Thu, Oct 22, 2020 at 5:51 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0<= u>

    =C2=A0

    Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

    =C2=A0

    =C2=A0

    These conclusions were discussed with the authors of= =C2=A0https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:<= /u>

    =C2=A0

    =C2=A0

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like = to thank the authors for their efforts in this matter.=

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    =C2=A0

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

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --000000000000b3ea7005b4f1d675-- From nobody Wed Nov 25 13:15:14 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD23A1E7F; Wed, 25 Nov 2020 13:15:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160633891317.7728.11013764359168930300@ietfa.amsl.com> Date: Wed, 25 Nov 2020 13:15:13 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-26.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 21:15:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-26.txt Pages : 39 Date : 2020-11-25 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-26 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-26 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 Nov 25 13:22:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CCD3A1E87 for ; Wed, 25 Nov 2020 13:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=ac54p92F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eR2cNltw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgOvyOxRR365 for ; Wed, 25 Nov 2020 13:22:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9868D3A1E55 for ; Wed, 25 Nov 2020 13:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2986; q=dns/txt; s=iport; t=1606339335; x=1607548935; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MXv5Kj8h4weAhKeYV92PErcEAuDgkdsHySUWnxEeF0E=; b=ac54p92F0OPj0z/OxqmUVYvxVKcK6Mf4mxCzMDsLHFxcwIA3cPlOXHEM dsLMw4NdTtuJEkFQa7uduf1miVpacGjqHiYJOqAo39oDJThhNbrLj9uCR 6rZeQYi8rJkw902nUQ8cpnguOMNUSxCcqWeSXzRBLmJ+JzKOgFMUBOVGg k=; X-IPAS-Result: =?us-ascii?q?A0AuCQCxyr5ffYwNJK1igQmDIVF8Wi8uCoQzg0kDpmeCU?= =?us-ascii?q?wNUCwEBAQ0BARgLCgIEAQGEBkQCF4INAiU4EwIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QYEFAEBhjwBC4VzAgQBARAREQwBASwMDwIBCBoCJgICAiULFRACBBMigwQBg?= =?us-ascii?q?lUDLgEOozcCgTyIaXaBMoMEAQEFgTcCDkFEgl0YghAJgQ4qgnODdoZXG4IAg?= =?us-ascii?q?REnHIJPPoJdAQECAQEVgUaDFzOCLJNzpGUKgm6JFpISAx+DG4EriHGUVpNgi?= =?us-ascii?q?waVYgIEAgQFAg4BAQWBbSGBWXAVGiEqAYI+CUcXAg2SEoUUhUR0NwIGAQkBA?= =?us-ascii?q?QMJfI41AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3APh4//xNyegbIqArGAK0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,370,1599523200"; d="scan'208";a="637395330" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 21:22:07 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0APLM7t0013636 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 21:22:07 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 15:22:06 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 15:22:06 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 16:22:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IyG4bFYVX9zZ8WYXhcF/aKMQiTHLBYnpNg4G71JWF5oTU/2ZrcP7Mkv3Qb4qtpavqwJFCn2J9Fget9Ilbmg5kmgCXo69uI4NFk346B7iuohDW/X8/qRnMJhKjU2N/qOd6phpzk/0j6Ih2GBheFr/8+8sY8e9LWa1LZC3PKNCl7Vnewo2LP40Y0DLa/PuLKuS34fJJfvwOVBkSP/PrE1TPmp54l951Jwo47uud+MzDq2R5sa99GtuleH9BZikVjKxhT7LA0cJ9rEBLJpGat82bR52AnaAKM8Fdzd+SaB2IUaZpZrTwg6W1UIF/c0Z8IB4eIJZQxECpFs+mfABa50M7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MXv5Kj8h4weAhKeYV92PErcEAuDgkdsHySUWnxEeF0E=; b=I23D+rVW9Tju7JF1z19M4NziyTyMkZgQooa1cAidMCdYXrtlFeyXg/VN7aj+kVDFKTOldLhTkhGrWQspk1TuJOPxaoQQzahQDQsEpS8YQtzrk/vKiO/cxK7p04hWPzf49ogkncDID+I41jDM1ZQjpef5Q1I/7FE01m26EQ0jDoXppNfy3RrbDRNGZH+Hl94j8rqi8vWN25xd/Iwf1M7YXRlU+n4yHhZR/PhDnihWRkPyVXOYAhY5CHopMy/izFVFGZpAOvIezWKRtTj0wMnb4x5gqr9qbK4OMohamCVA/IkN0XtZNr9Yg9v7ueDx/NIy/pTdsVlg6WkVPC1kysK6Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MXv5Kj8h4weAhKeYV92PErcEAuDgkdsHySUWnxEeF0E=; b=eR2cNltw9kIEFKt3MXb81bxxS+Ap4hDrFIAN55N34cVvVuTDda7Ux8yXdZpAbNhruJ8K5X2a+jrrqNgcSN/a+CrEZjsdKJ1HbyWjCd6bX8p4nuTaviEYJbSG4OH9ZRxG/oxYyPPUsV+bHKBqoJCBekDJxFKM2NY6/gYL16evumA= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2743.namprd11.prod.outlook.com (2603:10b6:a02:c7::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Wed, 25 Nov 2020 21:22:05 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Wed, 25 Nov 2020 21:22:05 +0000 From: "Acee Lindem (acee)" To: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-sr-yang-26.txt Thread-Index: AQHWw3AlHOaZ9qtKHk+xfCrWH5NikKnZB1SA Date: Wed, 25 Nov 2020 21:22:05 +0000 Message-ID: References: <160633891317.7728.11013764359168930300@ietfa.amsl.com> In-Reply-To: <160633891317.7728.11013764359168930300@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51b19932-434c-457e-988a-08d891882865 x-ms-traffictypediagnostic: BYAPR11MB2743: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 43Ft/OTqmFNd1fHzKfO5lpWaf6YrrJMgJvjpfdsP9CrTc5/9uQ6i3vPI+GRm8jC2BGHXf8HiLb44mK43k+vderddN+8resNiDl7VVv5ZNJLa9/c34otDaEHzdUU04BZbkdOf92zgOAvBEe2cgyAiE8qpS1yLjCWJtWO5vPRRPZMuliTw34ymkIeEPuM0jgQMAzpLCb/+Irp8245pBiA5wffBr2hnm2VdIXTLkXHw6DtHtKPQogZxqttwHWgU8x7lGVe7JFISOyESUIJx3tgSaPQKd1jVhGsqjs+JCfnJ1Vd/M9j94V1EnKNkEgFaEgaI38synArZ45bquokw6smgZp3oN8CBJ2FCn9dvN2aVs6uwRRmo2nnyhtXbBcePyCbW/UZ4j9dgkmloOKyeJNGZjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(366004)(376002)(136003)(33656002)(478600001)(6916009)(2906002)(86362001)(83380400001)(71200400001)(4001150100001)(66574015)(186003)(966005)(36756003)(5660300002)(26005)(8936002)(6506007)(66446008)(6512007)(66556008)(66946007)(8676002)(2616005)(6486002)(64756008)(66476007)(76116006)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZLImoPRfsJpeU7U1tWECnROFF6mK9kOS59ImQhLZA8SdHBHCKt6/W0zcmxLhmjKOyPAtOdpfvyURHuvSvc0FmCDpF6v7pDMFR2MKJ2F7N/EmR8xjr+svzZMVGI3Xb9I6O/v/dRhZFGC4j35/7/eSYmJI9O0umXHbV44tZ5Cl0kH2lz3VapWicClROfbvedG0stHxey1njv3kywFh7pgVcTgQ+4W4Hx1CdRTsOunOCXtk2/s1//ifLHmgV5z52QgP0UMEBtDHy10HDvkqtKC7khk3CWUiVV6N29iMEPsUtHS82W/hotlLftsOzr9jSNUsu9QmkoqfRMcJzElee3YOyv193gJRDzjjF009c7Ts4Ggh0LNd7SHRKm3ONVJ4gqPreQTpPTr3ouN729IHTPKVepLLjknbPjHnaiPo/lkfdsc7aXgg2PTf6s7BexFEDfLj4+rGEd7k7ZW30xbWJrHZDtGf47RAGiBNfEBdVWd7KzGwubcMNbIU+htqyTXDO94gi0CMphyhtCXOMpqTdRIYH8QBB3eG3UdGMmkbpLYt4nQ9rAyFVgMCR++1zIxyuY2L49R+N4mUPaqiYez/GCTzCPnFjqv4Yn/N1GKwtzhc8m4rjoQAB8Xuziqe7NvSP3ZJV6WI96WB8iaZccqZE/ZMLMx4eJirMLFtVMf2SbA/IC4fCOLMGBcFW9Px77mZ5Ce97rTB5I5Gugme2cqHCaSmhnuEVt2l1vdtUDQbwGTv93jsWb/TN6qDkeRRMYq5KeWhYxm+uKXhBPXWOBaDSJ0mXE9G5NLzc7+73WyXDPM+Cwx7+35cMGbNnX3le8ynlmrmEbdiWZ4V3XccaXS8dJ1+hYl0SwU/8n6x3wEHdaBq6zNCm4OblGwITRYQTwvuTSDkpxAHUyKtka+pUQNUpVVQvA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <69595B54EA6B6041AA02BDD5665B2E63@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51b19932-434c-457e-988a-08d891882865 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 21:22:05.1242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wbf3Dg6b+fEmDorQWJj7/lW3kPnm7mVTynzu3y5KZrxXPt82Fa+w2i5y+k0cTmPm X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2743 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-yang-26.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 21:22:18 -0000 LTI1IGFkZHJlc3NlZCBtb3N0IG9mIFRvbSBQZXRjaCdzIGNvbW1lbnRzIGFuZCAtMjYgdXBkYXRl ZCB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuIA0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAx MS8yNS8yMCwgNDoxNSBQTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIiA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAg ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTb3VyY2UgUGFja2V0IFJvdXRpbmcg aW4gTmV0d29ya2luZyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBTZWdtZW50IFJvdXRpbmcNCiAgICAgICAgICAgIEF1 dGhvcnMgICAgICAgICA6IFN0ZXBoYW5lIExpdGtvd3NraQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgWWluZ3poZW4gUXUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFjZWUg TGluZGVtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQdXNocGFzaXMgU2Fya2FyDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKZWZmIFRhbnRzdXJhDQogICAgCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmctMjYudHh0DQogICAgCVBhZ2VzICAg ICAgICAgICA6IDM5DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMjAtMTEtMjUNCg0KICAgIEFi c3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBm b3Igc2VnbWVudCByb3V0aW5nDQogICAgICAgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uLCB3 aGljaCBpcyB0byBiZSBhdWdtZW50ZWQgYnkgZGlmZmVyZW50DQogICAgICAgc2VnbWVudCByb3V0 aW5nIGRhdGEgcGxhbmVzLiAgVGhlIGRvY3VtZW50IGFsc28gZGVmaW5lcyBhIFlBTkcgbW9kZWwN CiAgICAgICB0aGF0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgb24gbmV0d29yayBlbGVtZW50cyB0 byBjb25maWd1cmUgb3INCiAgICAgICBvcGVyYXRlIHNlZ21lbnQgcm91dGluZyBNUExTIGRhdGEg cGxhbmUsIGFzIHdlbGwgYXMgc29tZSBnZW5lcmljDQogICAgICAgY29udGFpbmVycyB0byBiZSBy ZXVzZWQgYnkgSUdQIHByb3RvY29sIG1vZHVsZXMgdG8gc3VwcG9ydCBzZWdtZW50DQogICAgICAg cm91dGluZy4NCg0KDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zcHJpbmctc3IteWFuZy8NCg0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zcHJpbmctc3IteWFuZy0yNg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy0yNg0KDQogICAgQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zci15YW5nLTI2DQoNCg0KICAg IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQogICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAg IHNwcmluZ0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nDQoNCg== From nobody Wed Nov 25 13:38:40 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8250A3A0B3B; Wed, 25 Nov 2020 13:38:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160634031449.11285.2541081928510817201@ietfa.amsl.com> Date: Wed, 25 Nov 2020 13:38:34 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-25.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 21:38:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-25.txt Pages : 44 Date : 2020-11-25 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-25 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-25 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 Nov 25 13:42:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18DA3A1EA8; Wed, 25 Nov 2020 13:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=YL+xrRqs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eSmIuSel Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RpgFXNRz6_q; Wed, 25 Nov 2020 13:42:50 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF83A0BF1; Wed, 25 Nov 2020 13:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57914; q=dns/txt; s=iport; t=1606340570; x=1607550170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UW5j6FED8RfD8Pp9KAq4xWUPPCayYVGg3to2Soi5KqY=; b=YL+xrRqsxTQvc/qpRawvm0jaMd68pHnOIMuzg5woP5UDl5kELA/FpB2x 77n4ilKcMNzTNN7KCOLA6KMeEsxUhhumqrnppUN7pFiC3U6rBBCo9hDty 00B7AUUNqtkqEIKKa9mD0oMuIqgpp0EYBfB25QpVl8PWp9T6yqT66EwIu Y=; X-IPAS-Result: =?us-ascii?q?A0AtBQA5z75ffZtdJa1iDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVIjLnxaLy4KhDODSQONYpkFgUKBEQNUCwEBAQ0BASMKAgQBAYRKAheCD?= =?us-ascii?q?QIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYYPAQEGJQyFcgEBAQMBEggBC?= =?us-ascii?q?BEMAQEyBQEEBwQCAQgRBAEBAQICEQ4HAgICMBUICAIECgQFCBIIgwWCVQMOI?= =?us-ascii?q?AEOozECgTyIaXaBMoE7gUkBAQWBR0GDKRiCEAMGgQ4qgnODdoQMgksbgUE/g?= =?us-ascii?q?RFDgVF+PoJdAgEBAQGBEwESAQwGAQccBRAVDAIFglgzgiyQKBIOBAcrgjg9k?= =?us-ascii?q?zyQHIENCoJuiRaGF1KGGIUzggiBE4ockiCCNpViiQSSeIJqAgQCBAUCDgEBB?= =?us-ascii?q?YFtIWlYEQdwFTuCaVAXAg2GQYEFghWERgsBBRIUgzqFFIUEQHQCNQIGAQkBA?= =?us-ascii?q?QMJfI0AAQEFChcHgQYBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A50e8ih/sa57+4v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRSN4PRxylLFQNaT5/FFjr/QtKbtESwF7I2auX8POJpLS1?= =?us-ascii?q?ceiMoQkgBhZazNCUDyIPPwKSBvGsNEWQxg/m39PERIS47yYlTIqSi06jgfUh?= =?us-ascii?q?z0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1ah6xqFbc?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,370,1599523200"; d="scan'208";a="622434587" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 21:42:47 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0APLgkZe002893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2020 21:42:46 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 15:42:46 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 16:42:44 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 15:42:44 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Svgatoa/WMO8FwyGsXl/Kb5/oly3w5fLP+fmiUBcB3QBJnVdkxP72YYC2KAKwX18lOP20rWsYLiF0PPqrfWuGfaHfg3s26l3t85ecGf9/MJwop8i8jGbtFjrsx40lAfOMxEaSBSie+PPsTpF5+Tjzxj6+aGGruvaEV/m/McXx6t7UyEqYMiICpLkByrdAzJHnirGgq2KmDcP9uLH24Oci6MOPiCnbe0fd7x8Il69IZOH/osOXXeUF84ZFqfvcx1nHDNHTejFsPSMB7cOfB++kDws/taoIuuuXr6b1nQKQCdY4BsFBRDYWUzZ+gEE9Bul7cimIbztElEGkH0/kbKnbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UW5j6FED8RfD8Pp9KAq4xWUPPCayYVGg3to2Soi5KqY=; b=f7P/9lweUiGSATvrx0GXbX4tKDduOdazi5qu7Yr3YLNU8WKfn42mDHIsVm/gjaMyxaR1L8JcAEDs0PtNmGAf234oaM636aEtrbg6bBRkdztZ3lmhD60Ed5abtWchBewV2AO34gS9jUNDmRc0D2xat+KzI6SSauMyrUzGD3wuiRrJq/ob8397ObcgRnHIWpP4SZj+UoPpzusQ0Utp2XFVVm734KIE2OLaWKyxD+FRuB5jcRGwXE1xVhAiuXi+HW8RTYs/SxieNp1+5XwMghlMaZ2U2Q2eEHO/O7tALRZXW/YrACCtIYZ29PWh71OdHteUsoN1L2SPEIrMqy0HksrP1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UW5j6FED8RfD8Pp9KAq4xWUPPCayYVGg3to2Soi5KqY=; b=eSmIuSelwZWBShf4eWtgIQEs3eiMjEgDyInUICQ0YSGtz0Z2zfSKRSxcQrsSjAkj34qTxAeXNWXYfbSNICNuGTy/BH4BtQHU5ihB+lJlCq1wAlGvMoGfOs82OfL+h5VBpx9tpfIAUuKflPn1upDQyJRWZ+V34h48pSGACNry7+4= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SN6PR11MB3072.namprd11.prod.outlook.com (2603:10b6:805:d8::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Wed, 25 Nov 2020 21:42:42 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::51da:59d2:56d2:d4e5]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::51da:59d2:56d2:d4e5%7]) with mapi id 15.20.3611.023; Wed, 25 Nov 2020 21:42:42 +0000 From: "Pablo Camarillo (pcamaril)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) Thread-Index: AQHWkkehHHD2ovfWJ0icCuhr4TgPf6l5pP+AgF7GvICAARK2wA== Date: Wed, 25 Nov 2020 21:42:42 +0000 Message-ID: References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> <20201125011313.GH39170@kduck.mit.edu> In-Reply-To: <20201125011313.GH39170@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 56bb4d57-edc1-4a4d-5714-08d8918b0a25 x-ms-traffictypediagnostic: SN6PR11MB3072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5jHusbmnU5WuwmcoHs9Opp3GJ6xjAWX3UAkNb0Mx6FFcO9EqH1Ibd7yWFxbQRSw+rt0YKLZgRfQldtwXkzLSXE3y7Dpw8YCV44wXVUBrM5ffGkJccL08F6JQVP5BTOfTMzKE175CMbPnevEIfErQ/4t8CzCztcyhd3Ri4kFH91njojvRIpnbCNwAVBjliwDtxhCJhEW6HXHZFCpuhO5AwCi8Sx5Nu34GSIEiInzUPYlUMQynjoC0SMO64v+86UoWN52fn8Wcipa+Z83P6heq42drThatq+TUGlm6rYwCWg9oHYMnoaYuytlr6BxAVsYnQH1OcI4yefZEqZOPfD65AWaHp8c7nM7c2fXzcxjiUW0EaY7Rod+5N5ZCQyN4iZPsbJh9HmxJMcCaSUL4jzP0xQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(136003)(39860400002)(346002)(66446008)(26005)(7696005)(66946007)(316002)(86362001)(33656002)(8936002)(4326008)(5660300002)(71200400001)(966005)(30864003)(2906002)(66574015)(83380400001)(53546011)(6506007)(76116006)(52536014)(186003)(478600001)(8676002)(54906003)(9686003)(64756008)(66556008)(6916009)(66476007)(55016002)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Sjh0R2E2VWk1YVBGWDFKRnVhcmxxSnJLTUxmTTB6Z25oVlVYUzh6VUJoUVFw?= =?utf-8?B?SHh0WkJEMFluR1ppVFc0d1E4a1R0SXVMVjdlT0VlZ3FmTkY0ZnljcWxHZGRI?= =?utf-8?B?QitqOHFTajNTbXRSWndSYUxNZXdYUzlDZDFvSGxSbytwNHYrcncxaHFNOS84?= =?utf-8?B?eHlyVzlaaUpHNjE5VjRoRWMxa05GKy95RytNVTA1SlkrOFpHaE55QmlTenc5?= =?utf-8?B?RmV3amV0OUp4YnFBb3hqY0JlRkpPbnpQTWtQQ05WQmsrZFozSDBFTWFWT2lS?= =?utf-8?B?NkNPUzF6aE45REtpd2wvVDUrbUM0SVpBRHdvY1RWZUZpbDZwNXN2OVpRNXAy?= =?utf-8?B?ekU5OWNGZ3pUQTAzdnJtQnorR0dubnFOUk5kZzhXa250UTVOZHlCRjdIV0ZS?= =?utf-8?B?Vm5mUklpMlczQ0pzQm1VZUJPT2I1L0hXa1EvaVhncG90SWVSemx1Q2M3U0Y2?= =?utf-8?B?MVNITVFrT3RmaE0vZXhjVERibFkySmJVRVFNN3Q3Nk94RENiVkZMYWJwa25V?= =?utf-8?B?cFJFVlVLUk5kb3VFWXVDeVFvcW1PQlAzMWZmNmozYXNEUHA5VmhieUVwY2o3?= =?utf-8?B?dW5JTm1yRnNLUW1JZ3U0dldYRkh3YlM1NEpWSDF4QlVUd2ZQa3dURDlmV0Zy?= =?utf-8?B?VDJuUXlOemtkQ1V6ZTdwNlYrUjVVSHlIdld5NDZNZk9NWEF0ckpEcGRPZnBI?= =?utf-8?B?V3JOYWREYW44QTNyOHlSWVk2VXVPdStOeUtBUWhuU01xOWUxU0llRTFvQTJm?= =?utf-8?B?MmdEOXZLTWN5YTI1SEVhNVJKcmg0VE1KNDhqZitOcG9TbTdhY0pvSWo2emJF?= =?utf-8?B?cTlhNVZaSnBSd25PNHJVcXU2ZEI0cFFHRHcxUzRCZmc5ZEJxeDZ1N1cvVUEv?= =?utf-8?B?VXBIZys3MnhjdEVXaWF4VERyRW5JaTJmTGExMVBGd240TkhxL0Flb1EzZURQ?= =?utf-8?B?V0hpR2gzaDBtZ0RNb3o3dFFzdXNMMzFRdUxSdTZaeUtGYXVyODhQQ2N6WE44?= =?utf-8?B?MFlISk8zSjlZQzBncTdSZ1l3NXJvaTlqb2V2V0RFb3dNeGtBNTdIU2x0STVZ?= =?utf-8?B?cDgxWUVpc1N3WU5jRkg3c3htcDJ0N0U4OHp5SDQvU1F5ZkowOERvRWV1d20y?= =?utf-8?B?RHdVenlXZmFMWVdWTHQ5VEdwdWFSNWpidHFGMExRNmlYNlFubE5IczV6TGsv?= =?utf-8?B?M0hHM1VVTmlvZ21rK0V3R2oxR0RUNXR2V2k4RmY0K1ZlVCtHaHJyc3hIWHR2?= =?utf-8?B?QXF3THhpN3FqSjRaanBuN09PaDNNbUtmY1orTUtPZDI1OHBWT1U1RHArb20x?= =?utf-8?Q?l7HbNzBUAHkz4=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56bb4d57-edc1-4a4d-5714-08d8918b0a25 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 21:42:42.8491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aT1LiuQifIo50wCPUtpgFbh2H95HBy4TuRllxpeZwLcN2MxFdTO+2HAx8L/dz+XQEqQErL2fUEobumY+Xg7sNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3072 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 21:42:54 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcuIFJlcGxpZXMgdG8geW91 ciBjb21tZW50cyBpbmxpbmUgd2l0aCBQQzIuDQpOb3RlIHRoYXQgSeKAmXZlIHBvc3RlZCByZXYy NSBvZiB0aGUgZHJhZnQuDQoNClRoYW5rcywNClBhYmxvLg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQpTZW50OiBtacOp cmNvbGVzLCAyNSBkZSBub3ZpZW1icmUgZGUgMjAyMCAyOjEzDQpUbzogUGFibG8gQ2FtYXJpbGxv IChwY2FtYXJpbCkgPHBjYW1hcmlsQGNpc2NvLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9y Zzsgc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBCcnVubyBEZWNyYWVu ZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbT4NClN1YmplY3Q6IFJlOiBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTIwOiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQpIaSBQYWJsbywNCg0KSSBtdXN0IGFwb2xvZ2l6ZSB0d2ljZSBvdmVyOiBm aXJzdCBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcsIGFuZCBzZWNvbmQgZm9yIHRoZSBudW1i ZXIgb2YgcG9pbnRzIGluIG15IGRpc2N1c3MgYmFsbG90IHRoYXQgYXJlIG5vdCBhY3R1YWwgcHJv YmxlbXMuDQpJIHJlY2VudGx5IGhhZCB0aGUgdGltZSB0byBnbyBvdmVyIHRoZSBkb2N1bWVudCBh Z2Fpbiwgd2l0aCBiZW5lZml0IG9mIHlvdXIgcmVzcG9uc2VzIGhlcmUsIGFuZCBub3cgaGF2ZSBh IGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHNvbWUgYXNwZWN0cyB0aGF0IHdlcmUgY29uZnVzaW5n IHRvIG1lIGR1cmluZyBteSBmaXJzdCByZWFkaW5nLiAgSSBzdGlsbCBoYXZlIGEgZmV3IHRoaW5n cyBJIHdhbnQgdG8gdGFrZSBhbm90aGVyIGxvb2sgYXQsIGJ1dCBJIGNhbiByZXNwb25kIHRvIHlv dXIgY29tbWVudHMgbm93IC0tIHRoZSBnb29kIG5ld3MgaXMgdGhhdCB0aGVzZSBkaXNjdXNzIHBv aW50cyBhbGwgbG9vayB0byBiZSByZXNvbHZlZC4NCg0KTW9yZSBpbmxpbmUuLi4NCg0KT24gRnJp LCBTZXAgMjUsIDIwMjAgYXQgMDY6MzE6NTJQTSArMDAwMCwgUGFibG8gQ2FtYXJpbGxvIChwY2Ft YXJpbCkgd3JvdGU6DQo+IEhpIEJlbmphbWluLA0KPg0KPiBUaGFuayB5b3UgZm9yIHlvdXIgdGlt ZSBhbmQgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZSB3aXRoIFtQQ10uDQo+DQo+IFJlZ2FyZHMs DQo+IFBhYmxvLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5q YW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQo+IFNlbnQ6IGp1 ZXZlcywgMjQgZGUgc2VwdGllbWJyZSBkZSAyMDIwIDk6NTINCj4gVG86IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1t aW5nQGlldGYub3JnOw0KPiBzcHJpbmctY2hhaXJzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7 IEJydW5vIERlY3JhZW5lDQo+IDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsgSm9lbCBIYWxw ZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsNCj4gam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiBTdWJq ZWN0OiBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24NCj4gZHJhZnQtaWV0Zi1zcHJpbmctc3J2 Ni1uZXR3b3JrLXByb2dyYW1taW5nLTIwOiAod2l0aCBESVNDVVNTIGFuZA0KPiBDT01NRU5UKQ0K Pg0KPiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTIw OiBEaXNjdXNzDQo+DQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gdGhpcyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4NCj4NCj4gUGxlYXNlIHJlZmVyIHRvDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmENCj4gbW1pbmcvDQo+ DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0K PiBbZWRpdGVkIHRvIHJlbW92ZSBub25zZW5zaWNhbCBwb2ludCB0aGF0IGhhZCBjcmVwdCBpbiBh Ym91dCB0aGUgU1JIDQo+IGJlaW5nIGEgbmV3IGV4dGVuc2lvbiBoZWFkZXI7IGl0J3MgImp1c3Qi IGEgcm91dGluZyBoZWFkZXJdDQo+DQo+IFRoZSBjdXJyZW50IHJlcXVpcmVtZW50IHRoYXQgSUFO QS1hc3NpZ25lZCBTUnY2IEVuZHBvaW50IEJlaGF2aW9yIGNvZGVwb2ludHMgYXJlIHVzZWQsIHdp dGggbm8gcmFuZ2UgcmVzZXJ2ZWQgZm9yIGxvY2FsIGFzc2lnbm1lbnQsIHNlZW1zIHRvIGJlIGlu dml0aW5nIGNvZGVwb2ludCBzcXVhdHRpbmcgZnJvbSB0aGUgbm9taW5hbGx5IHJlc2VydmVkIHJh bmdlLg0KPiBXaHkgaXMgdGhlcmUgYW4gYWJzb2x1dGUgcmVxdWlyZW1lbnQgZm9yIHJlZ2lzdHJh dGlvbiAoZXZlbiBGQ0ZTKQ0KPiB3aXRob3V0IHJhbmdlcyBmb3IgbG9jYWwgb3IgZXhwZXJpbWVu dGFsIHVzZT8gIChXaGF0IGFyZSB0aGUgdmFyaW91cyByZXNlcnZlZCByYW5nZXMgcmVzZXJ2ZWQg Zm9yPykgW1BDXSBJIGFncmVlIHdpdGggeW91IHRoYXQgYSByYW5nZSBmb3IgbG9jYWwgdXNlIHdv dWxkIGNvbWUgdXNlZnVsLiBIZW5jZSwgd2XigJl2ZSBjYXJ2ZWQgMmsgZW50cmllcyBvZiB0aGUg cmVnaXN0cnkgZm9yIFByaXZhdGUgVXNlLg0KPiBUaGUgUmVzZXJ2ZWQgcmFuZ2UgKGhhbGYgb2Yg dGhlIDY1ayByZWdpc3RyeSkgaXMgZm9yIGZ1dHVyZSBhbGxvY2F0aW9uIGJ5IElFVEYuIEZ1dHVy ZSBSRkNzIG1pZ2h0IGRlY2lkZSBob3cgdG8gdXNlIHRoYXQuDQoNClNvdW5kcyBnb29kOyB0aGFu a3MhDQoNCj4gVGhlIChub3JtYXRpdmUpIHBzZXVkb2NvZGUgZG9lcyBub3Qgc2VlbSB0byBoYW5k bGUgdGhlIGNhc2Ugd2hlbiB0aGUgU1JIIGlzIG9taXR0ZWQgZm9yIHRoZSBkZWdlbmVyYXRlIGNh c2Ugd2hlcmUgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBzZWdtZW50LCBvciBmb3IgdGhlIFBTUCBm bGF2b3IuDQo+IFtQQ10gRWFjaCBvbmUgb2YgdGhlIHBzZXVkb2NvZGVzIHByb3ZpZGVzIHRoZSBT UkggcHJvY2Vzc2luZyBhbmQgdGhlIFVwcGVyLUxheWVyIHByb2Nlc3NpbmcuIElmIHRoZXJlIGlz IG5vIFNSSCwgdGhlbiB0aGUgU1JIIHByb2Nlc3NpbmcgaXMgbm90IGV4ZWN1dGVkLCBidXQgdGhl IFVwcGVyLWxheWVyIEhlYWRlciBwcm9jZXNzaW5nIGlzLiBUaGlzIGlzIHRoZSBzYW1lIGFzIGlu IFJGQzg3NTQuDQoNClRvIGV4cGFuZCBhIGJpdCBtb3JlIG9uIGhvdyBJIHdhcyBjb25mdXNlZCBo ZXJlLCBJIHdhcyBsb29raW5nIHBhcnRpY3VsYXJseSBhdCB0aGUgRW5kLCBFbmQuWCwgYW5kIEVu ZC5UIGNhc2VzICh0aG91Z2ggSSBndWVzcyBpdCBhbHNvIGFwcGxpZXMgdG8gdGhlIEVuY2FwcyBj YXNlcykuICBJbiB0aGUgbm9ybWFsIGZsYXZvciwgdXBwZXItbGF5ZXIgcHJvY2Vzc2luZyBnZXRz IHNodW50ZWQgb3ZlciB0byBzZWN0aW9uIDQuMS4xIHRoYXQgZG9lc24ndCByZWFsbHkgZG8gbXVj aCAtLSBpbiBwYXJ0aWN1bGFyLCB0aGVyZSBpcyBubyBpbnRlcmNvbm5lY3QgZm9yIEVuZC5YIGFu ZCBubyB0YWJsZSBsb29rdXAgZm9yIEVuZC5UISAgQnV0IHRoaXMgcmVhbGx5IGlzIHRoZSByaWdo dCBiZWhhdmlvciwgc2luY2UgdGhlIFNSSCBpcyBvbmx5IGFic2VudCB3aGVuIHRoaXMgU0lEIGlz IHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBvZiB0aGUgcGFja2V0LCBhbmQgaW4gdGhhdCBjYXNlIHdl IHJlYWxseSBtdXN0IGFjdCBhcyBhbiBlbmRwb2ludCBhbmQgbm90IGEgcm91dGVyLiAgSWYgd2Ug ZGlkIHNlbmQgdGhlIHBhY2tldCBvbndhcmQgaXQgd291bGQgbW9zdCBsaWtlbHkganVzdCBnZXQg bG9vcGVkIGJhY2sgdG8gdXMgdW50aWwgdGhlIGhvcCBsaW1pdCBleHBpcmVzIChvciBnZXQgc29t ZSBvdGhlciBlcnJvciksIHNvIGdlbmVyYXRpbmcgYSBsb2NhbCBJQ01QIGVycm9yIGlzIHRoZSBy aWdodCB0aGluZyB0byBkbyBpbiB0aGUgZ2VuZXJhbCBjYXNlLCB1bmxlc3MgdGhlcmUgaXMgbG9j YWwgY29uZmlndXJhdGlvbiBmb3IgdGhhdCB1cHBlci1sYXllciBwcm90b2NvbC4NCg0KW1BDMl0g QWNrDQoNCj4gVGhlIHBzZXVkb2NvZGUgZm9yIHRoZSBQU1AgYW5kIFVTUCBwcm9jZWR1cmVzIHNl ZW0gaW5jb3JyZWN0IC0tIEhkciBFeHQgTGVuIGlzIG1lYXN1cmVkIGluIHVuaXRzIG9mIDggb2N0 ZXRzLCBhbmQgZG9lcyBub3QgaW5jbHVkZSB0aGUgZmlyc3QgOCBvY3RldHMgb2YgdGhlIGV4dGVu c2lvbiBoZWFkZXIsIGJ1dCBQYXlsb2FkIExlbmd0aCBpcyBtZWFzdXJlZCBpbiBvY3RldHMuICBM aXRlcmFsbHkgZGVjcmVhc2luZyB0aGUgUGF5bG9hZCBMZW5ndGggYnkgdGhlIEhkciBFeHQgTGVu IHZhbHVlIHdpbGwgcHJvZHVjZSBhIG1hbGZvcm1lZCBJUHY2IHBhY2tldC4NCj4gW1BDXSBJbmRl ZWQuIEZpeGVkLg0KPg0KPiBJZiAiUFNQIG9wZXJhdGlvbiBpcyBkZXRlcm1pbmlzdGljYWxseSBj b250cm9sbGVkIGJ5IHRoZSBTUiBTb3VyY2UgTm9kZSIsIHdoeSBkbyB3ZSBuZWVkIHRvIGRlZmlu ZSBiZWhhdmlvciBjb2RlcG9pbnRzIHRoYXQgKGZvciBleGFtcGxlKSB1c2UgYm90aCBQU1AgYW5k IFVTUD8gIEkgZG9uJ3Qgc2VlIGhvdyB0aGVyZSBpcyBmdWxsIGRldGVybWluaXNtIGluIHRoaXMg Y2FzZSB3aGlsZSBiZWluZyBkaWZmZXJlbnQgZnJvbSB0aGUgIlBTUCBvbmx5IiBmbGF2b3IuDQo+ IFtQQ10gSW4gb3JkZXIgZm9yIHRoZSBQU1AgYmVoYXZpb3IgdG8gYmUgZXhlY3V0ZWQgdGhlcmUg bXVzdCBoYXBwZW4gdHdvIHRoaW5ncy4gRmlyc3QsIHRoZSBTUiBTb3VyY2UgTm9kZSBtdXN0IGlu c3RydWN0IGl0IHdhbnRzIHRvIHVzZSB0aGUgUFNQIGJlaGF2aW9yLiBUaGlzIGlzIGRvbmUgYnkg dXNpbmcgYW4gU1J2NiBTSUQgYXNzb2NpYXRlZCB3aXRoIGEgYmVoYXZpb3IgdGhhdCBzdXBwb3J0 IHRoZSBQU1AgZmxhdm9yIChlaXRoZXIgRW5kIHdpdGggUFNQIGFsb25lLCBvciBFbmQgd2l0aCBQ U1AgaW4gY29tYmluYXRpb24gb2Ygb3RoZXIpLiBUaGVuLCB0aGUgc2Vjb25kIHRoaW5nIGlzIHRo YXQgdGhlIHJlY2VpdmVkIHBhY2tldCBhdCB0aGUgbm9kZSBpdCBtdXN0IGhhdmUgYSBTTCB2YWx1 ZSBvZiAxLCB0aGF0IGR1cmluZyBwcm9jZXNzaW5nIGlzIGRlY3JlbWVudGVkIHRvIDAuIChJbiBv dGhlciB3b3JkcywgaXQgbXVzdCBiZSB0aGUgcGVudWx0aW1hdGUgc2VnbWVudCkuIElmIGJvdGgg Y29uZGl0aW9ucyBhcmUgZ2l2ZW4sIHRoZW4gbGluZXMgUzE0LjItUzE0LjQgb2YgdGhlIHBzZXVk b2NvZGUgYXJlIGV4ZWN1dGVkLg0KDQpJIHVuZGVyc3RhbmQgbm93OyB0aGFua3MgZm9yIGV4cGxh aW5pbmcgaXQgYWdhaW4uICAoVG8gcmVpdGVyYXRlOiBhbnkgZ2l2ZW4gU0lEIGNhbiBhcHBlYXIg ImFueXdoZXJlIiBpbiB0aGUgc2VnbWVudCBsaXN0LCBzbyBVU1AgaXMgcmVsZXZhbnQgd2hlbiBp dCBpcyBsYXN0IGFuZCBQU1AgaXMgcmVsZXZhbnQgd2hlbiBpdCBhcHBlYXJzIHNlY29uZC10by1s YXN0LiAgVGhlIFVTUC9QU1AgZmxhdm9yIGRvZXNuJ3QgbmVlZCB0byBiZSB0aGUgc2FtZSBmb3Ig YWxsIFNJRHMgaW4gdGhlIHBhdGgsIHNvIG1hcmtpbmcgYSBzaW5nbGUgU0lEIHdpdGggYm90aCBj YW4gYmUgcmVsZXZhbnQgZm9yIGRpZmZlcmVudCBwYXRocy4pDQoNCltQQzJdIENvcnJlY3QNCg0K PiBUaGVyZSBhcmUgbnVtZXJvdXMgZmFjdHVhbCBlcnJvcnMgYW5kIHVuL3VuZGVyLXNwZWNpZmll ZCBwcm90b2NvbCBiZWhhdmlvciAoc2VlIENPTU1FTlQpLCBpbmNsdWRpbmc6IGhvdyB0byBzZXQg dGhlIG91dGVyIEhvcCBMaW1pdCAobXVsdGlwbGUgaW5zdGFuY2VzKSwgdGhlIG9yZGVyIG9mIHNl Z21lbnRzIGluIHRoZSBTUkgsIHNwZWNpZmljYXRpb24gb2YgaGVhZGVuZCBiZWhhdmlvciBieSBy ZWZlcmVuY2UgdG8gaW5mb3JtYWwgZXhhbXBsZSwgTDIgZnJhbWUgZW4vZGVjYXBzdWxhdGlvbiBw cm9jZWR1cmVzLCBhbmQgdGhlICJPcGFxdWUiIG5vdGUgZm9yIGVuZHBvaW50IGJlaGF2aW9yIDY1 NTM1Lg0KPiBbUENdIEnigJlsbCBjb21tZW50IG9uIGVhY2ggcG9pbnQgaW4gdGhlIGNvbW1lbnQu DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0K PiBJIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IHJlZmVyZW5jZXMNCj4gZHJhZnQtZmlsc2ZpbHMt c3ByaW5nLXNydjYtbmV0LXBnbS1pbGx1c3RyYXRpb24sIHdoaWNoIHVzZXMgdGhlIElQdjQgQ0lE UiAyMC84IGluIGV4YW1wbGVzIGluc3RlYWQgb2YgYWRkcmVzc2VzIGZyb20gdGhlIFJGQyA1NzM3 IHJhbmdlLiAgSXQgd291bGQgYmUgZGlzYXBwb2ludGluZyB0byBoYXZlIGEgUFMgcmVmZXIgdG8g YSBkcmFmdCB0aGF0IHNxdWF0cyBvbiB0aGUgSVB2NCBuYW1lc3BhY2UgaW4gc3VjaCBhIG1hbm5l ci4NCj4gW1BDXSBBY2suIEnigJl2ZSB1cGRhdGVkIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2 LW5ldC1wZ20taWxsdXN0cmF0aW9uIHRvIGNvcnJlY3QgdGhhdC4NCg0KVGhhbmsgeW91IQ0KDQo+ IEFic3RyYWN0LCBJbnRyb2R1Y3Rpb24NCj4NCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRo ZSBTUnY2IE5ldHdvcmsgUHJvZ3JhbW1pbmcgY29uY2VwdCBhbmQNCj4gICAgc3BlY2lmaWVzIHRo ZSBiYXNlIHNldCBvZiBTUnY2IGJlaGF2aW9ycyB0aGF0IGVuYWJsZXMgdGhlIGNyZWF0aW9uIG9m DQo+ICAgIGludGVyb3BlcmFibGUgb3ZlcmxheXMgd2l0aCB1bmRlcmxheSBvcHRpbWl6YXRpb24g KFNlcnZpY2UgTGV2ZWwNCj4gICAgQWdyZWVtZW50cykuDQo+DQo+IEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aGF0IHRoZSBwYXJlbnRoZXRpY2FsIGlzIGludGVuZGluZyB0byBjb252ZXkuDQo+IFtQQ10g SeKAmXZlIHJlbW92ZWQgdGhlIHBhcmVudGhlc2lzLiBJdHMgdW5uZWVkZWQuDQo+DQo+IFNlY3Rp b24gMg0KPg0KPiAgICBUaGUgZm9sbG93aW5nIHRlcm1zIHVzZWQgd2l0aGluIHRoaXMgZG9jdW1l bnQgYXJlIGRlZmluZWQgaW4NCj4gICAgW1JGQzg0MDJdOiBTZWdtZW50IFJvdXRpbmcsIFNSIERv bWFpbiwgU2VnbWVudCBJRCAoU0lEKSwgU1J2NiwgU1J2Ng0KPiAgICBTSUQsIFNSIFBvbGljeSwg UHJlZml4IFNJRCwgYW5kIEFkamFjZW5jeSBTSUQuDQo+DQo+IFtSRkMgODQwMiBzcGVsbHMgaXQg UHJlZml4LVNJRCAod2l0aCBoeXBoZW4pIGFuZCBBZGotU0lELl0gW1BDXSBGaXhlZA0KPiBpbiBy ZXYyMS4NCj4NCj4gU2VjdGlvbiAzDQo+DQo+IFRoZSB0ZXh0IGFsbGVnZWRseSByZXByb2R1Y2Vk IGZyb20gUkZDIDg3NTQgwqc0LjMgZGlmZmVycyBpbiBjYXNlIGFuZCBoeXBoZW5hdGlvbi4NCj4g W1BDXSBGaXhlZCBpbiByZXYyMS4NCj4NCj4gU2VjdGlvbiAzLjENCj4NCj4gICAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGFuIFNSdjYgU0lEIGFzIGNvbnNpc3Rpbmcgb2YgTE9DOkZVTkNUOkFSRywN Cj4gICAgd2hlcmUgYSBsb2NhdG9yIChMT0MpIGlzIGVuY29kZWQgaW4gdGhlIEwgbW9zdCBzaWdu aWZpY2FudCBiaXRzIG9mDQo+ICAgIHRoZSBTSUQsIGZvbGxvd2VkIGJ5IEYgYml0cyBvZiBmdW5j dGlvbiAoRlVOQ1QpIGFuZCBBIGJpdHMgb2YNCj4gICAgYXJndW1lbnRzIChBUkcpLiAgTCwgdGhl IGxvY2F0b3IgbGVuZ3RoLCBpcyBmbGV4aWJsZSwgYW5kIGFuIG9wZXJhdG9yDQo+ICAgIGlzIGZy ZWUgdG8gdXNlIHRoZSBsb2NhdG9yIGxlbmd0aCBvZiB0aGVpciBjaG9pY2UuICBGIGFuZCBBIG1h eSBiZQ0KPiAgICBhbnkgdmFsdWUgYXMgbG9uZyBhcyBMK0YrQSA8PSAxMjguICBXaGVuIEwrRitB IGlzIGxlc3MgdGhhbiAxMjggdGhlbg0KPiAgICB0aGUgcmVtYWluaW5nIGJpdHMgb2YgdGhlIFNJ RCBNVVNUIGJlIHplcm8uDQo+DQo+IFdoeSBkb2VzIEEgaGF2ZSB0byBiZSBhIGZpeGVkIHZhbHVl OyBjYW4ndCBpdCBzYWZlbHkgYmUgYSBmdW5jdGlvbiBvZiBGIChldmVuIGlmIHdlIGV4Y2x1ZGUg dGhpbmdzIGxpa2UgaHVmZm1hbiBjb2RpbmcgZm9yIEYpPw0KPiBbUENdIENhbiB5b3UgcGxlYXNl IHJlLXN0YXRlIHlvdXIgcG9pbnQ/IFRoZSB0ZXh0IGFib3ZlIGRvZXMgbm90IHN1Z2dlc3QgdGhh dCBBIGlzIGEgZml4ZWQgdmFsdWUsIGhlbmNlIEnigJltIG5vdCBzdXJlIEkgZnVsbHkgdW5kZXJz dGFuZCB3aGF0IHlvdSBtZWFuLg0KDQpJdCdzIHRydWUgdGhhdCB0aGVyZSBpcyBubyBzcGVjaWZp YyBzdGF0ZW1lbnQgIkEgaXMgYSBjb25zdGFudCBhY3Jvc3MgPHNvbWUtcGFydGljdWxhci1zY29w ZT4iLiAgSG93ZXZlciwgdGhlcmUgaXMgYWxzbyBub3QgYSBzcGVjaWZpYyBzdGF0ZW1lbnQgInRo ZSB2YWx1ZSBvZiBBIGNhbiBkZXBlbmQgb24gPHNvbWUtcGFydGljdWxhci1zY29wZT4iLCBzbyB0 aGUgcmVhZGVyIGhhcyB0byBtYWtlIGFuIGludGVycHJldGF0aW9uLiAgV2UgZG8gc2F5IHRoYXQg TCBpcyBmbGV4aWJsZSBhbmQgdGhlIG9wZXJhdG9yIGNhbiBjaG9vc2UgdGhhdCBsZW5ndGg7IEkg aW50ZXJwcmV0ZWQgdGhpcyB0byBtZWFuIHRoYXQgdGhlIG9wZXJhdG9yIG1ha2VzIHRoZSBjaG9p Y2Ugb25jZSwgYW5kIHRoYXQgTCBpcyBmaXhlZCBmb3IgdGhlIGVudGlyZSBTUiBkb21haW4uICBX aXRoIHRoYXQgaW4gbXkgaGVhZCwgaXQgd2FzIGFsc28gbmF0dXJhbCB0byBpbmZlciB0aGF0IEYg YW5kIEEgYXJlIGFsc28gZml4ZWQgZm9yIHRoZSBlbnRpcmUgU1IgZG9tYWluLiAgKElzIEwgYWxs b3dlZCB0byB2YXJ5IGV2ZW4gd2l0aGluIHRoZSBkb21haW4/KQ0KDQpbUEMyXSAgTm90ZSB0aGF0 IGluIFJGQzg3NTQgd2UgaGF2ZSDigJxXaGVuIGFuIFNSdjYtY2FwYWJsZSBub2RlIHJlY2VpdmVz IGFuIElQdjYgcGFja2V0LCBpdCBwZXJmb3JtcyBsb25nZXN0LXByZWZpeC1tYXRjaCBsb29rdXAg b24gdGhlIHBhY2tldOKAmXMgZGVzdGluYXRpb24gYWRkcmVzcy7igJ0uIEhlbmNlICB0aGluZ3Mg d29yayBldmVuIGlmIHR3byBub2RlcyB1c2UgYSBkaWZmZXJlbnQgTCAgZm9yIHRoZWlyIGxvY2F0 b3JzIG9yIGRpZmZlcmVudCBzaXplcyBvZiBGIGFuZCBBIGZvciB0aGVpciBTSURzLg0KDQpJZiB3 ZSBkbyB3YW50IHRvIGFsbG93IEYgYW5kIEEgdG8gdmFyeSBhdCBhIChlLmcuKSBwZXItTE9DIHNj b3BlLCB3ZSBzaG91bGQgcHJvYmFibHkgbWFrZSBzb21lIHN0YXRlbWVudCBhYm91dCBiZWluZyBh YmxlIHRvIGRlY29kZSB0aGVtIHByb3Blcmx5IG9uIHJlY2VpcHQ7IHRoaXMgY291bGQgYmUgZG9u ZSBpbiBtYW55IHdheXMsIGluY2x1ZGluZyBhIHN0cmljdCBsb29rdXAgdGFibGUgYW5kIGEgc2Vs Zi1kZWxpbmlhdGluZyBsZW5ndGgtZW5jb2Rpbmcgc2NoZW1lLCBidXQgdGhlcmUgY2Fubm90IGJl IGFtYmlndWl0eSBhYm91dCBob3cgdG8gcGFydGl0aW9uIGEgZ2l2ZW4gSVAgYWRkcmVzcyBpbnRv IExPQzpGVU5DVDpBUkcuDQoNCltQQzJdIFBsZWFzZSByZWZlciB0byBwcmV2aW91cyBjb21tZW50 cyBhbmQgYWxzbyB0aGUgdGV4dCBpbiBTZWMgMy4gVGhlIFNSIEVuZHBvaW50IE5vZGUgcGVyZm9y bXMgTFBNIGxvb2t1cCB0byBtYXRjaCB0aGUgRklCIGVudHJ5IGNvcnJlc3BvbmRpbmcgdG8gU0lE cyB0aGF0IGl0IGhhcyBpbnN0YW50aWF0ZWQgaW4gb3JkZXIgdG8gZXhlY3V0ZSB0aGUgaW5zdHJ1 Y3Rpb25zIHNwZWNpZmljIHRvIGl0cyBiZWhhdmlvci4gVGhlIHBhY2tldCB3aXRoIHRoZSBTSUQg aW4gdGhlIERBIGlzIHJvdXRlZCB0aHJvdWdoIHRyYW5zaXQgbm9kZXMgYmFzZWQgb24gTFBNIGxv b2t1cCB0aGF0IGhhcHBlbnMgb24gdGhlIGxvY2F0b3IgcGFydHMgdGhhdCBhcmUgYWR2ZXJ0aXNl ZCB2aWEgcm91dGluZy9jb250cm9sIHBsYW5lIGFzIGRlc2NyaWJlZCBpbiBTZWMgMy4zLiBUaGUg dHJhbnNpdCBub2RlcyBkbyBub3QgaGF2ZSB0byBkZWNvZGUgb3IgcHJvZ3JhbSBTSURzIHRoYXQg aGF2ZSBiZWVuIGluc3RhbnRpYXRlZCBieSBvdGhlciBTUiBFbmRwb2ludCBub2RlcyBpbiB0aGUg ZG9tYWluLg0KDQo+ICAgIEFuIFNSdjYgU2VnbWVudCBFbmRwb2ludCBCZWhhdmlvciBtYXkgcmVx dWlyZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uDQo+ICAgIGZvciBpdHMgcHJvY2Vzc2luZyAoZS5n LiByZWxhdGVkIHRvIHRoZSBmbG93IG9yIHNlcnZpY2UpLiAgVGhpcw0KPiAgICBpbmZvcm1hdGlv biBtYXkgYmUgZW5jb2RlZCBpbiB0aGUgQVJHIGJpdHMgb2YgdGhlIFNJRC4NCj4NCj4gKEFzc3Vt aW5nIHRoYXQgaXQgY2FuIGJlIHN1ZmZpY2llbnRseSBjb21wYWN0bHkgZW5jb2RlZD8pIFtQQ10g Q29ycmVjdA0KPg0KPiAgICBUaGUgQVJHIHZhbHVlIG9mIGEgcm91dGVkIFNJRCBTSE9VTEQgcmVt YWluIGNvbnN0YW50IGFtb25nIHBhY2tldHMgaW4NCj4gICAgYSBnaXZlbiBmbG93LiAgVmFyeWlu ZyBBUkcgdmFsdWVzIGFtb25nIHBhY2tldHMgaW4gYSBmbG93IG1heQ0KPiByZXN1bHQNCj4NCj4g KFRodXMgbGltaXRpbmcgdGhlIHR5cGUgb2YgaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgcmVwcmVz ZW50ZWQgaW4gdGhlDQo+IEFSRz8pDQo+IFtQQ10gVGhpcyB0ZXh0IHByb3ZpZGVzIGEgU0hPVUxE LCBhbmQgYSByZWFzb24gZm9yIGl0LiBJZiBvdGhlciBiZWhhdmlvcnMgZGVmaW5lZCBpbiBmdXR1 cmUgZG9jdW1lbnRzIHdvdWxkIGxpa2UgdG8gaGF2ZSBBUkcgdmFsdWUgdmFyeWluZyBmb3IgcGFj a2V0cyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgZmxvdywgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhl eSB0YWtlIHRoaXMgaW50byBjb25zaWRlcmF0aW9uLg0KPg0KPiBTZWN0aW9uIDMuMg0KPg0KPiAg ICBTSURzLiAgVGhlIHByb3ZpZGVyIGhpc3RvcmljYWxseSBkZXBsb3llZCBJUHY2IGFuZCBhc3Np Z25lZA0KPiAgICBpbmZyYXN0cnVjdHVyZSBhZGRyZXNzZXMgZnJvbSBhIHBvcnRpb24gb2YgdGhl IGZjMDA6Oi83IHByZWZpeC4gIFRoZXkNCj4gICAgZnVydGhlciBzdWJkaXZpZGVkIHRoZSBwcmVm aXggaW50byB0aHJlZSAvNDggcHJlZml4ZXMgKENvdW50cnkgWCwNCj4gICAgQ291bnRyeSBZLCBD b3VudHJ5IFopIHRvIHN1cHBvcnQgdGhlaXIgU1J2NiBpbmZyYXN0cnVjdHVyZS4gIEZyb20NCj4g ICAgdGhvc2UgLzQ4IHByZWZpeGVzIGVhY2ggcm91dGVyIGlzIGFzc2lnbmVkIGEgLzY0IHByZWZp eCBmcm9tIHdoaWNoDQo+ICAgIGFsbCBTSURzIG9mIHRoYXQgcm91dGVyIGFyZSBhbGxvY2F0ZWQu DQo+DQo+IFRoaXMgaXMgbm90IHRoZSBsYW5ndWFnZSBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgZm9y IHVzZSBvZiB0aGUgVUxBIGFkZHJlc3MgcmFuZ2UuICBJdCBsb29rcyBsaWtlIHRoaXMgbWF5IGJl IHJlbGF0ZWQgdG8gRXJpayBLbGluZSdzIERpc2N1c3MgcG9pbnQuLi4NCj4gW1BDXSBJbmRlZWQg cmVsYXRlZC4gRXJpayBLbGluZSBoYXMgc3VnZ2VzdGVkIHRleHQuIElsbCB1c2UgRXJpa+KAmXMg dGV4dCBhcyBwcm92aWRlZC4NCj4NCj4gICAgSVB2NiBhZGRyZXNzIGNvbnN1bXB0aW9uIGluIGJv dGggdGhlc2UgZXhhbXBsZXMgaXMgbWluaW1hbCwNCj4gICAgcmVwcmVzZW50aW5nIG9uZSBiaWxs aW9udGggYW5kIG9uZSBtaWxsaW9udGggb2YgdGhlIGFzc2lnbmVkIGFkZHJlc3MNCj4gICAgc3Bh Y2UsIHJlc3BlY3RpdmVseS4NCj4NCj4gSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgY2Fs Y3VsYXRpb24gdGhhdCBwcm9kdWNlZCB0aGVzZSB2YWx1ZXMuDQo+IFtQQ10gSWYgdGhlIG9wZXJh dG9yIGdvdCBhc3NpZ25lZCBhIC8yMCBieSB0aGUgUklSLCB0aGVuIHRoZXkgaGF2ZSAyXjI4IC80 OCBwcmVmaXhlcyBhdmFpbGFibGUuIFRodXMsIGlmIHRoZXkgYXJlIG9ubHkgdXNpbmcgYSBmZXcg LzQ4IHByZWZpeGVzLCB0aGVuIHRoZXkgYXJlIHVzaW5nIGxlc3MgdGhhbiBhIG1pbGxpb250aCBv ZiB0aGUgYXZhaWxhYmxlIC80OCBwcmVmaXhlcy4NCg0KQXBwYXJlbnRseSBJIGRpZG4ndCB0YWtl IG5vdGVzIG9uIG15IGluaXRpYWwgY2FsY3VsYXRpb25zIHRoYXQgbGVmdCBtZSBjb25mdXNlZC4g IEFzc3VtaW5nIEkgaGF2ZSBpdCByaWdodCB0aGlzIHRpbWUuLi4NCg0KIyBVc2UgMyAvNDhzIGlu IHRoZSB3aG9sZSBVTEEgLzQwDQo+Pj4gMy4vMioqNDANCjIuNzI4NDg0MTA1MzE4Nzg0N2UtMTIN CiMgVXNlICJhIGZldyIgMyAvNDhzIGZyb20gdGhlIGFzc2lnbmVkIC8yMA0KPj4+IDMuLzIqKjI4 DQoxLjExNzU4NzA4OTUzODU3NDJlLTA4DQoNClRoaXMgc2VlbXMgdG8gYmUgd2VsbCBsZXNzIHRo YW4gYSBiaWxsaW9udGggYW5kIGEgbWlsbGlvbnRoLCByZXNwZWN0aXZlbHksIHNvIEknbSBub3Qg c3VyZSBpZiBJIGFtIGRvaW5nIHRoZSBtYXRoIGFzIGludGVuZGVkLg0KDQpbUEMyXSBJIGJlbGll dmUgeW91ciBtYXRocyBhcmUgcmlnaHQuDQpJZiBhbiBvcGVyYXRvciBpcyBhbGxvY2F0ZWQgYSAv MjAsIHRoZXkgY2FuIGFsbG9jYXRlIDIqKjI4ICAvNDggcHJlZml4ZXMuDQoyKioyOCA9IDI2ODQz NTQ1Ni4NClRodXMsIElmIFNSdjYgcmVxdWlyZXMgMyBvZiBzdWNoIC80OCBwcmVmaXhlcywgdGhl biB3ZSBhcmUgdXNpbmcgb25seSAxLjEyZS04IG9mIHRoYXQgc3BhY2UsIHdoaWNoIGlzIGxlc3Mg dGhhbiBhIG1pbGxpb250aCAoZS02KS4NCk5vPw0KSW4gb3RoZXIgd29yZHM6IGlmIHdlIGRvIGEg bWlsbGlvbiBvZiBkZXBsb3ltZW50cyBvZiBTUnY2LCB0aGVyZSB3b3VsZCBiZSBzcGFjZSB0byBm aXQgdGhlbSBhbGwgd2l0aGluIHRoYXQgLzIwLiAoYW5kIGFjdHVhbGx5IHRoZXJlIGlzIHNsaWdo dGx5IG1vcmUpDQoNCj4gICAgQW4gU1IgU291cmNlIE5vZGUgY2Fubm90IGluZmVyIHRoZSBiZWhh dmlvciBieSBleGFtaW5hdGlvbiBvZiB0aGUNCj4gICAgRlVOQ1QgdmFsdWUgb2YgYSBTSUQuDQo+ DQo+ICAgIFRoZXJlZm9yZSwgdGhlIFNSdjYgRW5kcG9pbnQgQmVoYXZpb3IgY29kZXBvaW50IGlz IGFkdmVydGlzZWQgYWxvbmcNCj4gICAgd2l0aCB0aGUgU0lEIGluIHRoZSBjb250cm9sIHBsYW5l Lg0KPg0KPiBUaGVzZSB0d28gc2VudGVuY2VzIGZlZWwgYSBsaXR0bGUgb3V0IG9mIHBsYWNlIGlu IHRoaXMgc3BvdCwgb2NjdXJyaW5nIGFmdGVyIHByZXZpb3VzIGRpc2N1c3Npb24gdGhhdCB0aGUg ZW5kcG9pbnQgYmVoYXZpb3IgY29kZXBvaW50IGlzIGFkdmVydGlzZWQgaW4gdGhlIGNvbnRyb2wg cGxhbmUuDQo+IFtQQ10gT3RoZXIgQURzIGhhdmUgZXhwcmVzc2VkIHRoZSB2YWx1ZSBvZiBwcmVj aXNlbHkgdGhvc2UgdHdvIHNlbnRlbmNlcy4NCg0KSSBhZ3JlZSB0aGF0IHRoZXNlIHNlbnRlbmNl cyBhcmUgdmFsdWFibGUuICBJIHdhcyBwcm9wb3NpbmcgdG8gbW92ZSB0aGVtIHR3byBwYXJhZ3Jh cGhzIGVhcmxpZXIsIHNvIHdlIHRyYW5zaXRpb24gZGlyZWN0bHkgZnJvbSAiYWR2ZXJ0aXNlcyB0 aGUgU0lEIC4uLiBpbiB0aGUgY29udHJvbCBwbGFuZSIgdG8gKHBhcmFwaHJhc2luZykgImNhbm5v dCBpbmZlciBiZWhhdmlvciBieSBleGFtaW5pbmcgRlVOQ1QiIGFuZCAiYmVoYXZpb3IgY29kZXBv aW50IGlzIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBTSUQiLg0KDQpbUEMyXSBNaXN1bmRlcnN0b29k IHlvdXIgb3JpZ2luYWwgcG9pbnQuIEkgbW92ZWQgdGhvc2UgdHdvIHVwIGFzIHlvdSBzdWdnZXN0 Lg0KDQo+ICAgIG8gIEF0IFJvdXRlciAzLCB3aXRoaW4gdGhlIGxvY2F0b3IgMjAwMTpkYjg6YmJi YjozOjovNjQsIG5ldHdvcmsNCj4gICAgICAgb3BlcmF0b3Igb3IgdGhlIHJvdXRlciBwZXJmb3Jt cyBkeW5hbWljIGFzc2lnbm1lbnQgZm9yOg0KPg0KPiBuaXQ6IG1pc3NpbmcgYXJ0aWNsZSAoInRo ZSBuZXR3b3JrIG9wZXJhdG9yIikuDQo+IFtQQ10gQWNrLiBGaXhlZCBpbiByZXYyMS4NCj4NCj4g ICAgICAgKiAgRnVuY3Rpb24gMTAwIGFzc29jaWF0ZWQgd2l0aCB0aGUgYmVoYXZpb3IgRW5kLlgg KEVuZHBvaW50IHdpdGgNCj4gICAgICAgICAgY3Jvc3MtY29ubmVjdCkgYmV0d2VlbiByb3V0ZXIg MyBhbmQgaXRzIGNvbm5lY3RlZCBuZWlnaGJvcg0KPiAgICAgICAgICByb3V0ZXIsIGZvciBleGFt cGxlIFJvdXRlciA0LiAgVGhpcyBmdW5jdGlvbiBpcyBlbmNvZGVkIGFzDQo+ICAgICAgICAgIDE2 LWJpdCB2YWx1ZSBhbmQgaGFzIG5vIGFyZ3VtZW50cy4NCj4NCj4gUGxlYXNlIGNsYXJpZnkgdGhh dCAiZnVuY3Rpb24gMTAwIiBpcyBhIGhleCBsaXRlcmFsLg0KPiBbUENdIEFjay4gRml4ZWQgaW4g cmV2MjEuDQo+DQo+IEkgYWxzbyBzdWdnZXN0IG5vdGluZyBjbGVhcmx5IGF0IHRoZSBzdGFydCBv ZiB0aGUgZXhhbXBsZSB0aGF0IEYgaXMgMTYgYW5kIEEgaXMgMC4NCj4gW1BDXSBBY2suIEFkZGVk IGZvciBlYWNoIFNJRCBpbiByZXYyMS4NCj4NCj4gICAgICAgKiAgRnVuY3Rpb24gMTAxIGFzc29j aWF0ZWQgd2l0aCB0aGUgYmVoYXZpb3IgRW5kLlggKEVuZHBvaW50IHdpdGgNCj4gICAgICAgICAg Y3Jvc3MtY29ubmVjdCkgYmV0d2VlbiByb3V0ZXIgMyBhbmQgaXRzIGNvbm5lY3RlZCBuZWlnaGJv cg0KPiAgICAgICAgICByb3V0ZXIsIGZvciBleGFtcGxlIFJvdXRlciAyLiAgVGhpcyBmdW5jdGlv biBpcyBlbmNvZGVkIGFzDQo+ICAgICAgICAgIDE2LWJpdCB2YWx1ZSBhbmQgaGFzIG5vIGFyZ3Vt ZW50cy4NCj4NCj4gRiBpcyBhIGNvbnN0YW50IGZvciB0aGUgU1IgZG9tYWluOyBzYXlpbmcgaXQg YXQgZWFjaCBTSUQgYXNzaWdubWVudCBpcyBtaXNsZWFkaW5nLg0KPiBbUENdIEZ1bmN0aW9uIGlz IHRoZSBiaXRzIGluIHRoZSBTSUQgaW5zdGFudGlhdGVkIGJ5IHRoZSByb3V0ZXIuIENhbiB5b3Ug cGxlYXNlIGV4cGxhaW4gd2hhdCB0ZXh0IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgRiBpcyBh IGNvbnN0YW50Pw0KDQpGVU5DVCBpcyBpbnN0YW50aWF0ZWQgYnkgdGhlIHJvdXRlciwgeWVzLCBh bmQgaXQgaXMgRiBiaXRzIGxvbmcuICBUaGlzIHRpZXMgaW4gdG8gbXkgcHJldmlvdXMgY29tbWVu dCBhYm91dCBMLCBGLCBhbmQgQSAobWF5YmUpIGJlaW5nIGNvbnN0YW50cyBhY3Jvc3MgdGhlIFNS IGRvbWFpbiwgb3IgY2xhcmlmeWluZyBhdCB3aGljaCBzY29wZSB0aGV5IGNhbiB2YXJ5Lg0KDQpb UEMyXSBJbmRlZWQsIHNlZSBwcmV2aW91cyBhbnN3ZXIuDQoNCj4gW3NhbWUgbm90ZSBhYm91dCBo ZXggZm9yIDEwMV0NCj4gW1BDXSBBY2suIEFkZGVkIGZvciBlYWNoIFNJRCBpbiByZXYyMS4NCj4N Cj4gU2VjdGlvbiA0DQo+DQo+ICAgIFRoZSBsaXN0IGlzIG5vdCBleGhhdXN0aXZlLiAgSW4gcHJh Y3RpY2UsIGFueSBmdW5jdGlvbiBjYW4gYmUNCj4gICAgYXR0YWNoZWQgdG8gYSBsb2NhbCBTSUQ6 IGUuZy4gYSBub2RlIE4gY2FuIGJpbmQgYSBTSUQgdG8gYSBsb2NhbCBWTQ0KPiAgICBvciBjb250 YWluZXIgd2hpY2ggY2FuIGFwcGx5IGFueSBjb21wbGV4IHByb2Nlc3Npbmcgb24gdGhlIHBhY2tl dC4NCj4NCj4gWWVzLCBidXQgaXQgY2FuJ3QgYWR2ZXJ0aXNlIHRoZSBiZWhhdmlvciBjb3JyZXNw b25kaW5nIHRvIHRoYXQgZnVuY3Rpb24gd2l0aG91dCBhIGNvZGVwb2ludC4NCj4gW1BDXSBUaGlz IGlzIGludGVuZGVkIHRvIGJlIGFuIGludHJvZHVjdG9yeSBwYXJhZ3JhcGggdG8gdGhlIGJlaGF2 aW9ycy4gQnV0IHlvdSBhcmUgYWJzb2x1dGVseSByaWdodDogZm9yIGFueSBuZXcgYmVoYXZpb3Ig eW91IG5lZWQgdG8gd3JpdGUgYSBuZXcgSS1EIChhcyBpdHMgY3VycmVudGx5IGhhcHBlbmluZyBp biBvdGhlciBTUFJJTkcgV0cgZG9jcyksIGFuZCB0aGVuIC1vbmNlIFJGQ2VkLSBnZXQgYW4gU1J2 NiBFbmRwb2ludCBCZWhhdmlvciBjb2RlcG9pbnQgZm9yIGl0Lg0KDQpNYXliZSB3ZSBjb3VsZCBh ZGQgYXQgdGhlIGVuZCAiLCBwcm92aWRlZCB0aGVyZSBpcyBhIGJlaGF2aW9yIGNvZGVwb2ludCBh bGxvY2F0ZWQgZm9yIHRoYXQgcHJvY2Vzc2luZyIgb3Igc29tZSBzaW1pbGFyIGVkaXQ/ICAoV2Ug ZG9uJ3QgaGF2ZSB0bzsgdGhlIGRlY2lzaW9uIGlzIHVwIHRvIHlvdS4pDQoNCltQQzJdIEknbSBm aW5lIHdpdGggaXQuIEFkZGVkIGFzIHN1Z2dlc3RlZC4NCg0KPiBTZWN0aW9uIDQuMS4xDQo+DQo+ ICAgIFdoZW4gcHJvY2Vzc2luZyB0aGUgVXBwZXItbGF5ZXIgSGVhZGVyIG9mIGEgcGFja2V0IG1h dGNoaW5nIGEgRklCDQo+ICAgIGVudHJ5IGxvY2FsbHkgaW5zdGFudGlhdGVkIGFzIGFuIFNSdjYg RW5kIFNJRCwgaWYgVXBwZXItbGF5ZXIgSGVhZGVyDQo+ICAgIHByb2Nlc3NpbmcgaXMgYWxsb3dl ZCBieSBsb2NhbCBjb25maWd1cmF0aW9uIChlLmcuICBJQ01QdjYpLCB0aGVuDQo+DQo+IG5pdDog dGhlIHBhcmVudGhldGljYWwgaXMgcGxhY2VkIHNvIGFzIHRvIGFwcGx5IHRvICJsb2NhbCBjb25m aWd1cmF0aW9uIiwgd2hpY2ggZG9lc24ndCByZWFsbHkgbWFrZSBzZW5zZTsgSSBwcmVzdW1lIHRo ZSBpbnRlbnQgaXMgdG8gc2F5IHRoYXQgdXBwZXItbGF5ZXIgaGVhZGVyIHByb2Nlc3NpbmcgaXMg YWxsb3dlZCAqZm9yIHRoYXQgdXBwZXItbGF5ZXIgcHJvdG9jb2wqLiAgQWxzbywgY29tbWEgYWZ0 ZXIgImUuZy4iLg0KPiBbUENdIEFncmVlZCwgYnV0IHNlZSBuZXh0IHBvaW50Lg0KPg0KPiAgICBw cm9ibGVtIG1lc3NhZ2UgdG8gdGhlIFNvdXJjZSBBZGRyZXNzIGFuZCBkaXNjYXJkIHRoZSBwYWNr ZXQuICBFcnJvcg0KPiAgICBjb2RlIDQgKFNSIFVwcGVyLWxheWVyIEhlYWRlciBFcnJvcikgYW5k IFBvaW50ZXIgc2V0IHRvIHRoZSBvZmZzZXQgb2YNCj4gICAgdGhlIHVwcGVyLWxheWVyIGhlYWRl ci4NCj4NCj4gbml0OiB0aGlzIGlzIG5vdCBhIGNvbXBsZXRlIHNlbnRlbmNlLg0KPiBbUENdIFdl IGhhdmUgYmVlbiBhc2tlZCB0byBjaGFuZ2UgdGhlIGVudGlyZSA0LjEuMSB0byBhIHBzZXVkb2Nv ZGUuIFBsZWFzZSByZXZpZXcgdGhlIHBzZXVkb2NvZGUgaW4gcmV2aXNpb24gMjEgYW5kIGxldCBt ZSBrbm93IHlvdXIgZmVlZGJhY2suDQoNClllcywgdGhpcyBwc2V1ZG9jb2RlIGxvb2tzIG11Y2gg YmV0dGVyIC0tIHRoYW5rIHlvdSENCg0KVGhhdCBzYWlkLCBJIGFtIG5vdCBzdXJlIHRoYXQgSSB1 bmRlcnN0YW5kIHdoeSBpdCBpcyBvbmx5IFJFQ09NTUVOREVEIChub3QNClJFUVVJUkVEKSB0byBv bmx5IGFsbG93IHVwcGVyLWxheWVyIHByb2Nlc3Npbmcgd2hlbiB0aGF0IGRvZXMgbm90IHJlc3Vs dCBpbiB0aGUgcGFja2V0IGJlaW5nIGZvcndhcmRlZC4gIEFyZSB0aGVyZSBjYXNlcyB3aGVuIHRo aXMgd291bGQgYmUgdXNlZnVsIGFuZCBub3QgcmVzdWx0IGluIGEgcGFja2V0IGxvb3A/DQoNCltQ QzJdIFdlIGJlbGlldmUgdGhhdCBSRUNPTU1FTkRBVElPTiBpcyBzdHJvbmcgZW5vdWdoIGZvciB0 aGlzIHNjZW5hcmlvLiBJIGFtIG5vdCBzdXJlIHRoYXQgd2UgY2FuIHNheSB0aGF0IHBhY2tldHMg Zm9yd2FyZGVkIGFmdGVyIGxvY2FsIHByb2Nlc3Npbmcgd2lsbCBhbHdheXMgcmVzdWx0IGluIGEg bG9vcCBlLmcuIGlmIHRoZXJlIGlzIGFuIGlubmVyIGVuY2Fwc3VsYXRlZCBJUCBwYWNrZXQgdGhh dCBuZWVkcyB0byBnZXQgZm9yd2FyZGVkIGZ1cnRoZXIuDQoNCj4gU2VjdGlvbiA0LjINCj4NCj4g ICAgSXQgaXMgdGhlIFNSdjYgaW5zdGFudGlhdGlvbiBvZiBhbiBBZGphY2VuY3ktU0lEIFtSRkM4 NDAyXSBhbmQgaXQgaXMNCj4gICAgcmVxdWlyZWQgdG8gZXhwcmVzcyBhbnkgdHJhZmZpYy1lbmdp bmVlcmluZyBwb2xpY3kuDQo+DQo+IFRoaXMgdGV4dCByZWFkcyBhcyBpZiBFbmQuWCBzcGVjaWZp Y2FsbHkgaXMgcmVxdWlyZWQgZm9yIFRFLCB3aGljaCBkb2VzIG5vdCBzZWVtIGNvcnJlY3QgdG8g bWUuDQo+IFtQQ10gRml4ZWQuDQo+IE9MRDogYW5kIGl0IGlzIHJlcXVpcmVkIHRvIGV4cHJlc3Mg YW55IHRyYWZmaWMtZW5naW5lZXJpbmcgcG9saWN5Lg0KPiBORVc6IGFuZCBpdHMgbWFpbiB1c2Ug aXMgZm9yIHRyYWZmaWMtZW5naW5lZXJpbmcgcG9saWNpZXMuDQo+DQo+IFNlY3Rpb24gNC40LCA0 LjUNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgaXMg ZXF1aXZhbGVudCB0byB0aGUgcGVyLUNFDQo+ICAgIFZQTiBsYWJlbCBpbiBNUExTIFtSRkM0MzY0 XS4NCj4NCj4gVGhlIHBocmFzZSAicGVyLUNFIFZQTiIgZG9lcyBub3QgYXBwZWFyIGluIFJGQyA0 MzY0Lg0KPiBbUENdIEFkZGVkIHRvIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLg0KPg0KPiBTZWN0 aW9uIDQuNQ0KPg0KPiAgICBTMDUuICBJZiB0aGUgRW5kLkRYNCBTSUQgaXMgYm91bmQgdG8gYW4g YXJyYXkgb2YgTDMgYWRqYWNlbmNpZXMsIHRoZW4NCj4gICAgb25lIGVudHJ5IG9mIHRoZSBhcnJh eSBpcyBzZWxlY3RlZCBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgcGFja2V0J3MNCj4gICAgaGVh ZGVyIFNlY3Rpb24gNy4NCj4NCj4gbml0OiBJIHN1Z2dlc3QgIihzZWUgU2VjdGlvbiA3KSIgdG8g bWF0Y2ggc2VjdGlvbiA0LjQuDQo+IFtQQ10gSW5kZWVkLiBGaXhlZC4NCj4NCj4gU2VjdGlvbiA0 LjYsIDQuNw0KPg0KPiAgICBpcyByZXF1aXJlZC4gIFRoaXMgaXMgZXF1aXZhbGVudCB0byB0aGUg cGVyLVZSRiBWUE4gbGFiZWwgaW4gTVBMUw0KPiAgICBbUkZDNDM2NF0uDQo+DQo+IFRoZSBwaHJh c2UgInBlci1WUkYgVlBOIiBkb2VzIG5vdCBhcHBlYXIgaW4gUkZDIDQzNjQuDQo+IChBIHNpbWls YXIgY29tbWVudCBhcHBsaWVzIHRvIFNlY3Rpb24gNC44IGFzIHdlbGwuKSBbUENdIEFkZGVkIHRv IHRoZQ0KPiB0ZXJtaW5vbG9neSBzZWN0aW9uIG9mIHRoZSBkb2N1bWVudC4NCj4NCj4gICAgTm90 ZSB0aGF0IGFuIEVuZC5EVDYgbWF5IGJlIGRlZmluZWQgZm9yIHRoZSBtYWluIElQdjYgdGFibGUg aW4gd2hpY2gNCj4gICAgY2FzZSBhbmQgRW5kLkRUNiBzdXBwb3J0cyB0aGUgZXF1aXZhbGVudCBv ZiBhbiBJUHY2aW5JUHY2DQo+DQo+IG5pdDogcy9hbmQvYW4vDQo+IFtQQ10gVGhhbmtzLiBGaXhl ZC4NCj4NCj4gU2VjdGlvbiA0LjcNCj4NCj4gICAgVGhlICJFbmRwb2ludCB3aXRoIGRlY2Fwc3Vs YXRpb24gYW5kIHNwZWNpZmljIElQdjQgdGFibGUgbG9va3VwIg0KPiAgICBiZWhhdmlvciAoRW5k LkRUNCBmb3Igc2hvcnQpIGlzIGEgdmFyaWFudCBvZiB0aGUgRW5kIGJlaGF2aW9yLg0KPg0KPiBu aXQ6IHZhcmlhbnQgb2YgRW5kLlQsIGp1c3QgbGlrZSBFbmQuRFQ2LCBubz8NCj4gW1BDXSBDb3Jy ZWN0LCBmaXhlZC4NCj4NCj4gU2VjdGlvbiA0LjkNCj4NCj4gICAgUzA0LiAgQW4gRW5kLkRYMiBi ZWhhdmlvciBjb3VsZCBiZSBjdXN0b21pemVkIHRvIGV4cGVjdCBhIHNwZWNpZmljDQo+ICAgIElF RUUgaGVhZGVyIChlLmcuICBWTEFOIHRhZykgYW5kIHJld3JpdGUgdGhlIGVncmVzcyBJRUVFIGhl YWRlcg0KPiAgICBiZWZvcmUgZm9yd2FyZGluZyBvbiB0aGUgb3V0Z29pbmcgaW50ZXJmYWNlLg0K Pg0KPiBXb3VsZCB0aGlzIGN1c3RvbWl6ZWQgYmVoYXZpb3IgcmVxdWlyZSBhIG5ldyBjb2RlcG9p bnQ/DQo+IFNpbWlsYXJseSBmb3IgRW5kLkRYMlYgKFNlY3Rpb24gNC4xMCkNCj4gW1BDXSBObywg dGhhdCBjdXN0b21pemF0aW9uIGlzIGxvY2FsIGNvbmZpZyB0byB0aGUgbm9kZS4NCg0KVGhhdCBp cyBzdXJwcmlzaW5nIHRvIG1lIChpdCBzZWVtcyBsaWtlIGFuIGltcG9ydGFudCBwYXJ0IG9mIHRo ZSBiZWhhdmlvciB0aGF0IHNob3VsZCBiZSBzaWduYWxsZWQgZXhwbGljaXRseSksIGJ1dCBJIGFt IG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCB0aGlzIGRvbWFpbiBpbiBvcmRlciB0byBhcmd1ZSBh Ym91dCBpdCBhbnkgZnVydGhlci4NCg0KW1BDMl0gSW4gTVBMUyB0aGlzIGlzIGxvY2FsIGNvbmZp Zy4gV2hpbGUgc29tZW9uZSBtaWdodCB0aGluayBhYm91dCBzaWduYWxpbmcgaXQgaW4gdGhlIGZ1 dHVyZSAtaW50dWl0aXZlbHkgbWFrZXMgc2Vuc2UtLCBpbiB0b2RheeKAmXMgdXNlLWNhc2UgaXQg aXNu4oCZdC4NCg0KPiBTZWN0aW9uIDQuMTANCj4NCj4gICAgUzA0LiBSZW1vdmUgdGhlIG91dGVy IElQdjYgSGVhZGVyIHdpdGggYWxsIGl0cyBleHRlbnNpb24gaGVhZGVycywNCj4gICAgICAgICAg ICBsb29rdXAgdGhlIGV4cG9zZWQgVkxBTnMgaW4gTDIgdGFibGUgVCwgYW5kIGZvcndhcmQNCj4g ICAgICAgICAgICB2aWEgdGhlIG1hdGNoZWQgdGFibGUgZW50cnkuDQo+DQo+IEp1c3QgdG8gY2hl Y2sgbXkgdW5kZXJzdGFuZGluZzogdGhlICJleHBvc2VkIFZMQU5zIiAocGx1cmFsPyEpIGFyZSBp biB0aGUgRXRoZXJuZXQgaGVhZGVyIG9mIHRoZSBwYWNrZXQgdGhhdCB3ZSBhcmUgbGVmdCB3aXRo IGFmdGVyIHJlbW92aW5nIHRoZSBvdXRlciBJUHY2IGhlYWRlciwgcmlnaHQ/DQo+IFtQQ10gQ29y cmVjdC4gQW5kIG11bHRpcGxlIHRhZ3MgaW4gY2FzZSBvZiBRLWluLVEuDQo+DQo+ICAgIFMwMS4g IElBTkEgaGFzIGFsbG9jYXRlZCB0aGUgSW50ZXJuZXQgUHJvdG9jb2wgbnVtYmVyIDE0MyB0byBF dGhlcm5ldA0KPiAgICAoc2VlIFNlY3Rpb24gMTAuMSkuDQo+DQo+IFRoaXMgc2VlbXMgbGlrZSBh IGNvcHkvcGFzdGUgbGVmdG92ZXIgZnJvbSBFbmQuRFgyIC0tIHdlIGRvbid0IG1lbnRpb24NCj4g MTQzIGluIHRoaXMgc2VjdGlvbi4NCj4gW1BDXSBJbmRlZWQuIEkgYWRkZWQgYnkgbWlzdGFrZSBv biByZXYyMCB0byBhZGRyZXNzIGFuIEFEIGNvbW1lbnQgYW5kIEkgaGF2ZSBqdXN0IHJlbW92ZWQg aW4gcmV2MjEgYWdhaW4uDQo+DQo+IFNlY3Rpb24gNC4xMg0KPg0KPiAgICBUd28gb2YgdGhlIGFw cGxpY2F0aW9ucyBvZiB0aGUgRW5kLkRUMk0gYmVoYXZpb3IgYXJlIHRoZSBFVlBODQo+ICAgIEJy aWRnaW5nIG9mIGJyb2FkY2FzdCwgdW5rbm93biBhbmQgbXVsdGljYXN0IChCVU0pIHRyYWZmaWMg d2l0aA0KPiAgICBFdGhlcm5ldCBTZWdtZW50IElkZW50aWZpZXIgKEVTSSkgZmlsdGVyaW5nIGFu ZCB0aGUgRVZQTiBFVFJFRSB1c2UtDQo+ICAgIGNhc2VzLg0KPg0KPiBBcmUgdGhlcmUgcmVmZXJl bmNlcyBmb3IgZWl0aGVyL2JvdGggb2YgdGhlc2U/DQo+IFtQQ10gQWRkZWQgaW4gcmV2MjEuDQoN ClRoYW5rcyENCg0KPiAgICBTMDQuIFJlbW92ZSB0aGUgSVB2NiBoZWFkZXIgYW5kIGFsbCBpdHMg ZXh0ZW5zaW9uIGhlYWRlcnMNCj4NCj4gbml0OiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgdXNl cyAiUmVtb3ZlIHRoZSBvdXRlciBJUHY2IGhlYWRlciB3aXRoIGFsbCBpdHMgZXh0ZW5zaW9uIGhl YWRlcnMiLg0KPiBbUENdIEZpeGVkLiBUaGFua3MuDQo+DQo+ICAgIFMwNi4gRm9yd2FyZCB2aWEg YWxsIEwyIE9JRnMgZXhjbHVkaW5nIHRoZSBvbmUgc3BlY2lmaWVkIGluIEFyZy5GRTINCj4NCj4g bml0OiBzL29uZS9vbmVzLw0KPiBbUENdIEZpeGVkLiBUaGFua3MuDQo+DQo+ICAgIEFyZy5GRTIg aXMgZW5jb2RlZCBpbiB0aGUgU0lEIGFzIGFuIChrKngpLWJpdCB2YWx1ZS4gIFRoZXNlIGJpdHMN Cj4gICAgcmVwcmVzZW50IGEgbGlzdCBvZiB1cCB0byBrIE9JRnMsIGVhY2ggaWRlbnRpZmllZCB3 aXRoIGFuIHgtYml0DQo+ICAgIHZhbHVlLiAgVmFsdWVzIGsgYW5kIHggYXJlIGRlZmluZWQgb24g YSBwZXIgRW5kLkRUMk0gU0lEIGJhc2lzLiAgVGhlDQo+ICAgIGludGVyZmFjZSBpZGVudGlmaWVy IDAgaW5kaWNhdGVzIGFuIGVtcHR5IGVudHJ5IGluIHRoZSBpbnRlcmZhY2UNCj4gICAgbGlzdC4N Cj4NCj4gKGVkaXRvcmlhbCkgcmF0aGVyIHRoYW4gaGF2ZSB0byBjb21lIHVwIHdpdGggdGhlIGNv bmNlcHQgb2YgYW4gImVtcHR5IGVudHJ5IiBpbiB0aGUgaW50ZXJmYWNlIGxpc3QsIEkgd291bGQg cHJvYmFibHkganVzdCBzYXkgdGhhdCB0aGUgaWRlbnRpZmllciAwIGlzIHJlc2VydmVkIGFuZCBp cyBpZ25vcmVkIHdoZW4gZG9pbmcgdGhlIGV4Y2x1c2lvbiBvZiBPSUZzLg0KPg0KPiBJIGFsc28g dGhpbmsgd2UgbmVlZCB0byBzYXkgdGhhdCB0aGUgb3JkZXIgYW5kIGlkZW50aWZpZXIgYXNzaWdu bWVudA0KPiBvZiBlbGVtZW50cyBvZiB0aGUgaW50ZXJmYWNlIGxpc3QgKHRoYXQgaXMsIHdoYXQg dGhlIHgtYml0IHZhbHVlcw0KPiBpbmRleA0KPiBpbnRvKSBpcyB1bmRlciB0aGUgbG9jYWwgY29u dHJvbCBvZiBOLCBidXQgaGFzIHRvIHJlbWFpbiBzdGFibGUgYXMNCj4gbG9uZyBhcyBTSURzIGFy ZSBhZHZlcnRpc2VkIHRoYXQgbGlzdCBtZW1iZXJzIG9mIHRoZSBsaXN0IGluIEFSRy4gIChUaGVy ZSBpcyBvdGhlcndpc2UgYSBncmVhdCBkZWFsIG9mIGZyZWVkb20gaW4gYXNzaWdubWVudCBzaW5j ZSB0aGUgdmFsdWVzIGFyZSBvbmx5IGNvbnN1bWVkIGJ5IHRoZSBub2RlIHRoYXQgYWR2ZXJ0aXNl cyB0aGVtLikgW1BDXSBUaGlzIHRleHQgaXMgdXBkYXRlZCBhcyBwYXJ0IG9mIEFsdmFyb+KAmXMg Y29tbWVudC4gQ2FuIHlvdSBwbGVhc2UgY2hlY2sgdGhlIGN1cnJlbnQgdGV4dCBpbiByZXYyMT8N Cg0KSSB0aGluayB0aGUgbmV3IHRleHQgaXMgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nIC0tIHRoZSBz dHJ1Y3R1cmUgb2YgdGhlIHZhbHVlIGlzIGVudGlyZWx5IGxvY2FsIHRvIHRoZSBTUiBFbmRwb2lu dCBhZHZlcnRpc2luZyBpdC4gIEkgd2lsbCBoYXZlIGFuIGVkaXRvcmlhbCBjb21tZW50IGluIG15 IHVwZGF0ZWQgYmFsbG90IHBvc2l0aW9uIGFib3V0IHRoZSAic2lnbmFsaW5nIG9mIHRoZSBhcmd1 bWVudCB0byBvdGhlciBub2Rlcy4uLiIgY2xhdXNlLCB0aG91Z2guDQoNCj4gU2VjdGlvbiA0LjEz DQo+DQo+IEl0J3MgcHJvYmFibHkgd29ydGggY2FsbGluZyBvdXQgdGhlIE1UVSBjb25zaWRlcmF0 aW9ucyBvZiBwdXNoaW5nIHRoZQ0KPiBuZXcgSVB2NiBoZWFkZXIrU1JIIGFuZCB0dW5uZWxpbmcg dGhlIHBhY2tldHMuICAoSSBrbm93IHdlIHJlZmVyZW5jZQ0KPiAyNDczIGFscmVhZHksIGJ1dCB0 aGUgTVRVIGlzIHByZXR0eSBpbXBvcnRhbnQuKSBbUENdIE1UVQ0KPiBjb25zaWRlcmF0aW9ucyBh cmUgY292ZXJlZCBpbiBSRkM4NzU0Lg0KPg0KPiAgICBTMTcuICBUaGUgUGF5bG9hZCBMZW5ndGgs IFRyYWZmaWMgQ2xhc3MgYW5kIE5leHQtSGVhZGVyIGZpZWxkcyBhcmUNCj4gICAgc2V0IGFzIHBl ciBbUkZDMjQ3M10uICBUaGUgRmxvdyBMYWJlbCBpcyBjb21wdXRlZCBhcyBwZXIgW1JGQzY0Mzdd Lg0KPg0KPiBIb3cgaXMgdGhlIEhvcCBMaW1pdCBzZXQgZm9yIHRoZSBvdXRlciBoZWFkZXI/DQo+ IChJIGFzc3VtZSDCpzYuMyBvZiBSRkMgMjQ3MywgYnV0IGdpdmVuIHRoYXQgeW91IHByb3ZpZGUg YSByZWZlcmVuY2UgZm9yDQo+IGFsbCB0aGUgb3RoZXIgZmllbGRzLCBpdCBzZWVtcyBsaWtlIGFu IG9taXNzaW9uIHRvIG5vdCBtZW50aW9uIEhvcCBMaW1pdCBhcyB3ZWxsLikgW1BDXSBTdXJlLCBh ZGRlZC4NCg0KW1RoYW5rcy4gSSdsbCBub3RlIHNvbWUgc2ltaWxhciByZWZlcmVuY2Ugbml0cyBy ZWdhcmRpbmcgwqc1LjEgaW4gbXkgdXBkYXRlZCBjb21tZW50c10NCg0KPiBTZWN0aW9uIDQuMTQN Cj4NCj4gICAgVGhlIFNSSCBNQVkgYmUgb21pdHRlZCB3aGVuIHRoZSBTUnY2IFBvbGljeSBvbmx5 IGNvbnRhaW5zIG9uZSBzZWdtZW50DQo+ICAgIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIHVzZSBh bnkgZmxhZywgdGFnIG9yIFRMVi4NCj4NCj4gSWYgdGhpcyBpcyB0aGUgY2FzZSBkb2VzIGl0IG1h dHRlciBpZiBJIHVzZSBFbmQuQjYuRW5jYXBzIG9yIEVuZC5CNi5FbmNhcHMuUmVkPw0KPiBbUENd IElmIHlvdSBvbmx5IGhhdmUgYSBzaW5nbGUgc2VnbWVudCwgdGhlbiBpdCBkb2VzIG5vdCBtYXR0 ZXIuIEhvd2V2ZXIgd2hlbiB5b3UgaGF2ZSBtb3JlIHRoYW4gb25lIHNlZ21lbnQgdGhlIGNoYW5n ZSBpcyBzaWduaWZpY2FudC4NCj4NCj4gU2VjdGlvbiA0LjE2DQo+DQo+IEkgZG9uJ3QgdGhpbmsg SSB1bmRlcnN0YW5kIHdoYXQgaXQgd291bGQgbWVhbiBmb3IgYSBzcGVjaWZpYyBTSUQgdG8gc3Vw cG9ydCB0aGUgbXVsdGlwbGUgZmxhdm9ycyAiaW4gY29tYmluYXRpb25zIi4NCj4gW1BDXSBDb252 b2x1dGVkIHNlbnRlbmNlIGluZGVlZC4NCj4gPE9MRD4NCj4gRm9yIGVhY2ggb2YgdGhlc2UNCj4g ICAgYmVoYXZpb3JzIHRoZXNlIGZsYXZvcnMgTUFZIGJlIHN1cHBvcnRlZCBmb3IgYSBTSUQgZWl0 aGVyDQo+ICAgIGluZGl2aWR1YWxseSBvciBpbiBjb21iaW5hdGlvbnMuDQo+IDwvT0xEPg0KPiA8 TkVXPg0KPiBUaGUgRW5kLCBFbmQuWCBvciBFbmQuVCBiZWhhdmlvcnMgY291bGQgc3VwcG9ydCB0 aGVzZSBmbGF2b3JzIGVpdGhlciBpbmRpdmlkdWFsbHkgb3IgaW4gY29tYmluYXRpb24uDQo+IDwv TkVXPg0KDQpNdWNoIGJldHRlcjsgdGhhbmtzISAgSXQgbWF5IGJlIGxlc3MgcmVsZXZhbnQgbm93 IHRoYXQgd2UgYXJlIGFzc2lnbmluZyBiZWhhdmlvciBjb2RlcG9pbnRzIGZvciBlYWNoIGZsYXZv ciBjb21iaW5hdGlvbiwgYnV0IElNTyB0aGUgVVNEIGZsYXZvciBmaXRzIG1vcmUgbmF0dXJhbGx5 IGludG8gYmVpbmcgInBhcnQgb2YgdGhlIG1haW4gYmVoYXZpb3IiLiAgRS5nLiwgd2UgaGF2ZQ0K RW5kLkRUNDYgYWxyZWFkeSwgYW5kIEknbSBub3Qgc3VyZSBob3cgdGhhdCAoYmVoYXZpb3IgY29k ZXBvaW50IDIwKSBkaWZmZXJzIGZyb20gRW5kLlQgd2l0aCBVU0QgKGJlaGF2aW9yIGNvZGVwb2lu dCAzNikuICBJIHRoaW5rIGl0J3MgZ2VuZXJhbGx5IGEgYmFkIGlkZWEgdG8gaGF2ZSBtdWx0aXBs ZSB3YXlzIG9mIGV4cHJlc3NpbmcgdGhlIHNhbWUgYmVoYXZpb3IuDQoNCltQQzJdIEVuZC5UIHdp dGggVVNEIGFuZCBFbmQuRFQ0NiBhcmUgdGhlIHNhbWUgb25seSB3aGVuIHRoZXkgYXJlIHRoZSBs YXN0IFNJRCBvZiB0aGUgU0lEIGxpc3QuIE5vdGUgdGhhdCB3aGVuIHRoZXkgYXJlIHVzZWQgYXMg aW50ZXJtZWRpYXRlIHNlZ21lbnQgdGhleSBkbyBkaWZmZXJlbnQgdGhpbmdzLiBJZiBFbmQuRFQ0 NiBpcyB1c2VkIGFzIGFuIGludGVybWVkaWF0ZSBzZWdtZW50IGluIHRoZSBzaWQgbGlzdCBpdCB3 aWxsIHJlc3VsdCBpbiBhbiBJQ01QIFBhcmFtZXRlciBQcm9ibGVtLiBJZiBFbmQuVCBpcyB1c2Vk IGFzIGFuIGludGVybWVkaWF0ZSBzZWdtZW50IHRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkLg0KDQo+ IFNlY3Rpb24gNC4xNi4xLjINCj4NCj4gICAgQSBwZW51bHRpbWF0ZSBTUiBTZWdtZW50IEVuZHBv aW50IE5vZGUgaXMgb25lIHRoYXQsIGFzIHBhcnQgb2YgdGhlDQo+ICAgIFNJRCBwcm9jZXNzaW5n LCBjb3BpZXMgdGhlIGxhc3QgU0lEIGZyb20gdGhlIFNSSCBpbnRvIHRoZSBJUHY2DQo+ICAgIERl c3RpbmF0aW9uIEFkZHJlc3MgYW5kIGRlY3JlbWVudHMgU2VnbWVudHMgTGVmdCB2YWx1ZSBmcm9t IG9uZSB0bw0KPiAgICB6ZXJvLg0KPg0KPiBJIHRoaW5rIHRlY2huaWNhbGx5IGl0IGNvcGllcyB0 aGUgZmlyc3QgU0lEIGZyb20gdGhlIFNSSCAoU1JILlNlZ21lbnQgTGlzdFswXSksIHdoaWNoIGlz IHRoZSBsYXN0IFNJRCBmcm9tIHRoZSBTUiBQb2xpY3kuDQo+IFtQQ10gUkZDODc1NCB1c2VzIHRo ZSB0ZXJtIOKAnGxhc3QgU0lE4oCdIHRvIHJlZmVyIHRvIFNSSC5TZWdtZW50TGlzdFswXS4gUGxl YXNlIHJlZmVyIFJGQzg3NTQgU2VjIDYuMSBmb3IgZGV0YWlscy4NCj4gQWxzbywgbml0OiAidGhl IiBmb3IgInRoZSBTZWdtZW50cyBMZWZ0IHZhbHVlIi4NCj4gW1BDXSBBY2suIENvcnJlY3RlZC4N Cj4NCj4gIFMxNC4yLiAgICAgIFVwZGF0ZSB0aGUgTmV4dCBIZWFkZXIgZmllbGQgaW4gdGhlIHBy ZWNlZGluZyBoZWFkZXIgdG8gdGhlDQo+ICAgICAgICAgICAgICAgICBOZXh0IEhlYWRlciB2YWx1 ZSBvZiB0aGUgU1JIDQo+DQo+IG5pdDogcGVyc29uYWxseSwgSSB3b3VsZCB3cml0ZSAiZnJvbSB0 aGUgU1JIIiwgc2luY2UgIm5leHQgaGVhZGVyIHZhbHVlIG9mIHRoZSBTUkgiIGlzIHZlcnkgY2xv c2UgdG8gIm5leHQgaGVhZGVyIHZhbHVlIG9mIFNSSCIsIGkuZS4sIDQzLg0KPiBbUENdIFJlYWRz IGJldHRlciBpbmRlZWQuIENvcnJlY3RlZC4NCj4NCj4gICAgQXMgYSByZW1pbmRlciwgW1JGQzg3 NTRdIGRlZmluZXMgaW4gc2VjdGlvbiA1IHRoZSBTUiBEZXBsb3ltZW50IE1vZGVsDQo+ICAgIHdp dGhpbiB0aGUgU1IgRG9tYWluIFtSRkM4NDAyXS4gIFdpdGhpbiB0aGlzIGZyYW1ld29yaywgdGhl DQo+ICAgIEF1dGhlbnRpY2F0aW9uIEhlYWRlciAoQUgpIGlzIG5vdCB1c2VkIHRvIHNlY3VyZSB0 aGUgU1JIIGFzIGRlc2NyaWJlZA0KPiAgICBpbiBTZWN0aW9uIDcuNSBvZiBbUkZDODc1NF0uDQo+ DQo+IEkgc3Ryb25nbHkgcmVjb21tZW5kIGFkZGluZyBhbm90aGVyIHNlbnRlbmNlIGNsYXJpZnlp bmcgd2h5IHRoaXMgaXMgcmVsZXZhbnQgdG8gZGlzY3Vzc2lvbiBvZiByZW1vdmluZyBhbiBleHRl bnNpb24gaGVhZGVyIGZyb20gdGhlIHBhY2tldC4NCj4gW1BDXSBJIHN1Z2dlc3QgdGhhdCBpcyBu b3QgcmVsZXZhbnQgdG8gdGhlIGRpc2N1c3Npb24gb2YgUFNQIHNpbmNlIEFIIGlzIG5vdCBkZWZp bmVkIGZvciB0aGUgU1JILg0KDQpXZSBzaG91bGQgZXhwbGFpbiB3aHkgd2UgYXJlIHNheWluZyBh bnl0aGluZyBhdCBhbGwgYWJvdXQgQUguICBSaWdodCBub3cgaXQgc291bmRzIGxpa2UgYW4gaXJy ZWxldmFudCBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZWRpdGVk IG91dCBvZiB0aGUgZG9jdW1lbnQsIGJ1dCBpdCBhY3R1YWxseSBpcyBxdWl0ZSBpbXBvcnRhbnQg aW4gYXR0ZW1wdGluZyB0byBqdXN0aWZ5IHRoZSBkZXNpZ24gZGVjaXNpb24gb2YgYWxsb3dpbmcg UFNQIQ0KDQpbUEMyXSBBY3R1YWxseSwgaXQgd2FzIGEgcmVxdWVzdGVkIGNsYXJpZmljYXRpb24g dG8gYmUgYWRkZWQgdG8gY29udmV5IHRoYXQgQUggbm90IGJlaW5nIHNwZWNpZmllZCBhbmQgdXNl ZCBmb3Igc2VjdXJpbmcgU1JIIHJlc3VsdHMgaW4gdGhlcmUgbm90IGJlaW5nIGFueSBpc3N1ZSB3 aXRoIEFIIHdoZW4gZG9pbmcgUFNQLg0KDQo+IFNlY3Rpb24gNQ0KPg0KPiAgICBUaGlzIGxpc3Qg Y2FuIGJlIGV4cGFuZGVkIGluIGNhc2UgYW55IG5ldyBmdW5jdGlvbmFsaXR5IHJlcXVpcmVzIGl0 Lg0KPg0KPiBIb3c/ICBCeSBhbiBSRkMgdGhhdCBVcGRhdGVzOiB0aGlzIG9uZT8NCj4gW1BDXSBO ZXcgZnVuY3Rpb25hbGl0eSB3b3VsZCBoYXZlIHRvIGJlIGludHJvZHVjZWQgdmlhIGEgbmV3IGRv Y3VtZW50IGJ1dCBpdCBkb2VzIG5vdCBoYXZlIHRvIHVwZGF0ZSB0aGlzIG9uZSBzaW5jZSBpdCBp cyBub3QgbW9kaWZ5aW5nIHdoYXQgaXMgaW4gdGhpcyBkb2N1bWVudCBidXQgYWRkaW5nIHNvbWV0 aGluZyBuZXcuDQo+IFdlIGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBhcyBzL1RoaXMgbGlzdCBjYW4g YmUgZXhwYW5kZWQgaW4gY2FzZSBhbnkgbmV3IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZXMgaXQvVGhp cyBsaXN0IGlzIG5vdCBleGhhdXN0aXZlIGFuZCBmdXR1cmUgZG9jdW1lbnRzIG1heSBkZWZpbmUg YWRkaXRpb25hbCBiZWhhdmlvcnMuDQoNClRoYW5rcy4NCg0KPiBTZWN0aW9uIDUueA0KPg0KPiBJ IGFncmVlIHdpdGggdGhlIGRpcmVjdG9yYXRlIHJldmlld2VyIHRoYXQgdGhlIHByb3RvY29sIGJl aGF2aW9yIHNob3VsZCBiZSB3cml0dGVuIG91dCBleHBsaWNpdGx5LCB3aXRob3V0IHJlZmVyZW5j ZSB0byB0aGUgaGFuZGxpbmcgb2YgZXhhbXBsZSBwYWNrZXQocykuDQo+IFtQQ10gVGhlcmUgaXMg YWxyZWFkeSBwc2V1ZG9jb2RlIGFuZCBkZXNjcmlwdGlvbnMgaW4gdGhlc2Ugc2VjdGlvbnMgdGhh dCBkZXNjcmliZXMgdGhlIGJlaGF2aW9yLiBFeGFtcGxlcyBhcmUgdG8gaGVscCB1bmRlcnN0YW5k aW5nLiBDYW4geW91IGNsYXJpZnkgd2hhdCBtb3JlIGlzIHJlcXVpcmVkPw0KDQpUaGUgcHNldWRv Y29kZSBoYXJkY29kZXMgdGhhdCB0aGUgc2VnbWVudCBsaXN0IGlzIChTMywgUzIsIFMxOyBTTD0y KSwgd2hpY2ggaXMganVzdCBhbiBleGFtcGxlIG9mIHdoYXQgdGhlIFNSSCBjb3VsZCBiZS4gIEl0 J3Mgbm90IHRydWx5IGdlbmVyaWMgcHNldWRvY29kZS4NCg0KW1BDMl0gQWdyZWVkLiBJ4oCZdmUg cmVtb3ZlZCB0aGUg4oCcKFMzLCBTMiwgUzE7IFNMPTIpIGZyb20gdGhlIHBzZXVkb2NvZGUuIEl0 cyBzcGVjaWZpYyB0byB0aGUgZXhhbXBsZSwgYW5kIGl0IGRvZXMgbm90IGJyaW5nIGFueSB2YWx1 ZSAodGhlIGVuY29kaW5nIG9mIHRoZSBTUkggaXMgYWxyZWFkeSBkZWZpbmVkIGluIFJGQzg3NTQp Lg0KDQpBbHNvLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdyZWF0IGlmIDUuMiwgNS4zLCBhbmQgNS40 IGNvdWxkIGRvIHRoZSBzb3J0IG9mIHRoaW5nIHdlIGRpZCBmb3IgdGhlIGVuZHBvaXRuIGJlaGF2 aW9ycyB3aGVyZSBpdCByZXBsYWNlcyB0aGUgZGVmaW5pdGlvbiBvZiBvbmUgb3IgbW9yZSBvZiB0 aGUgbnVtYmVyZWQgcHNldWRvY29kZSBzdGVwcy4gIChJIGRvbid0IHRoaW5rIHdlIGNhbiwgcmln aHQgbm93LCBzaW5jZSB0aGUgbnVtYmVyZWQgcHNldWRvY29kZSBkb2Vzbid0IGNvdmVyIGFsbCB0 aGUgcmVsZXZhbnQgcGFydHMgdGhhdCBhcmUgY2hhbmdpbmcsIGFuZCBJIGRpZG4ndCB0aGluayBh Ym91dCBob3cgaGFyZCBpdCB3b3VsZCBiZSB0byBjaGFuZ2UgdGhlIHBzZXVkb2NvZGUgdG8gbWFr ZSB0aGF0IHRoZSBjYXNlLg0KDQo+IFNlY3Rpb24gNS4xDQo+DQo+ICAgIFMwMy4gICBTZXQgb3V0 ZXIgcGF5bG9hZCBsZW5ndGgsIHRyYWZmaWMgY2xhc3MgYW5kIGZsb3cgbGFiZWwNCj4NCj4gV2hh dCBhYm91dCB0aGUgb3V0ZXIgSG9wIExpbWl0Pw0KPiBbUENdIEFkZGVkLg0KPg0KPiAgICBTMDM6 IEFzIGRlc2NyaWJlZCBpbiBbUkZDNjQzN10gKElQdjYgRmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9u KQ0KPg0KPiBXaHkgaXMgdGhpcyBhbGwgdGhlIHdheSBhdCB0aGUgYm90dG9tIG9mIHRoZSBzZWN0 aW9uIGluc3RlYWQgb2YgaW5jbHVkZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBjb250ZW50Pw0K PiBbUENdIEFjay4gQnJvdWdodCB1cC4NCj4NCj4gU2VjdGlvbiA1LjMNCj4NCj4gICAgVGhlIGVu Y2Fwc3VsYXRpbmcgbm9kZSBNVVNUIHJlbW92ZSB0aGUgcHJlYW1ibGUgb3IgZnJhbWUgY2hlY2sN Cj4gICAgc2VxdWVuY2UgKEZDUykgZnJvbSB0aGUgRXRoZXJuZXQgZnJhbWUgdXBvbiBlbmNhcHN1 bGF0aW9uIGFuZCB0aGUNCj4gICAgZGVjYXBzdWxhdGluZyBub2RlIE1VU1QgcmVnZW5lcmF0ZSB0 aGUgcHJlYW1ibGUgb3IgRkNTIGJlZm9yZQ0KPiAgICBmb3J3YXJkaW5nIEV0aGVybmV0IGZyYW1l Lg0KPg0KPiAib3IiPyAgSSBnZXQgdG8gY2hvb3NlIG9uZSBvciB0aGUgb3RoZXI/ICBJdCdzIG9r YXkgdG8gb25seSBwdXQgYmFjayBhIHByZWFtYmxlIGJ1dCBubyBGQ1MgKG9yIHZpY2UgdmVyc2Ep Pw0KPiBbUENdIEdvb2QgY2F0Y2guIHMvb3IvYW5kOyBhbHNvIHByZWFtYmxlIHJlbW92ZWQgb25s eSBpZiBwcmVzZW50DQo+DQo+IFNlY3Rpb24gNg0KPg0KPiAgICB0cmFmZmljIHRoYXQgbWF0Y2hl ZCB0aGF0IFNJRCBhbmQgd2FzIHByb2Nlc3NlZCBjb3JyZWN0bHkuICBUaGUNCj4gICAgcmV0cmll dmFsIG9mIHRoZXNlIGNvdW50ZXJzIHZpYSBNSUIsIE5FVENPTkYvWUFORyBvciBhbnkgb3RoZXIg bWVhbnMNCj4gICAgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4g KGVkaXRvcmlhbCkgYSBNSUIgaXMgYW4gYWJzdHJhY3QgZGF0YSBzdHJ1Y3R1cmUgKGxpa2V3aXNl IGEgWUFORyBtb2R1bGUpOyBpbmZvcm1hdGlvbiBtaWdodCBiZSByZXRyaWV2ZWQgKmZyb20qIGl0 IGJ1dCBub3QgKnZpYSogaXQuICBGb3IgKnZpYSosIHRoYXQgd291bGQgYmUgU05NUCwgTkVUQ09O RiwgYW5kL29yIFJFU1RDT05GLg0KPiBbUENdIEZpeGVkLg0KPg0KPiBTZWN0aW9uIDguMQ0KPg0K PiBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gcmVmZXJlbmNlIFJGQ3MgODQ5MSwgODQ3NiwgODg0MSwg ZXRjLiBmb3IgYWR2ZXJ0aXNpbmcgTVNEIHZpYSBJR1A/DQo+IFtQQ10gSSB3b3VsZCBsZWF2ZSB0 aGF0IHVwIHRvIHRoZSBzcnY2IGNvbnRyb2wgcGxhbmUgZHJhZnRzOyBidXQgbm8gc3Ryb25nIHBy ZWZlcmVuY2UuDQo+DQo+ICAgIEluIHBhcnRpY3VsYXIsIHRoZSBTUiBzb3VyY2UgKGUuZy4sIEgu RW5jYXBzKSwgaW50ZXJtZWRpYXRlIGVuZHBvaW50DQo+ICAgIChlLmcuLCBFbmQsIEVuZC5YKSBh bmQgZmluYWwgZW5kcG9pbnQgKGUuZy4sIEVuZC5EWDQsIEVuZC5EVDYpDQo+ICAgIGJlaGF2aW9y cy4gIFsuLi5dDQo+DQo+IFRoaXMgaXMgbm90IGEgY29tcGxldGUgc2VudGVuY2UsIGFuZCBJIHJl YWxseSBoYXZlIG5vIGlkZWEgd2hhdCB2ZXJiIHdhcyBpbnRlbmRlZC4NCj4gW1BDXSBJbmRlZWQs IGZpeGVkIGluIHJldjIxLg0KPg0KPiBTZWN0aW9uIDguMiwgOC4zDQo+DQo+IENhbiB3ZSBnZXQg cmVmZXJlbmNlcyBmb3IgdGhlIEJHUCB2YXJpYW50cyBoZXJlIGFuZCB0aGVpciB1c2FnZSBmb3Ig c2lnbmFsaW5nIFNSdjYgY2FwYWJpbGl0aWVzIGFuZCAoU0lELGJlaGF2aW9yIGNvZGVwb2ludCkg cGFpcnM/DQo+IFtQQ10gVGhlIHJlZmVyZW5jZXMgdG8gdGhlIEJHUCBmZWF0dXJlcyBoYXZlIGFs cmVhZHkgYmVlbiBwcm92aWRlZCBpbiB0aGUgcmVzcGVjdGl2ZSBzZWN0aW9ucyB3aGVyZSB0aGVz ZSBiZWhhdmlvcnMgYXJlIHNwZWNpZmllZC4gVGhlcmUgYXJlIFdHIGRyYWZ0cyBpbiBwcm9ncmVz cyBmb3IgU1J2NiBleHRlbnNpb25zIHRvIHJvdXRpbmcgcHJvdG9jb2xzIChub3QganVzdCBCR1Ap IHRoYXQgbm9ybWF0aXZlbHkgcmVmZXJlbmNlIHRoaXMgZG9jdW1lbnQuIFRoZXJlIHVzZWQgdG8g YmUgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB0aGUgb3RoZXIgd2F5IGFyb3VuZCBmcm9tIHRoaXMg ZG9jdW1lbnQgd2hpY2ggd2VyZSByZW1vdmVkIGR1cmluZyBXR0xDIGJhc2VkIG9uIGZlZWRiYWNr LiBXZSBjYW4gYWRkIHRoZW0gYmFjayBpZiB0aGF0IG1ha2VzIHNlbnNlIGZvciB0aGUgSUVTRy4N Cg0KSSB0aGluayB0aGF0IHRob3NlIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgd291bGQgYmUgaGVs cGZ1bCwgYnV0IEkgYWxzbyBkb24ndCBrbm93IGhvdyBzdHJvbmcgdGhlIFdHIGNvbnNlbnN1cyB3 YXMgdG8gcmVtb3ZlIHRoZW0gKG9yIHdoYXQgcmVhc29uaW5nIHdhcyBvZmZlcmVkIGZvciBkb2lu ZyBzbykuDQoNCltQQzJdIEnigJlsbCBsZWF2ZSBpdCB1cCB0byBNYXJ0aW4gKHJlc3BvbnNpYmxl IEFEKS4NCk9uIGEgc2VwYXJhdGUgbm90ZSwgb24gOC4zIEnigJl2ZSBhbHNvIGFkZGVkIHRoZSBu b3RlIG9uIHRoZSBPcGFxdWUgYXMgZGlzY3Vzc2VkLg0KPE5FVz4NCkluIHNvbWUgc2NlbmFyaW9z LCBhbiBlZ3Jlc3MgUEUgYWR2ZXJ0aXNpbmcgYSBWUE4gcm91dGUgbWlnaHQgd2lzaCB0byBhYnN0 cmFjdCB0aGUgc3BlY2lmaWMgYmVoYXZpb3IgYm91bmQgdG8gdGhlIFNJRCBmcm9tIHRoZSBpbmdy ZXNzIFBFIGFuZCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrLiBJbiBzdWNoIGNhc2UsIHRo ZSBTSUQgbWF5IGJlIGFkdmVydGlzZWQgdXNpbmcgdGhlIE9wYXF1ZSBTUnY2IEVuZHBvaW50IEJl aGF2aW9yIGNvZGVwb2ludCBkZWZpbmVkIGluIFtTZWN0aW9uIDEwLjIuMV0uIFRoZSBkZXRhaWxz IG9mIHN1Y2ggY29udHJvbCBwbGFuZSBzaWduYWxpbmcgbWVjaGFuaXNtcyBhcmUgb3V0IG9mIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPC9ORVc+DQoNCj4gU2VjdGlvbiA5DQo+DQo+IEkg d291bGQgcmVhbGx5IGxpa2UgdG8gaGF2ZSBhIHN0cm9uZ2VyIHJlZmVyZW5jZSB0byBTZWN0aW9u IDUgb2YgUkZDDQo+IDg3NTQgd2hlcmUgdGhlIGNvbmNlcHR1YWwgbW9kZWwgb2YgYSBTUiBEb21h aW4gYXMgYSBzaW5nbGUgc3lzdGVtLCB3aGVyZSBhbGwgcGFja2V0cyBpbiB0aGUgZG9tYWluIGFy ZSBlbmNhcHN1bGF0ZWQgdXNpbmcgSVB2NiBoZWFkZXJzIFt3aXRoIFNJRHMgYXMgU0EvREFdLiAg VGhlIHBhcnQgaW4gYnJhY2tldHMgaXMgbm90IHNwZWxsZWQgb3V0IHZlcnkgY2xlYXJseSBhbmQg Y291bGQgd2VsbCBiZSBleHBvdW5kZWQgdXBvbiBpbiB0aGlzIGRvY3VtZW50LiAgSSBjYW4gd3Jp dGUgdXAgc29tZSAodmVyeSBhZCBob2MpIGlkZWFzIGZvciB3aGF0IEkgaGFkIGluIG1pbmQsIHdo aWNoIHlvdSBhcmUgd2VsY29tZSB0byBhZG9wdCBidXQgZXhwZWN0ZWQgdG8gd29yZHNtaXRoL2Vk aXQgYXBwcm9wcmlhdGVseToNCj4NCj4gJSBTZWN0aW9uIDUgb2YgW1JGQzg3NTRdIGRlc2NyaWJl cyB0aGUgU1IgZGVwbG95bWVudCBtb2RlbCBhbmQgdGhlICUgYmFzZWxpbmUgcmVxdWlyZW1lbnRz IGZvciBzZWN1cmluZyB0aGUgU1IgRG9tYWluLiAgSW4gbWFueSB3YXlzIHRoZSBTUiAlIERvbWFp biBpcyBhbmFsb2dvdXMgdG8gYW4gTVBMUyBkb21haW4gLS0gaXQncyBhIHRpZ2h0bHkgY29udHJv bGxlZCAlIHN5c3RlbSB3aGVyZSBwYWNrZXQgcHJvY2Vzc2luZyBpcyBjb250cm9sbGVkIGJ5IGEg bGlzdCAob3Igc3RhY2spIG9mICUgb3BhcXVlIGlkZW50aWZpZXJzIHRoYXQsIGJ5IGFuZCBsYXJn ZSwgb25seSBoYXZlIGRlZmluZWQgc2VtYW50aWNzIGluICUgdGhlIGNvbnRleHQgb2YgdGhlIG5v ZGUgdGhhdCByZWNlaXZlcyBhbmQgcHJvY2Vzc2VzIHRoZSBwYWNrZXQgd2hlbiAlIHRoYXQgaWRl bnRpZmllciBpcyAidG9wbW9zdCIgb3IgImN1cnJlbnQiLiAgRXhwZXJpZW5jZSBpbiBzZWN1cmlu ZyBhbmQgJSBvcGVyYXRpbmcgTVBMUyBkb21haW5zIHNob3VsZCBiZSByZWFkaWx5IHRyYW5zZmVy cmFibGUgdG8gU1J2NiAlIGRvbWFpbnMsIGluIGVuc3VyaW5nIHRoYXQgYWxsIHRyYWZmaWMgd2l0 aGluIHRoZSBuZXR3b3JrIGlzIHRpZ2h0bHkgJSBjb250cm9sbGVkLCB3aXRoIGFsbCBleHRlcm5h bCBpbnB1dHMgYmVpbmcgcHJvcGVybHkgZW5jYXBzdWxhdGVkIChmb3IgJSBTUnY2LCBieSBhbiBJ UHY2IGhlYWRlciB1c3VhbGx5IHdpdGggU1JIOyBmb3IgTVBMUywgYnkgdGhlIGxhYmVsICUgc3Rh Y2spLiAgVGhlIGRlZGljYXRlZCBmb3JtYXQgZm9yIHRoZSBNUExTIGxhYmVsIHN0YWNrIGFuZCBs YWJlbCAlIGlkZW50aWZpZXJzIG1ha2VzIGEgY2xlYXIgbWVjaGFuaWNhbCBzZXBhcmF0aW9uIGJl dHdlZW4gImludGVybmFsIiBhbmQgJSAiZXh0ZXJuYWwiIGlkZW50aWZpZXJzLiBJbiBjb250cmFz dCwgU1J2NiB1c2VzIFNJRHMgZm9yIHRoZSBpbnRlcm5hbCAlIGlkZW50aWZpZXJzLCB3aGljaCBo YXZlIGZvcm1hdCBhbmQgb3BlcmF0aW9uIG9mIElQdjYgYWRkcmVzc2VzLiAgV2hpbGUgJSB0aGlz IGxldHMgU1J2NiBiZW5lZml0IGZyb20gSVAgbG9uZ2VzdC1wcmVmaXggcm91dGluZyBhbmQgdGh1 cyB0aGUgJSBzdHJ1Y3R1cmUgb2YgU0lEIHZhbHVlcywgaXQgYWxzbyBtZWFucyB0aGF0IHRoZXJl IGlzIG5vdCBhIGNyaXNwICUgbWVjaGFuaWNhbCBzZXBhcmF0aW9uIGJldHdlZW4gImludGVybmFs IiBhbmQgImV4dGVybmFsIiBpZGVudGlmaWVycy4NCj4gJSBBcyBzdWNoLCBjYXJlIGFuZCByaWdv ciBpbiBhbm5vdGF0aW5nIHdoaWNoIElQdjYgYWRkcmVzc2VzL2hlYWRlcnMgYXJlICUgaW50ZXJu YWwgdnMgZXh0ZXJuYWwgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gbWFpbnRhaW4gdGhlIGludGVn cml0eSAlIGFuZCBzZWN1cml0eSBvZiB0aGUgU1J2NiBkb21haW4uDQo+DQo+IFtQQ10gVGhhbmtz IGZvciB5b3VyIHN1Z2dlc3Rpb25zLiBJbmRlZWQgd2Ugc2hvdWxkIHVwZGF0ZSB0aGUgZHJhZnQg d2l0aCBzb21ldGhpbmcgYWxvbmcgdGhvc2UgbGluZXMuDQo+IFRoZSBjb21wYXJpc29uIG9yIGVx dWl2YWxlbmNlIHRvIE1QTFMgaXMgbGlrZWx5IGdvaW5nIHRvIGJlIGNvbmZ1c2luZyBhbmQgaGVu Y2Ugd2UgYXZvaWQgZ29pbmcgZG93biB0aGF0IHBhdGguIFdlIHdlcmUgdGhpbmtpbmcgb24gc29t ZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZy4NCj4gUGxlYXNlIGxldCBtZSBrbm93IG9mIHdoYXQg eW91IHRoaW5rLiAoSSBoYXZlIG5vdCBwdXNoZWQgdGhpcyBpbnRvIHRoZSBkcmFmdCB5ZXQpLg0K Pg0KPiA8UHJvcG9zYWw+DQoNCltyZS13cmFwcGVkIGZvciBlYXNlIG9mIGlubGluZSBjb21tZW50 aW5nXQ0KDQpUaGF0IHNhaWQsIEkgYW0ganVzdCBvZmZlcmluZyBlZGl0b3JpYWwgc3VnZ2VzdGlv bnM7IEkgcmVhbGx5IGxpa2Ugd2hhdCB5b3UgY2FtZSB1cCB3aXRoIC0tIHRoYW5rIHlvdSENCg0K PiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgU2VnbWVudCBSb3V0aW5nIGFyZSBk aXNjdXNzZWQgaW4NCj4gICBbUkZDODQwMl0uIFNlY3Rpb24gNSBvZiBbUkZDODc1NF0gZGVzY3Jp YmVzIHRoZSBTUiBEZXBsb3ltZW50IE1vZGVsIGFuZA0KPiAgIHRoZSByZXF1aXJlbWVudHMgZm9y IHNlY3VyaW5nIHRoZSBTUiBEb21haW4uIFRoZSBzZWN1cml0eQ0KPiAgIGNvbnNpZGVyYXRpb25z IG9mIFtSRkM4NzU0XSBhbHNvIGNvdmVyIGFzcGVjdHMgc3VjaCBhcyBhdHRhY2sNCj4gdmVjdG9y cw0KDQpuaXQ6IEknZCBjb25zaWRlciBzL2FzcGVjdHMvdG9waWNzLyBidXQgaXQncyBhIGJpdCBv ZiBhIGp1ZGdtZW50IGNhbGwNCltQQzJdIENoYW5nZWQuDQoNCj4gICBhbmQgdGhlaXIgbWl0aWdh dGlvbiBtZWNoYW5pc21zIHRoYXQgYWxzbyBhcHBseSB0byB0aGUgYmVoYXZpb3JzDQo+ICAgaW50 cm9kdWNlZCBpbiB0aGlzIGRvY3VtZW50LiBUb2dldGhlciwgdGhleSBkZXNjcmliZSB0aGUgcmVx dWlyZWQNCj4gICBzZWN1cml0eSBtZWNoYW5pc21zIHRoYXQgYWxsb3cgZXN0YWJsaXNobWVudCBv ZiBhbiBTUiBkb21haW4gb2YNCj4gdHJ1c3QNCg0KSSB3b3VsZCBlbmQgdGhlIHNlbnRlbmNlIGhl cmUsIGFmdGVyICJTUiBkb21haW4gb2YgdHJ1c3QiLiAgVGhlbiB3ZSBjb3VsZCBjb250aW51ZSBv biBhcyAiSGF2aW5nIHN1Y2ggYSB3ZWxsLWRlZmluZWQgdHJ1c3QgYm91bmRhcnkgaXMgbmVjZXNz YXJ5IGluIG9yZGVyIHRvIG9wZXJhdGUgWy4uLl0iDQpbUEMyXSBDaGFuZ2VkLiBUaGFua3MuDQoN Cj4gICB0byBvcGVyYXRlIFNSdjYtYmFzZWQgc2VydmljZXMgZm9yIGludGVybmFsIHRyYWZmaWMg d2hpbGUgcHJldmVudGluZw0KPiAgIGFueSAgIGV4dGVybmFsIHRyYWZmaWMgZnJvbSBhY2Nlc3Np bmcgb3IgZXhwbG9pdGluZyB0aGUgU1J2Ni1iYXNlZA0KPiAgIHNlcnZpY2VzLiAgQ2FyZSBhbmQg cmlnb3IgaW4gSVB2NiBhZGRyZXNzIGFsbG9jYXRpb24gZm9yIHVzZSBmb3IgU1J2Ng0KPiAgIFNJ RCBhbGxvY2F0aW9ucyBhbmQgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhZGRyZXNzZXMgdG8gYmUg c2VwYXJhdGUNCj4gICBmcm9tIElQdjYgYWRkcmVzc2VzIGFsbG9jYXRlZCBmb3IgZW5kLXVzZXJz L3N5c3RlbXMgKGFzIGlsbHVzdHJhdGVkIGluDQo+ICAgU2VjdGlvbiA1LjEgb2YgW1JGQzg3NTRd KSBoZWxwIGRpZmZlcmVudGlhdGUgaW50ZXJuYWwgdnMgZXh0ZXJuYWwNCj4gICBhZGRyZXNzIHNw YWNlIHRoYXQgaXMgcmVxdWlyZWQgdG8gbWFpbnRhaW4gdGhlIGludGVncml0eSBhbmQgc2VjdXJp dHkNCj4gICBvZiB0aGUgU1J2NiBEb21haW4uIEFkZGl0aW9uYWxseSwgW1JGQzg3NTRdIGRlZmlu ZXMgYW4gSE1BQyBUTFYNCg0KVGhpcyBzZW50ZW5jZSBnb3QgYSBiaXQgY29udm9sdXRlZCBhbmQg bWF5YmUgYSBiaXQgbG9uZy4gIEkgcHJvcG9zZSAob25seSBoZWxwaW5nIHdpdGggdGhlICJjb252 b2x1dGVkIiBidXQgbm90IHRoZSAibG9uZyIgcGFydCk6DQoNCiUgQ2FyZSBhbmQgcmlnb3IgaW4g SVB2NiBhZGRyZXNzIGFsbG9jYXRpb24gZm9yIHVzZSBmb3IgU1J2NiBTSUQgJSBhbGxvY2F0aW9u cyBhbmQgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhZGRyZXNzZXMsIGFzIGRpc3RpbmN0IGZyb20g SVB2NiAlIGFkZHJlc3NlcyBhbGxvY2F0ZWQgZm9yIGVuZC11c2Vycy9zeXN0ZW1zIChhcyBpbGx1 c3RyYXRlZCBpbiBTZWN0aW9uIDUuMSAlIG9mIFtSRkM4NzU0XSksIGNhbiBwcm92aWRlIHRoZSBj bGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIGludGVybmFsIGFuZCAlIGV4dGVybmFsIGFkZHJlc3Mg c3BhY2UgdGhhdCBpcyByZXF1aXJlZCB0byBtYWludGFpbiB0aGUgaW50ZWdyaXR5IGFuZCAlIHNl Y3VyaXR5IG9mIHRoZSBTUnY2IERvbWFpbi4NCltQQzJdIENoYW5nZWQuIFRoYW5rcy4NCg0KPiAg IHBlcm1pdHRpbmcgU1IgRW5kcG9pbnQgTm9kZXMgaW4gdGhlIFNSIGRvbWFpbiB0byB2ZXJpZnkg dGhhdCB0aGUgU1JIDQo+ICAgYXBwbGllZCB0byBhIHBhY2tldCB3YXMgc2VsZWN0ZWQgYnkgYW4g YXV0aG9yaXplZCBwYXJ0eSBhbmQgdG8gZW5zdXJlDQo+ICAgdGhhdCB0aGUgc2VnbWVudCBsaXN0 IGlzIG5vdCBtb2RpZmllZCBhZnRlciBnZW5lcmF0aW9uLCByZWdhcmRsZXNzIG9mDQo+ICAgdGhl IG51bWJlciBvZiBzZWdtZW50cyBpbiB0aGUgc2VnbWVudCBsaXN0LiAgV2hlbiBlbmFibGVkIGJ5 IGxvY2FsDQo+ICAgY29uZmlndXJhdGlvbiwgSE1BQyBwcm9jZXNzaW5nIG9jY3VycyBhdCB0aGUg YmVnaW5uaW5nIG9mIFNSSA0KPiAgIHByb2Nlc3NpbmcgYXMgZGVmaW5lZCBpbiBbUkZDODc1NF0g U2VjdGlvbiAyLjEuMi4xLg0KPg0KPiBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgU1J2NiBFbmRw b2ludCBhbmQgU1IgUG9saWN5IEhlYWRlbmQgICBiZWhhdmlvcnMNCj4gZm9yIGltcGxlbWVudGF0 aW9uIG9uIFNSdjYgY2FwYWJsZSBub2RlcyBpbiB0aGUgbmV0d29yay4gICBBcyBzdWNoLCB0aGlz DQo+IGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5ICAgY29uc2lk ZXJhdGlvbnMuDQo+IDwvUHJvcG9zYWw+DQoNCkknbSBsZXNzIHN1cmUgdGhhdCB3ZSB3YW50IHRv IGtlZXAgdGhlICJubyBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMiDQp0ZXh0LiAgSSBoYXZl IGEgZmV3IG5vdGVzIHN0YWdlZCBpbiBteSB1cGRhdGVkIGJhbGxvdCBjb21tZW50cywgYnV0IG9u ZSBub3Rld29ydGh5IHRoaW5nIHRoYXQgY29tZXMgdG8gbWluZCBpcyB0aGF0IFBTUCBwcmV2ZW50 cyB0aGUgZWdyZXNzIG5vZGUgZnJvbSB2YWxpZGF0aW5nIHRoZSBITUFDIFRMVi4NCg0KW1BDMl0g SWYgeW91IHdvdWxkIGxpa2UgdG8gdXNlIHRoZSBITUFDIFRMViB0aGVuIHdoeSB3b3VsZCB0aGUg c291cmNlIGNob29zZSB0byB1c2UgYSBQU1AtZmxhdm9yZWQgU0lEPyBUaGUgU1IgUG9saWN5IGNv bXB1dGF0aW9uIGlzIGF3YXJlIG9mIHRoaXMgYW5kIHRha2VzIGl0IGludG8gYWNjb3VudCB1cG9u IGRvaW5nIHBhdGggY29tcHV0YXRpb24uIE5vdGUgdGhhdCBpbiByZXYyNCB3ZSBhZGRlZCB0aGlz IHRleHQgYXMgd2VsbDoNCjxxdW90ZT4NCiAgIFRoZSBoZWFkZW5kIHBvbGljeSBkZWZpbml0aW9u IHNob3VsZCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHNwZWNpZmljDQogICBiZWhhdmlvciB1c2Vk IGFuZCBhbnkgbG9jYWwgY29uZmlndXJhdGlvbiAoYXMgc3BlY2lmaWVkIGluDQogICBTZWN0aW9u IDQuMS4xKS4NCjwvcXVvdGU+DQoNCj4gVGhlcmUgbWlnaHQgYWxzbyBiZSByb29tIGZvciBkaXNj dXNzaW9uIChpbiB0aGUgbWFpbiBib2R5IG9mIHRoZQ0KPiBkb2N1bWVudCkgb2YgaG93IHRoZSB2 YXJpb3VzIGRlY2Fwc3VsYXRpb24gcHJvY2VkdXJlcyBvY2N1ciBwcmVjaXNlbHkgd2hlbiB0aGUg cGFja2V0IGlzIGxlYXZpbmcgdGhlIFNSIERvbWFpbi4NCj4gW1BDXSBUaGUgc2VjdGlvbnMgNC40 IHRocm91Z2ggNC4xMiBkbyBkZXNjcmliZSB0aGVzZSBwcm9jZWR1cmVzIGZvciB0aGUgZGVjYXBz dWxhdGlvbiBiZWhhdmlvcnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQuDQoNClllcywgdGhl IGRlY2Fwc3VsYXRpb24gcHJvY2VkdXJlcyB0aGVtc2VsdmVzIGFyZSBjb3ZlcmVkIHdlbGwuICBJ IGFtIHN1Z2dlc3RpbmcgdG8gbWVudGlvbiB0aGF0IHRoZSBhY3Qgb2YgZGVjYXBzdWxhdGlvbiAo Z2VuZXJhbGx5KSBzaWduYWxzIHRoYXQgdGhlIHBhY2tldCBpcyBsZWF2aW5nIHRoZSBTUiBkb21h aW4sIHdoZXJlIHdlIGRlc2NyaWJlIHRoZSBwcm9jZWR1cmVzIHRoZW1zZWx2ZXMuDQoNCltQQzJd IERlY2Fwc3VsYXRpb24gbWF5IHByaW1hcmlseSBvY2N1ciBhdCB0aGUgZWRnZSBvZiBhbiBTUiBE b21haW4sIGFuZCBSRkM4NzU0IGRlc2NyaWJlcyB0aGlzIHNjZW5hcmlvIGluIHNlY3Rpb24gNS4N Cg0KPiBIYXZpbmcgdGhlIEFSRyBzdHJ1Y3R1cmUgc3BlY2lmaWVkIGFzIHBhcnQgb2YgdGhlIGJl aGF2aW9yIGNvZGVwb2ludCByZWdpc3RyYXRpb24gbWVhbnMgdGhhdCBhIG5vZGUgdGhhdCBjYW4g YXBwbHkgdGhhdCBTSUQgY2FuIGFsc28gc3Bvb2YgdGhlIEFSRyB0byBmb3JjZSBhIGRpZmZlcmVu dCAoZS5nLikgb3V0Z29pbmcgaW50ZXJmYWNlIGxpc3QuDQo+IFNwZWNpZmljYWxseSwgaXQgZ2l2 ZXMgdGhlIGF0dGFja2VyIGEgZGVncmVlIG9mIGZyZWVkb20gZ3JlYXRlciB0aGFuIGp1c3QgdGhl IFNJRCBiZWhhdmlvcnMgdGhhdCB0aGUgbm9kZSBhZHZlcnRpc2VzLiAgVGhlIEhNQUMgVExWIHdv dWxkIG1pdGlnYXRlIHRoaXMgdG8gdGhlIGV4dGVudCB0aGF0IGl0IGxpbWl0cyB3aGF0IFNJRHMg dGhlIG5vZGUgaW4gcXVlc3Rpb24gaXMgYWxsb3dlZCB0byBhcHBseSBhbmQgd2hhdCBjaGFuZ2Vz IGNhbiBiZSBtYWRlIG9uLXBhdGguDQo+IFtQQ10gVGhlIHByb2Nlc3Npbmcgb2YgQVJHIGlzIHNw ZWNpZmljIHRvIGEgYmVoYXZpb3IgZGVmaW5lZCBhbmQgbm90IGdlbmVyaWMuIFBsZWFzZSByZWZl ciB0byB0aGUgdXBkYXRlZCB0ZXh0IGluIFNlYyA0LjEyIGZvciBFbmQuRFQyTSAod2hpY2ggaXMg Y3VycmVudGx5IHRoZSBvbmx5IHNwZWNpZmllZCBiZWhhdmlvciB0aGF0IGFjY2VwdHMgQVJHcyku IFNpbmNlIHRoZSBBUkcgYml0cyBhcmUgcGFydCBvZiB0aGUgU0lEIHRoZXJlIGFyZSBubyBvdGhl ciBjb25zaWRlcmF0aW9ucyBmb3IgdGhlbSBhcGFydCBmcm9tIHRoZSBvbmVzIHRoYXQgYXBwbHkg dG8gdGhlIFNJRCBhcyBhIHdob2xlLg0KDQpFdmVuIHRob3VnaCB0aGUgQVJHIGJpdHMgYXJlIHNw ZWNpZmljIHRvIGEgYmVoYXZpb3IgKGEgZnVuY3Rpb24sIHJlYWxseSwgSUlVQyksIGlmIHRoZXJl IGlzIGEgbmVlZCB0byBoYXZlIEFSRyBiaXRzIHRoZW4gdGhlcmUgaXMgZ29pbmcgdG8gYmUgbW9y ZSB0aGFuIG9uZSB2YWxpZCB2YWx1ZSBmb3IgdGhlIEFSRyBiaXRzLiAgTm93IHRoYXQgd2UgaGF2 ZSByZW1vdmVkIGEgZGVzY3JpcHRpb24gZm9yIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIEFSRyBiaXRz LCBpdCBiZWNvbWVzIGEgbGl0dGxlIGhhcmRlciB0byBzcG9vZiB0aGVtLCBidXQgb25seSBhIGxp dHRsZSBiaXQuICBHaXZlbiB0aGUgTCtGK0E8MTI4IGNvbnN0cmFpbnQsIEEgbWF5IHZlcnkgd2Vs bCBiZSBzb21ldGhpbmcgc21hbGwsIG9uIHRoZSBvcmRlciBvZiAxMDsgYW4gZXhoYXVzdGl2ZSBz ZWFyY2ggb3ZlciB0aGUgMioqMTAgcG9zc2libGUgdmFsdWVzIGZvciBBUkcgdG8gc2VlIHdoaWNo IGFyZSB2YWxpZCBhbmQgd2hhdCB0aGV5IGRvIHdvdWxkIGJlIGZhaXJseSBlYXN5IHRvIGRvLiAg QW4gYXR0YWNrZXIgaW4gYSBwb3NpdGlvbiB0byBkbyB0aGF0IGV4aGF1c3RpdmUgc2VhcmNoIChh ZG1pdHRlZGx5LCBvbmUgd291bGQgYmUgdmlvbGF0aW5nIHRoZSAidHJ1c3RlZCBTUiBkb21haW4i IGFzc3VtcHRpb24gdG8gZ2V0IHRoZXJlKSBjb3VsZCBiZSBhYmxlIHRvIG9ic2VydmUgdGhlIGRp ZmZlcmVudCBiZWhhdmlvcnMgcHJvdmlkZWQgYnkgdGhlIGRpZmZlcmVudCBBUkcgdmFsdWVzIGFu ZCBzZWxlY3Qgd2hhdCBiZWhhdmlvciB0aGV5IHdhbnRlZCBieSBzcG9vZmluZyBBUkcuICBJZiBB IHdhcyBsYXJnZXIsIGxpa2UgNjQgb3IgMTI4LCB0aGlzIHNlYXJjaCBhbmQgZ3Vlc3Npbmcgd291 bGQgYmUgbXVjaCBsZXNzIHByYWN0aWNhbCwgYnV0IHdlIGRvbid0IHJlYWxseSBoYXZlIHRoYXQg bWFueSBiaXRzIGx5aW5nIGFyb3VuZC4gIFNvLCBJIHRoaW5rIHRoaXMgaXMgYSBuZXcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBpbnRyb2R1Y2VkIGJ5IHRoZSBwcmVzZW5jZSBvZiB0aGUgQVJHIGJp dHMgaW4gdGhlIFNJRCwgYW5kIHdlIHNob3VsZCBtZW50aW9uIGl0LiAgKFdlIHdvdWxkIGFsc28g bWVudGlvbiB0aGF0IHRoZSByaXNrIGlzIGxhcmdlbHkgbWl0aWdhdGVkIGJ5IHRoZSBhc3N1bXB0 aW9uIHRoYXQgdGhlIFNSIGRvbWFpbiBpcyB0cnVzdGVkLCBvZiBjb3Vyc2UuKQ0KDQpbUEMyXSBU aGlzIHNlcnZpY2UgdGhlZnQgY29uc2lkZXJhdGlvbiBleGlzdHMgZm9yIGV2ZXJ5IFNJRCwgcmVn YXJkbGVzcyBvZiB0aGUgdXNlIG9mIGFyZ3VtZW50cy4gIEl0IGlzIGRpc2N1c3NlZCBpbiBSRkM4 NzU0IHNlY3Rpb24gNy4yIGFuZCByZWZlcmVuY2VkIGZyb20gc2VjdGlvbiA5IG9mIHRoaXMgZHJh ZnQuDQoNCj4gICAgc2VydmljZXMuICBBZGRpdGlvbmFsbHksIFtSRkM4NzU0XSBkZWZpbmVzIGFu IEhNQUMgVExWIHBlcm1pdHRpbmcgU1INCj4gICAgRW5kcG9pbnQgTm9kZXMgaW4gdGhlIFNSIGRv bWFpbiB0byB2ZXJpZnkgdGhhdCB0aGUgU1JIIGFwcGxpZWQgdG8gYQ0KPiAgICBwYWNrZXQgd2Fz IHNlbGVjdGVkIGJ5IGFuIGF1dGhvcml6ZWQgcGFydHkgYW5kIHRvIGVuc3VyZSB0aGF0IHRoZQ0K PiAgICBzZWdtZW50IGxpc3QgaXMgbm90IG1vZGlmaWVkIGFmdGVyIGdlbmVyYXRpb24sIHJlZ2Fy ZGxlc3Mgb2YgdGhlDQo+ICAgIG51bWJlciBvZiBzZWdtZW50cyBpbiB0aGUgc2VnbWVudCBsaXN0 LiAgV2hlbiBlbmFibGVkIGJ5IGxvY2FsDQo+DQo+IEkgc3VnZ2VzdCBhZGRpbmcgYSBzZW50ZW5j ZSBzaW1pbGFyIHRvICIoVGhpcyBkb2VzLCBob3dldmVyLCByZXF1aXJlIHRoYXQgdGhlIHNlZ21l bnQgbGlzdCwgYW5kIHRodXMsIHRoZSBTUkggaXMgcHJlc2VudCBpbiB0aGUgcGFja2V0OyB0aGUg b3B0aW9uYWwgYWJpbGl0eSB0byBlbGlkZSB0aGUgU1JIIHdoZW4gdGhlcmUgaXMgb25seSBhIHNp bmdsZSBzZWdtZW50IGFuZCBubyBmbGFncywgdGFncywgb3IgVExWcyBuZWVkZWQgaW5oZXJlbnRs eSBleGNsdWRlcyB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgSE1BQyBUTFYuKSINCj4gW1BDXSBBbGwg dGhlIFNSIFBvbGljeSBIZWFkZW5kIChpLmUuIHRoZSBTUiBTb3VyY2UgTm9kZSkgYmVoYXZpb3Jz IGRlZmluZWQgaW4gU2VjIDUgc3RhdGU6DQo+ID4gIFRoZSBwdXNoIG9mIHRoZSBTUkggTUFZIGJl IG9taXR0ZWQgd2hlbiB0aGUgU1J2NiBQb2xpY3kgb25seSBjb250YWlucyAgIG9uZSBzZWdtZW50 IGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIHVzZSBhbnkgZmxhZywgdGFnIG9yIFRMVi4NCj4gU28s IGl0IGZvbGxvd3MgdGhhdCBpZiBITUFDIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIHRoZW4gU1JI IGhhcyB0byBiZSB1c2VkIGV2ZW4gd2l0aCBhIHNpbmdsZSBzZWdtZW50Lg0KDQpBaCwgSSBzZWUg eW91ciBwb2ludCwgeWVzLiAgU29ycnkgZm9yIG1pc3NpbmcgdGhhdC4NCihCdXQgSSB0aGluayBt eSBlYXJsaWVyIGNvbW1lbnQgYWJvdXQgUFNQIHN0aWxsIGFwcGxpZXMuKQ0KDQo+IFNlY3Rpb24g MTAuMQ0KPg0KPiAgICBkZWZpbml0aW9uOiBUaGUgdmFsdWUgMTQzIGluIHRoZSBOZXh0IEhlYWRl ciBmaWVsZCBvZiBhbiBJUHY2IGhlYWRlcg0KPiAgICBvciBhbnkgZXh0ZW5zaW9uIGhlYWRlciBp bmRpY2F0ZXMgdGhhdCB0aGUgcGF5bG9hZCBpcyBhbiBFdGhlcm5ldA0KPiAgICBbSUVFRS44MDIu M18yMDE4XS4NCj4NCj4gbml0OiBpcyB0aGVyZSBhIG1pc3Npbmcgd29yZCBoZXJlICgiZnJhbWUi Pyk/DQo+IFtQQ10gQWNrLCBmaXhlZC4NCj4NCj4gTWFueSB0aGFua3MgZm9yIHlvdXIgdGltZS4N Cg0KVGhhbmsgeW91IGZvciB5b3VycyBhcyB3ZWxsLCBhbmQgdGhlIHVwZGF0ZXMgYWxyZWFkeSBw cmVzZW50IGFuZCBxdWV1ZWQuDQoNClNvcnJ5IGFnYWluIGZvciB0YWtpbmcgc28gbG9uZyB0byBn ZXQgYmFjayB0byB5b3UuDQoNCi1CZW4NCg== From nobody Wed Nov 25 16:12:01 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48D13A0773; Wed, 25 Nov 2020 16:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HT66UqqXKWEw; Wed, 25 Nov 2020 16:11:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 714533A067A; Wed, 25 Nov 2020 16:11:54 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AQ0Bhgp014620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 19:11:48 -0500 Date: Wed, 25 Nov 2020 16:11:43 -0800 From: Benjamin Kaduk To: "Pablo Camarillo (pcamaril)" Cc: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Message-ID: <20201126001143.GO39170@kduck.mit.edu> References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> <20201125011313.GH39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 00:12:00 -0000 Hi Pablo, Thanks for the updates; the changes in the -25 all look good to me. More inline... On Wed, Nov 25, 2020 at 09:42:42PM +0000, Pablo Camarillo (pcamaril) wrote: > Hi Ben, >=20 > Thanks for your careful review. Replies to your comments inline with PC2. > Note that I=E2=80=99ve posted rev25 of the draft. >=20 > Thanks, > Pablo. >=20 > -----Original Message----- > From: Benjamin Kaduk > Sent: mi=C3=A9rcoles, 25 de noviembre de 2020 2:13 > To: Pablo Camarillo (pcamaril) > Cc: The IESG ; draft-ietf-spring-srv6-network-programming@= ietf.org; spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene ; Joel Halpern > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-p= rogramming-20: (with DISCUSS and COMMENT) >=20 > Hi Pablo, >=20 > I must apologize twice over: first for the delay in responding, and secon= d for the number of points in my discuss ballot that are not actual problem= s. > I recently had the time to go over the document again, with benefit of yo= ur responses here, and now have a better understanding of some aspects that= were confusing to me during my first reading. I still have a few things I= want to take another look at, but I can respond to your comments now -- th= e good news is that these discuss points all look to be resolved. >=20 > More inline... >=20 > On Fri, Sep 25, 2020 at 06:31:52PM +0000, Pablo Camarillo (pcamaril) wrot= e: > > Hi Benjamin, > > > > Thank you for your time and review. Please see inline with [PC]. > > > > Regards, > > Pablo. > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Sent: jueves, 24 de septiembre de 2020 9:52 > > To: The IESG > > Cc: draft-ietf-spring-srv6-network-programming@ietf.org; > > spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene > > ; Joel Halpern ; > > jmh@joelhalpern.com > > Subject: Benjamin Kaduk's Discuss on > > draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and > > COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-spring-srv6-network-programming-20: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-progra > > mming/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [edited to remove nonsensical point that had crept in about the SRH > > being a new extension header; it's "just" a routing header] > > > > The current requirement that IANA-assigned SRv6 Endpoint Behavior codep= oints are used, with no range reserved for local assignment, seems to be in= viting codepoint squatting from the nominally reserved range. > > Why is there an absolute requirement for registration (even FCFS) > > without ranges for local or experimental use? (What are the various re= served ranges reserved for?) [PC] I agree with you that a range for local u= se would come useful. Hence, we=E2=80=99ve carved 2k entries of the registr= y for Private Use. > > The Reserved range (half of the 65k registry) is for future allocation = by IETF. Future RFCs might decide how to use that. >=20 > Sounds good; thanks! >=20 > > The (normative) pseudocode does not seem to handle the case when the SR= H is omitted for the degenerate case where there is only a single segment, = or for the PSP flavor. > > [PC] Each one of the pseudocodes provides the SRH processing and the Up= per-Layer processing. If there is no SRH, then the SRH processing is not ex= ecuted, but the Upper-layer Header processing is. This is the same as in RF= C8754. >=20 > To expand a bit more on how I was confused here, I was looking particular= ly at the End, End.X, and End.T cases (though I guess it also applies to th= e Encaps cases). In the normal flavor, upper-layer processing gets shunted= over to section 4.1.1 that doesn't really do much -- in particular, there = is no interconnect for End.X and no table lookup for End.T! But this reall= y is the right behavior, since the SRH is only absent when this SID is the = final destination of the packet, and in that case we really must act as an = endpoint and not a router. If we did send the packet onward it would most = likely just get looped back to us until the hop limit expires (or get some = other error), so generating a local ICMP error is the right thing to do in = the general case, unless there is local configuration for that upper-layer = protocol. >=20 > [PC2] Ack >=20 > > The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext= Len is measured in units of 8 octets, and does not include the first 8 oct= ets of the extension header, but Payload Length is measured in octets. Lit= erally decreasing the Payload Length by the Hdr Ext Len value will produce = a malformed IPv6 packet. > > [PC] Indeed. Fixed. > > > > If "PSP operation is deterministically controlled by the SR Source Node= ", why do we need to define behavior codepoints that (for example) use both= PSP and USP? I don't see how there is full determinism in this case while= being different from the "PSP only" flavor. > > [PC] In order for the PSP behavior to be executed there must happen two= things. First, the SR Source Node must instruct it wants to use the PSP be= havior. This is done by using an SRv6 SID associated with a behavior that s= upport the PSP flavor (either End with PSP alone, or End with PSP in combin= ation of other). Then, the second thing is that the received packet at the = node it must have a SL value of 1, that during processing is decremented to= 0. (In other words, it must be the penultimate segment). If both condition= s are given, then lines S14.2-S14.4 of the pseudocode are executed. >=20 > I understand now; thanks for explaining it again. (To reiterate: any giv= en SID can appear "anywhere" in the segment list, so USP is relevant when i= t is last and PSP is relevant when it appears second-to-last. The USP/PSP = flavor doesn't need to be the same for all SIDs in the path, so marking a s= ingle SID with both can be relevant for different paths.) >=20 > [PC2] Correct >=20 > > There are numerous factual errors and un/under-specified protocol behav= ior (see COMMENT), including: how to set the outer Hop Limit (multiple inst= ances), the order of segments in the SRH, specification of headend behavior= by reference to informal example, L2 frame en/decapsulation procedures, an= d the "Opaque" note for endpoint behavior 65535. > > [PC] I=E2=80=99ll comment on each point in the comment. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I note that this document references > > draft-filsfils-spring-srv6-net-pgm-illustration, which uses the IPv4 CI= DR 20/8 in examples instead of addresses from the RFC 5737 range. It would= be disappointing to have a PS refer to a draft that squats on the IPv4 nam= espace in such a manner. > > [PC] Ack. I=E2=80=99ve updated draft-filsfils-spring-srv6-net-pgm-illus= tration to correct that. >=20 > Thank you! >=20 > > Abstract, Introduction > > > > This document defines the SRv6 Network Programming concept and > > specifies the base set of SRv6 behaviors that enables the creation of > > interoperable overlays with underlay optimization (Service Level > > Agreements). > > > > I don't understand what the parenthetical is intending to convey. > > [PC] I=E2=80=99ve removed the parenthesis. Its unneeded. > > > > Section 2 > > > > The following terms used within this document are defined in > > [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 > > SID, SR Policy, Prefix SID, and Adjacency SID. > > > > [RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.] [PC] Fixed > > in rev21. > > > > Section 3 > > > > The text allegedly reproduced from RFC 8754 =C2=A74.3 differs in case a= nd hyphenation. > > [PC] Fixed in rev21. > > > > Section 3.1 > > > > This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, > > where a locator (LOC) is encoded in the L most significant bits of > > the SID, followed by F bits of function (FUNCT) and A bits of > > arguments (ARG). L, the locator length, is flexible, and an operator > > is free to use the locator length of their choice. F and A may be > > any value as long as L+F+A <=3D 128. When L+F+A is less than 128 th= en > > the remaining bits of the SID MUST be zero. > > > > Why does A have to be a fixed value; can't it safely be a function of F= (even if we exclude things like huffman coding for F)? > > [PC] Can you please re-state your point? The text above does not sugges= t that A is a fixed value, hence I=E2=80=99m not sure I fully understand wh= at you mean. >=20 > It's true that there is no specific statement "A is a constant across ". However, there is also not a specific statement "th= e value of A can depend on ", so the reader has to m= ake an interpretation. We do say that L is flexible and the operator can c= hoose that length; I interpreted this to mean that the operator makes the c= hoice once, and that L is fixed for the entire SR domain. With that in my = head, it was also natural to infer that F and A are also fixed for the enti= re SR domain. (Is L allowed to vary even within the domain?) >=20 > [PC2] Note that in RFC8754 we have =E2=80=9CWhen an SRv6-capable node re= ceives an IPv6 packet, it performs longest-prefix-match lookup on the packe= t=E2=80=99s destination address.=E2=80=9D. Hence things work even if two n= odes use a different L for their locators or different sizes of F and A fo= r their SIDs. I guess so. (In my head the ability to use longest-prefix was useful for when the SID and non-SID addresses could be consolidated into a single prefix applicable to that node, but I have no particular reason to have been thinking that.) If I might make a suggestion, writing "free to use the locator length of their choice for any given SID" would have forestalled my confusion in this regard, and seems like a minor change to make. But it is your decision as to whether or not to make any changes here; I am satisfied just with the explanation above. > If we do want to allow F and A to vary at a (e.g.) per-LOC scope, we shou= ld probably make some statement about being able to decode them properly on= receipt; this could be done in many ways, including a strict lookup table = and a self-deliniating length-encoding scheme, but there cannot be ambiguit= y about how to partition a given IP address into LOC:FUNCT:ARG. >=20 > [PC2] Please refer to previous comments and also the text in Sec 3. The S= R Endpoint Node performs LPM lookup to match the FIB entry corresponding to= SIDs that it has instantiated in order to execute the instructions specifi= c to its behavior. The packet with the SID in the DA is routed through tran= sit nodes based on LPM lookup that happens on the locator parts that are ad= vertised via routing/control plane as described in Sec 3.3. The transit nod= es do not have to decode or program SIDs that have been instantiated by oth= er SR Endpoint nodes in the domain. I agree that the transit nodes don't need to know anything about this. The node that instantiates the SID, however, does. As a totally contrived example, suppose that I have a prefix of abcd:abcd:: as my LOC and I want to use FUNCT of 0x1234 to indicate behavior codepoint 1, FUNCT of 0x12351235 to indicate behavior codepoint 2, and FUNCT of 0x12351236 to indicate behavior codepoint 3. I basically have to store that in a table, and can't write some logic that looks at the 16 bits after the LOC. If I instead used 0x1234, 0x22351235, and 0x22351236, then the first four bits after LOC could be the length of FUNCT encoding in 2-byte increments, and I could have some "simple" code to unpack the self-delineating encoding. In short: this topic only considers how a given node assigns its own LOC:FUNCT:ARG values, and may be self-evident to most readers, but it can still be helpful to note as guidance on how to make those allocations. > > An SRv6 Segment Endpoint Behavior may require additional information > > for its processing (e.g. related to the flow or service). This > > information may be encoded in the ARG bits of the SID. > > > > (Assuming that it can be sufficiently compactly encoded?) [PC] Correct > > > > The ARG value of a routed SID SHOULD remain constant among packets in > > a given flow. Varying ARG values among packets in a flow may > > result > > > > (Thus limiting the type of information that can be represented in the > > ARG?) > > [PC] This text provides a SHOULD, and a reason for it. If other behavio= rs defined in future documents would like to have ARG value varying for pac= kets belonging to the same flow, it is important that they take this into c= onsideration. > > > > Section 3.2 > > > > SIDs. The provider historically deployed IPv6 and assigned > > infrastructure addresses from a portion of the fc00::/7 prefix. They > > further subdivided the prefix into three /48 prefixes (Country X, > > Country Y, Country Z) to support their SRv6 infrastructure. From > > those /48 prefixes each router is assigned a /64 prefix from which > > all SIDs of that router are allocated. > > > > This is not the language I would have expected for use of the ULA addre= ss range. It looks like this may be related to Erik Kline's Discuss point.= =2E. > > [PC] Indeed related. Erik Kline has suggested text. Ill use Erik=E2=80= =99s text as provided. > > > > IPv6 address consumption in both these examples is minimal, > > representing one billionth and one millionth of the assigned address > > space, respectively. > > > > I'm not sure I understand the calculation that produced these values. > > [PC] If the operator got assigned a /20 by the RIR, then they have 2^28= /48 prefixes available. Thus, if they are only using a few /48 prefixes, t= hen they are using less than a millionth of the available /48 prefixes. >=20 > Apparently I didn't take notes on my initial calculations that left me co= nfused. Assuming I have it right this time... >=20 > # Use 3 /48s in the whole ULA /40 > >>> 3./2**40 > 2.7284841053187847e-12 > # Use "a few" 3 /48s from the assigned /20 > >>> 3./2**28 > 1.1175870895385742e-08 >=20 > This seems to be well less than a billionth and a millionth, respectively= , so I'm not sure if I am doing the math as intended. >=20 > [PC2] I believe your maths are right. > If an operator is allocated a /20, they can allocate 2**28 /48 prefixes. > 2**28 =3D 268435456. > Thus, If SRv6 requires 3 of such /48 prefixes, then we are using only 1.1= 2e-8 of that space, which is less than a millionth (e-6). > No? > In other words: if we do a million of deployments of SRv6, there would be= space to fit them all within that /20. (and actually there is slightly mor= e) I would suggest adding "less than" in the text, then. > > An SR Source Node cannot infer the behavior by examination of the > > FUNCT value of a SID. > > > > Therefore, the SRv6 Endpoint Behavior codepoint is advertised along > > with the SID in the control plane. > > > > These two sentences feel a little out of place in this spot, occurring = after previous discussion that the endpoint behavior codepoint is advertise= d in the control plane. > > [PC] Other ADs have expressed the value of precisely those two sentence= s. >=20 > I agree that these sentences are valuable. I was proposing to move them = two paragraphs earlier, so we transition directly from "advertises the SID = =2E.. in the control plane" to (paraphrasing) "cannot infer behavior by exa= mining FUNCT" and "behavior codepoint is advertised along with SID". >=20 > [PC2] Misunderstood your original point. I moved those two up as you sugg= est. >=20 > > o At Router 3, within the locator 2001:db8:bbbb:3::/64, network > > operator or the router performs dynamic assignment for: > > > > nit: missing article ("the network operator"). > > [PC] Ack. Fixed in rev21. > > > > * Function 100 associated with the behavior End.X (Endpoint with > > cross-connect) between router 3 and its connected neighbor > > router, for example Router 4. This function is encoded as > > 16-bit value and has no arguments. > > > > Please clarify that "function 100" is a hex literal. > > [PC] Ack. Fixed in rev21. > > > > I also suggest noting clearly at the start of the example that F is 16 = and A is 0. > > [PC] Ack. Added for each SID in rev21. > > > > * Function 101 associated with the behavior End.X (Endpoint with > > cross-connect) between router 3 and its connected neighbor > > router, for example Router 2. This function is encoded as > > 16-bit value and has no arguments. > > > > F is a constant for the SR domain; saying it at each SID assignment is = misleading. > > [PC] Function is the bits in the SID instantiated by the router. Can yo= u please explain what text gives the impression that F is a constant? >=20 > FUNCT is instantiated by the router, yes, and it is F bits long. This ti= es in to my previous comment about L, F, and A (maybe) being constants acro= ss the SR domain, or clarifying at which scope they can vary. >=20 > [PC2] Indeed, see previous answer. >=20 > > [same note about hex for 101] > > [PC] Ack. Added for each SID in rev21. > > > > Section 4 > > > > The list is not exhaustive. In practice, any function can be > > attached to a local SID: e.g. a node N can bind a SID to a local VM > > or container which can apply any complex processing on the packet. > > > > Yes, but it can't advertise the behavior corresponding to that function= without a codepoint. > > [PC] This is intended to be an introductory paragraph to the behaviors.= But you are absolutely right: for any new behavior you need to write a new= I-D (as its currently happening in other SPRING WG docs), and then -once R= FCed- get an SRv6 Endpoint Behavior codepoint for it. >=20 > Maybe we could add at the end ", provided there is a behavior codepoint a= llocated for that processing" or some similar edit? (We don't have to; the= decision is up to you.) >=20 > [PC2] I'm fine with it. Added as suggested. >=20 > > Section 4.1.1 > > > > When processing the Upper-layer Header of a packet matching a FIB > > entry locally instantiated as an SRv6 End SID, if Upper-layer Header > > processing is allowed by local configuration (e.g. ICMPv6), then > > > > nit: the parenthetical is placed so as to apply to "local configuration= ", which doesn't really make sense; I presume the intent is to say that upp= er-layer header processing is allowed *for that upper-layer protocol*. Als= o, comma after "e.g.". > > [PC] Agreed, but see next point. > > > > problem message to the Source Address and discard the packet. Error > > code 4 (SR Upper-layer Header Error) and Pointer set to the offset of > > the upper-layer header. > > > > nit: this is not a complete sentence. > > [PC] We have been asked to change the entire 4.1.1 to a pseudocode. Ple= ase review the pseudocode in revision 21 and let me know your feedback. >=20 > Yes, this pseudocode looks much better -- thank you! >=20 > That said, I am not sure that I understand why it is only RECOMMENDED (not > REQUIRED) to only allow upper-layer processing when that does not result = in the packet being forwarded. Are there cases when this would be useful a= nd not result in a packet loop? >=20 > [PC2] We believe that RECOMMENDATION is strong enough for this scenario. = I am not sure that we can say that packets forwarded after local processing= will always result in a loop e.g. if there is an inner encapsulated IP pac= ket that needs to get forwarded further. Okay. > > Section 4.2 > > > > It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is > > required to express any traffic-engineering policy. > > > > This text reads as if End.X specifically is required for TE, which does= not seem correct to me. > > [PC] Fixed. > > OLD: and it is required to express any traffic-engineering policy. > > NEW: and its main use is for traffic-engineering policies. > > > > Section 4.4, 4.5 > > > > This is equivalent to the per-CE > > VPN label in MPLS [RFC4364]. > > > > The phrase "per-CE VPN" does not appear in RFC 4364. > > [PC] Added to the terminology section. > > > > Section 4.5 > > > > S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then > > one entry of the array is selected based on the hash of the packet's > > header Section 7. > > > > nit: I suggest "(see Section 7)" to match section 4.4. > > [PC] Indeed. Fixed. > > > > Section 4.6, 4.7 > > > > is required. This is equivalent to the per-VRF VPN label in MPLS > > [RFC4364]. > > > > The phrase "per-VRF VPN" does not appear in RFC 4364. > > (A similar comment applies to Section 4.8 as well.) [PC] Added to the > > terminology section of the document. > > > > Note that an End.DT6 may be defined for the main IPv6 table in which > > case and End.DT6 supports the equivalent of an IPv6inIPv6 > > > > nit: s/and/an/ > > [PC] Thanks. Fixed. > > > > Section 4.7 > > > > The "Endpoint with decapsulation and specific IPv4 table lookup" > > behavior (End.DT4 for short) is a variant of the End behavior. > > > > nit: variant of End.T, just like End.DT6, no? > > [PC] Correct, fixed. > > > > Section 4.9 > > > > S04. An End.DX2 behavior could be customized to expect a specific > > IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header > > before forwarding on the outgoing interface. > > > > Would this customized behavior require a new codepoint? > > Similarly for End.DX2V (Section 4.10) > > [PC] No, that customization is local config to the node. >=20 > That is surprising to me (it seems like an important part of the behavior= that should be signalled explicitly), but I am not familiar enough with th= is domain in order to argue about it any further. >=20 > [PC2] In MPLS this is local config. While someone might think about signa= ling it in the future -intuitively makes sense-, in today=E2=80=99s use-cas= e it isn=E2=80=99t. Thanks for the pointer about MPLS, that helps. And I agree that it seems straightforward to add signaling in the future if needed. > > Section 4.10 > > > > S04. Remove the outer IPv6 Header with all its extension headers, > > lookup the exposed VLANs in L2 table T, and forward > > via the matched table entry. > > > > Just to check my understanding: the "exposed VLANs" (plural?!) are in t= he Ethernet header of the packet that we are left with after removing the o= uter IPv6 header, right? > > [PC] Correct. And multiple tags in case of Q-in-Q. > > > > S01. IANA has allocated the Internet Protocol number 143 to Ethernet > > (see Section 10.1). > > > > This seems like a copy/paste leftover from End.DX2 -- we don't mention > > 143 in this section. > > [PC] Indeed. I added by mistake on rev20 to address an AD comment and I= have just removed in rev21 again. > > > > Section 4.12 > > > > Two of the applications of the End.DT2M behavior are the EVPN > > Bridging of broadcast, unknown and multicast (BUM) traffic with > > Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use- > > cases. > > > > Are there references for either/both of these? > > [PC] Added in rev21. >=20 > Thanks! >=20 > > S04. Remove the IPv6 header and all its extension headers > > > > nit: the rest of the document uses "Remove the outer IPv6 header with a= ll its extension headers". > > [PC] Fixed. Thanks. > > > > S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 > > > > nit: s/one/ones/ > > [PC] Fixed. Thanks. > > > > Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits > > represent a list of up to k OIFs, each identified with an x-bit > > value. Values k and x are defined on a per End.DT2M SID basis. The > > interface identifier 0 indicates an empty entry in the interface > > list. > > > > (editorial) rather than have to come up with the concept of an "empty e= ntry" in the interface list, I would probably just say that the identifier = 0 is reserved and is ignored when doing the exclusion of OIFs. > > > > I also think we need to say that the order and identifier assignment > > of elements of the interface list (that is, what the x-bit values > > index > > into) is under the local control of N, but has to remain stable as > > long as SIDs are advertised that list members of the list in ARG. (The= re is otherwise a great deal of freedom in assignment since the values are = only consumed by the node that advertises them.) [PC] This text is updated = as part of Alvaro=E2=80=99s comment. Can you please check the current text = in rev21? >=20 > I think the new text is doing the right thing -- the structure of the val= ue is entirely local to the SR Endpoint advertising it. I will have an edi= torial comment in my updated ballot position about the "signaling of the ar= gument to other nodes..." clause, though. >=20 > > Section 4.13 > > > > It's probably worth calling out the MTU considerations of pushing the > > new IPv6 header+SRH and tunneling the packets. (I know we reference > > 2473 already, but the MTU is pretty important.) [PC] MTU > > considerations are covered in RFC8754. > > > > S17. The Payload Length, Traffic Class and Next-Header fields are > > set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. > > > > How is the Hop Limit set for the outer header? > > (I assume =C2=A76.3 of RFC 2473, but given that you provide a reference= for > > all the other fields, it seems like an omission to not mention Hop Limi= t as well.) [PC] Sure, added. >=20 > [Thanks. I'll note some similar reference nits regarding =C2=A75.1 in my = updated comments] >=20 > > Section 4.14 > > > > The SRH MAY be omitted when the SRv6 Policy only contains one segment > > and there is no need to use any flag, tag or TLV. > > > > If this is the case does it matter if I use End.B6.Encaps or End.B6.Enc= aps.Red? > > [PC] If you only have a single segment, then it does not matter. Howeve= r when you have more than one segment the change is significant. > > > > Section 4.16 > > > > I don't think I understand what it would mean for a specific SID to sup= port the multiple flavors "in combinations". > > [PC] Convoluted sentence indeed. > > > > For each of these > > behaviors these flavors MAY be supported for a SID either > > individually or in combinations. > > > > > > The End, End.X or End.T behaviors could support these flavors either in= dividually or in combination. > > >=20 > Much better; thanks! It may be less relevant now that we are assigning b= ehavior codepoints for each flavor combination, but IMO the USD flavor fits= more naturally into being "part of the main behavior". E.g., we have > End.DT46 already, and I'm not sure how that (behavior codepoint 20) diffe= rs from End.T with USD (behavior codepoint 36). I think it's generally a b= ad idea to have multiple ways of expressing the same behavior. >=20 > [PC2] End.T with USD and End.DT46 are the same only when they are the las= t SID of the SID list. Note that when they are used as intermediate segment= they do different things. If End.DT46 is used as an intermediate segment i= n the sid list it will result in an ICMP Parameter Problem. If End.T is use= d as an intermediate segment the packet is forwarded. I seem to still be having a hard time getting the hang of this stuff; thank you again for your patience with explanations! So, a node would have to advertise both End.DT46 and End.T and have the route calculation use the respective one in order to get the same effect as End.T + USD. That is different enough that I will not complain too loudly about it, though in a greenfield ecosystem one could conceivably go with either approach... > > Section 4.16.1.2 > > > > A penultimate SR Segment Endpoint Node is one that, as part of the > > SID processing, copies the last SID from the SRH into the IPv6 > > Destination Address and decrements Segments Left value from one to > > zero. > > > > I think technically it copies the first SID from the SRH (SRH.Segment L= ist[0]), which is the last SID from the SR Policy. > > [PC] RFC8754 uses the term =E2=80=9Clast SID=E2=80=9D to refer to SRH.S= egmentList[0]. Please refer RFC8754 Sec 6.1 for details. > > Also, nit: "the" for "the Segments Left value". > > [PC] Ack. Corrected. > > > > S14.2. Update the Next Header field in the preceding header to the > > Next Header value of the SRH > > > > nit: personally, I would write "from the SRH", since "next header value= of the SRH" is very close to "next header value of SRH", i.e., 43. > > [PC] Reads better indeed. Corrected. > > > > As a reminder, [RFC8754] defines in section 5 the SR Deployment Model > > within the SR Domain [RFC8402]. Within this framework, the > > Authentication Header (AH) is not used to secure the SRH as described > > in Section 7.5 of [RFC8754]. > > > > I strongly recommend adding another sentence clarifying why this is rel= evant to discussion of removing an extension header from the packet. > > [PC] I suggest that is not relevant to the discussion of PSP since AH i= s not defined for the SRH. >=20 > We should explain why we are saying anything at all about AH. Right now = it sounds like an irrelevant piece of information that should have been edi= ted out of the document, but it actually is quite important in attempting t= o justify the design decision of allowing PSP! >=20 > [PC2] Actually, it was a requested clarification to be added to convey th= at AH not being specified and used for securing SRH results in there not be= ing any issue with AH when doing PSP. Yes, and I support that request. This text seems to only do half of that, though -- it says that AH is not used for securing SRH, but skips the part about there not being any issue with AH when doing PSP. > > Section 5 > > > > This list can be expanded in case any new functionality requires it. > > > > How? By an RFC that Updates: this one? > > [PC] New functionality would have to be introduced via a new document b= ut it does not have to update this one since it is not modifying what is in= this document but adding something new. > > We have updated the text as s/This list can be expanded in case any new= functionality requires it/This list is not exhaustive and future documents= may define additional behaviors. >=20 > Thanks. >=20 > > Section 5.x > > > > I agree with the directorate reviewer that the protocol behavior should= be written out explicitly, without reference to the handling of example pa= cket(s). > > [PC] There is already pseudocode and descriptions in these sections tha= t describes the behavior. Examples are to help understanding. Can you clari= fy what more is required? >=20 > The pseudocode hardcodes that the segment list is (S3, S2, S1; SL=3D2), w= hich is just an example of what the SRH could be. It's not truly generic p= seudocode. >=20 > [PC2] Agreed. I=E2=80=99ve removed the =E2=80=9C(S3, S2, S1; SL=3D2) from= the pseudocode. Its specific to the example, and it does not bring any val= ue (the encoding of the SRH is already defined in RFC8754). Ah, that looks to be a good resolution; thank you! We might want to do a minor follow-up and say "outer IPv6 DA as the first SID in the segment list" (since 'S1' is no longer defined as part of the pseudocode). > Also, I think it would be great if 5.2, 5.3, and 5.4 could do the sort of= thing we did for the endpoitn behaviors where it replaces the definition o= f one or more of the numbered pseudocode steps. (I don't think we can, rig= ht now, since the numbered pseudocode doesn't cover all the relevant parts = that are changing, and I didn't think about how hard it would be to change = the pseudocode to make that the case. >=20 > > Section 5.1 > > > > S03. Set outer payload length, traffic class and flow label > > > > What about the outer Hop Limit? > > [PC] Added. > > > > S03: As described in [RFC6437] (IPv6 Flow Label Specification) > > > > Why is this all the way at the bottom of the section instead of include= d with the corresponding content? > > [PC] Ack. Brought up. > > > > Section 5.3 > > > > The encapsulating node MUST remove the preamble or frame check > > sequence (FCS) from the Ethernet frame upon encapsulation and the > > decapsulating node MUST regenerate the preamble or FCS before > > forwarding Ethernet frame. > > > > "or"? I get to choose one or the other? It's okay to only put back a = preamble but no FCS (or vice versa)? > > [PC] Good catch. s/or/and; also preamble removed only if present > > > > Section 6 > > > > traffic that matched that SID and was processed correctly. The > > retrieval of these counters via MIB, NETCONF/YANG or any other means > > is outside the scope of this document. > > > > (editorial) a MIB is an abstract data structure (likewise a YANG module= ); information might be retrieved *from* it but not *via* it. For *via*, t= hat would be SNMP, NETCONF, and/or RESTCONF. > > [PC] Fixed. > > > > Section 8.1 > > > > Does it make sense to reference RFCs 8491, 8476, 8841, etc. for adverti= sing MSD via IGP? > > [PC] I would leave that up to the srv6 control plane drafts; but no str= ong preference. > > > > In particular, the SR source (e.g., H.Encaps), intermediate endpoint > > (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) > > behaviors. [...] > > > > This is not a complete sentence, and I really have no idea what verb wa= s intended. > > [PC] Indeed, fixed in rev21. > > > > Section 8.2, 8.3 > > > > Can we get references for the BGP variants here and their usage for sig= naling SRv6 capabilities and (SID,behavior codepoint) pairs? > > [PC] The references to the BGP features have already been provided in t= he respective sections where these behaviors are specified. There are WG dr= afts in progress for SRv6 extensions to routing protocols (not just BGP) th= at normatively reference this document. There used to be informative refere= nces the other way around from this document which were removed during WGLC= based on feedback. We can add them back if that makes sense for the IESG. >=20 > I think that those informative references would be helpful, but I also do= n't know how strong the WG consensus was to remove them (or what reasoning = was offered for doing so). >=20 > [PC2] I=E2=80=99ll leave it up to Martin (responsible AD). > On a separate note, on 8.3 I=E2=80=99ve also added the note on the Opaque= as discussed. > > In some scenarios, an egress PE advertising a VPN route might wish to abs= tract the specific behavior bound to the SID from the ingress PE and other = routers in the network. In such case, the SID may be advertised using the O= paque SRv6 Endpoint Behavior codepoint defined in [Section 10.2.1]. The det= ails of such control plane signaling mechanisms are out of the scope of thi= s document. > Thanks again for this clarification; this behavior feels perfectly natural once explained, but really confused me on first reading. > > Section 9 > > > > I would really like to have a stronger reference to Section 5 of RFC > > 8754 where the conceptual model of a SR Domain as a single system, wher= e all packets in the domain are encapsulated using IPv6 headers [with SIDs = as SA/DA]. The part in brackets is not spelled out very clearly and could = well be expounded upon in this document. I can write up some (very ad hoc)= ideas for what I had in mind, which you are welcome to adopt but expected = to wordsmith/edit appropriately: > > > > % Section 5 of [RFC8754] describes the SR deployment model and the % ba= seline requirements for securing the SR Domain. In many ways the SR % Doma= in is analogous to an MPLS domain -- it's a tightly controlled % system whe= re packet processing is controlled by a list (or stack) of % opaque identif= iers that, by and large, only have defined semantics in % the context of th= e node that receives and processes the packet when % that identifier is "to= pmost" or "current". Experience in securing and % operating MPLS domains s= hould be readily transferrable to SRv6 % domains, in ensuring that all traf= fic within the network is tightly % controlled, with all external inputs be= ing properly encapsulated (for % SRv6, by an IPv6 header usually with SRH; = for MPLS, by the label % stack). The dedicated format for the MPLS label s= tack and label % identifiers makes a clear mechanical separation between "i= nternal" and % "external" identifiers. In contrast, SRv6 uses SIDs for the = internal % identifiers, which have format and operation of IPv6 addresses. = While % this lets SRv6 benefit from IP longest-prefix routing and thus the= % structure of SID values, it also means that there is not a crisp % mecha= nical separation between "internal" and "external" identifiers. > > % As such, care and rigor in annotating which IPv6 addresses/headers ar= e % internal vs external is required in order to maintain the integrity % a= nd security of the SRv6 domain. > > > > [PC] Thanks for your suggestions. Indeed we should update the draft wit= h something along those lines. > > The comparison or equivalence to MPLS is likely going to be confusing a= nd hence we avoid going down that path. We were thinking on something like = the following. > > Please let me know of what you think. (I have not pushed this into the = draft yet). > > > > >=20 > [re-wrapped for ease of inline commenting] >=20 > That said, I am just offering editorial suggestions; I really like what y= ou came up with -- thank you! >=20 > > The security considerations for Segment Routing are discussed in > > [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model a= nd > > the requirements for securing the SR Domain. The security > > considerations of [RFC8754] also cover aspects such as attack > > vectors >=20 > nit: I'd consider s/aspects/topics/ but it's a bit of a judgment call > [PC2] Changed. >=20 > > and their mitigation mechanisms that also apply to the behaviors > > introduced in this document. Together, they describe the required > > security mechanisms that allow establishment of an SR domain of > > trust >=20 > I would end the sentence here, after "SR domain of trust". Then we could= continue on as "Having such a well-defined trust boundary is necessary in = order to operate [...]" > [PC2] Changed. Thanks. >=20 > > to operate SRv6-based services for internal traffic while preventing > > any external traffic from accessing or exploiting the SRv6-based > > services. Care and rigor in IPv6 address allocation for use for SRv6 > > SID allocations and network infrastructure addresses to be separate > > from IPv6 addresses allocated for end-users/systems (as illustrated in > > Section 5.1 of [RFC8754]) help differentiate internal vs external > > address space that is required to maintain the integrity and security > > of the SRv6 Domain. Additionally, [RFC8754] defines an HMAC TLV >=20 > This sentence got a bit convoluted and maybe a bit long. I propose (only= helping with the "convoluted" but not the "long" part): >=20 > % Care and rigor in IPv6 address allocation for use for SRv6 SID % alloca= tions and network infrastructure addresses, as distinct from IPv6 % address= es allocated for end-users/systems (as illustrated in Section 5.1 % of [RFC= 8754]), can provide the clear distinction between internal and % external a= ddress space that is required to maintain the integrity and % security of t= he SRv6 Domain. > [PC2] Changed. Thanks. >=20 > > permitting SR Endpoint Nodes in the SR domain to verify that the SRH > > applied to a packet was selected by an authorized party and to ensure > > that the segment list is not modified after generation, regardless of > > the number of segments in the segment list. When enabled by local > > configuration, HMAC processing occurs at the beginning of SRH > > processing as defined in [RFC8754] Section 2.1.2.1. > > > > This document introduces SRv6 Endpoint and SR Policy Headend behaviors > > for implementation on SRv6 capable nodes in the network. As such, this > > document does not introduce any new security considerations. > > >=20 > I'm less sure that we want to keep the "no new security considerations" > text. I have a few notes staged in my updated ballot comments, but one n= oteworthy thing that comes to mind is that PSP prevents the egress node fro= m validating the HMAC TLV. >=20 > [PC2] If you would like to use the HMAC TLV then why would the source cho= ose to use a PSP-flavored SID? The SR Policy computation is aware of this a= nd takes it into account upon doing path computation. Note that in rev24 we= added this text as well: It would be a pretty bizzare choice, but (even with the following paragraph) we don't seem to completely prohibit it. > > The headend policy definition should be consistent with the specific > behavior used and any local configuration (as specified in > Section 4.1.1). > I think I had failed to internalize what this was saying, so thank you for pointing it out specifically. It helps a lot, but I still think that "no new security considerations" is contingent on the headend policy heeding that advice. We typically do not make such assumptions when writing security considerations sections, and describe the risks that can occur when a deployment diverges from the recommended configuration. > > There might also be room for discussion (in the main body of the > > document) of how the various decapsulation procedures occur precisely w= hen the packet is leaving the SR Domain. > > [PC] The sections 4.4 through 4.12 do describe these procedures for the= decapsulation behaviors specified in this document. >=20 > Yes, the decapsulation procedures themselves are covered well. I am sugg= esting to mention that the act of decapsulation (generally) signals that th= e packet is leaving the SR domain, where we describe the procedures themsel= ves. >=20 > [PC2] Decapsulation may primarily occur at the edge of an SR Domain, and = RFC8754 describes this scenario in section 5. I agree. I'm not sure whether you are rejecting my suggestion (which, to be clear, is a perfectly fine thing to do) or it just wasn't coming across as I intended. For clarity, I was proposing to add something like "a decapsulating behavior such as End.DX6 is typically (but not exclusively) used at the egress of the SR Domain in accordance with Section 5 of [RFC8754]" as a note at the end of (e.g.) =C2=A74.4, and similarly for the = other decapsulating behaviors. > > Having the ARG structure specified as part of the behavior codepoint re= gistration means that a node that can apply that SID can also spoof the ARG= to force a different (e.g.) outgoing interface list. > > Specifically, it gives the attacker a degree of freedom greater than ju= st the SID behaviors that the node advertises. The HMAC TLV would mitigate= this to the extent that it limits what SIDs the node in question is allowe= d to apply and what changes can be made on-path. > > [PC] The processing of ARG is specific to a behavior defined and not ge= neric. Please refer to the updated text in Sec 4.12 for End.DT2M (which is = currently the only specified behavior that accepts ARGs). Since the ARG bit= s are part of the SID there are no other considerations for them apart from= the ones that apply to the SID as a whole. >=20 > Even though the ARG bits are specific to a behavior (a function, really, = IIUC), if there is a need to have ARG bits then there is going to be more t= han one valid value for the ARG bits. Now that we have removed a descripti= on for the structure of the ARG bits, it becomes a little harder to spoof t= hem, but only a little bit. Given the L+F+A<128 constraint, A may very wel= l be something small, on the order of 10; an exhaustive search over the 2**= 10 possible values for ARG to see which are valid and what they do would be= fairly easy to do. An attacker in a position to do that exhaustive search= (admittedly, one would be violating the "trusted SR domain" assumption to = get there) could be able to observe the different behaviors provided by the= different ARG values and select what behavior they wanted by spoofing ARG.= If A was larger, like 64 or 128, this search and guessing would be much l= ess practical, but we don't really have that many bits lying around. So, I= think this is a new security consideration introduced by the presence of t= he ARG bits in the SID, and we should mention it. (We would also mention t= hat the risk is largely mitigated by the assumption that the SR domain is t= rusted, of course.) >=20 > [PC2] This service theft consideration exists for every SID, regardless o= f the use of arguments. It is discussed in RFC8754 section 7.2 and referen= ced from section 9 of this draft. Well, yes and no. I am imagining some risk about service theft for an SID that is not explicitly advertised anywhere, if the implementation does not specifically check for the exact SID values that are advertised. Consider the case where a single node has SIDs that use multiple distinct LOCs, call them LOCs A and B. If a SID (call it Q) is advertised with A and behavior code X with ARG1, and a different SID (call it O) is advertised with B and behavior code X with ARG2, then this implementation is likely to also process an SID with LOC A, the FUNCT value from Q, and ARG2, even though such an SID is not actually advertised. So, the spoofing allows to create new behaviors in addition to just service theft of expected behaviors. Thanks again, Ben > > services. Additionally, [RFC8754] defines an HMAC TLV permitting SR > > Endpoint Nodes in the SR domain to verify that the SRH applied to a > > packet was selected by an authorized party and to ensure that the > > segment list is not modified after generation, regardless of the > > number of segments in the segment list. When enabled by local > > > > I suggest adding a sentence similar to "(This does, however, require th= at the segment list, and thus, the SRH is present in the packet; the option= al ability to elide the SRH when there is only a single segment and no flag= s, tags, or TLVs needed inherently excludes the protection of the HMAC TLV.= )" > > [PC] All the SR Policy Headend (i.e. the SR Source Node) behaviors defi= ned in Sec 5 state: > > > The push of the SRH MAY be omitted when the SRv6 Policy only contain= s one segment and there is no need to use any flag, tag or TLV. > > So, it follows that if HMAC protection is required, then SRH has to be = used even with a single segment. >=20 > Ah, I see your point, yes. Sorry for missing that. > (But I think my earlier comment about PSP still applies.) >=20 > > Section 10.1 > > > > definition: The value 143 in the Next Header field of an IPv6 header > > or any extension header indicates that the payload is an Ethernet > > [IEEE.802.3_2018]. > > > > nit: is there a missing word here ("frame"?)? > > [PC] Ack, fixed. > > > > Many thanks for your time. >=20 > Thank you for yours as well, and the updates already present and queued. >=20 > Sorry again for taking so long to get back to you. >=20 > -Ben From nobody Wed Nov 25 20:19:19 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E803A0603; Wed, 25 Nov 2020 20:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 header.b=WZBlCxP9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KzfgFZm5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 068QEfrccU0R; Wed, 25 Nov 2020 20:19:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD473A0596; Wed, 25 Nov 2020 20:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=257401; q=dns/txt; s=iport; t=1606364348; x=1607573948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t8GtclahXYKZYRp86vFv8Fr3gIBO0WRhWz7++/AtMOQ=; b=WZBlCxP9pvvApAEyFZGWrQ644c0onZNcD2BIP7aFKxjt9/ZN/pX0pClV NYNZZXPiKEpnTREAG4CbprV76kZjCWtnnLeCloHs1T93vV5n/KaDkxdZ1 4Qnp6WQMUOlDzmuBQlqZ3OHsn5zHsC+JLG0XTgow8skVSOdrJAgRH4CjZ g=; X-IPAS-Result: A0BEBAD4Kr9ffY0NJK2FXbw3SwgDAg8DBgQVAYZIhjk6wmqRHA IronPort-PHdr: =?us-ascii?q?9a23=3A4hCjwRB2vD+b/GFAJqJdUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3GWIza77RPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,371,1599523200"; d="scan'208,217";a="637659319" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 04:19:07 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQ4J7Tv004244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Nov 2020 04:19:07 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 22:19:07 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 23:19:05 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 22:19:05 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EWXRQwFaUHOM5zMxJ8wRU6xG8lTs6KIG4wVawYu/Il7EMYhSF0v8ZcTsqop6LjY2Da81/ut/837U4s+0wDl7ro2eTctqC31zrmY6R5GqRhErZw8oVZKqyq/u6qg8e8nE/tUNBzlBAI00Hl0Qy6aEzRSQWOt958n9MVjCjsiHqyaUjIp6tAdJl9+rg8Te9BCeOQDoYNiULXzoM91ODRGBywdvcLcz5qgH3x0+RUbT5zj2Tbz9DYx6g3GUAHrRu8alZYC3IPipRRlIwSMPQqAFFRkZXYbJS2B2PsEAtoog+w+dLKkZvjJPQu1YkTzuH+7ik0xPGaEqrPeCuC9MBO4pow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2YCvlfWbcAb/1jbgUr76RSK4GHclIAzE+09EJ+6fYEE=; b=KrZ6CKA5UVQhQLwA8na62JeEY4AeNdlh3/AgvG3Wzv5YCDJFothX0eAqcatSNHKHJJyD4T+9kxOhB+rV6oYejcQroKYqZhBoSC7ydiR2xDe9BFhzOLR5dFwc0KQ/I/0CEirADyW8r0ZbudZa8k4xJCDAcThLBIW0yyZ3fw67bq8OTJQdvvyBS25+dVIRjK/jS7deAM8kvXCu9sv4V2JWUzhTOev9SFeHgFQBTdFacGOJSwRAkmK7GYn3KcnfIL44/RPZYnNPW7lGmoFwM39S/hq78NMMGTSt4G/2pGVICuAu+b/KkIs83df/ym/F1MuEtZRdCjv0mHG/affXkQSmYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2YCvlfWbcAb/1jbgUr76RSK4GHclIAzE+09EJ+6fYEE=; b=KzfgFZm5k9yQiCLihKUtu/ZHMf1a2g1vW+Spn2TUM2AGEbI8PiQxNb/MFbaTgcSpT0/fE5XGz1xtYqt3Gg3urHMUqUWmNhJ+mw7yDx65u55uuJ2XLgbZdSlhTiyBE5jpPo1HWsZZGZya+Ciq1rSj9vUm4nbBOK76GP/Ay1vUS6Q= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB3451.namprd11.prod.outlook.com (2603:10b6:5:5b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.30; Thu, 26 Nov 2020 04:19:03 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Thu, 26 Nov 2020 04:19:03 +0000 From: "Rakesh Gandhi (rgandhi)" To: Gyan Mishra , Greg Mirsky CC: IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWw1FAi8Q0V5FtjUGdBFDHCBkgBqnZreOI Date: Thu, 26 Nov 2020 04:19:03 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17af9298-1919-47f6-167c-08d891c26843 x-ms-traffictypediagnostic: DM6PR11MB3451: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xu6IyDh2kq18aQSXDCsIPPJuV22PPXO2yAD+ydEFszmgN1Ph54I3meHbrIU1B3PDnh9cTCFwJdFDhXtZIe1trkKlDG1lH1n/wrUG6hXJ+9V6EBtn50tBZ4kLTm3V+HW3xl+Rkbfn14R0SXNDCsCn1Y918uR/GtDbMqxtduE6S3BrLFXeLeFHOpyiTN3My9eSF9IN1pROZ/0C51SP/z3RCTlnUCoRYS2DmBFvreyEnjdPq2R2U6ORsvAEmNYokB9Sg5rOXbeEi5MKPUkJ/iTqjybiDzc+S1ePj7VENiZe8gVoqXu8SxurER8QFMLRl2rBhSs5MKjLCorPBzrpwdD2BptJfqcQfliNyIbOl/O/OdGkYtYAt8vLu5om6sT3xY4nGrqCZmJRouJr7Hm5F+PKRHmlYtKNlMJIsf3LWFPv2+qBg4pMvb4w+1YEvE/Ct5Tb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(366004)(376002)(136003)(5660300002)(76116006)(86362001)(91956017)(8676002)(71200400001)(8936002)(66946007)(64756008)(30864003)(54906003)(66556008)(110136005)(316002)(66476007)(66446008)(9686003)(52536014)(2906002)(186003)(7696005)(4326008)(53546011)(478600001)(33656002)(55016002)(166002)(26005)(83380400001)(966005)(6506007)(559001)(569008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?fbV/aIzf9MwOo1xI8GgH7Jmz27ZESCUTc7sXq0ywdPnRe1B5TTaHoB97?= =?Windows-1252?Q?paE74K963sLu3DKblY2M2jS+GEFVyeEAyQELed0O8apNfWjqg+Gp9mJI?= =?Windows-1252?Q?MAYn8NZo7Vd6Pgx9+3+z2j8pOvOo7If7GDy2hPP9jDPf4RITmGoqW2qq?= =?Windows-1252?Q?RZUo68oesexDzEU/Ieg8Yutxh528+WL7zzwz7yA1sh1+dhki2XWhw5vL?= =?Windows-1252?Q?IqxFveZiHfR4+WVr1WmiTpQE0w9b/5deqVNs4CY6YioLwjjApG/WbK6P?= =?Windows-1252?Q?1VnuXVwdz9123+SZ/GCt1jLPyNx7PdzYM1ChwkNaMOl90Nc+IGfqwB1u?= =?Windows-1252?Q?K7iThT+KUDlge+5vFFkEgmsTsH7+sllwZnjMJwHDsN6QtT6GM+jxAY85?= =?Windows-1252?Q?YM7eOh6tYtZwwgMuIJCF2b866l03bu7ZUVLRYzINaCRMfpd4ckjhERI1?= =?Windows-1252?Q?JiuPMCHQUoYNy42mI+gqBSWk5VkZrmPR/cZQKIfT9kZ/3I0QDFZuVVYj?= =?Windows-1252?Q?7soGVfRnwQJWmHZFwbx3TRuNwO5ZiwAr4fzj+TG+AytS/154Uaq0nQA0?= =?Windows-1252?Q?KGyQhcmRDXIwhZiWZ35gUMHHHCGTAoEXAT/IK0IpGaZKydYai1Uuxk+L?= =?Windows-1252?Q?3Cif2g+fEhL4pk5iZS+Nm0U0q56KEVYOAL/o3WaxutkV60oi+fyx7G8s?= =?Windows-1252?Q?3lC1Z5vMMWm+0ldF8IcGDAp2YH2hykUAHpX0QpF+KpCfunFEsDkvHp6t?= =?Windows-1252?Q?mqQsWMco39T1Fa3LoMmkwAWJ+a+f7l0DYM6J6/bY2hWBffU6vYyHy6IP?= =?Windows-1252?Q?u15xz+oxCaTPAQhAeoWF2wsgOcBzVxekjSbCJDoDAqFd0ZBAv0/nkYXa?= =?Windows-1252?Q?Qhli92Ej+QcWZYImD5D21bM0sCoJsRB7815ZPnx2Km3dE8ivxwXs+ZF1?= =?Windows-1252?Q?jazDz0Pc+RoX5T6e/ilzhtKWsZBfGXCz5puRedejNz1ED9zGFPA8y1YF?= =?Windows-1252?Q?uoAvBWC06xu6TjPB7LxuA/NNr8zj3s0kmnMocMuVn3m6PuOM/JHOPyqa?= =?Windows-1252?Q?xoglOrWus3LwX38Ia7SszcK8C3bIsk4fGh8zDw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3115E8AAC89CECAA553E8191BFF90DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17af9298-1919-47f6-167c-08d891c26843 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 04:19:03.0757 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OBBT8P9yNKeLuDyoAAestS7qkUxVliqZaSmdSru5orP1nhRPSRFmQ5MMNhIic/1aK3aqZkSVdJpzOBt1YeZ/xw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3451 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 04:19:18 -0000 --_000_DM6PR11MB3115E8AAC89CECAA553E8191BFF90DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Gyan and Greg for your review comments and discussions. Please se= e inline replies with =85 From: Gyan Mishra Date: Wednesday, November 25, 2020 at 12:34 PM To: Greg Mirsky Cc: IETF IPPM WG , James Guichard , Rakesh Gandhi (rgandhi) , ippm-chairs@ietf.org <= ippm-chairs@ietf.org>, spring-chairs@ietf.org , spr= ing@ietf.org Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh I have been following this thread and to help progress the discussion I wou= ld like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes i= n-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm > Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard > Cc: spring@ietf.org >, ippm-chairs@ietf.org >, spring-chairs@ietf.org >,= IETF IPPM WG > Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. But I d= on't think that switching the terminology will fix the fundamental issue wi= th the proposal. The operation that is required from the remote entity, whe= ther it is referred to as responder or Session-Reflector, is not defined in= Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, th= e behavior required, as described in the draft, cannot be characterized as = an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new = protocol that, if there's a need in the new PM OAM protocol, must be proper= ly defined. Gyan> I am in complete agreement with Greg about terminology and consist= ency. The problem with inconsistency is that that you are not following we= ll known normative references required to understand the specification lead= ing to confusion and misunderstanding of the specification. The goal shoul= d be clear and concise in terminology and verbiage. Agree. Will address the terms from RFC 5357 in the next revision. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "tw= o figures or objects are congruent if they have the same shape and size, or= if one has the same shape and size as the mirror image of the other", it l= ooks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet o= f an active OAM intended to monitor a flow over the SR tunnel is out-of-ban= d relative to that flow and will not produce any meaningful measurement. Of= course, for the case of the extensions in drafts *-twamp-srpm, direct loss= measurement can be performed, as information collected from node F and pac= kets that collect the counters are not required to be in-band with the moni= tored flow. So, this example, in my opinion, illustrates two of my concerns= : =B7 using a congruent path for active performance measurement, e.g.= , TWAMP or TWAMP Light, may produce information that does not reflect the c= ondition experienced by the monitored flow. It seems that the terminology s= hould reflect the fundamental requirement of ensuring that active OAM test = packets are in-band with the monitored flow. =B7 there are no technical requirements to justify using in-band te= st packets for direct packet loss measurement. In fact, using the in-band m= ethod for collecting in-profile counters leads to a waste of bandwidth, whi= ch may have a negative impact on services that require low-latency and/or l= ow packet loss. As demonstrated in this example, direct packet loss can be = performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notif= ications based on YANG data model. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. Gyan> This may sound basic but is a very critical subject going down the = same lines of clarity in verbiage so their is no misunderstanding. =93Cong= ruent=94 by definition means shape of an object and if you super imposed tw= o objects on top of each other they fit perfectly and the edges coincide id= entically. The problem with congruent is that it is based on the shape and= that shape could be a mirror image or reflection which may not be exact. = So when referring to a SR-TE path taken this could lead to confusion as to = path taken if it=92s the same path or congruent which is vague as to =93exa= ctly=94 which path is taken where here there is criticality as to the path = being referenced in terms of in-band versus out-of-band. I agree that for = direct in band packet loss measurement can be done via existing OAM mechani= sme via ICMP. Ok, we will find an appropriate term for =93sending packets on the sa= me path as data traffic=94. Extending ICMP for direct-mode loss measurement is outside the scope = of this draft. But good to see the agreement for the direct in band packet = loss measurement to be done (albeit by some other means). There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP for exclusive = direct packet loss measurement. Gyan> Agreed There is definitely a need to do direct-mode loss measurement in IP/S= R networks, as RFC 6374 mechanisms are for MPLS networks. Note that there w= as an attempt to extend BFD for direct-mode loss measurement for this purpo= se using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-0= 3). * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough = vetting of RFC 6936. Yes, will add in the next revision. Hope we can work together on need= ed text. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. GIM>> I cannot find where RFC 5357 defines "the probe and response messages= ". Could you give a more specific reference or provide the text that, in yo= ur opinion, defines such messages? But I'm more concerned with the directio= n of "extending" non-protocol referred to as "TWAMP Light". As a contributo= r to BBF's TR-390, I'm have learned how different are existing implementati= ons of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interopera= bility 2019 white paper. The status of TWAMP Light is explain= ed in RFC 8545 and I cannot see that it can be used as a foundation of any = standard. Gyan> I don=92t see the probe a d response messages in TWAMP RFC 5357 Agree to use term test-packet from RFC 5357. * several parts of the proposed protocol, e.g., Zero UDP checksum in IP= v6, require detailed security analysis, which is currently absent; Gyan> Agreed Please see previous reply. This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. GIM>> I've noted above that a simple reference does not sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol. I believe that the proposal = to use zero UDP header checksum requires extensive analysis, using the anal= ysis provided in RFC 6936. Gyan> Completely Agree Please see previous reply. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If= anyone is interested in standardizing an "extension", I'd expect that they= first define the base specification to which the extension applies. I migh= t have missed the definition of TWAMP Light protocol in the draft. Could yo= u point to the definition, for example, of the Authenticated mode in TWAMP = Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? Gyan> Agreed The Appendix I of RFC 5357 does have information on the Authenticatio= n mode. As specified there, this is based on user configured parameters. * I believe that draft-gandhi-spring-twamp-srpm should be anchored at I= PPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, I= don't think we can have a draft that proposes extensions to a non-standard= mechanism (Appendix is for Informational material, as I understand it) on = the Standard track. Gyan> Agreed The procedure for using the RFC 5357 defined messages in TWAMP Light = configuration mode is defined in the corresponding spring drafts. It also d= escribes the provisioning model. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the li= ght, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot f= ind in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode = of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light. The Authentication information is user-configured as shown in Section= 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 GIM>> I think that the text you're proposing is even more confusing. It is = not clear which example the sentence is referring to. Also, what is the bas= is for such an assumption? This is the exact text from RFC 5357 Appendix I. Please go through th= e entire Section in that RFC 5357 to avoid =93out of context=94 discussion. * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a nor= mative reference while it is, by its nature, an Informational document. If approved, it is fine to have informational draft/RFC in a normativ= e reference. But RFC 5357 is PS. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? GIM>> If that fits into the operational model of the new protocol you're de= fining. * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). GIM>> Thank you for the references. I couldn't find a definition of an obje= ct "Link" (capitalized) but only "link" (lower case). Hence, since the draf= t consistently uses the capitalized form, I consider it to be something els= e, something different from a link. Ok, we can change Link to link in the next revision to avoid confusio= n. * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Gyan> Valid point Bidirectional SR tunnel may have an SR state but the statement above = is that no PM (i.e. TWAMP Light) protocol session state is created for it. = We can clarify in the next revision. Quoting the text from Appendix I in RFC 5357. We can quote the text as= is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 GIM>> By the informational nature of Appendix I, the text is not normative.= I am familiar with the implementation of TWAMP Light which does maintain t= he session state and thus supports one-way packet loss measurement. If you = require that the remote node does not maintain the state, the draft must de= fine that as part of the specifying the behavior of the protocol. Ok, we can discuss what information is to be maintained in that state= on the reflector for synthetic packet loss. We can add appropriate text if= you can help please. * Further, in Section 3 the selection of UDP port explained as the foll= owing: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. Gyan> Agreed Yes, we can use port 862 for both delay and synthetic packet loss =96= they are using the same test packet. There is no change proposed in the dr= aft. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 GIM>> I've found that there's some misconception in the draft. RFC 8545 re-= assigned UDP port 862 not for "delay measurement probe messages" but for TW= AMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, pac= ket loss, reordering (RFC 4737 defines packet reordering metric), and packe= t duplication measurement. * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Gyan> Good point Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ GIM>> I've looked through Section 6 but I don't find anything specifically = applicable to this draft we're discussing. If the protocol to use UDP port = numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it= seems that stating that explicitly would be the best way. This would be, User Ports and Dynamic Ports ranges, which are defined= in [RFC6335]. Yes, we can add this te= xt. * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measur= ement uses port number different from the one used by a TWAMP-Test packet, = in my opinion, is another indication that this is the definition of a diffe= rent from TWAMP Light PM OAM protocol. If we add a field in the packet then UDP port 862 may be used along w= ith the new field. But it will require extra processing in hardware. It is = better to use a different UDP port for processing efficiency in hardware. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draf= t-gandhi-ippm-twamp-srpm? Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? Gyan> Agreed. The use of congruent in the context of pathing is con= fusing as the path being addressed may not be reflected accurately by the t= erm congruent. As replied above. There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. GIM>> I cannot assume what was the context of these RFCs. I've sketched a n= etwork diagram above to illustrate that a "congruent path" may well lead to= out-of-band path. Is that the intention of the authors of the draft to use= this protocol out-of-band? As replied above. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. GIM>> Yes, but it appears that references to the two IOAM-related drafts ha= ve some purpose. What is it? How are these drafts related to draft-gandhi-s= pring-twamp-srpm? We can remove them if it is confusing. It is informational text (was = added to address a review comment). * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. GIM>> I think that theremust be some discussion on how the new protocol is = configured. If TWAMP YANG data model can be augmented, I'd expect that bein= g defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything abo= ut the configuration of the protocol. The Yang model extensions are not in the scope of this draft. * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. GIM>> True, direct loss measurement, in fact, is not active measurement and= thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). = The direct-loss measurement is, by the definition of RFC 7799, passive meas= urement method and fetching counters can be done using numerous methods, e.= g., SNMP, Netconf. RFC 7799 does not say using Test-packets to collect counters for dire= ct-mod loss measurement is passive. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? Gyan> Good question Yes, it is unique in the domain. This is user-defined and is up to the user what UDP port to provision = in a domain. GIM>> So, can user configure a port number from the User Ports range? Or, c= an the same port number be used on the same system for a number of test ses= sions? I find the use of UDP port numbers being underspecified. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. GIM>> I think that making it explicit would help. Also, that will highlight= what is being introduced by *twamp-srpm drafts is, in fact, a new protocol= to perform synthetic packet loss measurement. No, it does not change anything for synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Coul= d you please quote from any of these documents? It is test-packet, we will use RFC 5357 term. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the sym= metrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Contro= l protocol and Appendix I in RFC 5357 tells us nothing about that either (i= n part because RFC 6038 came later), I don't see that there's any certainty= in what is the sze of a test packet used in the direct-loss measurement. The test-packets as defined in these existing RFCs are used for delay= and synthetic packet loss. The direct-mode test-packets are defined in thi= s draft. * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twam= p-srpm? No change in existing in what is there in RFC 5357 and RFC 8186. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. GIM>> Perhaps you can propose some text, that would be helpful. Ack. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . Some Session-Sender can use authenticated and some not. It is part of= RFC 5357. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. GIM>> I cannot agree with your statement " The rest is the same as RFC 4656= and 5357" because the sender's direct-loss format does not have Error Esti= mate field, Thus, a reflected packet does not have Sender's Error Estimate,= nor Error Estimate of the reflector. And that, in my opinion, is another c= lear indication that *twamp-srpm drafts define a new protocol, separate fro= m OWAMP/TWAMP. That field is specific to timestamps and would not apply to counters = for direct-mode loss measurement. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). GIM>> I am not familiar with the term "pre-routed". What does it mean? Ensure that packets are routed over the link. * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). GIM>> So, LLA may be used as the source and destination addresses when test= ing an SR tunnel? As mentioned this is for links. * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. GIM>> You don't agree that the processing described cannot happen because o= f laws of physics or it wouldn't happen because no one will think of that? = If the latter, I think that that is security threat. There is no new threat like you have mentioned. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another= new protocol OWAMP Light. And it is not clear what you reference as "this = is existing behavior". Is it to reference behavior of TWAMP test packet? Bu= t the behavior of the TWAMP-Test protocol by itself is neither in-band, nor= out-of-band. It is the encapsulation of the TWAMP test packet that makes i= t either in-band or out-of-band. Right. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. GIM>> So, you believe that proposing to use the method described in RFC 840= 3 for the TWAMP packet is innovation? And what are the benefits of using th= e TWAMP test packet format in the Loopback mode? Please see the draft. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). GIM>> I believe you've misunderstood the text in RFC 5357. This bullet spec= ifies the behavior of a Session-Reflector. It is to try to read TTL value o= f the received TWAMP test packet and copy the value in Sender TTL field of = the reflected packet. If the Session-Reflector cannot access the TTL field,= it MUST write 255 in the Sender TTL field. So, I think that my questions s= till remains. Please see Section 4.2.1 of RFC 5357. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. GIM>> I don't think that the reference is sufficient for the Securit Consid= eration. I'd expect some extended discussion on why using zero UDP header c= hecksum is not a security threat for *twamp-srpm protocol. Please see reply above. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. GIM>> Can you point to a document that has defined "TWAMP probe messages a= re used today for synthetic packet loss"? Also, which document defines loss= of connectivity as a performance metric? Does *twamp-srpm proposes to use = the new protocol to detect the loss of path continuity? For example Y.1731 has such notion of connection loss. TWAMP is used = widely for synthetic packet loss and is well-known. There is no change in p= rotocol. This is reported metric. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use = of source IP addresses, as mentioned above, appears to be another security = risk introduced by *-twamp-srpm drafts. There is no mention of Source IP address above. * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? Yes, they need to be in-band with the flow, to collect the counter f= rom the right forwarding paths for the flow. Discussion of using ICMP for d= irect-mode loss measurement is outside the scope of this draft. As mentioned earlier, I am not sure extending ICMP to do PM is a good = option here. Both TWAMP and OWAMP are widely deployed today for delay and s= ynthetic loss measurement. GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend R= FC 4656 OWAMP as well? Also, what you see as the connection between using a= ctive measurement methods to measure packet delay and packet loss, on one h= and, and collecting packet counters? The Session-Sender test-packet is defined in OWAMP RFC and not TWAMP = RFC. Other than timestamp and its format vs. counter and its format, the me= ssages and processing are the same. Thanks, Rakesh * Section 3.1 introduces the new field, Sender Control Code. The format= of the packet, as I understand it, is presented in Figure 1. When comparin= g with the format of Session-Sender's test packet defined in RFC 4656 OWAMP= in Section 4.1.2 I've noticed that there are no MBZ fields. Are these intr= oduced by your proposal? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. * Also, it appears that the Sequence Number field in TWAMP Session-Send= er's test packet is absent in Figure 1. Is that intentional? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. Thanks, Rakesh Regards, Greg Thanks Gyan On Thu, Oct 22, 2020 at 5:51 AM James Guichard > wrote: Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_DM6PR11MB3115E8AAC89CECAA553E8191BFF90DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable --_000_DM6PR11MB3115E8AAC89CECAA553E8191BFF90DM6PR11MB3115namp_-- From nobody Thu Nov 26 02:43:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA83A110A; Thu, 26 Nov 2020 02:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 dgFYGuHvHGXk; Thu, 26 Nov 2020 02:43:05 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60109.outbound.protection.outlook.com [40.107.6.109]) (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 1FBFC3A1109; Thu, 26 Nov 2020 02:43:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVkLQj+SZbUlcZUqOqdkgw5TZcgUDt6k3hK2lEbkrU5PozAMHNHgHIAIzS+YHTTU8ParSmqTEB98aqnZHHgANqoMkVVymj0xW+FR39QmU7/cXSY62RZ0HxmwFLFcF47yYRhpUXLu6HcUViMqgWP2VFffKSJpgA2yWzMyFa6rZLqO7Cy/1SlAUJRzlwtVcIq7STCljWmSc6Cy5FIPc8aiulNioq6VlFHWCrleLfzTEWQUbOpmjOtVPD4vvuLchuZcXhhv7JyyFcqaNwvoxMvSWpYzO7sSZF4qKWHmrVEea1pslRDPz80tCab1+uCYemrozzRauLGtwWLCfdRCzvvnnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jYJ6FzAmihE4jpf8cYRoX/JTbkgMyBzlmX/SN//WJDY=; b=BEzj+8XvjqsvBH60bi/LzxXJZlRt+iHWiitDKmlA0lc45bTc+ajpnIBfeamBLxifcJ3U0vVXFX1ABZvm9uKtK1QwiBH90QPFB0U82fStXUwbN1sFYWJjFbRsqkPdkqQQQm/SVgKQZQtPFPp/w1Q4Iy0Rbl0ZUSgP+kU9GBESSaBfj8/y2VmYKdu2YRxMLvnA6Dx3QXSb7kvBQFDaJFW3NvKZxK4Gf24ZjSlfhdQTMbE5tVoS16EMHtWUuDLFLdwu43n6tRaFrZmFZdfCpgpNVgBEnVBRm4pbaj5hrzt9pOGQc99seIvmiliEoKGTe1qmMJo1HN3B7qpnmPdo04LOUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jYJ6FzAmihE4jpf8cYRoX/JTbkgMyBzlmX/SN//WJDY=; b=tMfGAWA/oCydXJ9mDdNw+50gTk8X7qAxczgdngS25TeYLqt4b32NBwNlNcAFXXXVsKMqCjwoxBNLlD0xlHuioBNJx77y0QhEr6wPNK98OzzVN7sleIQhS1Hnw2XN6igaL5wro7er0WaLN6oiNbWiIZ/FQMja67gMIILzWHnheA4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB5341.eurprd07.prod.outlook.com (2603:10a6:803:af::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.9; Thu, 26 Nov 2020 10:43:02 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3611.022; Thu, 26 Nov 2020 10:43:02 +0000 To: "Acee Lindem (acee)" , "last-call@ietf.org" References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <5FBCD392.3050706@btconnect.com> Cc: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" From: tom petch Message-ID: <5FBF86B2.7020907@btconnect.com> Date: Thu, 26 Nov 2020 10:42:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <5FBCD392.3050706@btconnect.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0208.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::28) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0208.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3611.20 via Frontend Transport; Thu, 26 Nov 2020 10:43:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b95ae52e-4f7d-40c8-4626-08d891f80c5b X-MS-TrafficTypeDiagnostic: VI1PR07MB5341: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:962; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SYEOZ1AUA1gvrG0FzUYntmM4ap1lzzGE783fjk4ZyVRqUiPyMOYkCpYze4wGjv02l/mJcjuDi/gXXd7rw0glwLsrfkmcaIGcsHQLQAuFPZYzyWb0SFkIdHyxU57SqUPqIMu1c9hbSniXQtqo5l+xFgYw0dk5caUxSDKwuDEW99pRhpsI2c48xizrmXZBnIg0eV66QtJ2UzS0P8E0NTQUzbAAra3gnvvCouno4NJfhXxW9HTE7j/C7wV8Ni7YRV6EgYnB5EfgYPiEiLcBJrPOPaqrKW1bVKAwz25kQaKwSXjNLoV1iGkNJ/06aHf21wJ9hPFe+Pan47rMb50WT0YYNw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(376002)(346002)(39860400002)(16526019)(186003)(5660300002)(16576012)(86362001)(6666004)(66476007)(36756003)(66946007)(6486002)(87266011)(110136005)(316002)(4326008)(66574015)(2616005)(54906003)(26005)(52116002)(478600001)(956004)(8936002)(8676002)(66556008)(2906002)(53546011)(83380400001)(33656002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?YWVENEZRemszYitQRmhwSEo4TndqOHBHTjd4NmFlMDhiUlZoQXkyT1hHdGxy?= =?utf-8?B?eTc4L0ZWdmdicmZRNnhhR1lBTTJ0dDZxTCtnZnM2WGs2TE5sSlFUaE9KZHA2?= =?utf-8?B?SVFkdVpaZCs1TFpYcVNhdHM3ci9pUzQzRk1TejJqb1FaakxNbXRiWXZ4dGpY?= =?utf-8?B?YzRSeUNWZ2xsQitQV0E3Rk4wSlpic3ZlWFNlTzlaRHk2Z3JkK04yUEE0eWdq?= =?utf-8?B?ck11NjZPMUR0VWFxZ0tZeXRGT1RwNUxTTTc3b29OWDJSUm5iN1F3ajRkaW4x?= =?utf-8?B?d0h5Q1VHeCtOTGx5V0gwMUVvdnBhTEZjZi9KRXRzdVFlK2txYkRCQktGdkRw?= =?utf-8?B?MTZoQlB1WG94cm54c3hHNjJkSFAreE1DbUhXUlFxM01LTzlQQWZZL2MrMkx6?= =?utf-8?B?QzgzeXo4NExPZXlZSDRyeDY1bng5ZGx1anRKRTJhQ2o3ZVFJSHAvQjJJQ2to?= =?utf-8?B?NmR6VTNRZklOUnc5ZmcxZThSSFUxcHJ4RFYvYjVHWUNWd29OemVYRkY4dldY?= =?utf-8?B?ZGk1QUF1TnRnM0h5S1NOZ0w0Zjk1QnlYK3RkNGpwTzVnd3paV09vNUorZi9p?= =?utf-8?B?WWFmOXNQTXBrQUZnYTdqbit2NEJCK0hnVzZ1aVRYZTFnNjd0VTJPOEpSL0tE?= =?utf-8?B?YnhDK1VjeXl0N3B4NmlZNUM5MnVaVDEzYjBuSW80djE1OWNubUhrUHJaY1RE?= =?utf-8?B?aHJvUk84aUhIQnFkTENxYWdvZTMra3pPS243VlZ3M1YrM2NLT3FsN0FXbDFK?= =?utf-8?B?WjBYL09nUllBaThoT1QxS1lBRk5CcVZsWXE1b3Y5M29GdGV4SE9yd2Zvd3Fi?= =?utf-8?B?MnJDZ1I4WEdITGp0SHRxZDU2RGtvRDM3VVRRVmUxN01lQ1JaVjdaSWVwdnBE?= =?utf-8?B?VWI0TVRxdWJMTE9NMHNyUHhlS2ZLbG1Dc3lqQzZiT0VmZ0paWG1teXhjdnRE?= =?utf-8?B?MmJURk84UFRtU2Zvb0IxNUZ0d0JuQ0dKMmlkUjVrYStBS3VRMEoyeFQxdW9W?= =?utf-8?B?YmZNT3V2TEU4YyszRlpyZmtRem4xbXREZDZJaG5ldG1MQXJEQWlPeWpyR0h6?= =?utf-8?B?a29SREd4L0hqVmVRb1lSNzE1Ujg4UStHcTdWQStvVUVGNzJqdnZoek0za1pM?= =?utf-8?B?SzViRXp6YVcwa1BnNUFnM0cvdTBMcHA5U3dsWWxzV09tdmRvNUs5bElwd2tk?= =?utf-8?B?cndralVTWFRFaTM3ZTErTmVxYksxSnE5Qzg0dnFaSE5rRFNTSUtWOHJkdHR3?= =?utf-8?B?NlN4RXZFNXYwQTdWRVJQbUtUZDZERHZQdDFFakVTVERpR29BdmloZm9Ob2Vv?= =?utf-8?Q?Pv0qY46dRMvOeAQkfFzN1Zdjt/wwPtZbO3?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: b95ae52e-4f7d-40c8-4626-08d891f80c5b X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2020 10:43:02.0908 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7xpIKMOWCuIU9xq5X786TBAY4fXiUQ0x9NoXEebbnskt8z9Goyzvh3DFhYgi5CsPfiQEnLpw4qeUxbuW4t5Axw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5341 Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 10:43:08 -0000 I have looked at -26 and it looks good apart from BGP. BGP gets a mention in passing but does not get the same treatment as the protocols of the LSR WG. I am unclear whether or not this I-D is intended to include networks using BGP or not with e.g. signalling of MSD and would value a clarification in the I-D. I wonder about the final D in Maximum SID Depth (MSD)D in the YANG; I suspect that it is spurious. Tom Petch On 24/11/2020 09:34, tom petch wrote: > On 23/11/2020 17:27, Acee Lindem (acee) wrote: >> Hi Tom, >> >> See a couple responses inline enclosed in and . We are >> addressing the rest of your comments. >> >> On 11/18/20, 7:39 AM, "tom petch" wrote: >> >> IANA Considerations does not register the module names used in >> the modules >> >> >> This is in the IANA considerations... > > > Indeed; I do not see a registration of ietf-segment-routing-mpls! > >> This document registers a YANG module in the YANG Module Names >> registry [RFC6020]. >> >> name: ietf-segment-routing-common >> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common >> prefix: sr-cmn >> reference: RFC XXXX >> >> name: ietf-segment-routing >> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing >> prefix: sr >> reference: RFC XXXX >> >> name: ietf-segment-routing >> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls >> prefix: sr-mpls >> reference: RFC XXXX >> >> >> Examples are IPv4 only, IPv6 would be good >> >> BGP is included when it comes to defining a router-id but is ignored >> everywhere else, such as signalling MSD, protocol extensions etc >> >> reference "RFC XXXX" would be improved by including the title in all >> cases not just some >> >> the scheme http: appears in many places. It would be lovely if this >> really was the scheme but I fear that it is not >> >> This is directly from the RFC 8407 template in Appendix B. What would >> you suggest? > > > Many I-D do now specify https: since that is now the only option > supported by the IETF; I have seen this called for by an AD. > > >> >> >> module srcmn >> the upper bound must be larger >> the value must be greater >> consistency is good - I think greater is better >> >> 8.3 >> operation states >> usually operational >> >> two imports lack references >> >> typedef router-id >> this is a well known type from RFC8394; it seems likely to >> confuse to >> redefine it with a related but different meaning >> >> leaf enabled >> enables protocol extensions >> which protocols? >> >> leaf protected >> it is used to protect >> how does it do that:-) >> >> enum dual >> ... In this case will be advertised with backup flag set >> What is the backup flag? It does not feature in RFC8660. Needs an >> explanation and reference >> >> container link-msd >> list link-msds >> leaf msd >> The usual YANG convention is for a list to be plural and the leaf >> singular. You have the plural list but not the leaf. >> >> So you are asking for a change from "leaf msd" to "leaf link-msd"? > > > Yes I would especially given node-msd. I wish that YANG Guidelines said > more about container names. I think that having the same identifier for > container, for list, for leaf (which I have seen in another I-D) > will lead to mistakes so having a convention for list and leaf will > reduce mistakes but having another for container would be even better. > That said, I have yet to think of a good convention > In passing, must link-msd be >= node-msd? > >> >> >> >> And who needs the >> container? This is mpls not a common module that might be >> augmented so >> what does the container give apart from complexity? >> >> list policy >> leaf string >> YANG string caters for very large items of very complex character >> sets. >> Is that desirable? >> >> IETF models normally do not limit identifiers. An individual >> implementation could do this with a deviation. > > > I know - I did see an AD challenge that, I think in IESG review, not > long ago. SMI was better at this! > > Tom Petch > >> >> >> Thanks, >> Acee >> >> leaf used >> will used plus free equal size? >> >> Indicates if the binding is /instal/installed/ >> >> notification-segment-routing-global-srgb-collision >> a mix of conflict and collision; consistency is good and I >> prefer the >> latter which is the name of the notification >> >> containing /s/a/ mapping >> >> ... sid collision >> again consistency good, prefer collision to conflicting >> >> s.9 >> I would have thought the srgb worthy of mention under sensitive >> nodes >> >> Tom Petch >> >> >> On 16/11/2020 19:32, The IESG wrote: >> > >> > The IESG has received a request from the Source Packet Routing >> in Networking From nobody Thu Nov 26 06:15:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E103A119E; Thu, 26 Nov 2020 06:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=PmZenp0n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IQDpowst Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp4785GmT3xM; Thu, 26 Nov 2020 06:15:28 -0800 (PST) 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 027993A119B; Thu, 26 Nov 2020 06:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=106078; q=dns/txt; s=iport; t=1606400128; x=1607609728; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LkPU02AxxVJOY3tNY2gAjZ/so7ssaR238T8uOPgJpUU=; b=PmZenp0nlC/Pg1AyGbZXQkc9fteEJjuig/54VaE0VZocFGSeVrg4OrNc zsNukWbDEG1tpsUZPJkBvVw7XrOpupq6FEcxEUKPRCtXcLn2wDkE8LM4z SOGX0H0SIhJ8N+FKaIOys+n5DQw7FWEqHDX8jimi5o/Nb8T70bwZIpHyq Y=; X-IPAS-Result: =?us-ascii?q?A0CjAAA6uL9ffY9dJa1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgSMvIy58Wi8uCod8A41bihaOb4FCgREDVAsBAQENAQEYA?= =?us-ascii?q?QwIAgQBAYRKAoIoAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBhjwMhXIBA?= =?us-ascii?q?QEEAQEQCAECIwEBJQcEBwEPAgEIEAEDAQEBIQEGByEGCxQHAQEFAwIEAQ0FC?= =?us-ascii?q?AwHB4MFgX5XAy4BDqN2AoE8iGl0gTSDBAEBBYEzAQMCDkGDHw0LghADBoE4g?= =?us-ascii?q?nOCZk6BSIE+hBMbgUE/gRABQ4JVPoIbQgEBAgEBgSEFARIBIwUZBgcJAoMSg?= =?us-ascii?q?iyQKgISBgwJKYI5h2GDLpkNCS9XCoJuiReGaYYVhTiDHIochVCPCZNjiwaCc?= =?us-ascii?q?o44gVCCbAIEAgQFAg4BAQWBbSFpcHAVO4I1AQEyUBcCDY4hDBcUgzqFFIVDA?= =?us-ascii?q?XQCNQIGCgEBAwl8jlEBMV8BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A5Q3PhhbQAceg2OvpNloXNJL/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD4re4vNAzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXxYlTTpju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,372,1599523200"; d="scan'208,217";a="601041568" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 14:15:16 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQEFGb1026782 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Nov 2020 14:15:16 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 08:15:15 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 09:15:14 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Nov 2020 09:15:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSXRNvJqKxldE7hI51MTA4nV4q+8eICEDCUw7rgVsDM4M+cZYFGgORvN9jig7k3W5OxVBH+nH8u7bhNPc0SyeQmXesyWZiJpteaVg/KUDRyr2DT3ZtDBK/R8vCZ9/5QwylYbaZ7hZoGw80ryvvBFPwV9AFj12DSXJIxjHQXZ7pXo9vX8xklqZxF6TPFeMzADVTN+rBApzBMFqU6DxmbSrlgU+f3bODNfIdmYIzjRfXj88C+64yGyYVrGcuad7ff88YW2u22StW7N+jhiA1veiQAQrnhRH3uYB/eXdTDlz1/15JbnfXgMOM7QSoq9WHNT0FaJZZf/bS9BjkMUx2HdIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aZEZUhN5OPGjvoJtwyGZEPl7zdRJlFgjsZcHHzeGRls=; b=E6YTRdwJDq2ziwJKZhOI9faAsc6ZSy4fB8hocaTAg4XK6l09DZiZmSinq9iT/masIKXLuO+MgSxTv7J9tmYlGVI6Qkd/I6JbwIZQEEm3NkvcoyJhNf/YmEyZtLPL5etbCurXHGhE6xVIyEcBO60kXv0HSzU2QDUgVmW/aL0AfnR1K9iU3ARGtj79pfLdY75ns/JLWJo3OV4zs59mPdnH/qrnH+/86c71Rl4mjyvFWYJX1y5fYY/V0lfK8Kdsa+AS5qxIzy6dAxDxUzCQII1zwk+Jqo36558Wu2Sov7tjDhJ1rXn1WeYUeDYUDTvIiUEPY7wVre7CX3/O5HE1lrPSwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aZEZUhN5OPGjvoJtwyGZEPl7zdRJlFgjsZcHHzeGRls=; b=IQDpowstVJ2L4PmpiCto4J9qus9WSq6q5OirC/mW2f65/kHaTrcZkdijycLLImBoG+0rNWlFPVZa8hrb1tyi2uaC0Yjj8XDSbqI6+ccqzlqNmnV5iGK7t6iFB+wgQkEmnGNXk1UnBpdiGnAJ7kHfU8+upS/n1mvRgqg/yn1UdGU= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2874.namprd11.prod.outlook.com (2603:10b6:5:c9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Thu, 26 Nov 2020 14:15:11 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Thu, 26 Nov 2020 14:15:11 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky , Mach Chen CC: Tianran Zhou , spring , "IPPM Chairs" , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KnAEieAgAGGXIqABKdzAIAEHsI6gAAB1ACAAqNDgIAAE4+WgAH1xICAACO6gIAAo7qAgAADtrqACsFURg== Date: Thu, 26 Nov 2020 14:15:11 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bff4696b-abf5-40fc-1e70-08d89215b00d x-ms-traffictypediagnostic: DM6PR11MB2874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DuECtsZEyTceI/psQVYwfJSUPrM0NaBcN7+m3O2fYnkiVTe04t9zWVoqGwJQ6q4Lo8os3vDj6OVgceR0FekWWbzv8wOs5JegIxmM9ZirzFoc1ywM1J8TgUwn+DPqZynMsCYfOMbxdN7wqfeUg2fNtp8afKCogzX1vNrEhH2BL2TCbrrnSvqtIFpUsNCndlt1Tc9/mKqXMbEpfrULizdQvTFGL3kkM07e1sunD1u/guv4IhLVVBbmpK0FuO7pJyXpy0T/rQyxsinCQ4MeiMjhjT4KnM8ZK194ViHX0bfrsncHhg5m0fktk8uOO5HzNYOpkW+YVxHPs9peQ62+wkUiICNqOusPFEKpdzn/e3ESHdsTV1P3qrGTQ5BPjCcsVzjtMAzcMpP9iLHGLNLzQiU0gA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(136003)(376002)(396003)(366004)(8936002)(26005)(186003)(478600001)(83380400001)(52536014)(4326008)(66446008)(66556008)(91956017)(66476007)(76116006)(64756008)(66946007)(2906002)(86362001)(966005)(166002)(316002)(5660300002)(30864003)(6506007)(19627235002)(7696005)(53546011)(71200400001)(55016002)(110136005)(54906003)(9686003)(8676002)(33656002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?McaZDaRf8Nql5M2b6lCNUHXkbdEfY7xUKmjTAKIcFU0N9YrjgHO9h20a?= =?Windows-1252?Q?2m0XQSYZlOn3IEsVly1vKsEyJe2MiO3jyA67dwSpWfYzw5qSmnVNWUuA?= =?Windows-1252?Q?Un8eLEEZgiOownADnf5UuqqiU0wMac0qx1f8b16tgt50urdhWH/EXDwa?= =?Windows-1252?Q?j+SCibL9ZePlqUPTO2qYc9hU7lQNBjkIWCHKwzlJtbu6QUGkegtbW9LW?= =?Windows-1252?Q?gaOYIV6KofNYV4nlG7iTHdZgFeulhAjtfXSJ1iAsL9Gp/j/MiCPOxoU5?= =?Windows-1252?Q?gsjidmHuC0B/mm35QSMGwHcGEiwC3PB5uWoCk1evPxuJohDeUATkDr68?= =?Windows-1252?Q?iszaXjXJNPA3KWpLPtY6rC3XSabHu9pE5pQTO/Y2wovRq6Pre5Y0PZWM?= =?Windows-1252?Q?XbA6D83Dv7LBIqIPjAC6fLbv1+sIGEQVUsfFKCrqb9tCwsZs7bIO0A/t?= =?Windows-1252?Q?oqswZ1AZLSaHeeqp5de1wRzC8+DrRhDEvKfgNtmwjxOvbxZyUJK5bRK6?= =?Windows-1252?Q?vVKZ9hrZpGnRcW5QX9+XYwxEUNMGHy094+mchexYowDd3F6wrqm8+abi?= =?Windows-1252?Q?vam4fSsy3lIGLTk8IDumGeAtfy+K7YxKofk9OKNAkzr7MnDV3Lc+dfyP?= =?Windows-1252?Q?FXymDdgo7Zylvi7sioZTVnbGMA27g0YafVuCQK8kOdbfh0zD93VzqSiK?= =?Windows-1252?Q?ya8c/ggRamaDw1f8YA5h/+BDZpRNxmsl8+Ne3I3xBj3/bCu02+03Cuzf?= =?Windows-1252?Q?5moVVFXvtrfUrP6kUHN+4hvoYOkk3L9ac7TuJyZVOLFa4H7Axo7TYzdU?= =?Windows-1252?Q?lrV5fCntfGF0drHsUz1dezNEeSJxlVSy+PyKabr1RvTIZOJdVjHr7PXS?= =?Windows-1252?Q?C3kgF9hsj823YkIOF1ocrvtlpj+adBQ8udNZMatAJcNokc4vOoJ3FYB7?= =?Windows-1252?Q?v04z7klINMCCAw4D3YpH3GS4UlsEjkTsLf6K4LGYSlAx+2+kO5E28L1x?= =?Windows-1252?Q?3hNdTr2Mab6K00IBAY4fhpFFAEQVzc8axqA1NV0UMHZ8SXy0RUIDHmYy?= =?Windows-1252?Q?Bom5pDvlgadvse6Mlqrhr+cL/0vCDu0oy5WygA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB311573C0EF2E032ED1F752C1BFF90DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bff4696b-abf5-40fc-1e70-08d89215b00d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 14:15:11.6751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5v7u40IcUCvI1EMjBjffH8zxW4u/Xq7nzmakw2cT3/7BJIU9NKIMBlEb6FBoohezQ1voAqtyuYo8T2/NZn+AdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2874 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: [spring] FW: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 14:15:33 -0000 --_000_DM6PR11MB311573C0EF2E032ED1F752C1BFF90DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Greg for your comments. Please see inline, I have added some replies= below inline with =85 From: Greg Mirsky Date: Thursday, November 19, 2020 at 12:28 PM To: Mach Chen Cc: Tianran Zhou , Rakesh Gandhi (rgandhi) , spring , IPPM Chairs , = spring-chairs@ietf.org , Tommy Pauly , IETF IPPM WG (ippm@ietf.org) Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Mach, thank you for your email. I've added my understanding of what has been prop= osed in-line tagged GIM>>. Regards, Greg On Wed, Nov 18, 2020 at 11:41 PM Mach Chen > wrote: Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]=85 From: ippm [mailto:ippm-bounces@ietf.org] On = Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) >; Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-= known terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If you prefe= r, we can define them here. For Zero checksum field, we can add a reference= for the RFC 6936 in Security section and also add some text for it. Will b= e happy to work with you to address these. But I am very much concerned with the technical value of these drafts. And= here's why I feel that the proposed documents don't provide a sound techni= cal solution to the task of direct loss measurement. Please find my reasoni= ng explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and = ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX a= nd RX counters for direct-mode loss measurement. TWAMP/STAMP messages defin= ed in the drafts are equivalent of them that take advantage of the widely d= eployed TWAMP protocol and as well this same protocol can be deployed in IP= v4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point = is if we need a new direct packet loss measurement for STAMP, when STAMP al= ready defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dr= aft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot f= ulfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussion= s are mainly about draft*-stamp-srpm. GIM>> You've brought a very good question on how the return path, in case r= equired by the Sender Control Code, introduced in draft-gandhi-ippm-twamp-s= rpm, is specified? As you've pointed out, RFC 5357 does not use TLV extensi= ons. Should I assume that the return path, if required, provisioned through= the management plane? I think that that requires clarification. Here the return SR path may be dynamic and can often change (when ing= ress nodes re-compute SR paths). Using controller based signaling/provision= ing for it defeats the purpose of overcoming scale limitations and using TW= AMP Light. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-st= amp-srpm assumes that marking-based solution (which can address the packet = out-ordering issue) is used, hence the block number is introduced. The bloc= k number is used to correlate the counters from the sender and reflector. T= he current direct loss measurement TLV may just apply to the scenario witho= ut packet out-ordering. GIM>> I agree with your observation on the purpose of the Block Number fiel= d in both TWAMP-Light and STAMP documents. In my understanding, the new pro= tocol may be also used to collect counters generated by methods other than = Alternate Marking. In that case, I assume, the value of Block Number may no= t convey any information. When TX and RX counters are collected by the TWAMP Light and STAMP ba= sed probe message defined in this draft, it=92s block number carried in the= message provides the context for the counters to be able to correlate the = TX and RX counters to measure the traffic loss =93at the Sender when the re= sponse is received=94. [Mach] In addition, whether to keep it as current design or to define a ne= w TLV for direct loss measurement can be debatable. GIM>> I agree with you. And that what I am proposing - review the requireme= nts, agree on requirements, and review the proposed solution based on these= requirements. Please see the previous reply sent: As TWAMP Light does not have a TLV, we need to define a stand-alone message= for direct-mode LM. STAMP is just the same message but fixed length, so th= is way both can interoperate and also we can leverage the message for both = of these protocols. For STAMP direct-mode LM TLV approach, some technical details are in the dr= aft as well: The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization for one-way delay). Furthermore, for hardware-based cou= nter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). How the proposed method of direct packet loss is related to TWAMP light an= d STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it=92s format, the messages and processing of them are the same for delay = and direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). =95 What are the potential benefits of specifying the return path i= n the new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. GIM>> I think you've pointed to some vagueness in the definition of a mecha= nism used to define the return path. My understanding is that if a response= required, the Return Path TLV must be present in a test packet. But, if TL= Vs are not used for TWAMP-like direct loss measurement, why not use the sam= e method to control the return path? I believe that consistency is a good q= uality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single p= rotocol only presented as different entities). Yes, it is the intention to be consistent between the two drafts. TWA= MP Light and STAMP are using the same method using the =93Sender control co= de=94. Obviously STAMP provides additional capability to specify Return Pat= h via TLV. Both drafts explain the methods used. Thanks, Rakesh Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also = used today for synthetic packet loss measurement which can be also used to = detect/monitor connection loss (performance metric). The draft simply highl= ights this obvious metric. This is also very similar to what is described i= n ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today= , the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address = your comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: =95 Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. * Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synt= hetic and direct-mode packet loss in segment-routing networks. OWAMP and TW= AMP protocols are widely deployed for performance delay and synthetic packe= t loss measurement today. I am not sure extending ICMP for LM is a good opt= ion here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security = section in RFC 6936. We will add reference to this RFC in our Security Sect= ion as well. This is only specific to the UDP port locally provisioned in t= he domain by the operator for STAMP or TWAMP Light. Other than this, I did = not find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we=92ve had updates on the work in the SPRING WG= that was using STAMP and TWAMP. Since those documents ended up making exte= nsions to the base protocols, the chairs of SPRING and IPPM decided that it= would be best to split the documents and track the IPPM extension work in = the IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandh= i-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not = you believe the IPPM WG should adopt this work by replying to this email. P= lease provide your feedback by the start of the IETF 109 meeting week, on M= onday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_DM6PR11MB311573C0EF2E032ED1F752C1BFF90DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Thanks Greg for your c= omments. Please see inline, I have added some replies below inline= with <RG3>=85=

     

    From: Greg Mirsky <gre= gimirsky@gmail.com>
    Date: Thursday, November 19, 2020 at 12:28 PM
    To: Mach Chen <mach.chen@huawei.com>
    Cc: Tianran Zhou <zhoutianran@huawei.com>, Rakesh Gandhi (rgan= dhi) <rgandhi@cisco.com>, spring <spring@ietf.org>, IPPM Chairs= <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@iet= f.org>, Tommy Pauly <tpauly@apple.com>, IETF IPPM WG (ippm@ietf.or= g) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Mach,

    thank you for your email. I've added my underst= anding of what has been proposed in-line tagged GIM>>.

     

    Regards,

    Greg

     

    On Wed, Nov 18, 2020 at 11:41 PM Mach Chen <mach.chen@huawei.com> wrote:=

    Hi Tianran, Rakesh and Greg,

     Please see some responses inline with [Mach]=85

    From:= ippm = [mailto:<= span lang=3D"EN-US" style=3D"mso-fareast-language:ZH-CN">ippm-bounces@ietf.= org] On Behalf Of Tianran Zhou
    Sent: Thursday, November 19, 2020 1:33 PM
    To: Rakesh Gandhi (rgandhi) <rgandhi=3D    40cisco.com@dmarc.ietf.org>; Greg Mirsky <gregimirs= ky@gmail.com>
    Cc: spring <    spring@iet= f.org&= gt;; IPPM Chairs <ippm-= chairs@ietf.org>; spring-chairs@ietf.org; Tommy P= auly <tpauly=3D40a= pple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

     Hi Rakesh and Greg,

    I may not very clear about the context. Please allow me to jump in.

    It seems both of you make some valid point.

    Please see in line with <ZTR>.

    Cheers,

    Tianran

    From:= sprin= g [mailto:spring-bounces= @ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
    Sent: Wednesday, November 18, 2020 7:41 AM
    To: Greg Mirsky <    gregimirsky@gmail.com>
    Cc: spring <    spring@iet= f.org&= gt;; IPPM Chairs <ippm-= chairs@ietf.org>; spring-chairs@ietf.org; Tommy P= auly <tpa= uly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

     Hi Greg,

    Thank you= for your review and discussions on the drafts. This will help improve the = work on this important work.

    Please se= e replies inline with <RG>..

     

     From: Greg Mirsky <= gregimirsky@gmail.com>
    Date: Tuesday, November 17, 2020 at 5:27 PM
    To: Rakesh Gandhi (rgandhi) <    rgandhi@cisco.com>
    Cc: Tommy Pauly <    tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-cha= irs@ietf.org>, spring-chairs@ietf.org<= /span> <spring-chai= rs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org&= gt;, spring <spring@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh, WG Chairs, a= nd All,

    I've read the responses= to my detailed comments. I don't think that only adding references will so= lve the problems with the documents. If authors are interested in addressing my comments, we can start working on = solving them one by one.

     <RG> As mentioned in previous replies, we can add refere= nces for the well-known terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If y= ou prefer, we can define them here. For Zero checksum field, we can add a r= eference for the RFC 6936 in Security section and also add some text for it= . Will be happy to work with you to address these.

     But I am very much concerned= with the technical value of these drafts. And here's why I feel that the proposed documents don't provide a sound techni= cal solution to the task of direct loss measurement. Please find my re= asoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

    • What is being proposed in these = drafts?

    Drafts *-twamp-srpm and= *-stamp-srpm propose a new protocol to support direct packet loss measurem= ents. Note, that RFC 6374 includes a method for direct loss measurement in MPLS networks that is applicable to the SR-= MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extensi= on to RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct = packet loss measurement. STAMP and all its extensions are applicable in IPv6 networks and, thus, can be used = in the SRv6 domain.

     <RG> As mentioned in previous replies, both RFC 6374 (in= Section 4.2) and ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX counters for direct-mode los= s measurement. TWAMP/STAMP messages defined in the drafts are equivalent of= them that take advantage of the widely deployed TWAMP protocol and as well= this same protocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

     <ZTR> I thi= nk RFC6374 for MPLS and Y.1731 make some noise here. The point is if we nee= d a new direct packet loss measurement for STAMP, when STAMP already defined a Direct Measurement TLV (https://datatracker.ietf.= org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

     [Mach] Given that TWAMP does not support TLV, I assume that t= he discussions are mainly about draft*-stamp-srpm.

    GIM>> You've brought a very good question on h= ow the return path, in case required by the Sender Control Code, introduced= in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out,= RFC 5357 does not use TLV extensions. Should I assume that the return path, if required, provisioned through the manage= ment plane? I think that that requires clarification.

     

    <RG3> Here the r= eturn SR path may be dynamic and can often change (when ingress nodes re-co= mpute SR paths). Using controller based signaling/provisioning for it defea= ts the purpose of overcoming scale limitations and using TWAMP Light.

     [Mach] In the case of direct packet loss measurement, draft-g= andhi-ippm-stamp-srpm assumes that marking-based solution (which can address the packet out-ordering issue) is used, hence = the block number is introduced. The block number is used to correlate the c= ounters from the sender and reflector. The current direct loss measurement = TLV may just apply to the scenario without packet out-ordering.

    GIM>> I agree with your observation on the pur= pose of the Block Number field in both TWAMP-Light and STAMP documents. In = my understanding, the new protocol may be also used to collect counters gen= erated by methods other than Alternate Marking. In that case, I assume, the value of Block Number may not convey any infor= mation.

     

    <RG3> When TX an= d RX counters are collected by the TWAMP Light and STAMP based probe messag= e defined in this draft, it=92s block number carried in the message provide= s the context for the counters to be able to correlate the TX and RX counters to measure the traffic loss =93at the Sen= der when the response is received=94.

     [Mach] In addition, whether to keep it as current design or t= o define a new TLV for direct loss measurement can be debatable.  

    GIM>> I agree with you. And that what I am pro= posing - review the requirements, agree on requirements, and review the pro= posed solution based on these requirements. 

     

    <RG3> Please see= the previous reply sent:

    As TWAMP Light does no= t have a TLV, we need to define a stand-alone message for direct-mode LM. S= TAMP is just the same message but fixed length, so this way both can intero= perate and also we can leverage the message for both of these protocols.

     

    For STAMP direct-mode = LM TLV approach, some technical details are in the draft as well:

     

       The STAMP message with a TLV fo= r "direct measurement" can be used for

       combined Delay + Loss measureme= nt [I-D.ietf-ippm-= stamp-option-tlv].

       However, in order to use only f= or loss measurement purpose, it

       requires the node to support th= e delay measurement messages and

       support timestamp for these mes= sages (which may also require clock

       synchronization for one-way del= ay).  Furthermore, for hardware-based counter collection

       for direct-mode loss measuremen= t, the optional TLV based processing

       adds unnecessary overhead (as c= ounters are not at well-known

       locations).

     How the pro= posed method of direct packet loss is related to TWAMP light and STAMP?

    There's no apparent tec= hnical relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm d= rafts and STAMP. Drafts do not extend or re-use the basic mechanisms defined for  TWAMP-Test and/or STAMP i= n their respective specifications. Rather than that, drafts introduce a new= query-response mode and new formats of test packets that are decisively di= fferent from the formats defined in respective specifications. As a result, the new protocols are required to use differe= nt from used by TWAMP Light tr STAMP test session UDP port numbers on the r= esponder. And that is another clear indication that the proposed mechanism = represents a new protocol, neither extends TWAMP Light and/or STAMP nor updates their specifications.<= o:p>

    <RG>= ; As mentioned in previous replies, other than timestamp vs. counter and it= =92s format, the messages and processing of them are the same for delay and direct-mode loss measure= ment.

    • Is there any advantage in introd= ucing a dedicated packet format for the direct packet loss in STAMP compari= ng to using the Direct Measurement TLV extension?

      • Though it appears the u= sing a dedicated packet format instead of TLV is more efficient, but the de= dicated for the direct loss measurement format is likely to precede one or even two TLVs, Node Address TLV and Pat= h TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processin= g of the new packet with TLVs is unlikely to be more efficient and reduce t= he processing delay, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

      <RG>= ; As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is no TLV required for example. For = direct-mode loss measurement in SR networks, it would typically be forward direction packet loss measurement (and not bidi= rectional).

      =B7         What are the potential be= nefits of specifying the return path in the new test packet's Sender Contro= l Code?

      Using the Sender Contro= l Code may require the use of the additional TLV that carries the return pa= th information, Path TLV. If the ability to control the return path is required that can be achieved by augmenting = the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than includin= g the Path TLV in each test packet. Hence, there seem no technical requirem= ents to introduce the Sender Control Code field in the Base STAMP format defined in RFC 8762.=

      <RG>= ; Per session basis between different sender nodes and this reflector node,= some senders will request the replies in-band (e.g. for two-way mode). Sessions are provisioned on the Sender nodes and = reflector simply reflects based on the received test-packet (e.g. for a bid= irectional SR path). This is also similar to as described Section 3.1 in RF= C 6374, top of page 22. There is no need to create a such state for each session on the reflector node and = create a scale limitation. Recall that we are trying to avoid the scale lim= itation by eliminating the Control protocol signaling.

      <ZTR> I find some= value to include the path TLV in wire. As Rakesh mentioned, this can reduc= e the reflector configuration. But I am not convinced to introduce the sender control code field. It seems to me, the = presence of path TLV indicates the bidirectional congruent path. Vise versa= .

      [Mach] Regarding how to specify the return path, the draft defines = two ways to achieve that, one is to use control code to direct whether the reflected Test should be along the reve= rse path of a bidirectional path, this applies to both TWAMP (no TLV mechan= isms) and STAMP. At the same time, in the case of STAMP, it also defines th= e return path TLV to explicitly specify the return path, which bring more options to specify the return pa= th. Therefore, I see benefit of the two ways.

    GIM>> I think you've pointed to some vagueness= in the definition of a mechanism used to define the return path. My unders= tanding is that if a response required, the Return Path TLV must be present= in a test packet. But, if TLVs are not used for TWAMP-like direct loss measurement, why not use the same method t= o control the return path? I believe that consistency is a good quality of = a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single protocol on= ly presented as different entities).

     

    <RG3> Yes, it is= the intention to be consistent between the two drafts. TWAMP Light and STA= MP are using the same method using the =93Sender control code=94. Obviously= STAMP provides additional capability to specify Return Path via TLV. Both drafts explain the methods used.

     

    Thanks,

    Rakesh

     

     Best regards,

    Mach

     What is the= relationship between the *-srpm drafts and BFD?

    Some text in the *-srpm= drafts suggest that the proposed method can be used to monitor for th= e loss of a path continuity. That may be viewed as an alternative to the BFD protocol method for the detection of a networ= k failure. If the discussion of Loopback mode and monitoring of liveness re= main in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be= made aware of the proposals. I didn't take the liberty of adding BFD WG or its Chairs. I believe that dec= ision to be made by the Chairs of IPPM And SPRING WGs.

     <RG> As mentioned in previous replies, STAMP/TWAMP test = messages are also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

     Tha= nks,

    Rakesh

    Regards,

    On Sun, Nov 15, 2020 at 10:10 PM= Greg Mirsky <gregimirsky@gmail.com> wrote:

    Hi Rakesh,<= /o:p>

    thank you for your prom= pt response, much appreciated. I'll carefully read your responses. Loo= king forward to the continued discussion.

     Regards,

    Greg<= /p>

     On Sun, Nov 15, 2= 020 at 10:07 PM Rakesh Gandhi (rgandhi) <r= gandhi@cisco.com> wrote:

    Hi Greg,

     Thank you for you= r review comments. As mentioned in the IPPM session today, the email respon= se was sent as attachments, see archive blow:

    https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/=

     I am attaching th= em in word documents for the convenience. We can address your comments belo= w in the next revision of the document.

     Thanks,

    Rakesh

    Hi Rakesh,<= /o:p>

    thank you for your resp= onse to my review. Please find my follow-up notes in-lined below under the = GIM>> tag.

    I hope you've found mor= e detailed comments in the attachments (re-attached for your convenience). = I'm looking forward to reading your responses to the detailed comments of all four drafts.

    Regards,

    Greg<= /p>

    Thank you= Greg for taking time for thoroughly reviewing the documents and providing = the comments.  Attached please find the email replies to your review sent earlier.  The replies are copied in= line below for convenience, tagged with <RG00>. 

    Dear WG Chairs, Authors= , and IPPM WG community,

    I've reviewed these dra= fts and have some comments to share. Below, please find my thoughts on whet= her these drafts can be adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related = draft and its accompanying draft targetted to the SPRING WG) are = in the attached documents.

    Usually, the bar for the adoption o= f a document can be evaluated by answers to these three questions:

    =B7  Is the document(s) reasonably well-wr= itten

    I've got surprised that the drafts = don't use the terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Sessi= on-Reflector. Also, many terms, e.g., Links, "congruent paths", a= re used in the documents without proper definitions. Other than that both d= rafts are readable and reasonably well-written.

    <RG00&= gt; We can change Sender to Session-Sender and Reflector to Session-Reflect= or if it helps. 

    GIM>> I believe t= hat the consistency in terminology between the core RFC and what is intende= d as its extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specific= ations.

    <RG00&= gt; There are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8= 330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-= known terms. Having said that, we can add a reference for them if it helps.=

    GIM>> Thank you f= or listing these RFCs. I think I need to clarify my questions. While a refe= rence to any of RFCs you've mentioned, I don't think that will address my concern. In reviewed documents, "Link"= ; is capitalized while referenced RFCs used the lower case form for the ter= m "link". Can these be used interchangeably? Do they refer to the= same network object?

    Now I'll try to illustr= ate my concern with using the term "congruent path" in these draf= ts (using ASCII-art):

          &n= bsp;                C---------D

          &n= bsp;              /      =            \

          &n= bsp;     A----B              &= nbsp;    E-----F

          &n= bsp;              \      =             /

          &n= bsp;              G------------H<= o:p>

    Consider an SR tunnel f= rom A to F that traverses the network as A-B-C-D-E-F. From the definition o= f "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same= shape and size as the mirror image of the other", path A-B-G-H-E-F is= congruent to the SR tunnel. But a packet of an active OAM intended to moni= tor a flow over the SR tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case o= f the extensions in drafts, direct loss measurement can be performed, as in= formation collected from node F. So, this example, in my opinion, illustrat= es two of my concerns:

    • using a congruent path for an ac= tive OAM protocol may produce information that does not reflect the conditi= on experienced by the monitored flow. It seems that the terminology should = reflect the fundamental requirement for using active OAM to maintain the test packets in-band with the monitor= ed flow.
    • there are no technical requireme= nts to justify using in-band active OAM protocol for direct packet loss mea= surement. As demonstrated in this example, direct packet loss can be perfor= med using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.=

     

    • Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts &nb= sp;define a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     <RG00> There is a requirement to measure performance del= ay as well as synthetic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed= for performance delay and synthetic packet loss measurement today. I am no= t sure extending ICMP for LM is a good option here.

    GIM>> I agree wit= h the requirements you've listed (though the SP= RING WG OAM requirements document has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason = to use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. = ;

    • Is the proposed solution technically viable?=

    There are too many unaddressed aspe= cts, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     <RG00> About your comment on zero checksum, this is described in Security section in RFC 6936. We wi= ll add reference to this RFC in our Security Section as well. This is only = specific to the UDP port locally provisioned in the domain by the operator = for STAMP or TWAMP Light. Other than this, I did not find any other security related issue in your review.=

    GIM>> I don't thi= nk that a mere reference sufficiently explains why the use of zero UDP chec= ksum in IPv6 header is not decremental, does not create a security risk for the protocol.

     Tha= nks,

    Rakesh

     Regards,

    Greg 

    On Fri, Oct 30, 2020 at= 11:35 AM Tommy Pauly <tpauly=3D4= 0apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,=

    For the past few meetin= gs, we=92ve had updates on the work in the SPRI= NG WG that was using STAMP and TWAMP. Since those documents ended up making extensions to the base protocols, the chai= rs of SPRING and IPPM decided that it would be best to split the documents = and track the IPPM extension work in the IPPM WG.

     As such, we are s= tarting a Working Group call for adoption for draft-gandhi-ippm-twamp-= srpm and draft-gandhi-ippm-stamp-srpm.

     Please provide yo= ur feedback on these documents, and state whether or not you believe the IP= PM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meet= ing week, on Monday, November 16.

     Best,=

    Tommy & Ian<= o:p>

    _______________________= ________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailma= n/listinfo/ippm

    --_000_DM6PR11MB311573C0EF2E032ED1F752C1BFF90DM6PR11MB3115namp_-- From nobody Thu Nov 26 08:31:56 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E03753A1485; Thu, 26 Nov 2020 08:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160640830888.25228.3979145084755540130@ietfa.amsl.com> Date: Thu, 26 Nov 2020 08:31:48 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-26.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 16:31:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-26.txt Pages : 44 Date : 2020-11-26 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-26 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-26 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 Nov 26 08:50:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B73A14C9; Thu, 26 Nov 2020 08:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=LLdhDS6f; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=G1skecJA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S42lNr2aAnmP; Thu, 26 Nov 2020 08:50:42 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946443A14C8; Thu, 26 Nov 2020 08:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69586; q=dns/txt; s=iport; t=1606409442; x=1607619042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Eir8RzLaslxpWphD+BFEHwn2cmM1DRsMQsQMkrD8IiI=; b=LLdhDS6fiUd4j//X5XtOZ4dwq3nGWv/WBnoTNRzW5NKbqJOFizb2XKXd jhTCuNrhH/DvkzFaf6COAVgVK42tzVNVrcLd22S2LxicHsxSSjv+w4hCn 7tT0edstDA20jOErF7Ttohob0d7hcK8qpnEIfNPe8RtokHGDqvWPGfw9K o=; X-IPAS-Result: =?us-ascii?q?A0DsCAC32r9f/4MNJK1iDg8BAQEBCQESAQUFAUCBT4FSI?= =?us-ascii?q?y4HdVovLgqEM4NJA41fmQWBQoERA1QLAQEBDQEBJQgCBAEBhEoCF4IRAiU4E?= =?us-ascii?q?wIDAQEBAwIDAQEBAQUBAQECAQYEcYU0AQclDIVyAQEBAwESCAEIEQwBATIFA?= =?us-ascii?q?QQHBAIBCBEEAQEBAgIRDgcCAgIwFQgIAgQKBAUIEgiDBYJVAw4gAQ6jcQKBP?= =?us-ascii?q?IhpdoEygTuBSQEBBYE3Ag5Bgy0YghADBoEOKoJzg3aEDIJLG4FBP4ERQ4FXf?= =?us-ascii?q?j6CXQIBAQEBFX4BEgEMBgEHHAUQFQwCBYJYM4IskCwSCAYEByuCOT2KUohuk?= =?us-ascii?q?B+BDwqCbokXhhdShhmFNIIIgRSKHJIjgjaVZYkEknqCbAIEAgQFAg4BAQWBb?= =?us-ascii?q?SNnWBEHcBU7gmlQFwINh0aCFYRGCwEFEhSDOoUUhQRAdAI1AgYBCQEBAwl8j?= =?us-ascii?q?RIBAQUKFweBBgGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3ANwRyGhS3QzAieFdCMp0cEXws19psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN2J7vNYzefarvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX7ZkGUr3GvvnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,372,1599523200"; d="scan'208";a="594310638" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 16:50:40 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQGoeqd018759 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Nov 2020 16:50:40 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 10:50:39 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 10:50:38 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Nov 2020 10:50:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=isFWl7Z/FuFYcoCyPsIt/U/qNQDRrPVnhgIF5x3b4impxLgv2hO7SrWWT6ZSTaMsN0KJZ+jNQg6fDd+s0Vh0QoByeb02C8NnsrKd7L71cv4Z9oEErUIZuJhK6nBy+k21DrziMRd1Fz8IRy294V6qy4rIZqnnJ3GzdsjRmpPzZLQ4K25y8BTdfRgrJevuC9Fkn9jr0m41FKUpF1WZ0BgO8ob0yeYRIV+SialGAYlghb5zLf7Pd0e4qUNi6vXfCyAnm9d3XOfAa7EigScGnceWvwLL4Cq4LHSXTJbI/W/YhM5jmaL3sHcxiv1K6bsYf2CB51mqDBeSLzQ6mLqB8a/Zeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Eir8RzLaslxpWphD+BFEHwn2cmM1DRsMQsQMkrD8IiI=; b=fqn11PVhSWEeDAXHAyXCOZGqyAs1ezV/FwoYMeC7jISWt3YabgiwBMH9J6GrVH0txU1pOjKOLdOozTHhxmgZ8RgKxZZ7iB6VkUOtRNiuTeeOU8zIvY5/1xa5PV8iUkxhEyhmnO4MUx0ohlWDAZR6TankMpNyS50ZjkjP7gRCmDHY4HalYtdCkie5d46ZjzjKKRCl8XOkO66eOwvisgqHxAF6D3y9VMLKdafp6Zr0oqEtxOwDB2qeUImgJJ9x8W23QK/1qEVA93SGePAjTqiBnZ2mFD5mh1D2Hpa1kWtBW7ZgdghUFigD6+emJ51TBk4UiIBK7+bDPDv1ZzvLP/UijQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Eir8RzLaslxpWphD+BFEHwn2cmM1DRsMQsQMkrD8IiI=; b=G1skecJA9ba7sKaAwi5NfoI/g9SShl4r8fY3zLMSD4/eZkLEDiy74xFeOzSJZ6nb9pqPuWebu6MC3/CI2WO+14AJ8jOU+3vqejg7UB/zAiU5iiUc80Vu87+v/q581S7W98k59CzhuIZCQykoYH594Y+cq0AB/Qs+YY3fttDwdlI= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SN6PR11MB2750.namprd11.prod.outlook.com (2603:10b6:805:54::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.24; Thu, 26 Nov 2020 16:50:36 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::51da:59d2:56d2:d4e5]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::51da:59d2:56d2:d4e5%7]) with mapi id 15.20.3611.023; Thu, 26 Nov 2020 16:50:36 +0000 From: "Pablo Camarillo (pcamaril)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) Thread-Index: AQHWkkehHHD2ovfWJ0icCuhr4TgPf6l5pP+AgF7GvICAARK2wIAAbnCAgAELy9A= Date: Thu, 26 Nov 2020 16:50:36 +0000 Message-ID: References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> <20201125011313.GH39170@kduck.mit.edu> <20201126001143.GO39170@kduck.mit.edu> In-Reply-To: <20201126001143.GO39170@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.43] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b74ea647-b780-47af-f5df-08d8922b6623 x-ms-traffictypediagnostic: SN6PR11MB2750: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S8cfaLxV8/MnjvExZMwlRctTnGwV4tjCxWrFycLkWg8RqXKt6CI/27fH+oxigTnmJBOTpnYYm3RQgrASCwvOS0RegWREdg9SdDVgC50FvwozST+7QMm1mglxQmlAnFjCYTdvhQejORO9zHnRx8Xh2/0F9ayh0tmoPBi073ZBLceWYS+Q3+2JpLJE2Ik0phuFwEGs0QujroneicKhBm+BkUL5QwXwCk+3Y66eEiMit4rsu+elTqH2cWPBChq54hqTm4ZMX950r8RbIcvnV1ym27AuomqpSN4QyCZ9PGlwlTq1dPKfDb1M/0Hov1gRBh/Xj3osnFIU6eu/EhND79nQPsR4dDUmZlpLZXpglvuKm3/a3D9ONkKbFltIjPp5MbkA83SOaHqdyHvR0Lir94nZKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(396003)(346002)(376002)(39860400002)(4326008)(66446008)(86362001)(54906003)(64756008)(8676002)(8936002)(66556008)(66476007)(478600001)(33656002)(66946007)(2906002)(71200400001)(6916009)(66574015)(83380400001)(5660300002)(76116006)(9686003)(55016002)(30864003)(7696005)(52536014)(966005)(26005)(316002)(186003)(53546011)(6506007)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VjJFV0o5NkJ1VlRkUDlBRXdOK1ZDc1hNbjNocjZtNTN4bTNTOE52cFRob1Fr?= =?utf-8?B?QkxROTRCYS9ycjBEV29aUGRZSitMa0I5OVlEeVVXVDFuV092TXcyb0JLVWwr?= =?utf-8?B?RWUweDRuMTZ3VkRGc3QwaVpaRnBPbmVja0JJOEFXa2JRMWg3WlExaXozU01J?= =?utf-8?B?b1hRbk1MZldxTUR2aFpRdzBwL0xMUG1LcHZVMXUvWktoWnYva1JkSEhGbXl5?= =?utf-8?B?ZCszdGU4blRuWDQrNjMyaHdqM1ZqQ1NaeWNFdGdFdkRUblpVaHRqS3NmRE1N?= =?utf-8?B?c1pEZHd5WnVJcjBKWGM3SlVPYWc4dTNPNjdwOHZUZWx0QzZURkpOZGFPR0Jr?= =?utf-8?B?TitHbFBqZ0ZGNWxWTHhhUm41dVJOYXk5NTlldmE4dUJ4SWxHTTRyWWtaN3Z3?= =?utf-8?B?UnozSGZpYkdHcTdzZ3FxYVhDRmJCVVZpcnhjcFpiQ3dwQmtjdlJEbVMxYmlH?= =?utf-8?B?T3ptbDBNQy9UdERVRzFxVFBYbUt4NEpTdExRNWxnV0lkZlhCQWUzTmx4ZTVC?= =?utf-8?B?aVZtZmd5MHNNK1c1cGdNTm91bHFYTU4yRVU2QWRNeWcraUdyaEdZT0djdEVH?= =?utf-8?B?M0xQWGdDQlVpSTd6Mk1uY0V3L01WdUZia0k4dDRsaW5LK3o2aGtQNFFveVEx?= =?utf-8?B?dWtlWTlvWVQ3eGxHMWE2VHhMRVF4QnIwTFN2eVNiTXZuZW9OcndPTG5rTXhD?= =?utf-8?B?UzlGNEM2N0grYmpvWlZSOUhXMWFoYVZQai9VdlZGM2VzcHhrSGhMd0hlZ1Av?= =?utf-8?B?eHZ0cEZESFY2M3I0Yjc0cHUxYytaK0xxQmFiNmRvSE9SbjBQN0F1QlNKbi9W?= =?utf-8?B?VG1wSkZVUEVyZVk2STZyeWo1cmdFeW9meG54SE5QNFRiUDV5T3lhUzJjeG9m?= =?utf-8?B?ZGsvM1gxNWttalJvWXVMeG1jZVRML0RRWTVPOGNYZFMxSTUvQVk5dmxYYnhz?= =?utf-8?B?N3dxNkUzOFE3MFg2VDlVWkVoODB1M2pNZUpSeEhLTmw1eUV6Y25QL2sxZ21W?= =?utf-8?B?RWtKUW44amtFazUzYVBhTldtVkJLMjhZTHVVQ0k4bHVPQVllUnJDYUp6YUdE?= =?utf-8?B?MmtGOVlwTzdDSTIrRnFrSW1nY0c4NkpEeVJhT0NKQjN6SDUxbERrd29NSDFM?= =?utf-8?B?L1BXajE1bHQydnlEb2RBL3lXa21MemZ6eVFUOVF3MHNsVktMUm5YV2lZbXJW?= =?utf-8?B?MVFxVWdvNmZwQWcwRGhFbi9LN3NVZG1KYUt6ai9hOTlteXNBZk1YMDVIbXJq?= =?utf-8?B?VWdtVWxDSVliSEdHZFhiVmV3VVRvRTJDSVdHclpBZEdrNnBHaDVHMkJmNkhh?= =?utf-8?Q?M+gj1JXZf1Rck=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b74ea647-b780-47af-f5df-08d8922b6623 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 16:50:36.6343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9AKJGLCoVo5+p7EgA0jMxZjOafiewcnVYY13qDZKxLDf5lv1WBS/3n48SLPeOnSNsq+noceSv/6hfJ5aj7iWvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2750 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 16:50:48 -0000 SGkgQmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZSB3aXRoIFBDMy4NCk5vdGUgdGhhdCB3ZSd2ZSBw b3N0ZWQgcmV2MjY6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMjYNCg0KTWFueSB0aGFua3MgZm9yIHlv dXIgdGltZSwNClBhYmxvLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmVu amFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+IA0KU2VudDoganVldmVzLCAyNiBkZSBub3ZpZW1i cmUgZGUgMjAyMCAxOjEyDQpUbzogUGFibG8gQ2FtYXJpbGxvIChwY2FtYXJpbCkgPHBjYW1hcmls QGNpc2NvLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc3By aW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9yZzsgc3ByaW5nLWNoYWlyc0BpZXRm Lm9yZzsgc3ByaW5nQGlldGYub3JnOyBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbT47IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NClN1YmplY3Q6IFJl OiBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3 b3JrLXByb2dyYW1taW5nLTIwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBQYWJs bywNCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlczsgdGhlIGNoYW5nZXMgaW4gdGhlIC0yNSBhbGwg bG9vayBnb29kIHRvIG1lLg0KDQpNb3JlIGlubGluZS4uLg0KDQpPbiBXZWQsIE5vdiAyNSwgMjAy MCBhdCAwOTo0Mjo0MlBNICswMDAwLCBQYWJsbyBDYW1hcmlsbG8gKHBjYW1hcmlsKSB3cm90ZToN Cj4gSGkgQmVuLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3LiBSZXBsaWVz IHRvIHlvdXIgY29tbWVudHMgaW5saW5lIHdpdGggUEMyLg0KPiBOb3RlIHRoYXQgSeKAmXZlIHBv c3RlZCByZXYyNSBvZiB0aGUgZHJhZnQuDQo+IA0KPiBUaGFua3MsDQo+IFBhYmxvLg0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVr QG1pdC5lZHU+DQo+IFNlbnQ6IG1pw6lyY29sZXMsIDI1IGRlIG5vdmllbWJyZSBkZSAyMDIwIDI6 MTMNCj4gVG86IFBhYmxvIENhbWFyaWxsbyAocGNhbWFyaWwpIDxwY2FtYXJpbEBjaXNjby5jb20+ DQo+IENjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IA0KPiBkcmFmdC1pZXRmLXNwcmluZy1z cnY2LW5ldHdvcmstcHJvZ3JhbW1pbmdAaWV0Zi5vcmc7IA0KPiBzcHJpbmctY2hhaXJzQGlldGYu b3JnOyBzcHJpbmdAaWV0Zi5vcmc7IEJydW5vIERlY3JhZW5lIA0KPiA8YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbT47IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gU3ViamVj dDogUmU6IEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiANCj4gZHJhZnQtaWV0Zi1zcHJpbmct c3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTIwOiAod2l0aCBESVNDVVNTIGFuZCANCj4gQ09NTUVO VCkNCj4gDQo+IEhpIFBhYmxvLA0KPiANCj4gSSBtdXN0IGFwb2xvZ2l6ZSB0d2ljZSBvdmVyOiBm aXJzdCBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcsIGFuZCBzZWNvbmQgZm9yIHRoZSBudW1i ZXIgb2YgcG9pbnRzIGluIG15IGRpc2N1c3MgYmFsbG90IHRoYXQgYXJlIG5vdCBhY3R1YWwgcHJv YmxlbXMuDQo+IEkgcmVjZW50bHkgaGFkIHRoZSB0aW1lIHRvIGdvIG92ZXIgdGhlIGRvY3VtZW50 IGFnYWluLCB3aXRoIGJlbmVmaXQgb2YgeW91ciByZXNwb25zZXMgaGVyZSwgYW5kIG5vdyBoYXZl IGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2Ygc29tZSBhc3BlY3RzIHRoYXQgd2VyZSBjb25mdXNp bmcgdG8gbWUgZHVyaW5nIG15IGZpcnN0IHJlYWRpbmcuICBJIHN0aWxsIGhhdmUgYSBmZXcgdGhp bmdzIEkgd2FudCB0byB0YWtlIGFub3RoZXIgbG9vayBhdCwgYnV0IEkgY2FuIHJlc3BvbmQgdG8g eW91ciBjb21tZW50cyBub3cgLS0gdGhlIGdvb2QgbmV3cyBpcyB0aGF0IHRoZXNlIGRpc2N1c3Mg cG9pbnRzIGFsbCBsb29rIHRvIGJlIHJlc29sdmVkLg0KPiANCj4gTW9yZSBpbmxpbmUuLi4NCj4g DQo+IE9uIEZyaSwgU2VwIDI1LCAyMDIwIGF0IDA2OjMxOjUyUE0gKzAwMDAsIFBhYmxvIENhbWFy aWxsbyAocGNhbWFyaWwpIHdyb3RlOg0KPiA+IEhpIEJlbmphbWluLA0KPiA+DQo+ID4gVGhhbmsg eW91IGZvciB5b3VyIHRpbWUgYW5kIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBbUENd Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBQYWJsby4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPg0KPiA+IFNlbnQ6IGp1ZXZlcywgMjQgZGUgc2VwdGllbWJyZSBkZSAy MDIwIDk6NTINCj4gPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IGRyYWZ0 LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9yZzsNCj4gPiBzcHJp bmctY2hhaXJzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IEJydW5vIERlY3JhZW5lIA0KPiA+ IDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsgSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPjsgDQo+ID4gam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+IFN1YmplY3Q6IEJlbmphbWlu IEthZHVrJ3MgRGlzY3VzcyBvbg0KPiA+IGRyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1w cm9ncmFtbWluZy0yMDogKHdpdGggRElTQ1VTUyBhbmQNCj4gPiBDT01NRU5UKQ0KPiA+DQo+ID4g QmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQo+ID4gZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTIwOiBE aXNjdXNzDQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0 IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byANCj4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gDQo+ID4gY3V0IHRoaXMg aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBy ZWZlciB0bw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbA0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5l dHdvcmstcHJvZw0KPiA+IHJhDQo+ID4gbW1pbmcvDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiAtLQ0KPiA+IERJU0NVU1M6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+ DQo+ID4gW2VkaXRlZCB0byByZW1vdmUgbm9uc2Vuc2ljYWwgcG9pbnQgdGhhdCBoYWQgY3JlcHQg aW4gYWJvdXQgdGhlIFNSSCANCj4gPiBiZWluZyBhIG5ldyBleHRlbnNpb24gaGVhZGVyOyBpdCdz ICJqdXN0IiBhIHJvdXRpbmcgaGVhZGVyXQ0KPiA+DQo+ID4gVGhlIGN1cnJlbnQgcmVxdWlyZW1l bnQgdGhhdCBJQU5BLWFzc2lnbmVkIFNSdjYgRW5kcG9pbnQgQmVoYXZpb3IgY29kZXBvaW50cyBh cmUgdXNlZCwgd2l0aCBubyByYW5nZSByZXNlcnZlZCBmb3IgbG9jYWwgYXNzaWdubWVudCwgc2Vl bXMgdG8gYmUgaW52aXRpbmcgY29kZXBvaW50IHNxdWF0dGluZyBmcm9tIHRoZSBub21pbmFsbHkg cmVzZXJ2ZWQgcmFuZ2UuDQo+ID4gV2h5IGlzIHRoZXJlIGFuIGFic29sdXRlIHJlcXVpcmVtZW50 IGZvciByZWdpc3RyYXRpb24gKGV2ZW4gRkNGUykgDQo+ID4gd2l0aG91dCByYW5nZXMgZm9yIGxv Y2FsIG9yIGV4cGVyaW1lbnRhbCB1c2U/ICAoV2hhdCBhcmUgdGhlIHZhcmlvdXMgcmVzZXJ2ZWQg cmFuZ2VzIHJlc2VydmVkIGZvcj8pIFtQQ10gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGEgcmFuZ2Ug Zm9yIGxvY2FsIHVzZSB3b3VsZCBjb21lIHVzZWZ1bC4gSGVuY2UsIHdl4oCZdmUgY2FydmVkIDJr IGVudHJpZXMgb2YgdGhlIHJlZ2lzdHJ5IGZvciBQcml2YXRlIFVzZS4NCj4gPiBUaGUgUmVzZXJ2 ZWQgcmFuZ2UgKGhhbGYgb2YgdGhlIDY1ayByZWdpc3RyeSkgaXMgZm9yIGZ1dHVyZSBhbGxvY2F0 aW9uIGJ5IElFVEYuIEZ1dHVyZSBSRkNzIG1pZ2h0IGRlY2lkZSBob3cgdG8gdXNlIHRoYXQuDQo+ IA0KPiBTb3VuZHMgZ29vZDsgdGhhbmtzIQ0KPiANCj4gPiBUaGUgKG5vcm1hdGl2ZSkgcHNldWRv Y29kZSBkb2VzIG5vdCBzZWVtIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVuIHRoZSBTUkggaXMgb21p dHRlZCBmb3IgdGhlIGRlZ2VuZXJhdGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBvbmx5IGEgc2luZ2xl IHNlZ21lbnQsIG9yIGZvciB0aGUgUFNQIGZsYXZvci4NCj4gPiBbUENdIEVhY2ggb25lIG9mIHRo ZSBwc2V1ZG9jb2RlcyBwcm92aWRlcyB0aGUgU1JIIHByb2Nlc3NpbmcgYW5kIHRoZSBVcHBlci1M YXllciBwcm9jZXNzaW5nLiBJZiB0aGVyZSBpcyBubyBTUkgsIHRoZW4gdGhlIFNSSCBwcm9jZXNz aW5nIGlzIG5vdCBleGVjdXRlZCwgYnV0IHRoZSBVcHBlci1sYXllciBIZWFkZXIgcHJvY2Vzc2lu ZyBpcy4gVGhpcyBpcyB0aGUgc2FtZSBhcyBpbiBSRkM4NzU0Lg0KPiANCj4gVG8gZXhwYW5kIGEg Yml0IG1vcmUgb24gaG93IEkgd2FzIGNvbmZ1c2VkIGhlcmUsIEkgd2FzIGxvb2tpbmcgcGFydGlj dWxhcmx5IGF0IHRoZSBFbmQsIEVuZC5YLCBhbmQgRW5kLlQgY2FzZXMgKHRob3VnaCBJIGd1ZXNz IGl0IGFsc28gYXBwbGllcyB0byB0aGUgRW5jYXBzIGNhc2VzKS4gIEluIHRoZSBub3JtYWwgZmxh dm9yLCB1cHBlci1sYXllciBwcm9jZXNzaW5nIGdldHMgc2h1bnRlZCBvdmVyIHRvIHNlY3Rpb24g NC4xLjEgdGhhdCBkb2Vzbid0IHJlYWxseSBkbyBtdWNoIC0tIGluIHBhcnRpY3VsYXIsIHRoZXJl IGlzIG5vIGludGVyY29ubmVjdCBmb3IgRW5kLlggYW5kIG5vIHRhYmxlIGxvb2t1cCBmb3IgRW5k LlQhICBCdXQgdGhpcyByZWFsbHkgaXMgdGhlIHJpZ2h0IGJlaGF2aW9yLCBzaW5jZSB0aGUgU1JI IGlzIG9ubHkgYWJzZW50IHdoZW4gdGhpcyBTSUQgaXMgdGhlIGZpbmFsIGRlc3RpbmF0aW9uIG9m IHRoZSBwYWNrZXQsIGFuZCBpbiB0aGF0IGNhc2Ugd2UgcmVhbGx5IG11c3QgYWN0IGFzIGFuIGVu ZHBvaW50IGFuZCBub3QgYSByb3V0ZXIuICBJZiB3ZSBkaWQgc2VuZCB0aGUgcGFja2V0IG9ud2Fy ZCBpdCB3b3VsZCBtb3N0IGxpa2VseSBqdXN0IGdldCBsb29wZWQgYmFjayB0byB1cyB1bnRpbCB0 aGUgaG9wIGxpbWl0IGV4cGlyZXMgKG9yIGdldCBzb21lIG90aGVyIGVycm9yKSwgc28gZ2VuZXJh dGluZyBhIGxvY2FsIElDTVAgZXJyb3IgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGluIHRoZSBn ZW5lcmFsIGNhc2UsIHVubGVzcyB0aGVyZSBpcyBsb2NhbCBjb25maWd1cmF0aW9uIGZvciB0aGF0 IHVwcGVyLWxheWVyIHByb3RvY29sLg0KPiANCj4gW1BDMl0gQWNrDQo+IA0KPiA+IFRoZSBwc2V1 ZG9jb2RlIGZvciB0aGUgUFNQIGFuZCBVU1AgcHJvY2VkdXJlcyBzZWVtIGluY29ycmVjdCAtLSBI ZHIgRXh0IExlbiBpcyBtZWFzdXJlZCBpbiB1bml0cyBvZiA4IG9jdGV0cywgYW5kIGRvZXMgbm90 IGluY2x1ZGUgdGhlIGZpcnN0IDggb2N0ZXRzIG9mIHRoZSBleHRlbnNpb24gaGVhZGVyLCBidXQg UGF5bG9hZCBMZW5ndGggaXMgbWVhc3VyZWQgaW4gb2N0ZXRzLiAgTGl0ZXJhbGx5IGRlY3JlYXNp bmcgdGhlIFBheWxvYWQgTGVuZ3RoIGJ5IHRoZSBIZHIgRXh0IExlbiB2YWx1ZSB3aWxsIHByb2R1 Y2UgYSBtYWxmb3JtZWQgSVB2NiBwYWNrZXQuDQo+ID4gW1BDXSBJbmRlZWQuIEZpeGVkLg0KPiA+ DQo+ID4gSWYgIlBTUCBvcGVyYXRpb24gaXMgZGV0ZXJtaW5pc3RpY2FsbHkgY29udHJvbGxlZCBi eSB0aGUgU1IgU291cmNlIE5vZGUiLCB3aHkgZG8gd2UgbmVlZCB0byBkZWZpbmUgYmVoYXZpb3Ig Y29kZXBvaW50cyB0aGF0IChmb3IgZXhhbXBsZSkgdXNlIGJvdGggUFNQIGFuZCBVU1A/ICBJIGRv bid0IHNlZSBob3cgdGhlcmUgaXMgZnVsbCBkZXRlcm1pbmlzbSBpbiB0aGlzIGNhc2Ugd2hpbGUg YmVpbmcgZGlmZmVyZW50IGZyb20gdGhlICJQU1Agb25seSIgZmxhdm9yLg0KPiA+IFtQQ10gSW4g b3JkZXIgZm9yIHRoZSBQU1AgYmVoYXZpb3IgdG8gYmUgZXhlY3V0ZWQgdGhlcmUgbXVzdCBoYXBw ZW4gdHdvIHRoaW5ncy4gRmlyc3QsIHRoZSBTUiBTb3VyY2UgTm9kZSBtdXN0IGluc3RydWN0IGl0 IHdhbnRzIHRvIHVzZSB0aGUgUFNQIGJlaGF2aW9yLiBUaGlzIGlzIGRvbmUgYnkgdXNpbmcgYW4g U1J2NiBTSUQgYXNzb2NpYXRlZCB3aXRoIGEgYmVoYXZpb3IgdGhhdCBzdXBwb3J0IHRoZSBQU1Ag Zmxhdm9yIChlaXRoZXIgRW5kIHdpdGggUFNQIGFsb25lLCBvciBFbmQgd2l0aCBQU1AgaW4gY29t YmluYXRpb24gb2Ygb3RoZXIpLiBUaGVuLCB0aGUgc2Vjb25kIHRoaW5nIGlzIHRoYXQgdGhlIHJl Y2VpdmVkIHBhY2tldCBhdCB0aGUgbm9kZSBpdCBtdXN0IGhhdmUgYSBTTCB2YWx1ZSBvZiAxLCB0 aGF0IGR1cmluZyBwcm9jZXNzaW5nIGlzIGRlY3JlbWVudGVkIHRvIDAuIChJbiBvdGhlciB3b3Jk cywgaXQgbXVzdCBiZSB0aGUgcGVudWx0aW1hdGUgc2VnbWVudCkuIElmIGJvdGggY29uZGl0aW9u cyBhcmUgZ2l2ZW4sIHRoZW4gbGluZXMgUzE0LjItUzE0LjQgb2YgdGhlIHBzZXVkb2NvZGUgYXJl IGV4ZWN1dGVkLg0KPiANCj4gSSB1bmRlcnN0YW5kIG5vdzsgdGhhbmtzIGZvciBleHBsYWluaW5n IGl0IGFnYWluLiAgKFRvIHJlaXRlcmF0ZTogYW55IA0KPiBnaXZlbiBTSUQgY2FuIGFwcGVhciAi YW55d2hlcmUiIGluIHRoZSBzZWdtZW50IGxpc3QsIHNvIFVTUCBpcyANCj4gcmVsZXZhbnQgd2hl biBpdCBpcyBsYXN0IGFuZCBQU1AgaXMgcmVsZXZhbnQgd2hlbiBpdCBhcHBlYXJzIA0KPiBzZWNv bmQtdG8tbGFzdC4gIFRoZSBVU1AvUFNQIGZsYXZvciBkb2Vzbid0IG5lZWQgdG8gYmUgdGhlIHNh bWUgZm9yIA0KPiBhbGwgU0lEcyBpbiB0aGUgcGF0aCwgc28gbWFya2luZyBhIHNpbmdsZSBTSUQg d2l0aCBib3RoIGNhbiBiZSANCj4gcmVsZXZhbnQgZm9yIGRpZmZlcmVudCBwYXRocy4pDQo+IA0K PiBbUEMyXSBDb3JyZWN0DQo+IA0KPiA+IFRoZXJlIGFyZSBudW1lcm91cyBmYWN0dWFsIGVycm9y cyBhbmQgdW4vdW5kZXItc3BlY2lmaWVkIHByb3RvY29sIGJlaGF2aW9yIChzZWUgQ09NTUVOVCks IGluY2x1ZGluZzogaG93IHRvIHNldCB0aGUgb3V0ZXIgSG9wIExpbWl0IChtdWx0aXBsZSBpbnN0 YW5jZXMpLCB0aGUgb3JkZXIgb2Ygc2VnbWVudHMgaW4gdGhlIFNSSCwgc3BlY2lmaWNhdGlvbiBv ZiBoZWFkZW5kIGJlaGF2aW9yIGJ5IHJlZmVyZW5jZSB0byBpbmZvcm1hbCBleGFtcGxlLCBMMiBm cmFtZSBlbi9kZWNhcHN1bGF0aW9uIHByb2NlZHVyZXMsIGFuZCB0aGUgIk9wYXF1ZSIgbm90ZSBm b3IgZW5kcG9pbnQgYmVoYXZpb3IgNjU1MzUuDQo+ID4gW1BDXSBJ4oCZbGwgY29tbWVudCBvbiBl YWNoIHBvaW50IGluIHRoZSBjb21tZW50Lg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ IC0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4NCj4gPiBJIG5v dGUgdGhhdCB0aGlzIGRvY3VtZW50IHJlZmVyZW5jZXMgDQo+ID4gZHJhZnQtZmlsc2ZpbHMtc3By aW5nLXNydjYtbmV0LXBnbS1pbGx1c3RyYXRpb24sIHdoaWNoIHVzZXMgdGhlIElQdjQgQ0lEUiAy MC84IGluIGV4YW1wbGVzIGluc3RlYWQgb2YgYWRkcmVzc2VzIGZyb20gdGhlIFJGQyA1NzM3IHJh bmdlLiAgSXQgd291bGQgYmUgZGlzYXBwb2ludGluZyB0byBoYXZlIGEgUFMgcmVmZXIgdG8gYSBk cmFmdCB0aGF0IHNxdWF0cyBvbiB0aGUgSVB2NCBuYW1lc3BhY2UgaW4gc3VjaCBhIG1hbm5lci4N Cj4gPiBbUENdIEFjay4gSeKAmXZlIHVwZGF0ZWQgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYt bmV0LXBnbS1pbGx1c3RyYXRpb24gdG8gY29ycmVjdCB0aGF0Lg0KPiANCj4gVGhhbmsgeW91IQ0K PiANCj4gPiBBYnN0cmFjdCwgSW50cm9kdWN0aW9uDQo+ID4NCj4gPiAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgdGhlIFNSdjYgTmV0d29yayBQcm9ncmFtbWluZyBjb25jZXB0IGFuZA0KPiA+ICAg IHNwZWNpZmllcyB0aGUgYmFzZSBzZXQgb2YgU1J2NiBiZWhhdmlvcnMgdGhhdCBlbmFibGVzIHRo ZSBjcmVhdGlvbiBvZg0KPiA+ICAgIGludGVyb3BlcmFibGUgb3ZlcmxheXMgd2l0aCB1bmRlcmxh eSBvcHRpbWl6YXRpb24gKFNlcnZpY2UgTGV2ZWwNCj4gPiAgICBBZ3JlZW1lbnRzKS4NCj4gPg0K PiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZSBwYXJlbnRoZXRpY2FsIGlzIGludGVuZGlu ZyB0byBjb252ZXkuDQo+ID4gW1BDXSBJ4oCZdmUgcmVtb3ZlZCB0aGUgcGFyZW50aGVzaXMuIEl0 cyB1bm5lZWRlZC4NCj4gPg0KPiA+IFNlY3Rpb24gMg0KPiA+DQo+ID4gICAgVGhlIGZvbGxvd2lu ZyB0ZXJtcyB1c2VkIHdpdGhpbiB0aGlzIGRvY3VtZW50IGFyZSBkZWZpbmVkIGluDQo+ID4gICAg W1JGQzg0MDJdOiBTZWdtZW50IFJvdXRpbmcsIFNSIERvbWFpbiwgU2VnbWVudCBJRCAoU0lEKSwg U1J2NiwgU1J2Ng0KPiA+ICAgIFNJRCwgU1IgUG9saWN5LCBQcmVmaXggU0lELCBhbmQgQWRqYWNl bmN5IFNJRC4NCj4gPg0KPiA+IFtSRkMgODQwMiBzcGVsbHMgaXQgUHJlZml4LVNJRCAod2l0aCBo eXBoZW4pIGFuZCBBZGotU0lELl0gW1BDXSANCj4gPiBGaXhlZCBpbiByZXYyMS4NCj4gPg0KPiA+ IFNlY3Rpb24gMw0KPiA+DQo+ID4gVGhlIHRleHQgYWxsZWdlZGx5IHJlcHJvZHVjZWQgZnJvbSBS RkMgODc1NCDCpzQuMyBkaWZmZXJzIGluIGNhc2UgYW5kIGh5cGhlbmF0aW9uLg0KPiA+IFtQQ10g Rml4ZWQgaW4gcmV2MjEuDQo+ID4NCj4gPiBTZWN0aW9uIDMuMQ0KPiA+DQo+ID4gICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGFuIFNSdjYgU0lEIGFzIGNvbnNpc3Rpbmcgb2YgTE9DOkZVTkNUOkFS RywNCj4gPiAgICB3aGVyZSBhIGxvY2F0b3IgKExPQykgaXMgZW5jb2RlZCBpbiB0aGUgTCBtb3N0 IHNpZ25pZmljYW50IGJpdHMgb2YNCj4gPiAgICB0aGUgU0lELCBmb2xsb3dlZCBieSBGIGJpdHMg b2YgZnVuY3Rpb24gKEZVTkNUKSBhbmQgQSBiaXRzIG9mDQo+ID4gICAgYXJndW1lbnRzIChBUkcp LiAgTCwgdGhlIGxvY2F0b3IgbGVuZ3RoLCBpcyBmbGV4aWJsZSwgYW5kIGFuIG9wZXJhdG9yDQo+ ID4gICAgaXMgZnJlZSB0byB1c2UgdGhlIGxvY2F0b3IgbGVuZ3RoIG9mIHRoZWlyIGNob2ljZS4g IEYgYW5kIEEgbWF5IGJlDQo+ID4gICAgYW55IHZhbHVlIGFzIGxvbmcgYXMgTCtGK0EgPD0gMTI4 LiAgV2hlbiBMK0YrQSBpcyBsZXNzIHRoYW4gMTI4IHRoZW4NCj4gPiAgICB0aGUgcmVtYWluaW5n IGJpdHMgb2YgdGhlIFNJRCBNVVNUIGJlIHplcm8uDQo+ID4NCj4gPiBXaHkgZG9lcyBBIGhhdmUg dG8gYmUgYSBmaXhlZCB2YWx1ZTsgY2FuJ3QgaXQgc2FmZWx5IGJlIGEgZnVuY3Rpb24gb2YgRiAo ZXZlbiBpZiB3ZSBleGNsdWRlIHRoaW5ncyBsaWtlIGh1ZmZtYW4gY29kaW5nIGZvciBGKT8NCj4g PiBbUENdIENhbiB5b3UgcGxlYXNlIHJlLXN0YXRlIHlvdXIgcG9pbnQ/IFRoZSB0ZXh0IGFib3Zl IGRvZXMgbm90IHN1Z2dlc3QgdGhhdCBBIGlzIGEgZml4ZWQgdmFsdWUsIGhlbmNlIEnigJltIG5v dCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuLg0KPiANCj4gSXQncyB0cnVl IHRoYXQgdGhlcmUgaXMgbm8gc3BlY2lmaWMgc3RhdGVtZW50ICJBIGlzIGEgY29uc3RhbnQgYWNy b3NzIA0KPiA8c29tZS1wYXJ0aWN1bGFyLXNjb3BlPiIuICBIb3dldmVyLCB0aGVyZSBpcyBhbHNv IG5vdCBhIHNwZWNpZmljIA0KPiBzdGF0ZW1lbnQgInRoZSB2YWx1ZSBvZiBBIGNhbiBkZXBlbmQg b24gPHNvbWUtcGFydGljdWxhci1zY29wZT4iLCBzbyANCj4gdGhlIHJlYWRlciBoYXMgdG8gbWFr ZSBhbiBpbnRlcnByZXRhdGlvbi4gIFdlIGRvIHNheSB0aGF0IEwgaXMgDQo+IGZsZXhpYmxlIGFu ZCB0aGUgb3BlcmF0b3IgY2FuIGNob29zZSB0aGF0IGxlbmd0aDsgSSBpbnRlcnByZXRlZCB0aGlz IA0KPiB0byBtZWFuIHRoYXQgdGhlIG9wZXJhdG9yIG1ha2VzIHRoZSBjaG9pY2Ugb25jZSwgYW5k IHRoYXQgTCBpcyBmaXhlZCANCj4gZm9yIHRoZSBlbnRpcmUgU1IgZG9tYWluLiAgV2l0aCB0aGF0 IGluIG15IGhlYWQsIGl0IHdhcyBhbHNvIG5hdHVyYWwgDQo+IHRvIGluZmVyIHRoYXQgRiBhbmQg QSBhcmUgYWxzbyBmaXhlZCBmb3IgdGhlIGVudGlyZSBTUiBkb21haW4uICAoSXMgTCANCj4gYWxs b3dlZCB0byB2YXJ5IGV2ZW4gd2l0aGluIHRoZSBkb21haW4/KQ0KPiANCj4gW1BDMl0gIE5vdGUg dGhhdCBpbiBSRkM4NzU0IHdlIGhhdmUg4oCcV2hlbiBhbiBTUnY2LWNhcGFibGUgbm9kZSByZWNl aXZlcyBhbiBJUHY2IHBhY2tldCwgaXQgcGVyZm9ybXMgbG9uZ2VzdC1wcmVmaXgtbWF0Y2ggbG9v a3VwIG9uIHRoZSBwYWNrZXTigJlzIGRlc3RpbmF0aW9uIGFkZHJlc3Mu4oCdLiBIZW5jZSAgdGhp bmdzIHdvcmsgZXZlbiBpZiB0d28gbm9kZXMgdXNlIGEgZGlmZmVyZW50IEwgIGZvciB0aGVpciBs b2NhdG9ycyBvciBkaWZmZXJlbnQgc2l6ZXMgb2YgRiBhbmQgQSBmb3IgdGhlaXIgU0lEcy4NCg0K SSBndWVzcyBzby4gIChJbiBteSBoZWFkIHRoZSBhYmlsaXR5IHRvIHVzZSBsb25nZXN0LXByZWZp eCB3YXMgdXNlZnVsIGZvciB3aGVuIHRoZSBTSUQgYW5kIG5vbi1TSUQgYWRkcmVzc2VzIGNvdWxk IGJlIGNvbnNvbGlkYXRlZCBpbnRvIGEgc2luZ2xlIHByZWZpeCBhcHBsaWNhYmxlIHRvIHRoYXQg bm9kZSwgYnV0IEkgaGF2ZSBubyBwYXJ0aWN1bGFyIHJlYXNvbiB0byBoYXZlIGJlZW4gdGhpbmtp bmcgdGhhdC4pDQoNCklmIEkgbWlnaHQgbWFrZSBhIHN1Z2dlc3Rpb24sIHdyaXRpbmcgImZyZWUg dG8gdXNlIHRoZSBsb2NhdG9yIGxlbmd0aCBvZiB0aGVpciBjaG9pY2UgZm9yIGFueSBnaXZlbiBT SUQiIHdvdWxkIGhhdmUgZm9yZXN0YWxsZWQgbXkgY29uZnVzaW9uIGluIHRoaXMgcmVnYXJkLCBh bmQgc2VlbXMgbGlrZSBhIG1pbm9yIGNoYW5nZSB0byBtYWtlLiAgQnV0IGl0IGlzIHlvdXIgZGVj aXNpb24gYXMgdG8gd2hldGhlciBvciBub3QgdG8gbWFrZSBhbnkgY2hhbmdlcyBoZXJlOyBJIGFt IHNhdGlzZmllZCBqdXN0IHdpdGggdGhlIGV4cGxhbmF0aW9uIGFib3ZlLg0KDQpbUEMzXSBBY2sg DQoNCj4gSWYgd2UgZG8gd2FudCB0byBhbGxvdyBGIGFuZCBBIHRvIHZhcnkgYXQgYSAoZS5nLikg cGVyLUxPQyBzY29wZSwgd2Ugc2hvdWxkIHByb2JhYmx5IG1ha2Ugc29tZSBzdGF0ZW1lbnQgYWJv dXQgYmVpbmcgYWJsZSB0byBkZWNvZGUgdGhlbSBwcm9wZXJseSBvbiByZWNlaXB0OyB0aGlzIGNv dWxkIGJlIGRvbmUgaW4gbWFueSB3YXlzLCBpbmNsdWRpbmcgYSBzdHJpY3QgbG9va3VwIHRhYmxl IGFuZCBhIHNlbGYtZGVsaW5pYXRpbmcgbGVuZ3RoLWVuY29kaW5nIHNjaGVtZSwgYnV0IHRoZXJl IGNhbm5vdCBiZSBhbWJpZ3VpdHkgYWJvdXQgaG93IHRvIHBhcnRpdGlvbiBhIGdpdmVuIElQIGFk ZHJlc3MgaW50byBMT0M6RlVOQ1Q6QVJHLg0KPiANCj4gW1BDMl0gUGxlYXNlIHJlZmVyIHRvIHBy ZXZpb3VzIGNvbW1lbnRzIGFuZCBhbHNvIHRoZSB0ZXh0IGluIFNlYyAzLiBUaGUgU1IgRW5kcG9p bnQgTm9kZSBwZXJmb3JtcyBMUE0gbG9va3VwIHRvIG1hdGNoIHRoZSBGSUIgZW50cnkgY29ycmVz cG9uZGluZyB0byBTSURzIHRoYXQgaXQgaGFzIGluc3RhbnRpYXRlZCBpbiBvcmRlciB0byBleGVj dXRlIHRoZSBpbnN0cnVjdGlvbnMgc3BlY2lmaWMgdG8gaXRzIGJlaGF2aW9yLiBUaGUgcGFja2V0 IHdpdGggdGhlIFNJRCBpbiB0aGUgREEgaXMgcm91dGVkIHRocm91Z2ggdHJhbnNpdCBub2RlcyBi YXNlZCBvbiBMUE0gbG9va3VwIHRoYXQgaGFwcGVucyBvbiB0aGUgbG9jYXRvciBwYXJ0cyB0aGF0 IGFyZSBhZHZlcnRpc2VkIHZpYSByb3V0aW5nL2NvbnRyb2wgcGxhbmUgYXMgZGVzY3JpYmVkIGlu IFNlYyAzLjMuIFRoZSB0cmFuc2l0IG5vZGVzIGRvIG5vdCBoYXZlIHRvIGRlY29kZSBvciBwcm9n cmFtIFNJRHMgdGhhdCBoYXZlIGJlZW4gaW5zdGFudGlhdGVkIGJ5IG90aGVyIFNSIEVuZHBvaW50 IG5vZGVzIGluIHRoZSBkb21haW4uDQoNCkkgYWdyZWUgdGhhdCB0aGUgdHJhbnNpdCBub2RlcyBk b24ndCBuZWVkIHRvIGtub3cgYW55dGhpbmcgYWJvdXQgdGhpcy4NClRoZSBub2RlIHRoYXQgaW5z dGFudGlhdGVzIHRoZSBTSUQsIGhvd2V2ZXIsIGRvZXMuICBBcyBhIHRvdGFsbHkgY29udHJpdmVk IGV4YW1wbGUsIHN1cHBvc2UgdGhhdCBJIGhhdmUgYSBwcmVmaXggb2YgYWJjZDphYmNkOjogYXMg bXkgTE9DIGFuZCBJIHdhbnQgdG8gdXNlIEZVTkNUIG9mIDB4MTIzNCB0byBpbmRpY2F0ZSBiZWhh dmlvciBjb2RlcG9pbnQgMSwgRlVOQ1Qgb2YNCjB4MTIzNTEyMzUgdG8gaW5kaWNhdGUgYmVoYXZp b3IgY29kZXBvaW50IDIsIGFuZCBGVU5DVCBvZiAweDEyMzUxMjM2IHRvIGluZGljYXRlIGJlaGF2 aW9yIGNvZGVwb2ludCAzLiAgSSBiYXNpY2FsbHkgaGF2ZSB0byBzdG9yZSB0aGF0IGluIGEgdGFi bGUsIGFuZCBjYW4ndCB3cml0ZSBzb21lIGxvZ2ljIHRoYXQgbG9va3MgYXQgdGhlIDE2IGJpdHMg YWZ0ZXIgdGhlIExPQy4gIElmIEkgaW5zdGVhZCB1c2VkIDB4MTIzNCwgMHgyMjM1MTIzNSwgYW5k IDB4MjIzNTEyMzYsIHRoZW4gdGhlIGZpcnN0IGZvdXIgYml0cyBhZnRlciBMT0MgY291bGQgYmUg dGhlIGxlbmd0aCBvZiBGVU5DVCBlbmNvZGluZyBpbiAyLWJ5dGUgaW5jcmVtZW50cywgYW5kIEkg Y291bGQgaGF2ZSBzb21lICJzaW1wbGUiIGNvZGUgdG8gdW5wYWNrIHRoZSBzZWxmLWRlbGluZWF0 aW5nIGVuY29kaW5nLg0KDQpbUEMzXSBMZXRzIHJlbWluZCB0aGF0IFJGQzg3NTQgZXhwbGljaXRs eSBzdGF0ZXMgIml0IHBlcmZvcm1zIGEgbG9uZ2VzdC1wcmVmaXgtbWF0Y2ggbG9va3VwIi4gQW55 dGhpbmcgYWZ0ZXIgdGhhdCBpcyBhIGxvY2FsIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIGJ5IHRo ZSBzZWdtZW50IGVuZHBvaW50IHRoYXQgaW5zdGFudGlhdGVzIHRoZSBTSUQgYW5kIGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIA0KDQpJbiBzaG9ydDogdGhpcyB0b3BpYyBv bmx5IGNvbnNpZGVycyBob3cgYSBnaXZlbiBub2RlIGFzc2lnbnMgaXRzIG93biBMT0M6RlVOQ1Q6 QVJHIHZhbHVlcywgYW5kIG1heSBiZSBzZWxmLWV2aWRlbnQgdG8gbW9zdCByZWFkZXJzLCBidXQg aXQgY2FuIHN0aWxsIGJlIGhlbHBmdWwgdG8gbm90ZSBhcyBndWlkYW5jZSBvbiBob3cgdG8gbWFr ZSB0aG9zZSBhbGxvY2F0aW9ucy4NCg0KPiA+ICAgIEFuIFNSdjYgU2VnbWVudCBFbmRwb2ludCBC ZWhhdmlvciBtYXkgcmVxdWlyZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uDQo+ID4gICAgZm9yIGl0 cyBwcm9jZXNzaW5nIChlLmcuIHJlbGF0ZWQgdG8gdGhlIGZsb3cgb3Igc2VydmljZSkuICBUaGlz DQo+ID4gICAgaW5mb3JtYXRpb24gbWF5IGJlIGVuY29kZWQgaW4gdGhlIEFSRyBiaXRzIG9mIHRo ZSBTSUQuDQo+ID4NCj4gPiAoQXNzdW1pbmcgdGhhdCBpdCBjYW4gYmUgc3VmZmljaWVudGx5IGNv bXBhY3RseSBlbmNvZGVkPykgW1BDXSANCj4gPiBDb3JyZWN0DQo+ID4NCj4gPiAgICBUaGUgQVJH IHZhbHVlIG9mIGEgcm91dGVkIFNJRCBTSE9VTEQgcmVtYWluIGNvbnN0YW50IGFtb25nIHBhY2tl dHMgaW4NCj4gPiAgICBhIGdpdmVuIGZsb3cuICBWYXJ5aW5nIEFSRyB2YWx1ZXMgYW1vbmcgcGFj a2V0cyBpbiBhIGZsb3cgbWF5IA0KPiA+IHJlc3VsdA0KPiA+DQo+ID4gKFRodXMgbGltaXRpbmcg dGhlIHR5cGUgb2YgaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgcmVwcmVzZW50ZWQgaW4gDQo+ID4g dGhlDQo+ID4gQVJHPykNCj4gPiBbUENdIFRoaXMgdGV4dCBwcm92aWRlcyBhIFNIT1VMRCwgYW5k IGEgcmVhc29uIGZvciBpdC4gSWYgb3RoZXIgYmVoYXZpb3JzIGRlZmluZWQgaW4gZnV0dXJlIGRv Y3VtZW50cyB3b3VsZCBsaWtlIHRvIGhhdmUgQVJHIHZhbHVlIHZhcnlpbmcgZm9yIHBhY2tldHMg YmVsb25naW5nIHRvIHRoZSBzYW1lIGZsb3csIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZXkgdGFr ZSB0aGlzIGludG8gY29uc2lkZXJhdGlvbi4NCj4gPg0KPiA+IFNlY3Rpb24gMy4yDQo+ID4NCj4g PiAgICBTSURzLiAgVGhlIHByb3ZpZGVyIGhpc3RvcmljYWxseSBkZXBsb3llZCBJUHY2IGFuZCBh c3NpZ25lZA0KPiA+ICAgIGluZnJhc3RydWN0dXJlIGFkZHJlc3NlcyBmcm9tIGEgcG9ydGlvbiBv ZiB0aGUgZmMwMDo6LzcgcHJlZml4LiAgVGhleQ0KPiA+ICAgIGZ1cnRoZXIgc3ViZGl2aWRlZCB0 aGUgcHJlZml4IGludG8gdGhyZWUgLzQ4IHByZWZpeGVzIChDb3VudHJ5IFgsDQo+ID4gICAgQ291 bnRyeSBZLCBDb3VudHJ5IFopIHRvIHN1cHBvcnQgdGhlaXIgU1J2NiBpbmZyYXN0cnVjdHVyZS4g IEZyb20NCj4gPiAgICB0aG9zZSAvNDggcHJlZml4ZXMgZWFjaCByb3V0ZXIgaXMgYXNzaWduZWQg YSAvNjQgcHJlZml4IGZyb20gd2hpY2gNCj4gPiAgICBhbGwgU0lEcyBvZiB0aGF0IHJvdXRlciBh cmUgYWxsb2NhdGVkLg0KPiA+DQo+ID4gVGhpcyBpcyBub3QgdGhlIGxhbmd1YWdlIEkgd291bGQg aGF2ZSBleHBlY3RlZCBmb3IgdXNlIG9mIHRoZSBVTEEgYWRkcmVzcyByYW5nZS4gIEl0IGxvb2tz IGxpa2UgdGhpcyBtYXkgYmUgcmVsYXRlZCB0byBFcmlrIEtsaW5lJ3MgRGlzY3VzcyBwb2ludC4u Lg0KPiA+IFtQQ10gSW5kZWVkIHJlbGF0ZWQuIEVyaWsgS2xpbmUgaGFzIHN1Z2dlc3RlZCB0ZXh0 LiBJbGwgdXNlIEVyaWvigJlzIHRleHQgYXMgcHJvdmlkZWQuDQo+ID4NCj4gPiAgICBJUHY2IGFk ZHJlc3MgY29uc3VtcHRpb24gaW4gYm90aCB0aGVzZSBleGFtcGxlcyBpcyBtaW5pbWFsLA0KPiA+ ICAgIHJlcHJlc2VudGluZyBvbmUgYmlsbGlvbnRoIGFuZCBvbmUgbWlsbGlvbnRoIG9mIHRoZSBh c3NpZ25lZCBhZGRyZXNzDQo+ID4gICAgc3BhY2UsIHJlc3BlY3RpdmVseS4NCj4gPg0KPiA+IEkn bSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGNhbGN1bGF0aW9uIHRoYXQgcHJvZHVjZWQgdGhl c2UgdmFsdWVzLg0KPiA+IFtQQ10gSWYgdGhlIG9wZXJhdG9yIGdvdCBhc3NpZ25lZCBhIC8yMCBi eSB0aGUgUklSLCB0aGVuIHRoZXkgaGF2ZSAyXjI4IC80OCBwcmVmaXhlcyBhdmFpbGFibGUuIFRo dXMsIGlmIHRoZXkgYXJlIG9ubHkgdXNpbmcgYSBmZXcgLzQ4IHByZWZpeGVzLCB0aGVuIHRoZXkg YXJlIHVzaW5nIGxlc3MgdGhhbiBhIG1pbGxpb250aCBvZiB0aGUgYXZhaWxhYmxlIC80OCBwcmVm aXhlcy4NCj4gDQo+IEFwcGFyZW50bHkgSSBkaWRuJ3QgdGFrZSBub3RlcyBvbiBteSBpbml0aWFs IGNhbGN1bGF0aW9ucyB0aGF0IGxlZnQgbWUgY29uZnVzZWQuICBBc3N1bWluZyBJIGhhdmUgaXQg cmlnaHQgdGhpcyB0aW1lLi4uDQo+IA0KPiAjIFVzZSAzIC80OHMgaW4gdGhlIHdob2xlIFVMQSAv NDANCj4gPj4+IDMuLzIqKjQwDQo+IDIuNzI4NDg0MTA1MzE4Nzg0N2UtMTINCj4gIyBVc2UgImEg ZmV3IiAzIC80OHMgZnJvbSB0aGUgYXNzaWduZWQgLzIwDQo+ID4+PiAzLi8yKioyOA0KPiAxLjEx NzU4NzA4OTUzODU3NDJlLTA4DQo+IA0KPiBUaGlzIHNlZW1zIHRvIGJlIHdlbGwgbGVzcyB0aGFu IGEgYmlsbGlvbnRoIGFuZCBhIG1pbGxpb250aCwgcmVzcGVjdGl2ZWx5LCBzbyBJJ20gbm90IHN1 cmUgaWYgSSBhbSBkb2luZyB0aGUgbWF0aCBhcyBpbnRlbmRlZC4NCj4gDQo+IFtQQzJdIEkgYmVs aWV2ZSB5b3VyIG1hdGhzIGFyZSByaWdodC4NCj4gSWYgYW4gb3BlcmF0b3IgaXMgYWxsb2NhdGVk IGEgLzIwLCB0aGV5IGNhbiBhbGxvY2F0ZSAyKioyOCAgLzQ4IHByZWZpeGVzLg0KPiAyKioyOCA9 IDI2ODQzNTQ1Ni4NCj4gVGh1cywgSWYgU1J2NiByZXF1aXJlcyAzIG9mIHN1Y2ggLzQ4IHByZWZp eGVzLCB0aGVuIHdlIGFyZSB1c2luZyBvbmx5IDEuMTJlLTggb2YgdGhhdCBzcGFjZSwgd2hpY2gg aXMgbGVzcyB0aGFuIGEgbWlsbGlvbnRoIChlLTYpLg0KPiBObz8NCj4gSW4gb3RoZXIgd29yZHM6 IGlmIHdlIGRvIGEgbWlsbGlvbiBvZiBkZXBsb3ltZW50cyBvZiBTUnY2LCB0aGVyZSB3b3VsZCAN Cj4gYmUgc3BhY2UgdG8gZml0IHRoZW0gYWxsIHdpdGhpbiB0aGF0IC8yMC4gKGFuZCBhY3R1YWxs eSB0aGVyZSBpcyANCj4gc2xpZ2h0bHkgbW9yZSkNCg0KSSB3b3VsZCBzdWdnZXN0IGFkZGluZyAi bGVzcyB0aGFuIiBpbiB0aGUgdGV4dCwgdGhlbi4NCg0KW1BDM10gR290IGl0LiBVcGRhdGVkLg0K IA0KPiA+ICAgIEFuIFNSIFNvdXJjZSBOb2RlIGNhbm5vdCBpbmZlciB0aGUgYmVoYXZpb3IgYnkg ZXhhbWluYXRpb24gb2YgdGhlDQo+ID4gICAgRlVOQ1QgdmFsdWUgb2YgYSBTSUQuDQo+ID4NCj4g PiAgICBUaGVyZWZvcmUsIHRoZSBTUnY2IEVuZHBvaW50IEJlaGF2aW9yIGNvZGVwb2ludCBpcyBh ZHZlcnRpc2VkIGFsb25nDQo+ID4gICAgd2l0aCB0aGUgU0lEIGluIHRoZSBjb250cm9sIHBsYW5l Lg0KPiA+DQo+ID4gVGhlc2UgdHdvIHNlbnRlbmNlcyBmZWVsIGEgbGl0dGxlIG91dCBvZiBwbGFj ZSBpbiB0aGlzIHNwb3QsIG9jY3VycmluZyBhZnRlciBwcmV2aW91cyBkaXNjdXNzaW9uIHRoYXQg dGhlIGVuZHBvaW50IGJlaGF2aW9yIGNvZGVwb2ludCBpcyBhZHZlcnRpc2VkIGluIHRoZSBjb250 cm9sIHBsYW5lLg0KPiA+IFtQQ10gT3RoZXIgQURzIGhhdmUgZXhwcmVzc2VkIHRoZSB2YWx1ZSBv ZiBwcmVjaXNlbHkgdGhvc2UgdHdvIHNlbnRlbmNlcy4NCj4gDQo+IEkgYWdyZWUgdGhhdCB0aGVz ZSBzZW50ZW5jZXMgYXJlIHZhbHVhYmxlLiAgSSB3YXMgcHJvcG9zaW5nIHRvIG1vdmUgdGhlbSB0 d28gcGFyYWdyYXBocyBlYXJsaWVyLCBzbyB3ZSB0cmFuc2l0aW9uIGRpcmVjdGx5IGZyb20gImFk dmVydGlzZXMgdGhlIFNJRCAuLi4gaW4gdGhlIGNvbnRyb2wgcGxhbmUiIHRvIChwYXJhcGhyYXNp bmcpICJjYW5ub3QgaW5mZXIgYmVoYXZpb3IgYnkgZXhhbWluaW5nIEZVTkNUIiBhbmQgImJlaGF2 aW9yIGNvZGVwb2ludCBpcyBhZHZlcnRpc2VkIGFsb25nIHdpdGggU0lEIi4NCj4gDQo+IFtQQzJd IE1pc3VuZGVyc3Rvb2QgeW91ciBvcmlnaW5hbCBwb2ludC4gSSBtb3ZlZCB0aG9zZSB0d28gdXAg YXMgeW91IHN1Z2dlc3QuDQo+IA0KPiA+ICAgIG8gIEF0IFJvdXRlciAzLCB3aXRoaW4gdGhlIGxv Y2F0b3IgMjAwMTpkYjg6YmJiYjozOjovNjQsIG5ldHdvcmsNCj4gPiAgICAgICBvcGVyYXRvciBv ciB0aGUgcm91dGVyIHBlcmZvcm1zIGR5bmFtaWMgYXNzaWdubWVudCBmb3I6DQo+ID4NCj4gPiBu aXQ6IG1pc3NpbmcgYXJ0aWNsZSAoInRoZSBuZXR3b3JrIG9wZXJhdG9yIikuDQo+ID4gW1BDXSBB Y2suIEZpeGVkIGluIHJldjIxLg0KPiA+DQo+ID4gICAgICAgKiAgRnVuY3Rpb24gMTAwIGFzc29j aWF0ZWQgd2l0aCB0aGUgYmVoYXZpb3IgRW5kLlggKEVuZHBvaW50IHdpdGgNCj4gPiAgICAgICAg ICBjcm9zcy1jb25uZWN0KSBiZXR3ZWVuIHJvdXRlciAzIGFuZCBpdHMgY29ubmVjdGVkIG5laWdo Ym9yDQo+ID4gICAgICAgICAgcm91dGVyLCBmb3IgZXhhbXBsZSBSb3V0ZXIgNC4gIFRoaXMgZnVu Y3Rpb24gaXMgZW5jb2RlZCBhcw0KPiA+ICAgICAgICAgIDE2LWJpdCB2YWx1ZSBhbmQgaGFzIG5v IGFyZ3VtZW50cy4NCj4gPg0KPiA+IFBsZWFzZSBjbGFyaWZ5IHRoYXQgImZ1bmN0aW9uIDEwMCIg aXMgYSBoZXggbGl0ZXJhbC4NCj4gPiBbUENdIEFjay4gRml4ZWQgaW4gcmV2MjEuDQo+ID4NCj4g PiBJIGFsc28gc3VnZ2VzdCBub3RpbmcgY2xlYXJseSBhdCB0aGUgc3RhcnQgb2YgdGhlIGV4YW1w bGUgdGhhdCBGIGlzIDE2IGFuZCBBIGlzIDAuDQo+ID4gW1BDXSBBY2suIEFkZGVkIGZvciBlYWNo IFNJRCBpbiByZXYyMS4NCj4gPg0KPiA+ICAgICAgICogIEZ1bmN0aW9uIDEwMSBhc3NvY2lhdGVk IHdpdGggdGhlIGJlaGF2aW9yIEVuZC5YIChFbmRwb2ludCB3aXRoDQo+ID4gICAgICAgICAgY3Jv c3MtY29ubmVjdCkgYmV0d2VlbiByb3V0ZXIgMyBhbmQgaXRzIGNvbm5lY3RlZCBuZWlnaGJvcg0K PiA+ICAgICAgICAgIHJvdXRlciwgZm9yIGV4YW1wbGUgUm91dGVyIDIuICBUaGlzIGZ1bmN0aW9u IGlzIGVuY29kZWQgYXMNCj4gPiAgICAgICAgICAxNi1iaXQgdmFsdWUgYW5kIGhhcyBubyBhcmd1 bWVudHMuDQo+ID4NCj4gPiBGIGlzIGEgY29uc3RhbnQgZm9yIHRoZSBTUiBkb21haW47IHNheWlu ZyBpdCBhdCBlYWNoIFNJRCBhc3NpZ25tZW50IGlzIG1pc2xlYWRpbmcuDQo+ID4gW1BDXSBGdW5j dGlvbiBpcyB0aGUgYml0cyBpbiB0aGUgU0lEIGluc3RhbnRpYXRlZCBieSB0aGUgcm91dGVyLiBD YW4geW91IHBsZWFzZSBleHBsYWluIHdoYXQgdGV4dCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0 IEYgaXMgYSBjb25zdGFudD8NCj4gDQo+IEZVTkNUIGlzIGluc3RhbnRpYXRlZCBieSB0aGUgcm91 dGVyLCB5ZXMsIGFuZCBpdCBpcyBGIGJpdHMgbG9uZy4gIFRoaXMgdGllcyBpbiB0byBteSBwcmV2 aW91cyBjb21tZW50IGFib3V0IEwsIEYsIGFuZCBBIChtYXliZSkgYmVpbmcgY29uc3RhbnRzIGFj cm9zcyB0aGUgU1IgZG9tYWluLCBvciBjbGFyaWZ5aW5nIGF0IHdoaWNoIHNjb3BlIHRoZXkgY2Fu IHZhcnkuDQo+IA0KPiBbUEMyXSBJbmRlZWQsIHNlZSBwcmV2aW91cyBhbnN3ZXIuDQo+IA0KPiA+ IFtzYW1lIG5vdGUgYWJvdXQgaGV4IGZvciAxMDFdDQo+ID4gW1BDXSBBY2suIEFkZGVkIGZvciBl YWNoIFNJRCBpbiByZXYyMS4NCj4gPg0KPiA+IFNlY3Rpb24gNA0KPiA+DQo+ID4gICAgVGhlIGxp c3QgaXMgbm90IGV4aGF1c3RpdmUuICBJbiBwcmFjdGljZSwgYW55IGZ1bmN0aW9uIGNhbiBiZQ0K PiA+ICAgIGF0dGFjaGVkIHRvIGEgbG9jYWwgU0lEOiBlLmcuIGEgbm9kZSBOIGNhbiBiaW5kIGEg U0lEIHRvIGEgbG9jYWwgVk0NCj4gPiAgICBvciBjb250YWluZXIgd2hpY2ggY2FuIGFwcGx5IGFu eSBjb21wbGV4IHByb2Nlc3Npbmcgb24gdGhlIHBhY2tldC4NCj4gPg0KPiA+IFllcywgYnV0IGl0 IGNhbid0IGFkdmVydGlzZSB0aGUgYmVoYXZpb3IgY29ycmVzcG9uZGluZyB0byB0aGF0IGZ1bmN0 aW9uIHdpdGhvdXQgYSBjb2RlcG9pbnQuDQo+ID4gW1BDXSBUaGlzIGlzIGludGVuZGVkIHRvIGJl IGFuIGludHJvZHVjdG9yeSBwYXJhZ3JhcGggdG8gdGhlIGJlaGF2aW9ycy4gQnV0IHlvdSBhcmUg YWJzb2x1dGVseSByaWdodDogZm9yIGFueSBuZXcgYmVoYXZpb3IgeW91IG5lZWQgdG8gd3JpdGUg YSBuZXcgSS1EIChhcyBpdHMgY3VycmVudGx5IGhhcHBlbmluZyBpbiBvdGhlciBTUFJJTkcgV0cg ZG9jcyksIGFuZCB0aGVuIC1vbmNlIFJGQ2VkLSBnZXQgYW4gU1J2NiBFbmRwb2ludCBCZWhhdmlv ciBjb2RlcG9pbnQgZm9yIGl0Lg0KPiANCj4gTWF5YmUgd2UgY291bGQgYWRkIGF0IHRoZSBlbmQg IiwgcHJvdmlkZWQgdGhlcmUgaXMgYSBiZWhhdmlvciANCj4gY29kZXBvaW50IGFsbG9jYXRlZCBm b3IgdGhhdCBwcm9jZXNzaW5nIiBvciBzb21lIHNpbWlsYXIgZWRpdD8gIChXZSANCj4gZG9uJ3Qg aGF2ZSB0bzsgdGhlIGRlY2lzaW9uIGlzIHVwIHRvIHlvdS4pDQo+IA0KPiBbUEMyXSBJJ20gZmlu ZSB3aXRoIGl0LiBBZGRlZCBhcyBzdWdnZXN0ZWQuDQo+IA0KPiA+IFNlY3Rpb24gNC4xLjENCj4g Pg0KPiA+ICAgIFdoZW4gcHJvY2Vzc2luZyB0aGUgVXBwZXItbGF5ZXIgSGVhZGVyIG9mIGEgcGFj a2V0IG1hdGNoaW5nIGEgRklCDQo+ID4gICAgZW50cnkgbG9jYWxseSBpbnN0YW50aWF0ZWQgYXMg YW4gU1J2NiBFbmQgU0lELCBpZiBVcHBlci1sYXllciBIZWFkZXINCj4gPiAgICBwcm9jZXNzaW5n IGlzIGFsbG93ZWQgYnkgbG9jYWwgY29uZmlndXJhdGlvbiAoZS5nLiAgSUNNUHY2KSwgdGhlbg0K PiA+DQo+ID4gbml0OiB0aGUgcGFyZW50aGV0aWNhbCBpcyBwbGFjZWQgc28gYXMgdG8gYXBwbHkg dG8gImxvY2FsIGNvbmZpZ3VyYXRpb24iLCB3aGljaCBkb2Vzbid0IHJlYWxseSBtYWtlIHNlbnNl OyBJIHByZXN1bWUgdGhlIGludGVudCBpcyB0byBzYXkgdGhhdCB1cHBlci1sYXllciBoZWFkZXIg cHJvY2Vzc2luZyBpcyBhbGxvd2VkICpmb3IgdGhhdCB1cHBlci1sYXllciBwcm90b2NvbCouICBB bHNvLCBjb21tYSBhZnRlciAiZS5nLiIuDQo+ID4gW1BDXSBBZ3JlZWQsIGJ1dCBzZWUgbmV4dCBw b2ludC4NCj4gPg0KPiA+ICAgIHByb2JsZW0gbWVzc2FnZSB0byB0aGUgU291cmNlIEFkZHJlc3Mg YW5kIGRpc2NhcmQgdGhlIHBhY2tldC4gIEVycm9yDQo+ID4gICAgY29kZSA0IChTUiBVcHBlci1s YXllciBIZWFkZXIgRXJyb3IpIGFuZCBQb2ludGVyIHNldCB0byB0aGUgb2Zmc2V0IG9mDQo+ID4g ICAgdGhlIHVwcGVyLWxheWVyIGhlYWRlci4NCj4gPg0KPiA+IG5pdDogdGhpcyBpcyBub3QgYSBj b21wbGV0ZSBzZW50ZW5jZS4NCj4gPiBbUENdIFdlIGhhdmUgYmVlbiBhc2tlZCB0byBjaGFuZ2Ug dGhlIGVudGlyZSA0LjEuMSB0byBhIHBzZXVkb2NvZGUuIFBsZWFzZSByZXZpZXcgdGhlIHBzZXVk b2NvZGUgaW4gcmV2aXNpb24gMjEgYW5kIGxldCBtZSBrbm93IHlvdXIgZmVlZGJhY2suDQo+IA0K PiBZZXMsIHRoaXMgcHNldWRvY29kZSBsb29rcyBtdWNoIGJldHRlciAtLSB0aGFuayB5b3UhDQo+ IA0KPiBUaGF0IHNhaWQsIEkgYW0gbm90IHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgd2h5IGl0IGlz IG9ubHkgUkVDT01NRU5ERUQgDQo+IChub3QNCj4gUkVRVUlSRUQpIHRvIG9ubHkgYWxsb3cgdXBw ZXItbGF5ZXIgcHJvY2Vzc2luZyB3aGVuIHRoYXQgZG9lcyBub3QgcmVzdWx0IGluIHRoZSBwYWNr ZXQgYmVpbmcgZm9yd2FyZGVkLiAgQXJlIHRoZXJlIGNhc2VzIHdoZW4gdGhpcyB3b3VsZCBiZSB1 c2VmdWwgYW5kIG5vdCByZXN1bHQgaW4gYSBwYWNrZXQgbG9vcD8NCj4gDQo+IFtQQzJdIFdlIGJl bGlldmUgdGhhdCBSRUNPTU1FTkRBVElPTiBpcyBzdHJvbmcgZW5vdWdoIGZvciB0aGlzIHNjZW5h cmlvLiBJIGFtIG5vdCBzdXJlIHRoYXQgd2UgY2FuIHNheSB0aGF0IHBhY2tldHMgZm9yd2FyZGVk IGFmdGVyIGxvY2FsIHByb2Nlc3Npbmcgd2lsbCBhbHdheXMgcmVzdWx0IGluIGEgbG9vcCBlLmcu IGlmIHRoZXJlIGlzIGFuIGlubmVyIGVuY2Fwc3VsYXRlZCBJUCBwYWNrZXQgdGhhdCBuZWVkcyB0 byBnZXQgZm9yd2FyZGVkIGZ1cnRoZXIuDQoNCk9rYXkuDQoNCj4gPiBTZWN0aW9uIDQuMg0KPiA+ DQo+ID4gICAgSXQgaXMgdGhlIFNSdjYgaW5zdGFudGlhdGlvbiBvZiBhbiBBZGphY2VuY3ktU0lE IFtSRkM4NDAyXSBhbmQgaXQgaXMNCj4gPiAgICByZXF1aXJlZCB0byBleHByZXNzIGFueSB0cmFm ZmljLWVuZ2luZWVyaW5nIHBvbGljeS4NCj4gPg0KPiA+IFRoaXMgdGV4dCByZWFkcyBhcyBpZiBF bmQuWCBzcGVjaWZpY2FsbHkgaXMgcmVxdWlyZWQgZm9yIFRFLCB3aGljaCBkb2VzIG5vdCBzZWVt IGNvcnJlY3QgdG8gbWUuDQo+ID4gW1BDXSBGaXhlZC4NCj4gPiBPTEQ6IGFuZCBpdCBpcyByZXF1 aXJlZCB0byBleHByZXNzIGFueSB0cmFmZmljLWVuZ2luZWVyaW5nIHBvbGljeS4NCj4gPiBORVc6 IGFuZCBpdHMgbWFpbiB1c2UgaXMgZm9yIHRyYWZmaWMtZW5naW5lZXJpbmcgcG9saWNpZXMuDQo+ ID4NCj4gPiBTZWN0aW9uIDQuNCwgNC41DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZSBwZXItQ0UNCj4gPiAg ICBWUE4gbGFiZWwgaW4gTVBMUyBbUkZDNDM2NF0uDQo+ID4NCj4gPiBUaGUgcGhyYXNlICJwZXIt Q0UgVlBOIiBkb2VzIG5vdCBhcHBlYXIgaW4gUkZDIDQzNjQuDQo+ID4gW1BDXSBBZGRlZCB0byB0 aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4NCj4gPg0KPiA+IFNlY3Rpb24gNC41DQo+ID4NCj4gPiAg ICBTMDUuICBJZiB0aGUgRW5kLkRYNCBTSUQgaXMgYm91bmQgdG8gYW4gYXJyYXkgb2YgTDMgYWRq YWNlbmNpZXMsIHRoZW4NCj4gPiAgICBvbmUgZW50cnkgb2YgdGhlIGFycmF5IGlzIHNlbGVjdGVk IGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBwYWNrZXQncw0KPiA+ICAgIGhlYWRlciBTZWN0aW9u IDcuDQo+ID4NCj4gPiBuaXQ6IEkgc3VnZ2VzdCAiKHNlZSBTZWN0aW9uIDcpIiB0byBtYXRjaCBz ZWN0aW9uIDQuNC4NCj4gPiBbUENdIEluZGVlZC4gRml4ZWQuDQo+ID4NCj4gPiBTZWN0aW9uIDQu NiwgNC43DQo+ID4NCj4gPiAgICBpcyByZXF1aXJlZC4gIFRoaXMgaXMgZXF1aXZhbGVudCB0byB0 aGUgcGVyLVZSRiBWUE4gbGFiZWwgaW4gTVBMUw0KPiA+ICAgIFtSRkM0MzY0XS4NCj4gPg0KPiA+ IFRoZSBwaHJhc2UgInBlci1WUkYgVlBOIiBkb2VzIG5vdCBhcHBlYXIgaW4gUkZDIDQzNjQuDQo+ ID4gKEEgc2ltaWxhciBjb21tZW50IGFwcGxpZXMgdG8gU2VjdGlvbiA0LjggYXMgd2VsbC4pIFtQ Q10gQWRkZWQgdG8gDQo+ID4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gb2YgdGhlIGRvY3VtZW50 Lg0KPiA+DQo+ID4gICAgTm90ZSB0aGF0IGFuIEVuZC5EVDYgbWF5IGJlIGRlZmluZWQgZm9yIHRo ZSBtYWluIElQdjYgdGFibGUgaW4gd2hpY2gNCj4gPiAgICBjYXNlIGFuZCBFbmQuRFQ2IHN1cHBv cnRzIHRoZSBlcXVpdmFsZW50IG9mIGFuIElQdjZpbklQdjYNCj4gPg0KPiA+IG5pdDogcy9hbmQv YW4vDQo+ID4gW1BDXSBUaGFua3MuIEZpeGVkLg0KPiA+DQo+ID4gU2VjdGlvbiA0LjcNCj4gPg0K PiA+ICAgIFRoZSAiRW5kcG9pbnQgd2l0aCBkZWNhcHN1bGF0aW9uIGFuZCBzcGVjaWZpYyBJUHY0 IHRhYmxlIGxvb2t1cCINCj4gPiAgICBiZWhhdmlvciAoRW5kLkRUNCBmb3Igc2hvcnQpIGlzIGEg dmFyaWFudCBvZiB0aGUgRW5kIGJlaGF2aW9yLg0KPiA+DQo+ID4gbml0OiB2YXJpYW50IG9mIEVu ZC5ULCBqdXN0IGxpa2UgRW5kLkRUNiwgbm8/DQo+ID4gW1BDXSBDb3JyZWN0LCBmaXhlZC4NCj4g Pg0KPiA+IFNlY3Rpb24gNC45DQo+ID4NCj4gPiAgICBTMDQuICBBbiBFbmQuRFgyIGJlaGF2aW9y IGNvdWxkIGJlIGN1c3RvbWl6ZWQgdG8gZXhwZWN0IGEgc3BlY2lmaWMNCj4gPiAgICBJRUVFIGhl YWRlciAoZS5nLiAgVkxBTiB0YWcpIGFuZCByZXdyaXRlIHRoZSBlZ3Jlc3MgSUVFRSBoZWFkZXIN Cj4gPiAgICBiZWZvcmUgZm9yd2FyZGluZyBvbiB0aGUgb3V0Z29pbmcgaW50ZXJmYWNlLg0KPiA+ DQo+ID4gV291bGQgdGhpcyBjdXN0b21pemVkIGJlaGF2aW9yIHJlcXVpcmUgYSBuZXcgY29kZXBv aW50Pw0KPiA+IFNpbWlsYXJseSBmb3IgRW5kLkRYMlYgKFNlY3Rpb24gNC4xMCkgW1BDXSBObywg dGhhdCBjdXN0b21pemF0aW9uIGlzIA0KPiA+IGxvY2FsIGNvbmZpZyB0byB0aGUgbm9kZS4NCj4g DQo+IFRoYXQgaXMgc3VycHJpc2luZyB0byBtZSAoaXQgc2VlbXMgbGlrZSBhbiBpbXBvcnRhbnQg cGFydCBvZiB0aGUgYmVoYXZpb3IgdGhhdCBzaG91bGQgYmUgc2lnbmFsbGVkIGV4cGxpY2l0bHkp LCBidXQgSSBhbSBub3QgZmFtaWxpYXIgZW5vdWdoIHdpdGggdGhpcyBkb21haW4gaW4gb3JkZXIg dG8gYXJndWUgYWJvdXQgaXQgYW55IGZ1cnRoZXIuDQo+IA0KPiBbUEMyXSBJbiBNUExTIHRoaXMg aXMgbG9jYWwgY29uZmlnLiBXaGlsZSBzb21lb25lIG1pZ2h0IHRoaW5rIGFib3V0IHNpZ25hbGlu ZyBpdCBpbiB0aGUgZnV0dXJlIC1pbnR1aXRpdmVseSBtYWtlcyBzZW5zZS0sIGluIHRvZGF54oCZ cyB1c2UtY2FzZSBpdCBpc27igJl0Lg0KDQpUaGFua3MgZm9yIHRoZSBwb2ludGVyIGFib3V0IE1Q TFMsIHRoYXQgaGVscHMuDQpBbmQgSSBhZ3JlZSB0aGF0IGl0IHNlZW1zIHN0cmFpZ2h0Zm9yd2Fy ZCB0byBhZGQgc2lnbmFsaW5nIGluIHRoZSBmdXR1cmUgaWYgbmVlZGVkLg0KDQo+ID4gU2VjdGlv biA0LjEwDQo+ID4NCj4gPiAgICBTMDQuIFJlbW92ZSB0aGUgb3V0ZXIgSVB2NiBIZWFkZXIgd2l0 aCBhbGwgaXRzIGV4dGVuc2lvbiBoZWFkZXJzLA0KPiA+ICAgICAgICAgICAgbG9va3VwIHRoZSBl eHBvc2VkIFZMQU5zIGluIEwyIHRhYmxlIFQsIGFuZCBmb3J3YXJkDQo+ID4gICAgICAgICAgICB2 aWEgdGhlIG1hdGNoZWQgdGFibGUgZW50cnkuDQo+ID4NCj4gPiBKdXN0IHRvIGNoZWNrIG15IHVu ZGVyc3RhbmRpbmc6IHRoZSAiZXhwb3NlZCBWTEFOcyIgKHBsdXJhbD8hKSBhcmUgaW4gdGhlIEV0 aGVybmV0IGhlYWRlciBvZiB0aGUgcGFja2V0IHRoYXQgd2UgYXJlIGxlZnQgd2l0aCBhZnRlciBy ZW1vdmluZyB0aGUgb3V0ZXIgSVB2NiBoZWFkZXIsIHJpZ2h0Pw0KPiA+IFtQQ10gQ29ycmVjdC4g QW5kIG11bHRpcGxlIHRhZ3MgaW4gY2FzZSBvZiBRLWluLVEuDQo+ID4NCj4gPiAgICBTMDEuICBJ QU5BIGhhcyBhbGxvY2F0ZWQgdGhlIEludGVybmV0IFByb3RvY29sIG51bWJlciAxNDMgdG8gRXRo ZXJuZXQNCj4gPiAgICAoc2VlIFNlY3Rpb24gMTAuMSkuDQo+ID4NCj4gPiBUaGlzIHNlZW1zIGxp a2UgYSBjb3B5L3Bhc3RlIGxlZnRvdmVyIGZyb20gRW5kLkRYMiAtLSB3ZSBkb24ndCANCj4gPiBt ZW50aW9uDQo+ID4gMTQzIGluIHRoaXMgc2VjdGlvbi4NCj4gPiBbUENdIEluZGVlZC4gSSBhZGRl ZCBieSBtaXN0YWtlIG9uIHJldjIwIHRvIGFkZHJlc3MgYW4gQUQgY29tbWVudCBhbmQgSSBoYXZl IGp1c3QgcmVtb3ZlZCBpbiByZXYyMSBhZ2Fpbi4NCj4gPg0KPiA+IFNlY3Rpb24gNC4xMg0KPiA+ DQo+ID4gICAgVHdvIG9mIHRoZSBhcHBsaWNhdGlvbnMgb2YgdGhlIEVuZC5EVDJNIGJlaGF2aW9y IGFyZSB0aGUgRVZQTg0KPiA+ICAgIEJyaWRnaW5nIG9mIGJyb2FkY2FzdCwgdW5rbm93biBhbmQg bXVsdGljYXN0IChCVU0pIHRyYWZmaWMgd2l0aA0KPiA+ICAgIEV0aGVybmV0IFNlZ21lbnQgSWRl bnRpZmllciAoRVNJKSBmaWx0ZXJpbmcgYW5kIHRoZSBFVlBOIEVUUkVFIHVzZS0NCj4gPiAgICBj YXNlcy4NCj4gPg0KPiA+IEFyZSB0aGVyZSByZWZlcmVuY2VzIGZvciBlaXRoZXIvYm90aCBvZiB0 aGVzZT8NCj4gPiBbUENdIEFkZGVkIGluIHJldjIxLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gPiAg ICBTMDQuIFJlbW92ZSB0aGUgSVB2NiBoZWFkZXIgYW5kIGFsbCBpdHMgZXh0ZW5zaW9uIGhlYWRl cnMNCj4gPg0KPiA+IG5pdDogdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IHVzZXMgIlJlbW92ZSB0 aGUgb3V0ZXIgSVB2NiBoZWFkZXIgd2l0aCBhbGwgaXRzIGV4dGVuc2lvbiBoZWFkZXJzIi4NCj4g PiBbUENdIEZpeGVkLiBUaGFua3MuDQo+ID4NCj4gPiAgICBTMDYuIEZvcndhcmQgdmlhIGFsbCBM MiBPSUZzIGV4Y2x1ZGluZyB0aGUgb25lIHNwZWNpZmllZCBpbiANCj4gPiBBcmcuRkUyDQo+ID4N Cj4gPiBuaXQ6IHMvb25lL29uZXMvDQo+ID4gW1BDXSBGaXhlZC4gVGhhbmtzLg0KPiA+DQo+ID4g ICAgQXJnLkZFMiBpcyBlbmNvZGVkIGluIHRoZSBTSUQgYXMgYW4gKGsqeCktYml0IHZhbHVlLiAg VGhlc2UgYml0cw0KPiA+ICAgIHJlcHJlc2VudCBhIGxpc3Qgb2YgdXAgdG8gayBPSUZzLCBlYWNo IGlkZW50aWZpZWQgd2l0aCBhbiB4LWJpdA0KPiA+ICAgIHZhbHVlLiAgVmFsdWVzIGsgYW5kIHgg YXJlIGRlZmluZWQgb24gYSBwZXIgRW5kLkRUMk0gU0lEIGJhc2lzLiAgVGhlDQo+ID4gICAgaW50 ZXJmYWNlIGlkZW50aWZpZXIgMCBpbmRpY2F0ZXMgYW4gZW1wdHkgZW50cnkgaW4gdGhlIGludGVy ZmFjZQ0KPiA+ICAgIGxpc3QuDQo+ID4NCj4gPiAoZWRpdG9yaWFsKSByYXRoZXIgdGhhbiBoYXZl IHRvIGNvbWUgdXAgd2l0aCB0aGUgY29uY2VwdCBvZiBhbiAiZW1wdHkgZW50cnkiIGluIHRoZSBp bnRlcmZhY2UgbGlzdCwgSSB3b3VsZCBwcm9iYWJseSBqdXN0IHNheSB0aGF0IHRoZSBpZGVudGlm aWVyIDAgaXMgcmVzZXJ2ZWQgYW5kIGlzIGlnbm9yZWQgd2hlbiBkb2luZyB0aGUgZXhjbHVzaW9u IG9mIE9JRnMuDQo+ID4NCj4gPiBJIGFsc28gdGhpbmsgd2UgbmVlZCB0byBzYXkgdGhhdCB0aGUg b3JkZXIgYW5kIGlkZW50aWZpZXIgYXNzaWdubWVudCANCj4gPiBvZiBlbGVtZW50cyBvZiB0aGUg aW50ZXJmYWNlIGxpc3QgKHRoYXQgaXMsIHdoYXQgdGhlIHgtYml0IHZhbHVlcyANCj4gPiBpbmRl eA0KPiA+IGludG8pIGlzIHVuZGVyIHRoZSBsb2NhbCBjb250cm9sIG9mIE4sIGJ1dCBoYXMgdG8g cmVtYWluIHN0YWJsZSBhcyANCj4gPiBsb25nIGFzIFNJRHMgYXJlIGFkdmVydGlzZWQgdGhhdCBs aXN0IG1lbWJlcnMgb2YgdGhlIGxpc3QgaW4gQVJHLiAgKFRoZXJlIGlzIG90aGVyd2lzZSBhIGdy ZWF0IGRlYWwgb2YgZnJlZWRvbSBpbiBhc3NpZ25tZW50IHNpbmNlIHRoZSB2YWx1ZXMgYXJlIG9u bHkgY29uc3VtZWQgYnkgdGhlIG5vZGUgdGhhdCBhZHZlcnRpc2VzIHRoZW0uKSBbUENdIFRoaXMg dGV4dCBpcyB1cGRhdGVkIGFzIHBhcnQgb2YgQWx2YXJv4oCZcyBjb21tZW50LiBDYW4geW91IHBs ZWFzZSBjaGVjayB0aGUgY3VycmVudCB0ZXh0IGluIHJldjIxPw0KPiANCj4gSSB0aGluayB0aGUg bmV3IHRleHQgaXMgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nIC0tIHRoZSBzdHJ1Y3R1cmUgb2YgdGhl IHZhbHVlIGlzIGVudGlyZWx5IGxvY2FsIHRvIHRoZSBTUiBFbmRwb2ludCBhZHZlcnRpc2luZyBp dC4gIEkgd2lsbCBoYXZlIGFuIGVkaXRvcmlhbCBjb21tZW50IGluIG15IHVwZGF0ZWQgYmFsbG90 IHBvc2l0aW9uIGFib3V0IHRoZSAic2lnbmFsaW5nIG9mIHRoZSBhcmd1bWVudCB0byBvdGhlciBu b2Rlcy4uLiIgY2xhdXNlLCB0aG91Z2guDQo+IA0KPiA+IFNlY3Rpb24gNC4xMw0KPiA+DQo+ID4g SXQncyBwcm9iYWJseSB3b3J0aCBjYWxsaW5nIG91dCB0aGUgTVRVIGNvbnNpZGVyYXRpb25zIG9m IHB1c2hpbmcgDQo+ID4gdGhlIG5ldyBJUHY2IGhlYWRlcitTUkggYW5kIHR1bm5lbGluZyB0aGUg cGFja2V0cy4gIChJIGtub3cgd2UgDQo+ID4gcmVmZXJlbmNlDQo+ID4gMjQ3MyBhbHJlYWR5LCBi dXQgdGhlIE1UVSBpcyBwcmV0dHkgaW1wb3J0YW50LikgW1BDXSBNVFUgDQo+ID4gY29uc2lkZXJh dGlvbnMgYXJlIGNvdmVyZWQgaW4gUkZDODc1NC4NCj4gPg0KPiA+ICAgIFMxNy4gIFRoZSBQYXls b2FkIExlbmd0aCwgVHJhZmZpYyBDbGFzcyBhbmQgTmV4dC1IZWFkZXIgZmllbGRzIGFyZQ0KPiA+ ICAgIHNldCBhcyBwZXIgW1JGQzI0NzNdLiAgVGhlIEZsb3cgTGFiZWwgaXMgY29tcHV0ZWQgYXMg cGVyIFtSRkM2NDM3XS4NCj4gPg0KPiA+IEhvdyBpcyB0aGUgSG9wIExpbWl0IHNldCBmb3IgdGhl IG91dGVyIGhlYWRlcj8NCj4gPiAoSSBhc3N1bWUgwqc2LjMgb2YgUkZDIDI0NzMsIGJ1dCBnaXZl biB0aGF0IHlvdSBwcm92aWRlIGEgcmVmZXJlbmNlIA0KPiA+IGZvciBhbGwgdGhlIG90aGVyIGZp ZWxkcywgaXQgc2VlbXMgbGlrZSBhbiBvbWlzc2lvbiB0byBub3QgbWVudGlvbiBIb3AgTGltaXQg YXMgd2VsbC4pIFtQQ10gU3VyZSwgYWRkZWQuDQo+IA0KPiBbVGhhbmtzLiBJJ2xsIG5vdGUgc29t ZSBzaW1pbGFyIHJlZmVyZW5jZSBuaXRzIHJlZ2FyZGluZyDCpzUuMSBpbiBteSANCj4gdXBkYXRl ZCBjb21tZW50c10NCj4gDQo+ID4gU2VjdGlvbiA0LjE0DQo+ID4NCj4gPiAgICBUaGUgU1JIIE1B WSBiZSBvbWl0dGVkIHdoZW4gdGhlIFNSdjYgUG9saWN5IG9ubHkgY29udGFpbnMgb25lIHNlZ21l bnQNCj4gPiAgICBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byB1c2UgYW55IGZsYWcsIHRhZyBvciBU TFYuDQo+ID4NCj4gPiBJZiB0aGlzIGlzIHRoZSBjYXNlIGRvZXMgaXQgbWF0dGVyIGlmIEkgdXNl IEVuZC5CNi5FbmNhcHMgb3IgRW5kLkI2LkVuY2Fwcy5SZWQ/DQo+ID4gW1BDXSBJZiB5b3Ugb25s eSBoYXZlIGEgc2luZ2xlIHNlZ21lbnQsIHRoZW4gaXQgZG9lcyBub3QgbWF0dGVyLiBIb3dldmVy IHdoZW4geW91IGhhdmUgbW9yZSB0aGFuIG9uZSBzZWdtZW50IHRoZSBjaGFuZ2UgaXMgc2lnbmlm aWNhbnQuDQo+ID4NCj4gPiBTZWN0aW9uIDQuMTYNCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgSSB1 bmRlcnN0YW5kIHdoYXQgaXQgd291bGQgbWVhbiBmb3IgYSBzcGVjaWZpYyBTSUQgdG8gc3VwcG9y dCB0aGUgbXVsdGlwbGUgZmxhdm9ycyAiaW4gY29tYmluYXRpb25zIi4NCj4gPiBbUENdIENvbnZv bHV0ZWQgc2VudGVuY2UgaW5kZWVkLg0KPiA+IDxPTEQ+DQo+ID4gRm9yIGVhY2ggb2YgdGhlc2UN Cj4gPiAgICBiZWhhdmlvcnMgdGhlc2UgZmxhdm9ycyBNQVkgYmUgc3VwcG9ydGVkIGZvciBhIFNJ RCBlaXRoZXINCj4gPiAgICBpbmRpdmlkdWFsbHkgb3IgaW4gY29tYmluYXRpb25zLg0KPiA+IDwv T0xEPg0KPiA+IDxORVc+DQo+ID4gVGhlIEVuZCwgRW5kLlggb3IgRW5kLlQgYmVoYXZpb3JzIGNv dWxkIHN1cHBvcnQgdGhlc2UgZmxhdm9ycyBlaXRoZXIgaW5kaXZpZHVhbGx5IG9yIGluIGNvbWJp bmF0aW9uLg0KPiA+IDwvTkVXPg0KPiANCj4gTXVjaCBiZXR0ZXI7IHRoYW5rcyEgIEl0IG1heSBi ZSBsZXNzIHJlbGV2YW50IG5vdyB0aGF0IHdlIGFyZSANCj4gYXNzaWduaW5nIGJlaGF2aW9yIGNv ZGVwb2ludHMgZm9yIGVhY2ggZmxhdm9yIGNvbWJpbmF0aW9uLCBidXQgSU1PIHRoZSANCj4gVVNE IGZsYXZvciBmaXRzIG1vcmUgbmF0dXJhbGx5IGludG8gYmVpbmcgInBhcnQgb2YgdGhlIG1haW4g YmVoYXZpb3IiLiAgDQo+IEUuZy4sIHdlIGhhdmUNCj4gRW5kLkRUNDYgYWxyZWFkeSwgYW5kIEkn bSBub3Qgc3VyZSBob3cgdGhhdCAoYmVoYXZpb3IgY29kZXBvaW50IDIwKSBkaWZmZXJzIGZyb20g RW5kLlQgd2l0aCBVU0QgKGJlaGF2aW9yIGNvZGVwb2ludCAzNikuICBJIHRoaW5rIGl0J3MgZ2Vu ZXJhbGx5IGEgYmFkIGlkZWEgdG8gaGF2ZSBtdWx0aXBsZSB3YXlzIG9mIGV4cHJlc3NpbmcgdGhl IHNhbWUgYmVoYXZpb3IuDQo+IA0KPiBbUEMyXSBFbmQuVCB3aXRoIFVTRCBhbmQgRW5kLkRUNDYg YXJlIHRoZSBzYW1lIG9ubHkgd2hlbiB0aGV5IGFyZSB0aGUgbGFzdCBTSUQgb2YgdGhlIFNJRCBs aXN0LiBOb3RlIHRoYXQgd2hlbiB0aGV5IGFyZSB1c2VkIGFzIGludGVybWVkaWF0ZSBzZWdtZW50 IHRoZXkgZG8gZGlmZmVyZW50IHRoaW5ncy4gSWYgRW5kLkRUNDYgaXMgdXNlZCBhcyBhbiBpbnRl cm1lZGlhdGUgc2VnbWVudCBpbiB0aGUgc2lkIGxpc3QgaXQgd2lsbCByZXN1bHQgaW4gYW4gSUNN UCBQYXJhbWV0ZXIgUHJvYmxlbS4gSWYgRW5kLlQgaXMgdXNlZCBhcyBhbiBpbnRlcm1lZGlhdGUg c2VnbWVudCB0aGUgcGFja2V0IGlzIGZvcndhcmRlZC4NCg0KSSBzZWVtIHRvIHN0aWxsIGJlIGhh dmluZyBhIGhhcmQgdGltZSBnZXR0aW5nIHRoZSBoYW5nIG9mIHRoaXMgc3R1ZmY7IHRoYW5rIHlv dSBhZ2FpbiBmb3IgeW91ciBwYXRpZW5jZSB3aXRoIGV4cGxhbmF0aW9ucyENCg0KU28sIGEgbm9k ZSB3b3VsZCBoYXZlIHRvIGFkdmVydGlzZSBib3RoIEVuZC5EVDQ2IGFuZCBFbmQuVCBhbmQgaGF2 ZSB0aGUgcm91dGUgY2FsY3VsYXRpb24gdXNlIHRoZSByZXNwZWN0aXZlIG9uZSBpbiBvcmRlciB0 byBnZXQgdGhlIHNhbWUgZWZmZWN0IGFzIEVuZC5UICsgVVNELiAgVGhhdCBpcyBkaWZmZXJlbnQg ZW5vdWdoIHRoYXQgSSB3aWxsIG5vdCBjb21wbGFpbiB0b28gbG91ZGx5IGFib3V0IGl0LCB0aG91 Z2ggaW4gYSBncmVlbmZpZWxkIGVjb3N5c3RlbSBvbmUgY291bGQgY29uY2VpdmFibHkgZ28gd2l0 aCBlaXRoZXIgYXBwcm9hY2guLi4NCg0KPiA+IFNlY3Rpb24gNC4xNi4xLjINCj4gPg0KPiA+ICAg IEEgcGVudWx0aW1hdGUgU1IgU2VnbWVudCBFbmRwb2ludCBOb2RlIGlzIG9uZSB0aGF0LCBhcyBw YXJ0IG9mIHRoZQ0KPiA+ICAgIFNJRCBwcm9jZXNzaW5nLCBjb3BpZXMgdGhlIGxhc3QgU0lEIGZy b20gdGhlIFNSSCBpbnRvIHRoZSBJUHY2DQo+ID4gICAgRGVzdGluYXRpb24gQWRkcmVzcyBhbmQg ZGVjcmVtZW50cyBTZWdtZW50cyBMZWZ0IHZhbHVlIGZyb20gb25lIHRvDQo+ID4gICAgemVyby4N Cj4gPg0KPiA+IEkgdGhpbmsgdGVjaG5pY2FsbHkgaXQgY29waWVzIHRoZSBmaXJzdCBTSUQgZnJv bSB0aGUgU1JIIChTUkguU2VnbWVudCBMaXN0WzBdKSwgd2hpY2ggaXMgdGhlIGxhc3QgU0lEIGZy b20gdGhlIFNSIFBvbGljeS4NCj4gPiBbUENdIFJGQzg3NTQgdXNlcyB0aGUgdGVybSDigJxsYXN0 IFNJROKAnSB0byByZWZlciB0byBTUkguU2VnbWVudExpc3RbMF0uIFBsZWFzZSByZWZlciBSRkM4 NzU0IFNlYyA2LjEgZm9yIGRldGFpbHMuDQo+ID4gQWxzbywgbml0OiAidGhlIiBmb3IgInRoZSBT ZWdtZW50cyBMZWZ0IHZhbHVlIi4NCj4gPiBbUENdIEFjay4gQ29ycmVjdGVkLg0KPiA+DQo+ID4g IFMxNC4yLiAgICAgIFVwZGF0ZSB0aGUgTmV4dCBIZWFkZXIgZmllbGQgaW4gdGhlIHByZWNlZGlu ZyBoZWFkZXIgdG8gdGhlDQo+ID4gICAgICAgICAgICAgICAgIE5leHQgSGVhZGVyIHZhbHVlIG9m IHRoZSBTUkgNCj4gPg0KPiA+IG5pdDogcGVyc29uYWxseSwgSSB3b3VsZCB3cml0ZSAiZnJvbSB0 aGUgU1JIIiwgc2luY2UgIm5leHQgaGVhZGVyIHZhbHVlIG9mIHRoZSBTUkgiIGlzIHZlcnkgY2xv c2UgdG8gIm5leHQgaGVhZGVyIHZhbHVlIG9mIFNSSCIsIGkuZS4sIDQzLg0KPiA+IFtQQ10gUmVh ZHMgYmV0dGVyIGluZGVlZC4gQ29ycmVjdGVkLg0KPiA+DQo+ID4gICAgQXMgYSByZW1pbmRlciwg W1JGQzg3NTRdIGRlZmluZXMgaW4gc2VjdGlvbiA1IHRoZSBTUiBEZXBsb3ltZW50IE1vZGVsDQo+ ID4gICAgd2l0aGluIHRoZSBTUiBEb21haW4gW1JGQzg0MDJdLiAgV2l0aGluIHRoaXMgZnJhbWV3 b3JrLCB0aGUNCj4gPiAgICBBdXRoZW50aWNhdGlvbiBIZWFkZXIgKEFIKSBpcyBub3QgdXNlZCB0 byBzZWN1cmUgdGhlIFNSSCBhcyBkZXNjcmliZWQNCj4gPiAgICBpbiBTZWN0aW9uIDcuNSBvZiBb UkZDODc1NF0uDQo+ID4NCj4gPiBJIHN0cm9uZ2x5IHJlY29tbWVuZCBhZGRpbmcgYW5vdGhlciBz ZW50ZW5jZSBjbGFyaWZ5aW5nIHdoeSB0aGlzIGlzIHJlbGV2YW50IHRvIGRpc2N1c3Npb24gb2Yg cmVtb3ZpbmcgYW4gZXh0ZW5zaW9uIGhlYWRlciBmcm9tIHRoZSBwYWNrZXQuDQo+ID4gW1BDXSBJ IHN1Z2dlc3QgdGhhdCBpcyBub3QgcmVsZXZhbnQgdG8gdGhlIGRpc2N1c3Npb24gb2YgUFNQIHNp bmNlIEFIIGlzIG5vdCBkZWZpbmVkIGZvciB0aGUgU1JILg0KPiANCj4gV2Ugc2hvdWxkIGV4cGxh aW4gd2h5IHdlIGFyZSBzYXlpbmcgYW55dGhpbmcgYXQgYWxsIGFib3V0IEFILiAgUmlnaHQgbm93 IGl0IHNvdW5kcyBsaWtlIGFuIGlycmVsZXZhbnQgcGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCBz aG91bGQgaGF2ZSBiZWVuIGVkaXRlZCBvdXQgb2YgdGhlIGRvY3VtZW50LCBidXQgaXQgYWN0dWFs bHkgaXMgcXVpdGUgaW1wb3J0YW50IGluIGF0dGVtcHRpbmcgdG8ganVzdGlmeSB0aGUgZGVzaWdu IGRlY2lzaW9uIG9mIGFsbG93aW5nIFBTUCENCj4gDQo+IFtQQzJdIEFjdHVhbGx5LCBpdCB3YXMg YSByZXF1ZXN0ZWQgY2xhcmlmaWNhdGlvbiB0byBiZSBhZGRlZCB0byBjb252ZXkgdGhhdCBBSCBu b3QgYmVpbmcgc3BlY2lmaWVkIGFuZCB1c2VkIGZvciBzZWN1cmluZyBTUkggcmVzdWx0cyBpbiB0 aGVyZSBub3QgYmVpbmcgYW55IGlzc3VlIHdpdGggQUggd2hlbiBkb2luZyBQU1AuDQoNClllcywg YW5kIEkgc3VwcG9ydCB0aGF0IHJlcXVlc3QuICBUaGlzIHRleHQgc2VlbXMgdG8gb25seSBkbyBo YWxmIG9mIHRoYXQsIHRob3VnaCAtLSBpdCBzYXlzIHRoYXQgQUggaXMgbm90IHVzZWQgZm9yIHNl Y3VyaW5nIFNSSCwgYnV0IHNraXBzIHRoZSBwYXJ0IGFib3V0IHRoZXJlIG5vdCBiZWluZyBhbnkg aXNzdWUgd2l0aCBBSCB3aGVuIGRvaW5nIFBTUC4NCg0KW1BDM10gV2UgYXJlIG5vdCBjb25zaWRl cmluZyB0aGUgdXNlIG9mIEFIIHRvIHByb3RlY3QgdGhlIFNSIERvbWFpbiBhcyBkZWZpbmVkIGlu IFNlY3Rpb24gNy41IG9mIFJGQzg3NTQuIEZ1dHVyZSBkb2N1bWVudHMgbWF5IGRlZmluZSB0aGUg dXNlIG9mIEFIIGluIHRoZSBTUiBEb21haW4uDQoNCj4gPiBTZWN0aW9uIDUNCj4gPg0KPiA+ICAg IFRoaXMgbGlzdCBjYW4gYmUgZXhwYW5kZWQgaW4gY2FzZSBhbnkgbmV3IGZ1bmN0aW9uYWxpdHkg cmVxdWlyZXMgaXQuDQo+ID4NCj4gPiBIb3c/ICBCeSBhbiBSRkMgdGhhdCBVcGRhdGVzOiB0aGlz IG9uZT8NCj4gPiBbUENdIE5ldyBmdW5jdGlvbmFsaXR5IHdvdWxkIGhhdmUgdG8gYmUgaW50cm9k dWNlZCB2aWEgYSBuZXcgZG9jdW1lbnQgYnV0IGl0IGRvZXMgbm90IGhhdmUgdG8gdXBkYXRlIHRo aXMgb25lIHNpbmNlIGl0IGlzIG5vdCBtb2RpZnlpbmcgd2hhdCBpcyBpbiB0aGlzIGRvY3VtZW50 IGJ1dCBhZGRpbmcgc29tZXRoaW5nIG5ldy4NCj4gPiBXZSBoYXZlIHVwZGF0ZWQgdGhlIHRleHQg YXMgcy9UaGlzIGxpc3QgY2FuIGJlIGV4cGFuZGVkIGluIGNhc2UgYW55IG5ldyBmdW5jdGlvbmFs aXR5IHJlcXVpcmVzIGl0L1RoaXMgbGlzdCBpcyBub3QgZXhoYXVzdGl2ZSBhbmQgZnV0dXJlIGRv Y3VtZW50cyBtYXkgZGVmaW5lIGFkZGl0aW9uYWwgYmVoYXZpb3JzLg0KPiANCj4gVGhhbmtzLg0K PiANCj4gPiBTZWN0aW9uIDUueA0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIHRoZSBkaXJlY3RvcmF0 ZSByZXZpZXdlciB0aGF0IHRoZSBwcm90b2NvbCBiZWhhdmlvciBzaG91bGQgYmUgd3JpdHRlbiBv dXQgZXhwbGljaXRseSwgd2l0aG91dCByZWZlcmVuY2UgdG8gdGhlIGhhbmRsaW5nIG9mIGV4YW1w bGUgcGFja2V0KHMpLg0KPiA+IFtQQ10gVGhlcmUgaXMgYWxyZWFkeSBwc2V1ZG9jb2RlIGFuZCBk ZXNjcmlwdGlvbnMgaW4gdGhlc2Ugc2VjdGlvbnMgdGhhdCBkZXNjcmliZXMgdGhlIGJlaGF2aW9y LiBFeGFtcGxlcyBhcmUgdG8gaGVscCB1bmRlcnN0YW5kaW5nLiBDYW4geW91IGNsYXJpZnkgd2hh dCBtb3JlIGlzIHJlcXVpcmVkPw0KPiANCj4gVGhlIHBzZXVkb2NvZGUgaGFyZGNvZGVzIHRoYXQg dGhlIHNlZ21lbnQgbGlzdCBpcyAoUzMsIFMyLCBTMTsgU0w9MiksIHdoaWNoIGlzIGp1c3QgYW4g ZXhhbXBsZSBvZiB3aGF0IHRoZSBTUkggY291bGQgYmUuICBJdCdzIG5vdCB0cnVseSBnZW5lcmlj IHBzZXVkb2NvZGUuDQo+IA0KPiBbUEMyXSBBZ3JlZWQuIEnigJl2ZSByZW1vdmVkIHRoZSDigJwo UzMsIFMyLCBTMTsgU0w9MikgZnJvbSB0aGUgcHNldWRvY29kZS4gSXRzIHNwZWNpZmljIHRvIHRo ZSBleGFtcGxlLCBhbmQgaXQgZG9lcyBub3QgYnJpbmcgYW55IHZhbHVlICh0aGUgZW5jb2Rpbmcg b2YgdGhlIFNSSCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gUkZDODc1NCkuDQoNCkFoLCB0aGF0IGxv b2tzIHRvIGJlIGEgZ29vZCByZXNvbHV0aW9uOyB0aGFuayB5b3UhDQpXZSBtaWdodCB3YW50IHRv IGRvIGEgbWlub3IgZm9sbG93LXVwIGFuZCBzYXkgIm91dGVyIElQdjYgREEgYXMgdGhlIGZpcnN0 IFNJRCBpbiB0aGUgc2VnbWVudCBsaXN0IiAoc2luY2UgJ1MxJyBpcyBubyBsb25nZXIgZGVmaW5l ZCBhcyBwYXJ0IG9mIHRoZSBwc2V1ZG9jb2RlKS4NCg0KW1BDM10gQ2hhbmdlZC4NCiANCj4gQWxz bywgSSB0aGluayBpdCB3b3VsZCBiZSBncmVhdCBpZiA1LjIsIDUuMywgYW5kIDUuNCBjb3VsZCBk byB0aGUgc29ydCBvZiB0aGluZyB3ZSBkaWQgZm9yIHRoZSBlbmRwb2l0biBiZWhhdmlvcnMgd2hl cmUgaXQgcmVwbGFjZXMgdGhlIGRlZmluaXRpb24gb2Ygb25lIG9yIG1vcmUgb2YgdGhlIG51bWJl cmVkIHBzZXVkb2NvZGUgc3RlcHMuICAoSSBkb24ndCB0aGluayB3ZSBjYW4sIHJpZ2h0IG5vdywg c2luY2UgdGhlIG51bWJlcmVkIHBzZXVkb2NvZGUgZG9lc24ndCBjb3ZlciBhbGwgdGhlIHJlbGV2 YW50IHBhcnRzIHRoYXQgYXJlIGNoYW5naW5nLCBhbmQgSSBkaWRuJ3QgdGhpbmsgYWJvdXQgaG93 IGhhcmQgaXQgd291bGQgYmUgdG8gY2hhbmdlIHRoZSBwc2V1ZG9jb2RlIHRvIG1ha2UgdGhhdCB0 aGUgY2FzZS4NCj4gDQo+ID4gU2VjdGlvbiA1LjENCj4gPg0KPiA+ICAgIFMwMy4gICBTZXQgb3V0 ZXIgcGF5bG9hZCBsZW5ndGgsIHRyYWZmaWMgY2xhc3MgYW5kIGZsb3cgbGFiZWwNCj4gPg0KPiA+ IFdoYXQgYWJvdXQgdGhlIG91dGVyIEhvcCBMaW1pdD8NCj4gPiBbUENdIEFkZGVkLg0KPiA+DQo+ ID4gICAgUzAzOiBBcyBkZXNjcmliZWQgaW4gW1JGQzY0MzddIChJUHY2IEZsb3cgTGFiZWwgU3Bl Y2lmaWNhdGlvbikNCj4gPg0KPiA+IFdoeSBpcyB0aGlzIGFsbCB0aGUgd2F5IGF0IHRoZSBib3R0 b20gb2YgdGhlIHNlY3Rpb24gaW5zdGVhZCBvZiBpbmNsdWRlZCB3aXRoIHRoZSBjb3JyZXNwb25k aW5nIGNvbnRlbnQ/DQo+ID4gW1BDXSBBY2suIEJyb3VnaHQgdXAuDQo+ID4NCj4gPiBTZWN0aW9u IDUuMw0KPiA+DQo+ID4gICAgVGhlIGVuY2Fwc3VsYXRpbmcgbm9kZSBNVVNUIHJlbW92ZSB0aGUg cHJlYW1ibGUgb3IgZnJhbWUgY2hlY2sNCj4gPiAgICBzZXF1ZW5jZSAoRkNTKSBmcm9tIHRoZSBF dGhlcm5ldCBmcmFtZSB1cG9uIGVuY2Fwc3VsYXRpb24gYW5kIHRoZQ0KPiA+ICAgIGRlY2Fwc3Vs YXRpbmcgbm9kZSBNVVNUIHJlZ2VuZXJhdGUgdGhlIHByZWFtYmxlIG9yIEZDUyBiZWZvcmUNCj4g PiAgICBmb3J3YXJkaW5nIEV0aGVybmV0IGZyYW1lLg0KPiA+DQo+ID4gIm9yIj8gIEkgZ2V0IHRv IGNob29zZSBvbmUgb3IgdGhlIG90aGVyPyAgSXQncyBva2F5IHRvIG9ubHkgcHV0IGJhY2sgYSBw cmVhbWJsZSBidXQgbm8gRkNTIChvciB2aWNlIHZlcnNhKT8NCj4gPiBbUENdIEdvb2QgY2F0Y2gu IHMvb3IvYW5kOyBhbHNvIHByZWFtYmxlIHJlbW92ZWQgb25seSBpZiBwcmVzZW50DQo+ID4NCj4g PiBTZWN0aW9uIDYNCj4gPg0KPiA+ICAgIHRyYWZmaWMgdGhhdCBtYXRjaGVkIHRoYXQgU0lEIGFu ZCB3YXMgcHJvY2Vzc2VkIGNvcnJlY3RseS4gIFRoZQ0KPiA+ICAgIHJldHJpZXZhbCBvZiB0aGVz ZSBjb3VudGVycyB2aWEgTUlCLCBORVRDT05GL1lBTkcgb3IgYW55IG90aGVyIG1lYW5zDQo+ID4g ICAgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4gPg0KPiA+IChlZGl0 b3JpYWwpIGEgTUlCIGlzIGFuIGFic3RyYWN0IGRhdGEgc3RydWN0dXJlIChsaWtld2lzZSBhIFlB TkcgbW9kdWxlKTsgaW5mb3JtYXRpb24gbWlnaHQgYmUgcmV0cmlldmVkICpmcm9tKiBpdCBidXQg bm90ICp2aWEqIGl0LiAgRm9yICp2aWEqLCB0aGF0IHdvdWxkIGJlIFNOTVAsIE5FVENPTkYsIGFu ZC9vciBSRVNUQ09ORi4NCj4gPiBbUENdIEZpeGVkLg0KPiA+DQo+ID4gU2VjdGlvbiA4LjENCj4g Pg0KPiA+IERvZXMgaXQgbWFrZSBzZW5zZSB0byByZWZlcmVuY2UgUkZDcyA4NDkxLCA4NDc2LCA4 ODQxLCBldGMuIGZvciBhZHZlcnRpc2luZyBNU0QgdmlhIElHUD8NCj4gPiBbUENdIEkgd291bGQg bGVhdmUgdGhhdCB1cCB0byB0aGUgc3J2NiBjb250cm9sIHBsYW5lIGRyYWZ0czsgYnV0IG5vIHN0 cm9uZyBwcmVmZXJlbmNlLg0KPiA+DQo+ID4gICAgSW4gcGFydGljdWxhciwgdGhlIFNSIHNvdXJj ZSAoZS5nLiwgSC5FbmNhcHMpLCBpbnRlcm1lZGlhdGUgZW5kcG9pbnQNCj4gPiAgICAoZS5nLiwg RW5kLCBFbmQuWCkgYW5kIGZpbmFsIGVuZHBvaW50IChlLmcuLCBFbmQuRFg0LCBFbmQuRFQ2KQ0K PiA+ICAgIGJlaGF2aW9ycy4gIFsuLi5dDQo+ID4NCj4gPiBUaGlzIGlzIG5vdCBhIGNvbXBsZXRl IHNlbnRlbmNlLCBhbmQgSSByZWFsbHkgaGF2ZSBubyBpZGVhIHdoYXQgdmVyYiB3YXMgaW50ZW5k ZWQuDQo+ID4gW1BDXSBJbmRlZWQsIGZpeGVkIGluIHJldjIxLg0KPiA+DQo+ID4gU2VjdGlvbiA4 LjIsIDguMw0KPiA+DQo+ID4gQ2FuIHdlIGdldCByZWZlcmVuY2VzIGZvciB0aGUgQkdQIHZhcmlh bnRzIGhlcmUgYW5kIHRoZWlyIHVzYWdlIGZvciBzaWduYWxpbmcgU1J2NiBjYXBhYmlsaXRpZXMg YW5kIChTSUQsYmVoYXZpb3IgY29kZXBvaW50KSBwYWlycz8NCj4gPiBbUENdIFRoZSByZWZlcmVu Y2VzIHRvIHRoZSBCR1AgZmVhdHVyZXMgaGF2ZSBhbHJlYWR5IGJlZW4gcHJvdmlkZWQgaW4gdGhl IHJlc3BlY3RpdmUgc2VjdGlvbnMgd2hlcmUgdGhlc2UgYmVoYXZpb3JzIGFyZSBzcGVjaWZpZWQu IFRoZXJlIGFyZSBXRyBkcmFmdHMgaW4gcHJvZ3Jlc3MgZm9yIFNSdjYgZXh0ZW5zaW9ucyB0byBy b3V0aW5nIHByb3RvY29scyAobm90IGp1c3QgQkdQKSB0aGF0IG5vcm1hdGl2ZWx5IHJlZmVyZW5j ZSB0aGlzIGRvY3VtZW50LiBUaGVyZSB1c2VkIHRvIGJlIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMg dGhlIG90aGVyIHdheSBhcm91bmQgZnJvbSB0aGlzIGRvY3VtZW50IHdoaWNoIHdlcmUgcmVtb3Zl ZCBkdXJpbmcgV0dMQyBiYXNlZCBvbiBmZWVkYmFjay4gV2UgY2FuIGFkZCB0aGVtIGJhY2sgaWYg dGhhdCBtYWtlcyBzZW5zZSBmb3IgdGhlIElFU0cuDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhvc2Ug aW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB3b3VsZCBiZSBoZWxwZnVsLCBidXQgSSBhbHNvIGRvbid0 IGtub3cgaG93IHN0cm9uZyB0aGUgV0cgY29uc2Vuc3VzIHdhcyB0byByZW1vdmUgdGhlbSAob3Ig d2hhdCByZWFzb25pbmcgd2FzIG9mZmVyZWQgZm9yIGRvaW5nIHNvKS4NCj4gDQo+IFtQQzJdIEni gJlsbCBsZWF2ZSBpdCB1cCB0byBNYXJ0aW4gKHJlc3BvbnNpYmxlIEFEKS4NCj4gT24gYSBzZXBh cmF0ZSBub3RlLCBvbiA4LjMgSeKAmXZlIGFsc28gYWRkZWQgdGhlIG5vdGUgb24gdGhlIE9wYXF1 ZSBhcyBkaXNjdXNzZWQuDQo+IDxORVc+DQo+IEluIHNvbWUgc2NlbmFyaW9zLCBhbiBlZ3Jlc3Mg UEUgYWR2ZXJ0aXNpbmcgYSBWUE4gcm91dGUgbWlnaHQgd2lzaCB0byBhYnN0cmFjdCB0aGUgc3Bl Y2lmaWMgYmVoYXZpb3IgYm91bmQgdG8gdGhlIFNJRCBmcm9tIHRoZSBpbmdyZXNzIFBFIGFuZCBv dGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrLiBJbiBzdWNoIGNhc2UsIHRoZSBTSUQgbWF5IGJl IGFkdmVydGlzZWQgdXNpbmcgdGhlIE9wYXF1ZSBTUnY2IEVuZHBvaW50IEJlaGF2aW9yIGNvZGVw b2ludCBkZWZpbmVkIGluIFtTZWN0aW9uIDEwLjIuMV0uIFRoZSBkZXRhaWxzIG9mIHN1Y2ggY29u dHJvbCBwbGFuZSBzaWduYWxpbmcgbWVjaGFuaXNtcyBhcmUgb3V0IG9mIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50Lg0KPiA8L05FVz4NCg0KVGhhbmtzIGFnYWluIGZvciB0aGlzIGNsYXJpZmlj YXRpb247IHRoaXMgYmVoYXZpb3IgZmVlbHMgcGVyZmVjdGx5IG5hdHVyYWwgb25jZSBleHBsYWlu ZWQsIGJ1dCByZWFsbHkgY29uZnVzZWQgbWUgb24gZmlyc3QgcmVhZGluZy4NCg0KPiA+IFNlY3Rp b24gOQ0KPiA+DQo+ID4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBoYXZlIGEgc3Ryb25nZXIgcmVm ZXJlbmNlIHRvIFNlY3Rpb24gNSBvZiBSRkMNCj4gPiA4NzU0IHdoZXJlIHRoZSBjb25jZXB0dWFs IG1vZGVsIG9mIGEgU1IgRG9tYWluIGFzIGEgc2luZ2xlIHN5c3RlbSwgd2hlcmUgYWxsIHBhY2tl dHMgaW4gdGhlIGRvbWFpbiBhcmUgZW5jYXBzdWxhdGVkIHVzaW5nIElQdjYgaGVhZGVycyBbd2l0 aCBTSURzIGFzIFNBL0RBXS4gIFRoZSBwYXJ0IGluIGJyYWNrZXRzIGlzIG5vdCBzcGVsbGVkIG91 dCB2ZXJ5IGNsZWFybHkgYW5kIGNvdWxkIHdlbGwgYmUgZXhwb3VuZGVkIHVwb24gaW4gdGhpcyBk b2N1bWVudC4gIEkgY2FuIHdyaXRlIHVwIHNvbWUgKHZlcnkgYWQgaG9jKSBpZGVhcyBmb3Igd2hh dCBJIGhhZCBpbiBtaW5kLCB3aGljaCB5b3UgYXJlIHdlbGNvbWUgdG8gYWRvcHQgYnV0IGV4cGVj dGVkIHRvIHdvcmRzbWl0aC9lZGl0IGFwcHJvcHJpYXRlbHk6DQo+ID4NCj4gPiAlIFNlY3Rpb24g NSBvZiBbUkZDODc1NF0gZGVzY3JpYmVzIHRoZSBTUiBkZXBsb3ltZW50IG1vZGVsIGFuZCB0aGUg JSBiYXNlbGluZSByZXF1aXJlbWVudHMgZm9yIHNlY3VyaW5nIHRoZSBTUiBEb21haW4uICBJbiBt YW55IHdheXMgdGhlIFNSICUgRG9tYWluIGlzIGFuYWxvZ291cyB0byBhbiBNUExTIGRvbWFpbiAt LSBpdCdzIGEgdGlnaHRseSBjb250cm9sbGVkICUgc3lzdGVtIHdoZXJlIHBhY2tldCBwcm9jZXNz aW5nIGlzIGNvbnRyb2xsZWQgYnkgYSBsaXN0IChvciBzdGFjaykgb2YgJSBvcGFxdWUgaWRlbnRp ZmllcnMgdGhhdCwgYnkgYW5kIGxhcmdlLCBvbmx5IGhhdmUgZGVmaW5lZCBzZW1hbnRpY3MgaW4g JSB0aGUgY29udGV4dCBvZiB0aGUgbm9kZSB0aGF0IHJlY2VpdmVzIGFuZCBwcm9jZXNzZXMgdGhl IHBhY2tldCB3aGVuICUgdGhhdCBpZGVudGlmaWVyIGlzICJ0b3Btb3N0IiBvciAiY3VycmVudCIu ICBFeHBlcmllbmNlIGluIHNlY3VyaW5nIGFuZCAlIG9wZXJhdGluZyBNUExTIGRvbWFpbnMgc2hv dWxkIGJlIHJlYWRpbHkgdHJhbnNmZXJyYWJsZSB0byBTUnY2ICUgZG9tYWlucywgaW4gZW5zdXJp bmcgdGhhdCBhbGwgdHJhZmZpYyB3aXRoaW4gdGhlIG5ldHdvcmsgaXMgdGlnaHRseSAlIGNvbnRy b2xsZWQsIHdpdGggYWxsIGV4dGVybmFsIGlucHV0cyBiZWluZyBwcm9wZXJseSBlbmNhcHN1bGF0 ZWQgKGZvciAlIFNSdjYsIGJ5IGFuIElQdjYgaGVhZGVyIHVzdWFsbHkgd2l0aCBTUkg7IGZvciBN UExTLCBieSB0aGUgbGFiZWwgJSBzdGFjaykuICBUaGUgZGVkaWNhdGVkIGZvcm1hdCBmb3IgdGhl IE1QTFMgbGFiZWwgc3RhY2sgYW5kIGxhYmVsICUgaWRlbnRpZmllcnMgbWFrZXMgYSBjbGVhciBt ZWNoYW5pY2FsIHNlcGFyYXRpb24gYmV0d2VlbiAiaW50ZXJuYWwiIGFuZCAlICJleHRlcm5hbCIg aWRlbnRpZmllcnMuIEluIGNvbnRyYXN0LCBTUnY2IHVzZXMgU0lEcyBmb3IgdGhlIGludGVybmFs ICUgaWRlbnRpZmllcnMsIHdoaWNoIGhhdmUgZm9ybWF0IGFuZCBvcGVyYXRpb24gb2YgSVB2NiBh ZGRyZXNzZXMuICBXaGlsZSAlIHRoaXMgbGV0cyBTUnY2IGJlbmVmaXQgZnJvbSBJUCBsb25nZXN0 LXByZWZpeCByb3V0aW5nIGFuZCB0aHVzIHRoZSAlIHN0cnVjdHVyZSBvZiBTSUQgdmFsdWVzLCBp dCBhbHNvIG1lYW5zIHRoYXQgdGhlcmUgaXMgbm90IGEgY3Jpc3AgJSBtZWNoYW5pY2FsIHNlcGFy YXRpb24gYmV0d2VlbiAiaW50ZXJuYWwiIGFuZCAiZXh0ZXJuYWwiIGlkZW50aWZpZXJzLg0KPiA+ ICUgQXMgc3VjaCwgY2FyZSBhbmQgcmlnb3IgaW4gYW5ub3RhdGluZyB3aGljaCBJUHY2IGFkZHJl c3Nlcy9oZWFkZXJzIGFyZSAlIGludGVybmFsIHZzIGV4dGVybmFsIGlzIHJlcXVpcmVkIGluIG9y ZGVyIHRvIG1haW50YWluIHRoZSBpbnRlZ3JpdHkgJSBhbmQgc2VjdXJpdHkgb2YgdGhlIFNSdjYg ZG9tYWluLg0KPiA+DQo+ID4gW1BDXSBUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbnMuIEluZGVl ZCB3ZSBzaG91bGQgdXBkYXRlIHRoZSBkcmFmdCB3aXRoIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBs aW5lcy4NCj4gPiBUaGUgY29tcGFyaXNvbiBvciBlcXVpdmFsZW5jZSB0byBNUExTIGlzIGxpa2Vs eSBnb2luZyB0byBiZSBjb25mdXNpbmcgYW5kIGhlbmNlIHdlIGF2b2lkIGdvaW5nIGRvd24gdGhh dCBwYXRoLiBXZSB3ZXJlIHRoaW5raW5nIG9uIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcu DQo+ID4gUGxlYXNlIGxldCBtZSBrbm93IG9mIHdoYXQgeW91IHRoaW5rLiAoSSBoYXZlIG5vdCBw dXNoZWQgdGhpcyBpbnRvIHRoZSBkcmFmdCB5ZXQpLg0KPiA+DQo+ID4gPFByb3Bvc2FsPg0KPiAN Cj4gW3JlLXdyYXBwZWQgZm9yIGVhc2Ugb2YgaW5saW5lIGNvbW1lbnRpbmddDQo+IA0KPiBUaGF0 IHNhaWQsIEkgYW0ganVzdCBvZmZlcmluZyBlZGl0b3JpYWwgc3VnZ2VzdGlvbnM7IEkgcmVhbGx5 IGxpa2Ugd2hhdCB5b3UgY2FtZSB1cCB3aXRoIC0tIHRoYW5rIHlvdSENCj4gDQo+ID4gICBUaGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIFNlZ21lbnQgUm91dGluZyBhcmUgZGlzY3Vzc2Vk IGluDQo+ID4gICBbUkZDODQwMl0uIFNlY3Rpb24gNSBvZiBbUkZDODc1NF0gZGVzY3JpYmVzIHRo ZSBTUiBEZXBsb3ltZW50IE1vZGVsIGFuZA0KPiA+ICAgdGhlIHJlcXVpcmVtZW50cyBmb3Igc2Vj dXJpbmcgdGhlIFNSIERvbWFpbi4gVGhlIHNlY3VyaXR5DQo+ID4gICBjb25zaWRlcmF0aW9ucyBv ZiBbUkZDODc1NF0gYWxzbyBjb3ZlciBhc3BlY3RzIHN1Y2ggYXMgYXR0YWNrIA0KPiA+IHZlY3Rv cnMNCj4gDQo+IG5pdDogSSdkIGNvbnNpZGVyIHMvYXNwZWN0cy90b3BpY3MvIGJ1dCBpdCdzIGEg Yml0IG9mIGEganVkZ21lbnQgY2FsbCANCj4gW1BDMl0gQ2hhbmdlZC4NCj4gDQo+ID4gICBhbmQg dGhlaXIgbWl0aWdhdGlvbiBtZWNoYW5pc21zIHRoYXQgYWxzbyBhcHBseSB0byB0aGUgYmVoYXZp b3JzDQo+ID4gICBpbnRyb2R1Y2VkIGluIHRoaXMgZG9jdW1lbnQuIFRvZ2V0aGVyLCB0aGV5IGRl c2NyaWJlIHRoZSByZXF1aXJlZA0KPiA+ICAgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IGFsbG93 IGVzdGFibGlzaG1lbnQgb2YgYW4gU1IgZG9tYWluIG9mIA0KPiA+IHRydXN0DQo+IA0KPiBJIHdv dWxkIGVuZCB0aGUgc2VudGVuY2UgaGVyZSwgYWZ0ZXIgIlNSIGRvbWFpbiBvZiB0cnVzdCIuICBU aGVuIHdlIGNvdWxkIGNvbnRpbnVlIG9uIGFzICJIYXZpbmcgc3VjaCBhIHdlbGwtZGVmaW5lZCB0 cnVzdCBib3VuZGFyeSBpcyBuZWNlc3NhcnkgaW4gb3JkZXIgdG8gb3BlcmF0ZSBbLi4uXSINCj4g W1BDMl0gQ2hhbmdlZC4gVGhhbmtzLg0KPiANCj4gPiAgIHRvIG9wZXJhdGUgU1J2Ni1iYXNlZCBz ZXJ2aWNlcyBmb3IgaW50ZXJuYWwgdHJhZmZpYyB3aGlsZSBwcmV2ZW50aW5nDQo+ID4gICBhbnkg ICBleHRlcm5hbCB0cmFmZmljIGZyb20gYWNjZXNzaW5nIG9yIGV4cGxvaXRpbmcgdGhlIFNSdjYt YmFzZWQNCj4gPiAgIHNlcnZpY2VzLiAgQ2FyZSBhbmQgcmlnb3IgaW4gSVB2NiBhZGRyZXNzIGFs bG9jYXRpb24gZm9yIHVzZSBmb3IgU1J2Ng0KPiA+ICAgU0lEIGFsbG9jYXRpb25zIGFuZCBuZXR3 b3JrIGluZnJhc3RydWN0dXJlIGFkZHJlc3NlcyB0byBiZSBzZXBhcmF0ZQ0KPiA+ICAgZnJvbSBJ UHY2IGFkZHJlc3NlcyBhbGxvY2F0ZWQgZm9yIGVuZC11c2Vycy9zeXN0ZW1zIChhcyBpbGx1c3Ry YXRlZCBpbg0KPiA+ICAgU2VjdGlvbiA1LjEgb2YgW1JGQzg3NTRdKSBoZWxwIGRpZmZlcmVudGlh dGUgaW50ZXJuYWwgdnMgZXh0ZXJuYWwNCj4gPiAgIGFkZHJlc3Mgc3BhY2UgdGhhdCBpcyByZXF1 aXJlZCB0byBtYWludGFpbiB0aGUgaW50ZWdyaXR5IGFuZCBzZWN1cml0eQ0KPiA+ICAgb2YgdGhl IFNSdjYgRG9tYWluLiBBZGRpdGlvbmFsbHksIFtSRkM4NzU0XSBkZWZpbmVzIGFuIEhNQUMgVExW DQo+IA0KPiBUaGlzIHNlbnRlbmNlIGdvdCBhIGJpdCBjb252b2x1dGVkIGFuZCBtYXliZSBhIGJp dCBsb25nLiAgSSBwcm9wb3NlIChvbmx5IGhlbHBpbmcgd2l0aCB0aGUgImNvbnZvbHV0ZWQiIGJ1 dCBub3QgdGhlICJsb25nIiBwYXJ0KToNCj4gDQo+ICUgQ2FyZSBhbmQgcmlnb3IgaW4gSVB2NiBh ZGRyZXNzIGFsbG9jYXRpb24gZm9yIHVzZSBmb3IgU1J2NiBTSUQgJSBhbGxvY2F0aW9ucyBhbmQg bmV0d29yayBpbmZyYXN0cnVjdHVyZSBhZGRyZXNzZXMsIGFzIGRpc3RpbmN0IGZyb20gSVB2NiAl IGFkZHJlc3NlcyBhbGxvY2F0ZWQgZm9yIGVuZC11c2Vycy9zeXN0ZW1zIChhcyBpbGx1c3RyYXRl ZCBpbiBTZWN0aW9uIDUuMSAlIG9mIFtSRkM4NzU0XSksIGNhbiBwcm92aWRlIHRoZSBjbGVhciBk aXN0aW5jdGlvbiBiZXR3ZWVuIGludGVybmFsIGFuZCAlIGV4dGVybmFsIGFkZHJlc3Mgc3BhY2Ug dGhhdCBpcyByZXF1aXJlZCB0byBtYWludGFpbiB0aGUgaW50ZWdyaXR5IGFuZCAlIHNlY3VyaXR5 IG9mIHRoZSBTUnY2IERvbWFpbi4NCj4gW1BDMl0gQ2hhbmdlZC4gVGhhbmtzLg0KPiANCj4gPiAg IHBlcm1pdHRpbmcgU1IgRW5kcG9pbnQgTm9kZXMgaW4gdGhlIFNSIGRvbWFpbiB0byB2ZXJpZnkg dGhhdCB0aGUgU1JIDQo+ID4gICBhcHBsaWVkIHRvIGEgcGFja2V0IHdhcyBzZWxlY3RlZCBieSBh biBhdXRob3JpemVkIHBhcnR5IGFuZCB0byBlbnN1cmUNCj4gPiAgIHRoYXQgdGhlIHNlZ21lbnQg bGlzdCBpcyBub3QgbW9kaWZpZWQgYWZ0ZXIgZ2VuZXJhdGlvbiwgcmVnYXJkbGVzcyBvZg0KPiA+ ICAgdGhlIG51bWJlciBvZiBzZWdtZW50cyBpbiB0aGUgc2VnbWVudCBsaXN0LiAgV2hlbiBlbmFi bGVkIGJ5IGxvY2FsDQo+ID4gICBjb25maWd1cmF0aW9uLCBITUFDIHByb2Nlc3Npbmcgb2NjdXJz IGF0IHRoZSBiZWdpbm5pbmcgb2YgU1JIDQo+ID4gICBwcm9jZXNzaW5nIGFzIGRlZmluZWQgaW4g W1JGQzg3NTRdIFNlY3Rpb24gMi4xLjIuMS4NCj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgaW50cm9k dWNlcyBTUnY2IEVuZHBvaW50IGFuZCBTUiBQb2xpY3kgSGVhZGVuZCAgIGJlaGF2aW9ycw0KPiA+ IGZvciBpbXBsZW1lbnRhdGlvbiBvbiBTUnY2IGNhcGFibGUgbm9kZXMgaW4gdGhlIG5ldHdvcmsu ICAgQXMgc3VjaCwgdGhpcw0KPiA+IGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3 IHNlY3VyaXR5ICAgY29uc2lkZXJhdGlvbnMuDQo+ID4gPC9Qcm9wb3NhbD4NCj4gDQo+IEknbSBs ZXNzIHN1cmUgdGhhdCB3ZSB3YW50IHRvIGtlZXAgdGhlICJubyBuZXcgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMiDQo+IHRleHQuICBJIGhhdmUgYSBmZXcgbm90ZXMgc3RhZ2VkIGluIG15IHVwZGF0 ZWQgYmFsbG90IGNvbW1lbnRzLCBidXQgb25lIG5vdGV3b3J0aHkgdGhpbmcgdGhhdCBjb21lcyB0 byBtaW5kIGlzIHRoYXQgUFNQIHByZXZlbnRzIHRoZSBlZ3Jlc3Mgbm9kZSBmcm9tIHZhbGlkYXRp bmcgdGhlIEhNQUMgVExWLg0KPiANCj4gW1BDMl0gSWYgeW91IHdvdWxkIGxpa2UgdG8gdXNlIHRo ZSBITUFDIFRMViB0aGVuIHdoeSB3b3VsZCB0aGUgc291cmNlIGNob29zZSB0byB1c2UgYSBQU1At Zmxhdm9yZWQgU0lEPyBUaGUgU1IgUG9saWN5IGNvbXB1dGF0aW9uIGlzIGF3YXJlIG9mIHRoaXMg YW5kIHRha2VzIGl0IGludG8gYWNjb3VudCB1cG9uIGRvaW5nIHBhdGggY29tcHV0YXRpb24uIE5v dGUgdGhhdCBpbiByZXYyNCB3ZSBhZGRlZCB0aGlzIHRleHQgYXMgd2VsbDoNCg0KSXQgd291bGQg YmUgYSBwcmV0dHkgYml6emFyZSBjaG9pY2UsIGJ1dCAoZXZlbiB3aXRoIHRoZSBmb2xsb3dpbmcN CnBhcmFncmFwaCkgd2UgZG9uJ3Qgc2VlbSB0byBjb21wbGV0ZWx5IHByb2hpYml0IGl0Lg0KDQo+ IDxxdW90ZT4NCj4gICAgVGhlIGhlYWRlbmQgcG9saWN5IGRlZmluaXRpb24gc2hvdWxkIGJlIGNv bnNpc3RlbnQgd2l0aCB0aGUgc3BlY2lmaWMNCj4gICAgYmVoYXZpb3IgdXNlZCBhbmQgYW55IGxv Y2FsIGNvbmZpZ3VyYXRpb24gKGFzIHNwZWNpZmllZCBpbg0KPiAgICBTZWN0aW9uIDQuMS4xKS4N Cj4gPC9xdW90ZT4NCg0KSSB0aGluayBJIGhhZCBmYWlsZWQgdG8gaW50ZXJuYWxpemUgd2hhdCB0 aGlzIHdhcyBzYXlpbmcsIHNvIHRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgaXQgb3V0IHNwZWNpZmlj YWxseS4gIEl0IGhlbHBzIGEgbG90LCBidXQgSSBzdGlsbCB0aGluayB0aGF0ICJubyBuZXcgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMiIGlzIGNvbnRpbmdlbnQgb24gdGhlIGhlYWRlbmQgcG9saWN5 IGhlZWRpbmcgdGhhdCBhZHZpY2UuICBXZSB0eXBpY2FsbHkgZG8gbm90IG1ha2Ugc3VjaCBhc3N1 bXB0aW9ucyB3aGVuIHdyaXRpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbnMsIGFu ZCBkZXNjcmliZSB0aGUgcmlza3MgdGhhdCBjYW4gb2NjdXIgd2hlbiBhIGRlcGxveW1lbnQgZGl2 ZXJnZXMgZnJvbSB0aGUgcmVjb21tZW5kZWQgY29uZmlndXJhdGlvbi4NCg0KW1BDM10gVGhlIHZl cnkgZXNzZW5jZSBvZiBTUiBpcyBhYm91dCBzb3VyY2Ugcm91dGluZyBvZiBwYWNrZXRzIHVzaW5n IGEgbGlzdCBvZiBzZWdtZW50cy4gVGhlIHZlcnkgYmFzaXMgb2YgdGhlIHNvdXJjZSByb3V0aW5n IG1vZGVsIGlzIHRoYXQgdGhlIFNSIFNvdXJjZSBOb2Rl4oCZcyBzZWxlY3Rpb24gb2YgdGhlc2Ug c2VnbWVudHMgaXMgYmFzZWQgb24gc29tZSBzb3VuZCBsb2dpYyBhbmQgYXdhcmVuZXNzIG9mIHRo ZWlyIGNoYXJhY3RlcmlzdGljcy4gVGhpcyBpcyBkYXRhIHBsYW5lIGluZGVwZW5kZW50LiBTbywg SSBmYWlsIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBpdCB0aGF0IHlvdSBzZWVrIHRvIGFkZCB0byB0 aGUgdGV4dCBhbmQgaG93IGl0IGhlbHBzLiBJIGRvbuKAmXQgdGhpbmsgdGhpcyBkb2N1bWVudCBo YXMgYW55dGhpbmcgZnVydGhlciB0byBhZGQgaW4gdGhhdCBtYXR0ZXIgYmVzaWRlcyB3aGF0IGlz IGRpc2N1c3NlZCBpbiBSRkM4NDAyLg0KDQo+ID4gVGhlcmUgbWlnaHQgYWxzbyBiZSByb29tIGZv ciBkaXNjdXNzaW9uIChpbiB0aGUgbWFpbiBib2R5IG9mIHRoZQ0KPiA+IGRvY3VtZW50KSBvZiBo b3cgdGhlIHZhcmlvdXMgZGVjYXBzdWxhdGlvbiBwcm9jZWR1cmVzIG9jY3VyIHByZWNpc2VseSB3 aGVuIHRoZSBwYWNrZXQgaXMgbGVhdmluZyB0aGUgU1IgRG9tYWluLg0KPiA+IFtQQ10gVGhlIHNl Y3Rpb25zIDQuNCB0aHJvdWdoIDQuMTIgZG8gZGVzY3JpYmUgdGhlc2UgcHJvY2VkdXJlcyBmb3Ig dGhlIGRlY2Fwc3VsYXRpb24gYmVoYXZpb3JzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50Lg0K PiANCj4gWWVzLCB0aGUgZGVjYXBzdWxhdGlvbiBwcm9jZWR1cmVzIHRoZW1zZWx2ZXMgYXJlIGNv dmVyZWQgd2VsbC4gIEkgYW0gc3VnZ2VzdGluZyB0byBtZW50aW9uIHRoYXQgdGhlIGFjdCBvZiBk ZWNhcHN1bGF0aW9uIChnZW5lcmFsbHkpIHNpZ25hbHMgdGhhdCB0aGUgcGFja2V0IGlzIGxlYXZp bmcgdGhlIFNSIGRvbWFpbiwgd2hlcmUgd2UgZGVzY3JpYmUgdGhlIHByb2NlZHVyZXMgdGhlbXNl bHZlcy4NCj4gDQo+IFtQQzJdIERlY2Fwc3VsYXRpb24gbWF5IHByaW1hcmlseSBvY2N1ciBhdCB0 aGUgZWRnZSBvZiBhbiBTUiBEb21haW4sIGFuZCBSRkM4NzU0IGRlc2NyaWJlcyB0aGlzIHNjZW5h cmlvIGluIHNlY3Rpb24gNS4NCg0KSSBhZ3JlZS4gIEknbSBub3Qgc3VyZSB3aGV0aGVyIHlvdSBh cmUgcmVqZWN0aW5nIG15IHN1Z2dlc3Rpb24gKHdoaWNoLCB0byBiZSBjbGVhciwgaXMgYSBwZXJm ZWN0bHkgZmluZSB0aGluZyB0byBkbykgb3IgaXQganVzdCB3YXNuJ3QgY29taW5nIGFjcm9zcyBh cyBJIGludGVuZGVkLiAgRm9yIGNsYXJpdHksIEkgd2FzIHByb3Bvc2luZyB0byBhZGQgc29tZXRo aW5nIGxpa2UgImEgZGVjYXBzdWxhdGluZyBiZWhhdmlvciBzdWNoIGFzIEVuZC5EWDYgaXMgdHlw aWNhbGx5IChidXQgbm90IGV4Y2x1c2l2ZWx5KSB1c2VkIGF0IHRoZSBlZ3Jlc3Mgb2YgdGhlIFNS IERvbWFpbiBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA1IG9mIFtSRkM4NzU0XSIgYXMgYSBu b3RlIGF0IHRoZSBlbmQgb2YgKGUuZy4pIMKnNC40LCBhbmQgc2ltaWxhcmx5IGZvciB0aGUgb3Ro ZXIgZGVjYXBzdWxhdGluZyBiZWhhdmlvcnMuDQoNCltQQzNdIFRoZSBjdXJyZW50IHRleHQgZXhw bGljaXRseSBzdGF0ZXMgdGhhdCBpdCBpcyB1c2VkIGF0IGFuIGVncmVzcyBQRSBmb3IgYW4gTDNW UE4gdXNlLWNhc2UuIA0KZS5nLiBmb3IgRW5kLkRYNDoNCiAgIE9uZSBvZiB0aGUgYXBwbGljYXRp b25zIG9mIHRoZSBFbmQuRFg0IGJlaGF2aW9yIGlzIHRoZSBMM1ZQTnY0IHVzZS0NCiAgIGNhc2Ug d2hlcmUgYSBGSUIgbG9va3VwIGluIGEgc3BlY2lmaWMgdGVuYW50IHRhYmxlIGF0IHRoZSBlZ3Jl c3MNCiAgIFByb3ZpZGVyIEVkZ2UgKFBFKSBpcyBub3QgcmVxdWlyZWQuICBUaGlzIGlzIGVxdWl2 YWxlbnQgdG8gdGhlIHBlci1DRQ0KICAgVlBOIGxhYmVsIGluIE1QTFMgW1JGQzQzNjRdLg0KIA0K PiA+IEhhdmluZyB0aGUgQVJHIHN0cnVjdHVyZSBzcGVjaWZpZWQgYXMgcGFydCBvZiB0aGUgYmVo YXZpb3IgY29kZXBvaW50IHJlZ2lzdHJhdGlvbiBtZWFucyB0aGF0IGEgbm9kZSB0aGF0IGNhbiBh cHBseSB0aGF0IFNJRCBjYW4gYWxzbyBzcG9vZiB0aGUgQVJHIHRvIGZvcmNlIGEgZGlmZmVyZW50 IChlLmcuKSBvdXRnb2luZyBpbnRlcmZhY2UgbGlzdC4NCj4gPiBTcGVjaWZpY2FsbHksIGl0IGdp dmVzIHRoZSBhdHRhY2tlciBhIGRlZ3JlZSBvZiBmcmVlZG9tIGdyZWF0ZXIgdGhhbiBqdXN0IHRo ZSBTSUQgYmVoYXZpb3JzIHRoYXQgdGhlIG5vZGUgYWR2ZXJ0aXNlcy4gIFRoZSBITUFDIFRMViB3 b3VsZCBtaXRpZ2F0ZSB0aGlzIHRvIHRoZSBleHRlbnQgdGhhdCBpdCBsaW1pdHMgd2hhdCBTSURz IHRoZSBub2RlIGluIHF1ZXN0aW9uIGlzIGFsbG93ZWQgdG8gYXBwbHkgYW5kIHdoYXQgY2hhbmdl cyBjYW4gYmUgbWFkZSBvbi1wYXRoLg0KPiA+IFtQQ10gVGhlIHByb2Nlc3Npbmcgb2YgQVJHIGlz IHNwZWNpZmljIHRvIGEgYmVoYXZpb3IgZGVmaW5lZCBhbmQgbm90IGdlbmVyaWMuIFBsZWFzZSBy ZWZlciB0byB0aGUgdXBkYXRlZCB0ZXh0IGluIFNlYyA0LjEyIGZvciBFbmQuRFQyTSAod2hpY2gg aXMgY3VycmVudGx5IHRoZSBvbmx5IHNwZWNpZmllZCBiZWhhdmlvciB0aGF0IGFjY2VwdHMgQVJH cykuIFNpbmNlIHRoZSBBUkcgYml0cyBhcmUgcGFydCBvZiB0aGUgU0lEIHRoZXJlIGFyZSBubyBv dGhlciBjb25zaWRlcmF0aW9ucyBmb3IgdGhlbSBhcGFydCBmcm9tIHRoZSBvbmVzIHRoYXQgYXBw bHkgdG8gdGhlIFNJRCBhcyBhIHdob2xlLg0KPiANCj4gRXZlbiB0aG91Z2ggdGhlIEFSRyBiaXRz IGFyZSBzcGVjaWZpYyB0byBhIGJlaGF2aW9yIChhIGZ1bmN0aW9uLCANCj4gcmVhbGx5LCBJSVVD KSwgaWYgdGhlcmUgaXMgYSBuZWVkIHRvIGhhdmUgQVJHIGJpdHMgdGhlbiB0aGVyZSBpcyBnb2lu ZyANCj4gdG8gYmUgbW9yZSB0aGFuIG9uZSB2YWxpZCB2YWx1ZSBmb3IgdGhlIEFSRyBiaXRzLiAg Tm93IHRoYXQgd2UgaGF2ZSANCj4gcmVtb3ZlZCBhIGRlc2NyaXB0aW9uIGZvciB0aGUgc3RydWN0 dXJlIG9mIHRoZSBBUkcgYml0cywgaXQgYmVjb21lcyBhIA0KPiBsaXR0bGUgaGFyZGVyIHRvIHNw b29mIHRoZW0sIGJ1dCBvbmx5IGEgbGl0dGxlIGJpdC4gIEdpdmVuIHRoZSANCj4gTCtGK0E8MTI4 IGNvbnN0cmFpbnQsIEEgbWF5IHZlcnkgd2VsbCBiZSBzb21ldGhpbmcgc21hbGwsIG9uIHRoZSBv cmRlciANCj4gb2YgMTA7IGFuIGV4aGF1c3RpdmUgc2VhcmNoIG92ZXIgdGhlIDIqKjEwIHBvc3Np YmxlIHZhbHVlcyBmb3IgQVJHIHRvIA0KPiBzZWUgd2hpY2ggYXJlIHZhbGlkIGFuZCB3aGF0IHRo ZXkgZG8gd291bGQgYmUgZmFpcmx5IGVhc3kgdG8gZG8uICBBbiANCj4gYXR0YWNrZXIgaW4gYSBw b3NpdGlvbiB0byBkbyB0aGF0IGV4aGF1c3RpdmUgc2VhcmNoIChhZG1pdHRlZGx5LCBvbmUgDQo+ IHdvdWxkIGJlIHZpb2xhdGluZyB0aGUgInRydXN0ZWQgU1IgZG9tYWluIiBhc3N1bXB0aW9uIHRv IGdldCB0aGVyZSkgDQo+IGNvdWxkIGJlIGFibGUgdG8gb2JzZXJ2ZSB0aGUgZGlmZmVyZW50IGJl aGF2aW9ycyBwcm92aWRlZCBieSB0aGUgDQo+IGRpZmZlcmVudCBBUkcgdmFsdWVzIGFuZCBzZWxl Y3Qgd2hhdCBiZWhhdmlvciB0aGV5IHdhbnRlZCBieSBzcG9vZmluZyANCj4gQVJHLiAgSWYgQSB3 YXMgbGFyZ2VyLCBsaWtlIDY0IG9yIDEyOCwgdGhpcyBzZWFyY2ggYW5kIGd1ZXNzaW5nIHdvdWxk IA0KPiBiZSBtdWNoIGxlc3MgcHJhY3RpY2FsLCBidXQgd2UgZG9uJ3QgcmVhbGx5IGhhdmUgdGhh dCBtYW55IGJpdHMgbHlpbmcgDQo+IGFyb3VuZC4gIFNvLCBJIHRoaW5rIHRoaXMgaXMgYSBuZXcg c2VjdXJpdHkgY29uc2lkZXJhdGlvbiBpbnRyb2R1Y2VkIA0KPiBieSB0aGUgcHJlc2VuY2Ugb2Yg dGhlIEFSRyBiaXRzIGluIHRoZSBTSUQsIGFuZCB3ZSBzaG91bGQgbWVudGlvbiBpdC4gIA0KPiAo V2Ugd291bGQgYWxzbyBtZW50aW9uIHRoYXQgdGhlIHJpc2sgaXMgbGFyZ2VseSBtaXRpZ2F0ZWQg YnkgdGhlIA0KPiBhc3N1bXB0aW9uIHRoYXQgdGhlIFNSIGRvbWFpbiBpcyB0cnVzdGVkLCBvZiBj b3Vyc2UuKQ0KPiANCj4gW1BDMl0gVGhpcyBzZXJ2aWNlIHRoZWZ0IGNvbnNpZGVyYXRpb24gZXhp c3RzIGZvciBldmVyeSBTSUQsIHJlZ2FyZGxlc3Mgb2YgdGhlIHVzZSBvZiBhcmd1bWVudHMuICBJ dCBpcyBkaXNjdXNzZWQgaW4gUkZDODc1NCBzZWN0aW9uIDcuMiBhbmQgcmVmZXJlbmNlZCBmcm9t IHNlY3Rpb24gOSBvZiB0aGlzIGRyYWZ0Lg0KDQpXZWxsLCB5ZXMgYW5kIG5vLiAgSSBhbSBpbWFn aW5pbmcgc29tZSByaXNrIGFib3V0IHNlcnZpY2UgdGhlZnQgZm9yIGFuIFNJRCB0aGF0IGlzIG5v dCBleHBsaWNpdGx5IGFkdmVydGlzZWQgYW55d2hlcmUsIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBk b2VzIG5vdCBzcGVjaWZpY2FsbHkgY2hlY2sgZm9yIHRoZSBleGFjdCBTSUQgdmFsdWVzIHRoYXQg YXJlIGFkdmVydGlzZWQuDQoNCkNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIGEgc2luZ2xlIG5vZGUg aGFzIFNJRHMgdGhhdCB1c2UgbXVsdGlwbGUgZGlzdGluY3QgTE9DcywgY2FsbCB0aGVtIExPQ3Mg QSBhbmQgQi4gIElmIGEgU0lEIChjYWxsIGl0IFEpIGlzIGFkdmVydGlzZWQgd2l0aCBBIGFuZCBi ZWhhdmlvciBjb2RlIFggd2l0aCBBUkcxLCBhbmQgYSBkaWZmZXJlbnQgU0lEIChjYWxsIGl0IE8p IGlzIGFkdmVydGlzZWQgd2l0aCBCIGFuZCBiZWhhdmlvciBjb2RlIFggd2l0aCBBUkcyLCB0aGVu IHRoaXMgaW1wbGVtZW50YXRpb24gaXMgbGlrZWx5IHRvIGFsc28gcHJvY2VzcyBhbiBTSUQgd2l0 aCBMT0MgQSwgdGhlIEZVTkNUIHZhbHVlIGZyb20gUSwgYW5kIEFSRzIsIGV2ZW4gdGhvdWdoIHN1 Y2ggYW4gU0lEIGlzIG5vdCBhY3R1YWxseSBhZHZlcnRpc2VkLiAgU28sIHRoZSBzcG9vZmluZyBh bGxvd3MgdG8gY3JlYXRlIG5ldyBiZWhhdmlvcnMgaW4gYWRkaXRpb24gdG8ganVzdCBzZXJ2aWNl IHRoZWZ0IG9mIGV4cGVjdGVkIGJlaGF2aW9ycy4NCg0KW1BDM10gQXJndW1lbnRzIGRvIG5vdCBj cmVhdGUgYmVoYXZpb3JzLiBTbywgdGhlIGhhbmRsaW5nIG9mIHVuZXhwZWN0ZWQgYXJndW1lbnRz IGlzIGVudGlyZWx5IGRlcGVuZGVudCBvbiB0aGUgYmVoYXZpb3IgYW5kIGl0cyBwc2V1ZG9jb2Rl LiBTbyBpbiBlZmZlY3QgaXQgaXMgbm90IGRpZmZlcmVudCBpZiBzb21lb25lIHdlcmUgdG8gc3Bv b2YgdGhlIGVudGlyZSBTSUQgYXMgd2Ugd2VyZSBkaXNjdXNzaW5nIGVhcmxpZXIuDQoNCk1hbnkg dGhhbmtzIEJlbiENCiANClRoYW5rcyBhZ2FpbiwNCg0KQmVuDQoNCj4gPiAgICBzZXJ2aWNlcy4g IEFkZGl0aW9uYWxseSwgW1JGQzg3NTRdIGRlZmluZXMgYW4gSE1BQyBUTFYgcGVybWl0dGluZyBT Ug0KPiA+ICAgIEVuZHBvaW50IE5vZGVzIGluIHRoZSBTUiBkb21haW4gdG8gdmVyaWZ5IHRoYXQg dGhlIFNSSCBhcHBsaWVkIHRvIGENCj4gPiAgICBwYWNrZXQgd2FzIHNlbGVjdGVkIGJ5IGFuIGF1 dGhvcml6ZWQgcGFydHkgYW5kIHRvIGVuc3VyZSB0aGF0IHRoZQ0KPiA+ICAgIHNlZ21lbnQgbGlz dCBpcyBub3QgbW9kaWZpZWQgYWZ0ZXIgZ2VuZXJhdGlvbiwgcmVnYXJkbGVzcyBvZiB0aGUNCj4g PiAgICBudW1iZXIgb2Ygc2VnbWVudHMgaW4gdGhlIHNlZ21lbnQgbGlzdC4gIFdoZW4gZW5hYmxl ZCBieSBsb2NhbA0KPiA+DQo+ID4gSSBzdWdnZXN0IGFkZGluZyBhIHNlbnRlbmNlIHNpbWlsYXIg dG8gIihUaGlzIGRvZXMsIGhvd2V2ZXIsIHJlcXVpcmUgdGhhdCB0aGUgc2VnbWVudCBsaXN0LCBh bmQgdGh1cywgdGhlIFNSSCBpcyBwcmVzZW50IGluIHRoZSBwYWNrZXQ7IHRoZSBvcHRpb25hbCBh YmlsaXR5IHRvIGVsaWRlIHRoZSBTUkggd2hlbiB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIHNlZ21l bnQgYW5kIG5vIGZsYWdzLCB0YWdzLCBvciBUTFZzIG5lZWRlZCBpbmhlcmVudGx5IGV4Y2x1ZGVz IHRoZSBwcm90ZWN0aW9uIG9mIHRoZSBITUFDIFRMVi4pIg0KPiA+IFtQQ10gQWxsIHRoZSBTUiBQ b2xpY3kgSGVhZGVuZCAoaS5lLiB0aGUgU1IgU291cmNlIE5vZGUpIGJlaGF2aW9ycyBkZWZpbmVk IGluIFNlYyA1IHN0YXRlOg0KPiA+ID4gIFRoZSBwdXNoIG9mIHRoZSBTUkggTUFZIGJlIG9taXR0 ZWQgd2hlbiB0aGUgU1J2NiBQb2xpY3kgb25seSBjb250YWlucyAgIG9uZSBzZWdtZW50IGFuZCB0 aGVyZSBpcyBubyBuZWVkIHRvIHVzZSBhbnkgZmxhZywgdGFnIG9yIFRMVi4NCj4gPiBTbywgaXQg Zm9sbG93cyB0aGF0IGlmIEhNQUMgcHJvdGVjdGlvbiBpcyByZXF1aXJlZCwgdGhlbiBTUkggaGFz IHRvIGJlIHVzZWQgZXZlbiB3aXRoIGEgc2luZ2xlIHNlZ21lbnQuDQo+IA0KPiBBaCwgSSBzZWUg eW91ciBwb2ludCwgeWVzLiAgU29ycnkgZm9yIG1pc3NpbmcgdGhhdC4NCj4gKEJ1dCBJIHRoaW5r IG15IGVhcmxpZXIgY29tbWVudCBhYm91dCBQU1Agc3RpbGwgYXBwbGllcy4pDQo+IA0KPiA+IFNl Y3Rpb24gMTAuMQ0KPiA+DQo+ID4gICAgZGVmaW5pdGlvbjogVGhlIHZhbHVlIDE0MyBpbiB0aGUg TmV4dCBIZWFkZXIgZmllbGQgb2YgYW4gSVB2NiBoZWFkZXINCj4gPiAgICBvciBhbnkgZXh0ZW5z aW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCB0aGUgcGF5bG9hZCBpcyBhbiBFdGhlcm5ldA0KPiA+ ICAgIFtJRUVFLjgwMi4zXzIwMThdLg0KPiA+DQo+ID4gbml0OiBpcyB0aGVyZSBhIG1pc3Npbmcg d29yZCBoZXJlICgiZnJhbWUiPyk/DQo+ID4gW1BDXSBBY2ssIGZpeGVkLg0KPiA+DQo+ID4gTWFu eSB0aGFua3MgZm9yIHlvdXIgdGltZS4NCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91cnMgYXMgd2Vs bCwgYW5kIHRoZSB1cGRhdGVzIGFscmVhZHkgcHJlc2VudCBhbmQgcXVldWVkLg0KPiANCj4gU29y cnkgYWdhaW4gZm9yIHRha2luZyBzbyBsb25nIHRvIGdldCBiYWNrIHRvIHlvdS4NCj4gDQo+IC1C ZW4NCg== From nobody Thu Nov 26 10:55:03 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866143A083F; Thu, 26 Nov 2020 10:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 SnRCu9SKh9gq; Thu, 26 Nov 2020 10:55:00 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7D1C23A083E; Thu, 26 Nov 2020 10:54:59 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AQIskRh032217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Nov 2020 13:54:51 -0500 Date: Thu, 26 Nov 2020 10:54:46 -0800 From: Benjamin Kaduk To: tom petch Cc: "Acee Lindem (acee)" , "last-call@ietf.org" , "spring@ietf.org" , Joel Halpern , "spring-chairs@ietf.org" , "draft-ietf-spring-sr-yang@ietf.org" Message-ID: <20201126185446.GC34187@kduck.mit.edu> References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <5FBCD392.3050706@btconnect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FBCD392.3050706@btconnect.com> Archived-At: Subject: Re: [spring] [Last-Call] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 18:55:02 -0000 On Tue, Nov 24, 2020 at 09:34:10AM +0000, tom petch wrote: > On 23/11/2020 17:27, Acee Lindem (acee) wrote: > > > > Examples are IPv4 only, IPv6 would be good > > > > BGP is included when it comes to defining a router-id but is ignored > > everywhere else, such as signalling MSD, protocol extensions etc > > > > reference "RFC XXXX" would be improved by including the title in all > > cases not just some > > > > the scheme http: appears in many places. It would be lovely if this > > really was the scheme but I fear that it is not > > > > This is directly from the RFC 8407 template in Appendix B. What would you suggest? > > > Many I-D do now specify https: since that is now the only option > supported by the IETF; I have seen this called for by an AD. I think we have typically been using https: in recent RFCs, but we should probably write a (very short) draft to update 8407 and the template therein. Any volunteers? -Ben From nobody Thu Nov 26 19:12:39 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D7C3A10FA; Thu, 26 Nov 2020 19:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qCEWDam6FW4b; Thu, 26 Nov 2020 19:12:35 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id ED9813A10F6; Thu, 26 Nov 2020 19:12:30 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb5fc06e8c1d2-5f41d; Fri, 27 Nov 2020 11:12:12 +0800 (CST) X-RM-TRANSID: 2eeb5fc06e8c1d2-5f41d X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.130]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35fc06e8ba40-4a31f; Fri, 27 Nov 2020 11:12:12 +0800 (CST) X-RM-TRANSID: 2ee35fc06e8ba40-4a31f From: "Weiqiang Cheng" To: "'James Guichard'" , Cc: References: In-Reply-To: Date: Fri, 27 Nov 2020 11:12:16 +0800 Message-ID: <024201d6c46b$1c70af20$55520d60$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0243_01D6C4AE.2A93EF20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdbCa21c1PFQQWUVQJOg9p9otl0vogB/6B4w Content-Language: zh-cn Archived-At: Subject: Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 03:12:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0243_01D6C4AE.2A93EF20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR disclosures for this document. =20 Weiqiang =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C224=C8=D5 22:57 =CA=D5=BC=FE=C8=CB: spring@ietf.org =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 =20 Dear WG: =20 The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has = just concluded and the chairs agree that enough support was received to = approve this adoption. =20 Authors, please resubmit a new document as draft-ietf-spring-srv6-path-segment-00. In addition, please indicate = whether you are aware of any IPR disclosures for this document. =20 Thanks! =20 Jim, Joel & Bruno =20 =20 ------=_NextPart_000_0243_01D6C4AE.2A93EF20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    I am not = aware of any IPR disclosures for this document.

     

    Weiqiang

     

    =B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
    =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C224=C8=D5 22:57
    =CA=D5=BC=FE=C8=CB: = spring@ietf.org
    =B3=AD=CB=CD: = spring-chairs@ietf.org
    =D6=F7=CC=E2: [spring] WG Adoption Call = Concluded for = draft-li-spring-srv6-path-segment-07

     

    Dear WG:

     

    The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 = has just concluded and the chairs agree that enough support was received = to approve this adoption.

     

    Authors, please resubmit a new = document as draft-ietf-spring-srv6-path-segment-00. In addition, please = indicate whether you are aware of any IPR disclosures for this = document.

     

    Thanks!

     

    Jim, Joel & Bruno

     

     

    ------=_NextPart_000_0243_01D6C4AE.2A93EF20-- From nobody Thu Nov 26 19:40:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D749D3A1138; Thu, 26 Nov 2020 19:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lqn46UJ2TTRR; Thu, 26 Nov 2020 19:40:41 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C3C3A1136; Thu, 26 Nov 2020 19:40:40 -0800 (PST) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cj0j408b0z67H52; Fri, 27 Nov 2020 11:38:48 +0800 (CST) Received: from fraeml703-chm.china.huawei.com (10.206.15.52) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Fri, 27 Nov 2020 04:40:35 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Fri, 27 Nov 2020 04:40:35 +0100 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.58]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Fri, 27 Nov 2020 11:40:29 +0800 From: Mach Chen To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 Thread-Index: AdbCa21c1PFQQWUVQJOg9p9otl0vogCA4lhg Date: Fri, 27 Nov 2020 03:40:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FF91AFdggeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 03:40:43 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FF91AFdggeml510mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I am not aware of any IPR that applies to this document. Best regards, Mach From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Tuesday, November 24, 2020 10:57 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-= segment-07 Dear WG: The 3-week WG adoption call for draft https://tools.ietf.org/html/draft-li-= spring-srv6-path-segment-07 has just concluded and the chairs agree that en= ough support was received to approve this adoption. Authors, please resubmit a new document as draft-ietf-spring-srv6-path-segm= ent-00. In addition, please indicate whether you are aware of any IPR discl= osures for this document. Thanks! Jim, Joel & Bruno --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FF91AFdggeml510mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Jim,

     

    I am not aware of any IPR that applies to this document.

     

    Best regards,

    Mach

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Tuesday, November 24, 2020 10:57 PM
    To: spring@ietf.org
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv= 6-path-segment-07

     

    Dear WG:

     

    The 3-week WG adoption call for= draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has ju= st concluded and the chairs agree that enough support was received to appro= ve this adoption.

     

    Authors, please resubmit a new = document as draft-ietf-spring-srv6-path-segment-00. In addition, please ind= icate whether you are aware of any IPR disclosures for this document.<= /o:p>

     

    Thanks!

     

    Jim, Joel & Bruno

     

     

    --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FF91AFdggeml510mbschi_-- From nobody Fri Nov 27 06:34:32 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8254F3A0D6E; Fri, 27 Nov 2020 06:34:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160648766749.26341.8287356700145861441@ietfa.amsl.com> Date: Fri, 27 Nov 2020 06:34:27 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-27.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 14:34:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-27.txt Pages : 39 Date : 2020-11-27 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-27 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 27 06:36:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95653A0D8A; Fri, 27 Nov 2020 06:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=mYK38XQz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=P6dhApy7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucgnMCo_SuDc; Fri, 27 Nov 2020 06:36:11 -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 A1F623A0D89; Fri, 27 Nov 2020 06:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8498; q=dns/txt; s=iport; t=1606487770; x=1607697370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JGzwiPPMacVRt+iPhfcfwJaJXhUEc/CpUoYdUmAOAX8=; b=mYK38XQzhO2d9Jzgy5pL3OxoXTB9odVhkvE9kq6Suf6iGrYnqpkeRH49 XWQha9DpF1X0OcB6GAWTw6Nm9/bkfx/OSCQ2us1oiQ241KyRlIciiG1Ve nWrWN6hbQ9yTeFiX23CgXpTeBtf3WthVqisTp1EqHCxrFfhu5+hpsyaHx Y=; X-IPAS-Result: =?us-ascii?q?A0DfAAD7DcFffZxdJa1iHQEBAQEJARIBBQUBQIE8BwELA?= =?us-ascii?q?YFRTgN8Wi8uCoQzg0kDjV6ZBoEugSUDVAsBAQENAQEtAgQBAYRKAheCEgIlN?= =?us-ascii?q?QgOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcwEBBBIREQwBATcBDwIBC?= =?us-ascii?q?BgCAh8HAgICMBUQAgQBDQUigwQBglUDLgGlSQKBPIhpdoEygwQBAQWFKhiCE?= =?us-ascii?q?AmBDioBgnKDdoZXG4IAgREnHIJVPoN4HigXgwCCX5N8h0ydJgqCb5ssAx+DH?= =?us-ascii?q?YodlFodk0igbgIEAgQFAg4BAQWBWAI0gVlwFRohKgGCPlAXAg2OIQwXFIM6i?= =?us-ascii?q?lh0NwIGAQkBAQMJfIw2gTQBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AAK7AWxErDVUpJq95JGIBSZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gWbV5nQ7PRChuHK9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Yvna16zgfEQ?= =?us-ascii?q?m5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="scan'208";a="601932285" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 14:36:06 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AREa6DJ015405 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Nov 2020 14:36:06 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 08:36:05 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 09:36:01 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 09:36:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+u22ZT+qCtYO9Ll+6puAQ5LNXf/HrKypAru4/A3ABpkLURtb3AzSM+1iBCOxYjKZqv353vWNm4N3fvcCy3K8+eaoEDZkUcSsdWGeHjVTs67ZIzBNCNiNXq+WSbnEYfwLQAJWL6r2KXj/YDe89A9w24s7jgVi7FDpUArXwQ1NMTHXZWtL51KDYBMMa8esQVSHDuldGYhOx1sWKdNZC55i/BbXtVyNw/6hkVcHbmuqLY24fIh0PKAF8wMp7sXXXlILcQjGeUxP5vvpYX9x+yVUk0BLXRrqkpYJOP5GlM1EP73ek+JOyTTglMpgV8Zj6HYGUp9iLSAXCEPlrcnt3Y8Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JGzwiPPMacVRt+iPhfcfwJaJXhUEc/CpUoYdUmAOAX8=; b=T8+pLragdOt8j0GacT++/Jn6QqEycD0QS6tHf3AuojZd5hIiD/alBeEIFrHunGpLUr0eMSbOhdJYHfv12MH4FDt0cciwALyDUdXYESyTYlRfTCA/W9oBPai5om4jrgjImpXRciDeQ/beQCfk76quOw14TvbzL69SGYUC3zgGhXY8wfjnohjyvg/xrOrDtO3g8dsi1ox0pLGkv3J4XTJExYWAfN87dLgbRSUlpz7kDvnUJoENPH/JSs9UOqPezC7xRVJGVz1WL6K5W3u8M+IzaRL/gOcjlqIcBd47Km77xIyANRQ9f6M0Vft1Euat21KWURFxN0g8yIM7VtAIypLwAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JGzwiPPMacVRt+iPhfcfwJaJXhUEc/CpUoYdUmAOAX8=; b=P6dhApy7gsV6qvdQ24VhDZ8D1+gMtAFG11JtLn0VFSYysxzVmBKE4yCiCo+bUiOjjSokbQt/ARCEJJLQLNa5a+DCjacSS4xbFeX7W1zeReByKwO8JFzS7gDDcF9pne1rwYY7DcHs3dMMxwCAhUszViQaDQXjo1wxcC6vJ4rRmE4= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5103.namprd11.prod.outlook.com (2603:10b6:a03:2d3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Fri, 27 Nov 2020 14:35:58 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Fri, 27 Nov 2020 14:35:58 +0000 From: "Acee Lindem (acee)" To: tom petch , "last-call@ietf.org" CC: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" Thread-Topic: Last Call: (YANG Data Model for Segment Routing) to Proposed Standard Thread-Index: AQHWvE9TnHz4xC0KAECDY9QT1Wf1oanN1wuAgAfYZQCAAWHdAIADN+MAgAF/mgA= Date: Fri, 27 Nov 2020 14:35:58 +0000 Message-ID: <2E1DE08B-47AA-4D29-8ACD-30335BDFFCFE@cisco.com> References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <5FBCD392.3050706@btconnect.com> <5FBF86B2.7020907@btconnect.com> In-Reply-To: <5FBF86B2.7020907@btconnect.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a1689d93-7970-4977-e149-08d892e1c1ae x-ms-traffictypediagnostic: SJ0PR11MB5103: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:962; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bwJFYAPCY0X76fk5Vj84q355H0DSscta51qFCuHYYr5i1povcUjZd0DijHaKUMnyzU7Fm2H5EzPsU32q627+Xr2XAIXv0fKEgBhDglbgfHglnP43oWKt7Atn+KeSYNfE+7ltElMFMvQIeAwlUlJ0GM0qSyJTTEGlxJckI8g6CTRYMAS3AcTrOg1aOmun8d7KLnVFEiRaRvXTqthoLLFHVGNaZeTr3jg1ce95NnOPNHy/e76qDlzUjrQMbiSOtsIqoLe0k6BZ5W32rmF+twn9QhsGJWFfOe0NIrghRLnTVZ1B4WhbveZyb2xrMEKySpncq+tup2TncHxYZWNiSQ3+qg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(39860400002)(366004)(396003)(6512007)(110136005)(296002)(54906003)(2906002)(316002)(71200400001)(66574015)(36756003)(83380400001)(86362001)(8676002)(66476007)(66556008)(66446008)(76116006)(33656002)(5660300002)(66946007)(64756008)(478600001)(6486002)(4326008)(186003)(26005)(8936002)(2616005)(6506007)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aDN5UkYxYUd0SFFGalllREZvNVphN3NuQzh3ejJDeG44S1c3dmplaUluRzdI?= =?utf-8?B?aTlUVXRFZHRnQTZnWWd3K2paZ2x5WlM0MGtwWUt3cTlBVUI5K3ZKZ1Exb2Jn?= =?utf-8?B?aFQvOEJ0enkwYzBqWUF4MDlkVll2SUVXK3dueS9rcCs3QmtObzFjY0tSUDNV?= =?utf-8?B?elVDRnpYY3QvN3Z6SmdESkV1dHZzL1QxK0IzSmFZZFhHektOT3hZczdmQzk1?= =?utf-8?B?dUV3eGJQcDdacVBrSGh6VG94ak5BdSs2ZlpxdDB2MmhOWTdvamRTVEFiZWxX?= =?utf-8?B?ZXFyRDVOeG1HbG43QVFrSmc5bHpZdDM2MndwcitSajYrSFBObGZQQUlJZFV3?= =?utf-8?B?TTVVbklCQmlHc09DUTlNSmh6R2F5Q2VOaTdVNUtPSjhackJKZ2J3VXlwbHpV?= =?utf-8?B?TUduNHJRK2kyS3JHNkcyT0hUaE1WSExwZERIeWQ3dnR5Y3BSRTFjYlkwTlRq?= =?utf-8?B?UDhYUlJNbjRCWHVUSHU3YXp0OVVPSnFQVjFEcHQxVEJkbUxrL2d6U1Rad1M2?= =?utf-8?B?MWxGc3dld0RaL3BHUGxZWG9nTXMrSitYNFg5QVFQUjEwV1BYU0szOWkwdVNV?= =?utf-8?B?VEM0QStFR2tGUEtVczRWL1QvR3kzVm9aNGltTmVoeGtGNTMwRGVIQXRzMUd1?= =?utf-8?B?dGhNNUtoZnMvWmZBTU9wTGVSbmFKNHB4M0JETUUxcVRQT0hXTGtyRmIxUDdu?= =?utf-8?B?eGZ1dlROZjBseVFqeTY1Tmk0UDhwdjgyR01wT3JTd3ZLY0M1dnBySW1xWHBI?= =?utf-8?B?V3l4WFhYeFZwdFNnK01QMlR2NjBsRjdOYUhTRzk5bnJOU0IwQU5KYUZUSFhH?= =?utf-8?B?S2kwZVlNVkg3cDNWTlY5ZWRERW1SY3FsKytreHB3NVhiQTcxaWVtalR1UTJ4?= =?utf-8?B?YjNqT3VyR0RCa3VIaEpkcFF3cmJQeHArc1BMalJKWUZyQU1ZemtUSkpxcmlz?= =?utf-8?B?bFcvZFNpdjZGSVFzYlhVcjVwVmNnVWI2ZVk4dGJHR3lvVTV6MVpqd0dUYU9W?= =?utf-8?B?bTh0bHoxZnc1SWRDUk40Q1p1WkhwV3lwd1NnejJyZk1Gc0JKdkxMZGdicjBk?= =?utf-8?B?TXZqdHF6ZHQ4aktSalNaMHpObVRGSHRWQ00wMXIwb05XSGF6WDR2cXFsSDUx?= =?utf-8?B?cjBhWTVQdnVVdjhRK2JodDg2ckZKUHp1TElNTk1MMGQyQ09NZ1Z5M0JVaGJz?= =?utf-8?B?aFJWUXNqN1lXUnFGdGtxYVRKMkg4TG4zK0hjalRNdEkzUGo4QlBmNEpBMDNu?= =?utf-8?B?bERkVDAwbldwWklGRG9vZEdmRkZ1bzdpSjVaR2l5OUljNnJUY1dyVDZnSFZR?= =?utf-8?Q?bL9g7D0NN7Bg0VeKpWdSKowCFxz+FBmRnC?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <004545F6D4837E40B9FC9429405C9440@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a1689d93-7970-4977-e149-08d892e1c1ae X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 14:35:58.6066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BziIgFxXxvFUicU2ouPepNW2Kn/S0GiTtUTaXPYSy3H0rwtGvvtZpHocd0Ctb+J4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5103 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 14:36:13 -0000 SGkgVG9tIA0KUGxlYXNlIHNlZSB0aGUgLTI3IHZlcnNpb24uIEkgYmVsaWV2ZSBpdCBhZGRyZXNz ZXMgeW91ciBjb25jZXJucyBhcyB3ZWxsIGFzIGNoYW5naW5nICJodHRwOiIgdG8gImh0dHBzOiIu IA0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAxMS8yNi8yMCwgNTo0MyBBTSwgInRvbSBwZXRjaCIg PGRhZWR1bHVzQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KDQogICAgSSBoYXZlIGxvb2tlZCBhdCAt MjYgYW5kIGl0IGxvb2tzIGdvb2QgYXBhcnQgZnJvbSBCR1AuDQoNCiAgICBCR1AgZ2V0cyBhIG1l bnRpb24gaW4gcGFzc2luZyBidXQgZG9lcyBub3QgZ2V0IHRoZSBzYW1lIHRyZWF0bWVudCBhcyB0 aGUgDQogICAgcHJvdG9jb2xzIG9mIHRoZSBMU1IgV0cuICBJIGFtIHVuY2xlYXIgd2hldGhlciBv ciBub3QgdGhpcyBJLUQgaXMgDQogICAgaW50ZW5kZWQgdG8gaW5jbHVkZSBuZXR3b3JrcyB1c2lu ZyBCR1Agb3Igbm90IHdpdGggZS5nLiBzaWduYWxsaW5nIG9mIA0KICAgIE1TRCBhbmQgd291bGQg dmFsdWUgYSBjbGFyaWZpY2F0aW9uIGluIHRoZSBJLUQuDQoNCiAgICBJIHdvbmRlciBhYm91dCB0 aGUgZmluYWwgRCBpbg0KICAgIE1heGltdW0gU0lEIERlcHRoIChNU0QpRA0KICAgIGluIHRoZSBZ QU5HOyBJIHN1c3BlY3QgdGhhdCBpdCBpcyBzcHVyaW91cy4NCg0KICAgIFRvbSBQZXRjaA0KDQog ICAgT24gMjQvMTEvMjAyMCAwOTozNCwgdG9tIHBldGNoIHdyb3RlOg0KICAgID4gT24gMjMvMTEv MjAyMCAxNzoyNywgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KICAgID4+IEhpIFRvbSwNCiAg ICA+Pg0KICAgID4+IFNlZSBhIGNvdXBsZSByZXNwb25zZXMgaW5saW5lIGVuY2xvc2VkIGluIDxh Y2VlPiBhbmQgPC9hY2VlPi4gV2UgYXJlDQogICAgPj4gYWRkcmVzc2luZyB0aGUgcmVzdCBvZiB5 b3VyIGNvbW1lbnRzLg0KICAgID4+DQogICAgPj4gT24gMTEvMTgvMjAsIDc6MzkgQU0sICJ0b20g cGV0Y2giIDxkYWVkdWx1c0BidGNvbm5lY3QuY29tPiB3cm90ZToNCiAgICA+Pg0KICAgID4+ICAg ICAgSUFOQSBDb25zaWRlcmF0aW9ucyBkb2VzIG5vdCByZWdpc3RlciB0aGUgbW9kdWxlIG5hbWVz IHVzZWQgaW4NCiAgICA+PiB0aGUgbW9kdWxlcw0KICAgID4+DQogICAgPj4gPGFjZWU+DQogICAg Pj4gVGhpcyBpcyBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucy4uLg0KICAgID4NCiAgICA+IDx0 cD4NCiAgICA+IEluZGVlZDsgSSBkbyBub3Qgc2VlIGEgcmVnaXN0cmF0aW9uIG9mIGlldGYtc2Vn bWVudC1yb3V0aW5nLW1wbHMhDQogICAgPg0KICAgID4+ICAgICBUaGlzIGRvY3VtZW50IHJlZ2lz dGVycyBhIFlBTkcgbW9kdWxlIGluIHRoZSBZQU5HIE1vZHVsZSBOYW1lcw0KICAgID4+ICAgICBy ZWdpc3RyeSBbUkZDNjAyMF0uDQogICAgPj4NCiAgICA+PiAgICAgICAgbmFtZTogaWV0Zi1zZWdt ZW50LXJvdXRpbmctY29tbW9uDQogICAgPj4gICAgICAgIG5hbWVzcGFjZTogdXJuOmlldGY6cGFy YW1zOnhtbDpuczp5YW5nOmlldGYtc2VnbWVudC1yb3V0aW5nLWNvbW1vbg0KICAgID4+ICAgICAg ICBwcmVmaXg6IHNyLWNtbg0KICAgID4+ICAgICAgICByZWZlcmVuY2U6IFJGQyBYWFhYDQogICAg Pj4NCiAgICA+PiAgICAgICAgbmFtZTogaWV0Zi1zZWdtZW50LXJvdXRpbmcNCiAgICA+PiAgICAg ICAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zZWdtZW50LXJv dXRpbmcNCiAgICA+PiAgICAgICAgcHJlZml4OiBzcg0KICAgID4+ICAgICAgICByZWZlcmVuY2U6 IFJGQyBYWFhYDQogICAgPj4NCiAgICA+PiAgICAgICAgbmFtZTogaWV0Zi1zZWdtZW50LXJvdXRp bmcNCiAgICA+PiAgICAgICAgbmFtZXNwYWNlOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6 aWV0Zi1zZWdtZW50LXJvdXRpbmctbXBscw0KICAgID4+ICAgICAgICBwcmVmaXg6IHNyLW1wbHMN CiAgICA+PiAgICAgICAgcmVmZXJlbmNlOiBSRkMgWFhYWA0KICAgID4+IDwvYWNlZT4NCiAgICA+ Pg0KICAgID4+ICAgICAgRXhhbXBsZXMgYXJlIElQdjQgb25seSwgSVB2NiB3b3VsZCBiZSBnb29k DQogICAgPj4NCiAgICA+PiAgICAgIEJHUCBpcyBpbmNsdWRlZCB3aGVuIGl0IGNvbWVzIHRvIGRl ZmluaW5nIGEgcm91dGVyLWlkIGJ1dCBpcyBpZ25vcmVkDQogICAgPj4gICAgICBldmVyeXdoZXJl IGVsc2UsIHN1Y2ggYXMgc2lnbmFsbGluZyBNU0QsIHByb3RvY29sIGV4dGVuc2lvbnMgZXRjDQog ICAgPj4NCiAgICA+PiAgICAgIHJlZmVyZW5jZSAiUkZDIFhYWFgiIHdvdWxkIGJlIGltcHJvdmVk IGJ5IGluY2x1ZGluZyB0aGUgdGl0bGUgaW4gYWxsDQogICAgPj4gICAgICBjYXNlcyBub3QganVz dCBzb21lDQogICAgPj4NCiAgICA+PiAgICAgIHRoZSBzY2hlbWUgaHR0cDogYXBwZWFycyBpbiBt YW55IHBsYWNlcy4gIEl0IHdvdWxkIGJlIGxvdmVseSBpZiB0aGlzDQogICAgPj4gICAgICByZWFs bHkgd2FzIHRoZSBzY2hlbWUgYnV0IEkgZmVhciB0aGF0IGl0IGlzIG5vdA0KICAgID4+IDxhY2Vl Pg0KICAgID4+IFRoaXMgaXMgZGlyZWN0bHkgZnJvbSB0aGUgUkZDIDg0MDcgdGVtcGxhdGUgaW4g QXBwZW5kaXggQi4gV2hhdCB3b3VsZA0KICAgID4+IHlvdSBzdWdnZXN0Pw0KICAgID4NCiAgICA+ IDx0cD4NCiAgICA+IE1hbnkgSS1EIGRvIG5vdyBzcGVjaWZ5IGh0dHBzOiBzaW5jZSB0aGF0IGlz IG5vdyB0aGUgb25seSBvcHRpb24NCiAgICA+IHN1cHBvcnRlZCBieSB0aGUgSUVURjsgSSBoYXZl IHNlZW4gdGhpcyBjYWxsZWQgZm9yIGJ5IGFuIEFELg0KICAgID4NCiAgICA+DQogICAgPj4gPC9h Y2VlPg0KICAgID4+DQogICAgPj4gICAgICBtb2R1bGUgc3JjbW4NCiAgICA+PiAgICAgICAgdGhl IHVwcGVyIGJvdW5kIG11c3QgYmUgbGFyZ2VyDQogICAgPj4gICAgICAgIHRoZSB2YWx1ZSBtdXN0 IGJlIGdyZWF0ZXINCiAgICA+PiAgICAgIGNvbnNpc3RlbmN5IGlzIGdvb2QgLSBJIHRoaW5rIGdy ZWF0ZXIgaXMgYmV0dGVyDQogICAgPj4NCiAgICA+PiAgICAgIDguMw0KICAgID4+ICAgICAgb3Bl cmF0aW9uIHN0YXRlcw0KICAgID4+ICAgICAgdXN1YWxseSBvcGVyYXRpb25hbA0KICAgID4+DQog ICAgPj4gICAgICB0d28gaW1wb3J0cyBsYWNrIHJlZmVyZW5jZXMNCiAgICA+Pg0KICAgID4+ICAg ICAgdHlwZWRlZiByb3V0ZXItaWQNCiAgICA+PiAgICAgIHRoaXMgaXMgYSB3ZWxsIGtub3duIHR5 cGUgZnJvbSBSRkM4Mzk0OyBpdCBzZWVtcyBsaWtlbHkgdG8NCiAgICA+PiBjb25mdXNlIHRvDQog ICAgPj4gICAgICByZWRlZmluZSBpdCB3aXRoIGEgcmVsYXRlZCBidXQgZGlmZmVyZW50IG1lYW5p bmcNCiAgICA+Pg0KICAgID4+ICAgICAgbGVhZiBlbmFibGVkDQogICAgPj4gICAgICBlbmFibGVz IHByb3RvY29sIGV4dGVuc2lvbnMNCiAgICA+PiAgICAgIHdoaWNoIHByb3RvY29scz8NCiAgICA+ Pg0KICAgID4+ICAgICAgbGVhZiBwcm90ZWN0ZWQNCiAgICA+PiAgICAgIGl0IGlzIHVzZWQgdG8g cHJvdGVjdA0KICAgID4+ICAgICAgaG93IGRvZXMgaXQgZG8gdGhhdDotKQ0KICAgID4+DQogICAg Pj4gICAgICBlbnVtIGR1YWwNCiAgICA+PiAgICAgIC4uLiBJbiB0aGlzIGNhc2Ugd2lsbCBiZSBh ZHZlcnRpc2VkIHdpdGggYmFja3VwIGZsYWcgc2V0DQogICAgPj4gICAgICBXaGF0IGlzIHRoZSBi YWNrdXAgZmxhZz8gIEl0IGRvZXMgbm90IGZlYXR1cmUgaW4gUkZDODY2MC4gIE5lZWRzIGFuDQog ICAgPj4gICAgICBleHBsYW5hdGlvbiBhbmQgcmVmZXJlbmNlDQogICAgPj4NCiAgICA+PiAgICAg IGNvbnRhaW5lciBsaW5rLW1zZA0KICAgID4+ICAgICAgICBsaXN0IGxpbmstbXNkcw0KICAgID4+ ICAgICAgICAgIGxlYWYgbXNkDQogICAgPj4gICAgICBUaGUgdXN1YWwgWUFORyBjb252ZW50aW9u IGlzIGZvciBhIGxpc3QgdG8gYmUgcGx1cmFsIGFuZCB0aGUgbGVhZg0KICAgID4+ICAgICAgc2lu Z3VsYXIuICBZb3UgaGF2ZSB0aGUgcGx1cmFsIGxpc3QgYnV0IG5vdCB0aGUgbGVhZi4NCiAgICA+ PiA8YWNlZT4NCiAgICA+PiBTbyB5b3UgYXJlIGFza2luZyBmb3IgYSBjaGFuZ2UgZnJvbSAibGVh ZiBtc2QiIHRvICJsZWFmIGxpbmstbXNkIj8NCiAgICA+DQogICAgPiA8dHA+DQogICAgPiBZZXMg SSB3b3VsZCBlc3BlY2lhbGx5IGdpdmVuIG5vZGUtbXNkLiAgSSB3aXNoIHRoYXQgWUFORyBHdWlk ZWxpbmVzIHNhaWQNCiAgICA+IG1vcmUgYWJvdXQgY29udGFpbmVyIG5hbWVzLiAgSSB0aGluayB0 aGF0IGhhdmluZyB0aGUgc2FtZSBpZGVudGlmaWVyIGZvcg0KICAgID4gY29udGFpbmVyLCBmb3Ig bGlzdCwgZm9yIGxlYWYgKHdoaWNoIEkgaGF2ZSBzZWVuIGluIGFub3RoZXIgSS1EKQ0KICAgID4g d2lsbCBsZWFkIHRvIG1pc3Rha2VzIHNvIGhhdmluZyBhIGNvbnZlbnRpb24gZm9yIGxpc3QgYW5k IGxlYWYgd2lsbA0KICAgID4gcmVkdWNlIG1pc3Rha2VzIGJ1dCBoYXZpbmcgYW5vdGhlciBmb3Ig Y29udGFpbmVyIHdvdWxkIGJlIGV2ZW4gYmV0dGVyLg0KICAgID4gVGhhdCBzYWlkLCBJIGhhdmUg eWV0IHRvIHRoaW5rIG9mIGEgZ29vZCBjb252ZW50aW9uDQogICAgPiBJbiBwYXNzaW5nLCBtdXN0 IGxpbmstbXNkIGJlID49IG5vZGUtbXNkPw0KICAgID4NCiAgICA+PiA8L2FjZWU+DQogICAgPj4N CiAgICA+Pg0KICAgID4+ICAgQW5kIHdobyBuZWVkcyB0aGUNCiAgICA+PiAgICAgIGNvbnRhaW5l cj8gIFRoaXMgaXMgbXBscyBub3QgYSBjb21tb24gbW9kdWxlIHRoYXQgbWlnaHQgYmUNCiAgICA+ PiBhdWdtZW50ZWQgc28NCiAgICA+PiAgICAgIHdoYXQgZG9lcyB0aGUgY29udGFpbmVyIGdpdmUg YXBhcnQgZnJvbSBjb21wbGV4aXR5Pw0KICAgID4+DQogICAgPj4gICAgICBsaXN0IHBvbGljeQ0K ICAgID4+ICAgICAgICBsZWFmIHN0cmluZw0KICAgID4+ICAgICAgWUFORyBzdHJpbmcgY2F0ZXJz IGZvciB2ZXJ5IGxhcmdlIGl0ZW1zIG9mIHZlcnkgY29tcGxleCBjaGFyYWN0ZXINCiAgICA+PiBz ZXRzLg0KICAgID4+ICAgICAgICBJcyB0aGF0IGRlc2lyYWJsZT8NCiAgICA+PiA8YWNlZT4NCiAg ICA+PiBJRVRGIG1vZGVscyBub3JtYWxseSBkbyBub3QgbGltaXQgaWRlbnRpZmllcnMuIEFuIGlu ZGl2aWR1YWwNCiAgICA+PiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBkbyB0aGlzIHdpdGggYSBkZXZp YXRpb24uDQogICAgPg0KICAgID4gPHRwPg0KICAgID4gSSBrbm93IC0gSSBkaWQgc2VlIGFuIEFE IGNoYWxsZW5nZSB0aGF0LCBJIHRoaW5rIGluIElFU0cgcmV2aWV3LCBub3QNCiAgICA+IGxvbmcg YWdvLiAgU01JIHdhcyBiZXR0ZXIgYXQgdGhpcyENCiAgICA+DQogICAgPiBUb20gUGV0Y2gNCiAg ICA+DQogICAgPj4gPC9hY2VlPg0KICAgID4+DQogICAgPj4gVGhhbmtzLA0KICAgID4+IEFjZWUN CiAgICA+Pg0KICAgID4+ICAgICAgbGVhZiB1c2VkDQogICAgPj4gICAgICB3aWxsIHVzZWQgcGx1 cyBmcmVlIGVxdWFsIHNpemU/DQogICAgPj4NCiAgICA+PiAgICAgIEluZGljYXRlcyBpZiB0aGUg YmluZGluZyBpcyAvaW5zdGFsL2luc3RhbGxlZC8NCiAgICA+Pg0KICAgID4+ICAgICAgbm90aWZp Y2F0aW9uLXNlZ21lbnQtcm91dGluZy1nbG9iYWwtc3JnYi1jb2xsaXNpb24NCiAgICA+PiAgICAg IGEgbWl4IG9mIGNvbmZsaWN0IGFuZCBjb2xsaXNpb247ICBjb25zaXN0ZW5jeSBpcyBnb29kIGFu ZCBJDQogICAgPj4gcHJlZmVyIHRoZQ0KICAgID4+ICAgICAgbGF0dGVyIHdoaWNoIGlzIHRoZSBu YW1lIG9mIHRoZSBub3RpZmljYXRpb24NCiAgICA+Pg0KICAgID4+ICAgICAgY29udGFpbmluZyAv cy9hLyBtYXBwaW5nDQogICAgPj4NCiAgICA+PiAgICAgIC4uLiBzaWQgY29sbGlzaW9uDQogICAg Pj4gICAgICBhZ2FpbiBjb25zaXN0ZW5jeSBnb29kLCBwcmVmZXIgY29sbGlzaW9uIHRvIGNvbmZs aWN0aW5nDQogICAgPj4NCiAgICA+PiAgICAgIHMuOQ0KICAgID4+ICAgICAgSSB3b3VsZCBoYXZl IHRob3VnaHQgdGhlIHNyZ2Igd29ydGh5IG9mIG1lbnRpb24gdW5kZXIgc2Vuc2l0aXZlDQogICAg Pj4gbm9kZXMNCiAgICA+Pg0KICAgID4+ICAgICAgVG9tIFBldGNoDQogICAgPj4NCiAgICA+Pg0K ICAgID4+ICAgICAgT24gMTYvMTEvMjAyMCAxOTozMiwgVGhlIElFU0cgd3JvdGU6DQogICAgPj4g ICAgICA+DQogICAgPj4gICAgICA+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJv bSB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nDQogICAgPj4gaW4gTmV0d29ya2luZw0KDQo= From nobody Fri Nov 27 10:03:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379A23A0B10; Fri, 27 Nov 2020 10:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Vado7kezbb80; Fri, 27 Nov 2020 10:03:40 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 11D2A3A0B0C; Fri, 27 Nov 2020 10:03:39 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id r18so6823527ljc.2; Fri, 27 Nov 2020 10:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIqJsXoNmuaMEriey6cBHw3NhcbmYxCZbjc3bOpdY1w=; b=p8+48Vov8ZVVl6RIMVewyDmi3whCDyLQy3CTiQAv3rFsJ4gf+J98kMuXk/RlgUyG7S eJK8Y4LxjJ53LefOzSvv+kmWMC2Jh9ziSO9g/fhDiGjnWWl1ZMkFIahzbD4TkbwQg6VH oAI0AmJZUd3C4llBdXEFv+spsBcGK7T7oioEhuwvwLGxnqjab/SWErN6UrLd3HFNNf+v 5zx0zz8fU/MDnNQfBL4mlevF9w8DN8Dlc1X+Hlo+SfVd8422JnhNDJ6GTo+5DBI1K0x5 AsH0wOScbx8PM4IBOy1Ofy+OMSAn6nNZpfNRsrFZrP5QaCDKXGzJ1UWr07IVKDxnG4CJ 0xyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TIqJsXoNmuaMEriey6cBHw3NhcbmYxCZbjc3bOpdY1w=; b=sY2auqoOC0tFANnDdbTAljHMw1DO/JrNiWxx7J1+N3rt3eElWwbxnSm81EkJ+zv6Tx Q5tEtPtwX5a3H14ELF/qI5AD4a/qDb1QmqxBXxt9XV5PgwHq0Fr+oVEsnl/p2GoIY0ad 8up3zVhftbm3enAlZJ/5lJe5sy5Koaidk6ik7Y2AX4YZHT6EXDnpTgCMkKxfdrX0gSEj F7qzGWvENur2mMCxyvUXOK00RyPHZNndRjbE+YsnUD+/964Z1sJDTl+Dfkpg4gpozxPF LjzKW7Uu4hRxqqjOMldMVG9rPrGb/9rDIML+1ZcBUJW+PaNOP2kH+ZOCcwO0VHwLlAjx XA3w== X-Gm-Message-State: AOAM5315LCLn8RVesvTJTOStU1G5vFhEyS5Zq7Uz6vxJpNz+kBaOhSg5 DduZx3ZM7crPcZH5lpXg19rGU4l4oq0CZZLsvw== X-Google-Smtp-Source: ABdhPJzKOXikol1FfO70NkHVVJb2G3RaMWiynMAsRAAQcPfws9c4xJxGlXcD2bSm91iELwH6KhZQk4f5SrBCeROcWMI= X-Received: by 2002:a05:651c:1b6:: with SMTP id c22mr4116377ljn.365.1606500217767; Fri, 27 Nov 2020 10:03:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Fri, 27 Nov 2020 13:03:26 -0500 Message-ID: To: James Guichard Cc: "spring@ietf.org" , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cfca8e05b51a7ae8" Archived-At: Subject: Re: [spring] WG Adoption Call Concluded for draft-li-spring-srv6-path-segment-07 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 18:03:42 -0000 --000000000000cfca8e05b51a7ae8 Content-Type: text/plain; charset="UTF-8" Hi WG, I am not aware of any IPR that applies to this draft. Thanks, Rakesh > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *James > Guichard > *Sent:* Tuesday, November 24, 2020 10:57 PM > *To:* spring@ietf.org > *Cc:* spring-chairs@ietf.org > *Subject:* [spring] WG Adoption Call Concluded for > draft-li-spring-srv6-path-segment-07 > > > > Dear WG: > > > > The 3-week WG adoption call for draft > https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has just > concluded and the chairs agree that enough support was received to approve > this adoption. > > > > Authors, please resubmit a new document as > draft-ietf-spring-srv6-path-segment-00. In addition, please indicate > whether you are aware of any IPR disclosures for this document. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000cfca8e05b51a7ae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi WG,
    I am not aware of any IPR that appli= es to this draft.
    Thanks,
    Rakesh

    =C2=A0

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Tuesday, November 24, 2020 10:57 PM
    To: spring@ietf= .org
    Cc: spri= ng-chairs@ietf.org
    Subject: [spring] WG Adoption Call Concluded for draft-li-spring-srv= 6-path-segment-07

    =C2=A0

    Dear WG:

    =C2=A0

    The 3-week WG adoption call for= draft https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07 has ju= st concluded and the chairs agree that enough support was received to appro= ve this adoption.

    =C2=A0

    Authors, please resubmit a new = document as draft-ietf-spring-srv6-path-segment-00. In addition, please ind= icate whether you are aware of any IPR disclosures for this document.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Joel & Bruno=

    =C2=A0

    =C2=A0

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

    Thank you Gyan and Gre= g for your review comments and discussions. Please see inline replies with = <RG2>=85

     

     

    From: Gyan Mishra <hay= abusagsm@gmail.com>
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.g= uichard@futurewei.com>, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>= ;, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.or= g <spring-chairs@ietf.org>, spring@ietf.org <spring@ietf.org> Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

     

    Hi Rakesh 

     

    I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>&nb= sp;

     

    Thanks 

     

    Gyan

     

    Hi Rakesh,

    thank you for the response to my comments. Plea= se find my follow-up notes in-lined below under the GIM>> tag.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

    Please see replies inline with <RG>=85<= /span>

     

    From: ippm <ippm-bounces@ietf.org&= gt;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

    Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,

    I've found myself in the situation when two related drafts are in = the WG APs in the SPRING and IPPM WG (with the possibility that expertise f= rom the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a sing= le thread. I hope that would be acceptable and considered by the SPRING WG = as well as IPPM WG.

    Usually, the bar for the adoption of a document can be evaluated&n= bsp;by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use the terminology from = RFC 4656 and 5357 and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Se= ssion-Sender and Reflector to Session-Reflector if it helps.

     

    GIM>> I believe that the consistency in termin= ology between the core RFC and what is intended as its extension is not onl= y helpful to a reader but, to the best of my understanding, is required for= IETF specifications. But I don't think that switching the terminology will fix the fundamental issue with the pro= posal. The operation that is required from the remote entity, whether it is= referred to as responder or Session-Reflector, is not defined in Appendix = I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior required, as described in the = draft, cannot be characterized as an extension of OWAMP, TWAMP, or TWAMP Li= ght but presents a completely new protocol that, if there's a need in the n= ew PM OAM protocol, must be properly defined.

     

       Gyan> I am in complete agreement wit= h Greg about terminology and consistency.  The problem with inconsiste= ncy is that that you are not following well known normative references requ= ired to understand the specification leading to confusion and misunderstanding of the specification.  The goal should be clear = and concise in terminology and verbiage.

     

    <RG2> Agree. Wil= l address the terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs tha= t use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congrue= nt Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you've m= entioned, I don't think that will address my concern. In reviewed documents= , "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be = used interchangeably? Do they refer to the same network object?<= /p>

    Now I'll try to illustrate my concern with using the= term "congruent path" in these drafts (using ASCII-art):

                  &nb= sp;        C---------D

                  &nb= sp;      /              &= nbsp;  \

                A----B&nbs= p;                  E-----F

                  &nb= sp;      \              &= nbsp;   /

                  &nb= sp;      G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if= they have the same shape and size, or if one has the same shape and size as the mirror image of the other", it looks a= s the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet of an a= ctive OAM intended to monitor a flow over the SR tunnel is out-of-band rela= tive to that flow and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts *-twamp-srpm, direct loss measurement can be performed, as informatio= n collected from node F and packets that collect the counters are not requi= red to be in-band with the monitored flow. So, this example, in my opinion, illustrates two of my concerns:

    =B7         using a congruent path for active performanc= e measurement, e.g., TWAMP or TWAMP Light, may produce information that doe= s not reflect the condition experienced by the monitored flow. It seems tha= t the terminology should reflect the fundamental requirement of ensuring that active OAM test packets are i= n-band with the monitored flow.

    =B7         there are no technical requirements to justi= fy using in-band test packets for direct packet loss measurement. In fact, = using the in-band method for collecting in-profile counters leads to a wast= e of bandwidth, which may have a negative impact on services that require low-latency and/or low packet los= s. As demonstrated in this example, direct packet loss can be performed usi= ng an out-of-band mechanism, e.g., SNMP queries, Netconf notifications base= d on YANG data model.

    • Does the document solve a real problem?

    No, it appears that these drafts define a new performance measurem= ent protocol for the purpose of combining OWAMP and TWAMP functionality and= adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical ar= guments for using a PM protocol instead of, for example, extending the exis= ting OAM mechanisms like ICMP.

     Gyan>  This may sound basic but is a very critical s= ubject going down the same lines of clarity in verbiage so their is no misu= nderstanding.  =93Congruent=94 by definition means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.  The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=92s the same path or congruent which is vagu= e as to =93exactly=94 which path is taken where here there is criticality a= s to the path being referenced in terms of in-band versus out-of-band.  I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

    <RG2> Ok, we will find an appr= opriate term for =93sending packets on the same path as data traffic=94.

    <RG2> Extending ICMP for direc= t-mode loss measurement is outside the scope of this draft. But good to see the agreement for the direct in band packet= loss measurement to be done (albeit by some other means).

    <RG> There is a requirement to measur= e performance delay as well as synthetic and direct-mode packet loss in seg= ment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the requirements you'v= e listed (though the SPRING WG OAM requirements= document has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OW= AMP/TWAMP for exclusive direct packet loss measurement.  

     

        Gyan> Agreed

     

    <RG2> There i= s definitely a need to do direct-mode loss measurement in IP/SR networks, a= s RFC 6374 mechanisms are for MPLS networks. Note that there was an attempt to extend BFD for direct-mode loss measurem= ent for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03).

     

     

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly the risk intr= oduced by the protocol on network security, to comprehensively evaluate the= proposed solution.

    <RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference suff= iciently explains why the use of zero UDP checksum in IPv6 header is not de= cremental, does not create a security risk for the protocol.

     

        Gyan> Agreed 0 UDP MIMA security th= reats and that you need to thorough vetting of RFC 6936.

     

    <RG2> Yes, will = add in the next revision. Hope we can work together on needed text.

     

     

     

    To summarize my review of these two drafts:

    • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

    <RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =93extensions=94 = for TWAMP Light.

    GIM>> I cannot find where RFC 5357 defines &qu= ot;the probe and response messages". Could you give a more specific re= ference or provide the text that, in your opinion, defines such messages? B= ut I'm more concerned with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to B= BF's TR-390, I'm have learned how different are existing implementatio= ns of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

     

        Gyan> I don=92t see the probe a d r= esponse messages in TWAMP RFC 5357

     

    <RG2> Agree to u= se term test-packet from RFC 5357.

    • several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, re= quire detailed security analysis, which is currently absent;

     

         Gyan> Agreed =

     

    <RG2> Please see= previous reply.

     

     

    <RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>  I've noted above that a simple ref= erence does not sufficiently explains why the use of zero UDP checksum in I= Pv6 header is not decremental, does not create a security risk for the prot= ocol. I believe that the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provid= ed in RFC 6936.

     

        Gyan> Completely Agree

     

    <RG2> Please see= previous reply.

     

    • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment qu=
oted as:
     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Light is not a s= tandard but its idea is

       described in the informational text only, I t= hink that the Informational

      track is more appropriate for this specification.= =94

    https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Lig= ht is an idea", not a protocol. If anyone is interested in standardizi= ng an "extension", I'd expect that they first define the base spe= cification to which the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you point to the definition, for example, of the Authenticated mode i= n TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? =

     

         Gyan> Agreed =

     

    <RG2> The Append= ix I of RFC 5357 does have information on the Authentication mode. As speci= fied there, this is based on user configured parameters.

     

     

    • I believe that draft-gandhi-spring-twamp-srpm should be anchored at IP= PM WG as it does introduce the new PM protocol.

        

     

    <RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

     

    Below, please find my detailed comments, questions on these d= rafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships between this draf= t and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light = has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of RFC 8545 (apologies for the long quote):

       "TWAMP Light" is an idea described in Appen= dix I ("TWAMP Light
       (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
       control protocol combined with the TWAMP-Test protocol.  = In
       [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
       TWAMP Light failed to meet the requirements for IETF protocols= (there
       are no specifications for negotiating this form of operation a= nd no
       specifications for mandatory-to-implement security features), = as
       described in Appendix A of this memo.  See also [LarsAD] = and
       [TimDISCUSS].

       Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
       use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
       is specified in this document).  Clearly, the TWAMP Light= idea
       envisions many components and communication capabilities beyon= d
       TWAMP-Test (implementing the security requirements, for exampl= e);
       otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

     

    Since we don't have an IETF document that addressed these open que= stions, I don't think we can have a draft that proposes extensions to a non= -standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.

     Gyan> Agreed 

    <RG2> The procedure for using = the RFC 5357 defined messages in TWAMP Light configuration mode is defined in the corresponding spring drafts. It also = describes the provisioning model.

     

    <RG> This was to address your previous comment qu=
oted as
     =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

       mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

       protocol itself. Since TWAMP Light is not a s= tandard but its idea is

       described in the informational text only, I t= hink that the Informational

       track is more appropriate for this specificat= ion.=94

    https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

    <RG> Having said that, we are = ok to change to PS as you mentioned above.

    <RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in draft-gandhi-spring-twamp-srpm def= inition of the Authenticated mode of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the discussion of &quo= t;extension" to TWAMP Light.

     

    <RG2> The Authentication infor= mation is user-configured as shown in Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357.

     

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

      The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provid= es
       simplified mechanisms for active performance measurement in Cu= stomer
       IP networks by provisioning UDP paths and eliminates the need = for
       control-channel signaling.

    I can not find where, either Appendix I or TR-390, "elim= inated the need for control-channel signaling". Also, could you point = where the referenced documents describe "provisioning UDP paths"?

     

    <RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

     
    

    =93This example eliminates the need=
 for the TWAMP-Control protocol, and
    

       assumes that the Session-Re=
flector is configured=94

    GIM>> I think that the text you're proposing i= s even more confusing. It is not clear which example the sentence is referr= ing to. Also, what is the basis for such an assumption? 

     

    <RG2> This is th= e exact text from RFC 5357 Appendix I. Please go through the entire Section= in that RFC 5357 to avoid =93out of context=94 discussion.

     

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

       The procedure uses the mechanisms defined in [RFC5357= ]
       (TWAMP Light) and its extensions for Performance Measurement.<= o:p>

    I think that the reference must be to Appendix I, not RFC 5357. Al= so, could you please specify which extensions of TWAMP Light have been used= in this draft?

    <RG> We can add the Appendix I as ref= erence in the next revision. Extensions are defined in draft-gandhi-ippm-tw= amp-srpm, we can add this reference.

    GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document. 

     

    <RG2> If approve= d, it is fine to have informational draft/RFC in a normative reference. But= RFC 5357 is PS.

    • In Section 2.3 describing the reference model is noted:

      •    The probe response message is typically sent to the s= ender node R1.

      In which scenarios the reflector acts differently? How such behavi= or is related to the behavior of a TWAMP Session-Reflector, as defined in R= FC 5357?

      <RG> Do you prefer we remove =93typic= ally=94 from the sentence?

    GIM>> If that fits into the operational model = of the new protocol you're defining. 

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both, please see Section = 4.1.3. =93Link=94 is well known term used in many existing RFCs (please see= RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn't= find a definition of an object "Link" (capitalized) but only &qu= ot;link" (lower case). Hence, since the draft consistently uses the ca= pitalized form, I consider it to be something else, something different from a link. 

     

    <RG2> Ok, we can= change Link to link in the next revision to avoid confusion.

    • In Section 3 behavior of the reflector described as

       ... no PM state for delay or loss measurement need to= be created on the
       reflector node R5.

    That is in contradiction to the behavior of a TWAMP Session-Reflec= tor as defined in RFC 5357. Could you provide a reference to an IETF standa= rd where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?

     Gyan> Valid point 

    <RG2> Bidirectional SR tunnel = may have an SR state but the statement above is that no PM (i.e. TWAMP Light) protocol session state is created for it.= We can clarify in the next revision.

     

    <RG> Quoting the text from Appendix I= in RFC 5357. We can quote the text as is.

    =93In the case of TWAMP Light, the Sessi=
on-Reflector does not necessarily have knowledge of the session state. =93<=
/span>

    GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way pac= ket loss measurement. If you require that the remote node does not maintain the state, the draft must define that as= part of the specifying the behavior of the protocol.

     

    <RG2> Ok, we can= discuss what information is to be maintained in that state on the reflecto= r for synthetic packet loss. We can add appropriate text if you can help please.

     

    • Further, in Section 3 the selection of UDP port explained as the following:=

       As specified in [RFC8545], the reflector
       supports the destination UDP port 862 for delay measurement pr= obe
       messages by default.  This UDP port however, is not used = for loss
       measurement probe messages.

    To the best of my understanding, as one of the contributors and&nb= sp;Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Ses= sion-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.<= /p>

     Gyan> Agreed 

    <RG2> Yes, we can use port 862= for both delay and synthetic packet loss =96 they are using the same test packet. There is no change proposed in the dr= aft.

    <RG> The packet loss in existi= ng RFC 5357 refers to synthetic loss as there is no support for direct-mode= loss in RFC 5357. We can change the text to clarify as =93This UDP port however, is not used for direct-mode loss meas= urement probe messages.=94

    GIM>> I've found that there's some misconcepti= on in the draft. RFC 8545 re-assigned UDP port 862 not for "delay meas= urement probe messages" but for TWAMP-Test protocol. TWAMP-Test protoc= ol, in turn, supports packet delay, packet loss, reordering (RFC 4737 defines packet reordering metric), and packet duplication measur= ement.

    • Then the draft states that

    The sender uses the UDP port number following the guidelines speci= fied in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can use when selecti= ng a UDP port number of a test session?

    Gyan> Good point  

    <RG> Please see section 6 in [RFC6335= ]. We can cite the range which will be the same as used in [RFC8762]. This = was also discussed earlier.

    https://mailarchive.ietf.org/arch/msg/i= ppm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I don'= t find anything specifically applicable to this draft we're discussing. If = the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., = Private or Ephemeral, then it seems that stating that explicitly would be the best way. 

     

    <RG2> This would be, User P=
orts and Dynamic Ports ranges, which are defined in [RFC6335]. Yes, we can add this text.

     

    • At the closing of the paragraph, we read that

      The number of UDP ports with PM functionality needs to be m= inimized due
       to limited hardware resources.

    Does a UDP port number pose PM functionality? How it is assigned t= o the port number?

    <RG> UDP ports are user config= ured for delay and direct-mode loss PM as described in Section 3.1.<= o:p>

    GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this= is the definition of a different from TWAMP Light PM OAM protocol.

     

    <RG2> If we add = a field in the packet then UDP port 862 may be used along with the new fiel= d. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficien= cy in hardware.

     

    • Following the above-quoted text, in Section 3 is noted:

      •    For Performance Measurement, probe query and response= messages are
         sent as following:

      Could you clarify if the listed further procedures deviate from OW= AMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session= -Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same p= rocedure as defined in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in draft-gandhi-ippm-twamp-srpm? 

     

    <RG2> Yes, unles= s otherwise specified in the draft-gandhi-ippm-twamp-srpm.

     

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

          the probe messages are sent on the
          congruent path of the data traffic by the sender node<= o:p>

    It is not clear what "the congruent path" means. The def= inition of congruency in geometry tells us that an object B is congrue= nt to object A if it has the same shape and size, but is allowed to flip, slide or turn. How a path can be congruent to another = path?

     

           Gyan> Agreed.  Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.

     

    <RG2> As replied= above.

     

    <RG> There are many existing R= FCs that use term Congruent Path (e.g. RFC 5921, 6669) without defining the= m. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate that a= "congruent path" may well lead to out-of-band path. Is that the = intention of the authors of the draft to use this protocol out-of-band?

     

    <RG2> As replied= above.

    • The last paragraph in Section 3 refers to work on iOAM:

      •    The In-Situ Operations, Administration, and Maintenan= ce (IOAM)
         mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
         SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
         information such as timestamp in-band as part of the data pack= ets,
         and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are the relations= hips between iOAM and draft-gandhi-spring-twamp-srpm?

      <RG> As mentioned in the draft, IOAM = is outside the scope.

    GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to draft-gandhi-spring-twamp-srpm? 

     

    <RG2> We can rem= ove them if it is confusing. It is informational text (was added to address= a review comment).

     

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?

    <RG> Yes, this can be Yang mod= el. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

    GIM>> I think that theremust be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in draft-gandhi-ippm-twamp= -srpm. But I couldn't find anything about the configuration of the protocol. 

     

    <RG2> The Yang m= odel extensions are not in the scope of this draft.

     

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Existing TWAMP messages d= o not support =93direct-mode=94 loss measurement. We can add =93direct-mode= =94 in the text to clarify.

    GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definit= ion of RFC 7799, passive measurement method and fetching counters can be done using numerous methods, e.g., SNMP, Netc= onf.

     

    <RG2> RFC 7799 d= oes not say using Test-packets to collect counters for direct-mod loss meas= urement is passive.

     

    • Section 4.1.1 requires that

      The Destination UDP port cannot be used as Source port, sin= ce
       the message does not have any indication to distinguish betwee= n the
       query and response message.

    Does that imply that the Destination UDP port used for the Delay m= easurement is unique throughout the particular domain?

     

           Gyan> Good question&nb= sp;

    <RG2> Yes, it is unique in the= domain.

    <RG> This is user-defined and = is up to the user what UDP port to provision in a domain.=

    GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers bein= g underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test packet i= n RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet= format to perform both delay and packet loss measurement.

    <RG> Ok, we can update the tex= t in the next revision to indicate exact name from the RFC 4656. We can als= o add text to include synthetic packet loss.

    GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=  

     

    <RG2> No, it doe= s not change anything for synthetic packet loss.

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?

    <RG> We can update the text in= the next revision to indicate query format name from RFC 5357.=

    GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

     

    <RG2> It is test= -packet, we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
    =93For symmetrical size query and respon=
se messages as defined in [RFC6038],=94

    GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us= nothing about that either (in part because RFC 6038 came later), I don't see that there's any certainty in what is th= e sze of a test packet used in the direct-loss measurement. 

     

    <RG2> The test-p= ackets as defined in these existing RFCs are used for delay and synthetic p= acket loss. The direct-mode test-packets are defined in this draft.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This is same as TWAMP. Th= ere is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm? 

     

    <RG2> No change = in existing in what is there in RFC 5357 and RFC 8186.

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hardware timestamps are r= ecommended for SR use-cases. We can change the sentence.<= /p>

    GIM>> Perhaps you can propose some text, that = would be helpful. 

     

    <RG2> Ack.<= /o:p>

    • Section 4.1.1.1 stated that

       A separate user-configured
       destination UDP port is used for the delay measurement in
       authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurrent authenticat= ed and unauthenticated test sessions using this protocol? Would different a= uthentication methods require using unique destination UDP port numbers?

    <RG> Yes, and Yes, and these a= re based on provisioning.

    GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

     

    <RG2> Some Sessi= on-Sender can use authenticated and some not. It is part of RFC 5357.<= /o:p>

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The direct-mode loss defi= nes new procedure for sender/reflector to collect traffic counters, as oppo= sed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's dire= ct-loss format does not have Error Estimate field, Thus, a reflected packet= does not have Sender's Error Estimate, nor Error Estimate of the reflector. And that, in my opinion, is another clear indic= ation that *twamp-srpm drafts define a new protocol, separate from OWAMP/TW= AMP.

     

    <RG2> That field= is specific to timestamps and would not apply to counters for direct-mode = loss measurement.

     

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:

       The local and remote IP
       addresses of the link are used as Source and Destination Addre= sses.
       They can also be IPv6 link local address as probe messages are= pre-
       routed.

      • What are the addresses of a link?

    <RG> I am assuming this well-k= nown (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pr= e-routed". What does it mean? 

     

    <RG2> Ensure tha= t packets are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am assuming this is wel= l-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel? 

     

    <RG2> As mention= ed this is for links.

     

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Absolutely do not agree. = It is no different than IP routed TWAMP packet as defined in [RFC5357].

    GIM>> You don't agree that the processing desc= ribed cannot happen because of laws of physics or it wouldn't happen becaus= e no one will think of that? If the latter, I think that that is security t= hreat.

     

    <RG2> There is n= o new threat like you have mentioned.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the&= nbsp;format of a probe query message. In figure two references to RFC 5357 = are provided - a section that references RFC 4656 OWAMP definition of the S= ession-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is= used for the delay measurement in the proposed protocol?

      • <RG> The probe query packet in= the Session-Sender text packet. We can update the name.<= /p>

      • Section 4.2.1 states that

         In one-way measurement mode, the probe response messa= ge as defined in
         Figure 6 is sent back out-of-band to the sender node ...<= /o:p>

      Could you clarify how the responder controls that the response pac= ket is sent not in-band but out-of-band?

      <RG> Please refer to section 3= .1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for ou= t-of-band.

    GIM>> draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to= reference behavior of TWAMP test packet? But the behavior of the TWAMP-Test protocol by itself is neither in-band, nor out-of-band. = It is the encapsulation of the TWAMP test packet that makes it either in-ba= nd or out-of-band. 

     

    <RG2> Right.

    GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mod= e?

     

    <RG2> Please see= the draft.

    • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

    <RG> This is as defined in Sec= tion 4.2 of RFC 5357 (Bullet 4).

    GIM>> I believe you've misunderstood the text = in RFC 5357. This bullet specifies the behavior of a Session-Reflector. It = is to try to read TTL value of the received TWAMP test packet and copy the = value in Sender TTL field of the reflected packet. If the Session-Reflector cannot access the TTL field, it MUST writ= e 255 in the Sender TTL field. So, I think that my questions still remains.=

     

    <RG2> Please see= Section 4.2.1 of RFC 5357.

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This is described in RFC = 6936. It will be very specific to the UDP port provisioned for TWAMP. We wi= ll add reference to RFC 6936 in Security Section.

    GIM>> I don't think that the reference is suff= icient for the Securit Consideration. I'd expect some extended discuss= ion on why using zero UDP header checksum is not a security threat for *twa= mp-srpm  protocol.

     

    <RG2> Please see= reply above.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be als= o reviewed by the BFD WG?

    <RG> TWAMP  probe message= s are used today for synthetic packet loss which can also be used to detect= connection loss (performance metric). The section simply highlights this obvious metric.

    GIM>> Can you point to a document that has def= ined "TWAMP  probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the loss of path continuity?

     

    <RG2> For exampl= e Y.1731 has such notion of connection loss. TWAMP is used widely for synth= etic packet loss and is well-known. There is no change in protocol. This is reported metric.

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Other than referring RFC = 6936 for zero checksum what else is missing? Otherwise it is no different t= han RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts. <= o:p>

     

    <RG2> There is n= o mention of Source IP address above.

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Measurement mode d= efined in this specification is to collect "in-profile" counters.= Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

     <RG2> Yes, they need to = be in-band with the flow, to collect the counter from the right forwarding paths for the flow. Discussion of using ICMP for= direct-mode loss measurement is outside the scope of this draft.

    <RG> As mentioned earlier, I a= m not sure extending ICMP to do PM is a good option here. Both TWAMP and OW= AMP are widely deployed today for delay and synthetic loss measurement.

    GIM>> What is the reason mentioning OWAMP? Are= drafts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as t= he connection between using active measurement methods to measure packet de= lay and packet loss, on one hand, and collecting packet counters?

     

    <RG2> The Sessio= n-Sender test-packet is defined in OWAMP RFC and not TWAMP RFC. Other than = timestamp and its format vs. counter and its format, the messages and processing are the same.

     

    Thanks,

    Rakesh

     

     

    • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP in Se= ction 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?
      • <= /ul>

      <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

      • Also, it appears that the Sequence Number field in TWAMP Session-Sender's t= est packet is absent in Figure 1. Is that intentional?

      <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

      Thanks,

      Rakesh

       

      Regards,

      Greg

       Thanks 

     

              Gyan 

     

    On Thu, Oct 22, 2020 at 5:51 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

    Dear WG:

     

    This message starts a 3 week WG adoption call= for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

     

    Some background:  

     

    Several review comments were received previou= sly for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

     

     

    These conclusions were discussed with the authors of  https://tools.ietf.org/html/draft-gandhi-s= pring-twamp-srpm-10 the result of which is the publication of the following two documents:

     

     

    After review of the SPRING document please indicate support (or no= t) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.=

     

    Finally, the chairs would like to thank the a= uthors for their efforts in this matter.

     

    Thanks!

     

    Jim, Bruno, & Joel

     

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

     

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

    --

    =

    Gyan Mishra=

    Network Solutions Architect&nb= sp;

    M 301 502-1347
    13101 Columbia Pike 
    Silver Spring, MD<= /p>

     

    --000000000000cfca8e05b51a7ae8-- From nobody Sat Nov 28 09:18:53 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791EF3A0BF1; Sat, 28 Nov 2020 09:18:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160658393242.11429.8902423075982205198@ietfa.amsl.com> Date: Sat, 28 Nov 2020 09:18:52 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-28.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 17:18:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-28.txt Pages : 40 Date : 2020-11-28 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-28 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-28 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 Sat Nov 28 09:22:28 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B13A091B for ; Sat, 28 Nov 2020 09:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=WtzWts8M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E0STe3/l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1WuDjrtkWxw for ; Sat, 28 Nov 2020 09:22:24 -0800 (PST) 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 4C70F3A0880 for ; Sat, 28 Nov 2020 09:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3178; q=dns/txt; s=iport; t=1606584144; x=1607793744; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wOs1ABfnhtLr8Szka3n6MA8Ej1ceOPJ9mM2xZhR6cMk=; b=WtzWts8M/e8LQrRIBinlXPIof0IVs/Qo4GuKaqL/a6lYYVn7yj0X8dtI Rbm/bLv6D/nmEH4CoUSuaVZbTMZ2xYXt49Mff1XQOB2RRErD2BIhXKc31 AK3A7DzpXFLoCZ6HjYJQcMbJxWtBtYGsGUh4/i4ZzPdjGij1UfujLG3KM E=; X-IPAS-Result: =?us-ascii?q?A0CNCwBZhsJffYwNJK1igQmDIVF8Wi8uCoQzg0kDjTKZL?= =?us-ascii?q?YJTA1QLAQEBDQEBGAsKAgQBAYQGRAIXghICJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAELhXMCBAEBEBERDAEBLAwPAgEIGgImAgICJQsVEAIEEyKDB?= =?us-ascii?q?AGCVQMuAQ6kDgKBPIhpdoEygwQBAQWBNwIOQUSCNxiCEAmBDiqCc4N2hlcbg?= =?us-ascii?q?gCBEScMEIJVPoJdAQECAQEVgUYXgwAzgiyTfKRyCoJwiReSFQMfgx2BK4hyl?= =?us-ascii?q?FqTZYsHlWgCBAIEBQIOAQEFgW0hgVlwFRohKgGCPglHFwINkhKFFIVEdDcCB?= =?us-ascii?q?gEJAQEDCXyNTwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AniKseRUnv82vbyZRN/IrIahM6e3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,377,1599523200"; d="scan'208";a="602702181" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Nov 2020 17:22:23 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ASHMN2o017837 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 28 Nov 2020 17:22:23 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 28 Nov 2020 11:22:23 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 28 Nov 2020 12:22:21 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 28 Nov 2020 11:22:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UvHyqs7SSeaKp+kccT99FugCxcIfP0NjbznjVCkQUTTWAXSDGi/Z/SBKV5kpWjHwEEZwRDFqPhA9mgH0X0+Fbgkg3GLtv7lZPeC3GS54jgv0s8gwbrjHyyKSyddQer7LKj7Bo7h4q+XAK37xQP++gNMmpVsvClDW/x9qu18l9RX6I3IMts0qDuMKfZghQTdglV7FoVIyyfhMII2Ed2agSeBvOuK2nhSuDrFqF78QuJLL6bpuHZ+1FXef0FNPquI1xy7zZDMHqA3IuSLy1A+hNil7c5BenH9rndf7V9bha8y57NtpatEHTcDtEOBFmj7R4ufqxVGDyGk3/5lkJmnDag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wOs1ABfnhtLr8Szka3n6MA8Ej1ceOPJ9mM2xZhR6cMk=; b=ENPrddzeJCdVWxfhha2YV0mCe/X006ZAXfRzn9e3Eo50c3GAOoQRHYzVJ8S2vzzSmn3rNdVNcvlY7BQyLe6erf2ZpTNM6y5Lm26SXh/W5JGSl5Hbb6L5FyLCihx8ueMrMU38wdCfQJBysFffvFHCtG0Bh3iiIcEU3hBYARz6FdXXI+9OjMsInm09YH70pzzEX20cifN1f+Zrbtzt/CMUsDbz4Nb2klX4lpZ1YiXh8Udnp9w1MH4QBKLzFgy3gf4rUujrtzC0VWwLkPV9VqwKHTP8EwJVJUAu82dThps7rSlCJ/Zs1dnl0cpTLjJFhOFx2PSYjK08xwzniPxJHHWy0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wOs1ABfnhtLr8Szka3n6MA8Ej1ceOPJ9mM2xZhR6cMk=; b=E0STe3/lAI4M5Eiv0NAI/JR8/Mi9wz2GxouqrJYc3J847kNIxd0rGKhzhO+DQYMmmDonIDR0YIi3E6RNf9t8xON7wpmNsGZTwaPsTxx2wTQ2NPl6hl4JAS77RMcMaF+IZXfz6inan7TLTNw43nsw4vidS7zGKG/BNQAO8FWk+PM= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB4895.namprd11.prod.outlook.com (2603:10b6:a03:2de::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Sat, 28 Nov 2020 17:22:20 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Sat, 28 Nov 2020 17:22:20 +0000 From: "Acee Lindem (acee)" To: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-sr-yang-28.txt Thread-Index: AQHWxaqdzs7HCucJQkyAhbA6g4L4wqndduQA Date: Sat, 28 Nov 2020 17:22:19 +0000 Message-ID: <45920C81-3075-401F-9634-035D4AC6961E@cisco.com> References: <160658393242.11429.8902423075982205198@ietfa.amsl.com> In-Reply-To: <160658393242.11429.8902423075982205198@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f41136a-adcf-418c-a793-08d893c22976 x-ms-traffictypediagnostic: SJ0PR11MB4895: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2ONkp6r56LrxfX8A7qFGYDKTgXhfO98LYAnSBZXDhqba6VM5eyYElAb7295MJZwRO4tACmQfnW2Z9MpD5gduIXuR4kUyuRxzb9NuTwWY/2bBBZRVZOsEKXbUVoDkcIaxtlCuL81H9KUkYnCEow/ROyJ2MYf/10f706RE8i8MB1o/ejPs0O3v9QX7PIfyA5VWvI0aB4rTeGmu/g4h6l54n8v+emIr0WL4Yhd2zI+WvfC0svKf/Lqlk8PhlAw/ukOAOcGsNxLd8D1ayOuRH14oBlu9S9ih0juyHl/5E21t0rWS1Hvtp/wqZdUJoSYsVB5Vdc0jlUcgrm21uA9QHv6s3AJPegXmsj6Or+wmHhqveiqqng/y8qe05nt6a9QT5ix9h1ITxZRBEta7t5iBx9vfaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(346002)(39860400002)(376002)(33656002)(66574015)(2616005)(26005)(6916009)(71200400001)(36756003)(8936002)(6506007)(186003)(2906002)(86362001)(6486002)(4001150100001)(6512007)(8676002)(316002)(64756008)(76116006)(66476007)(5660300002)(966005)(66556008)(478600001)(66446008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q0s1dm4yQVNUeTc5bHNWTG1EcjFGVWt2SE9pay9JcFVvWVpsWWNUWDdOWXRZ?= =?utf-8?B?enM5SWdiYWpwSzBnOWsxNFlacUFnQ0NIaGs3eXF0ZEFFQ1VqeG1QOTgzUGVP?= =?utf-8?B?VTJVcjJZTk9IUWZvN1ppaGFBU3d5dUw0a1BUVlZwLzV1VVl5NG1iK2VLa3ov?= =?utf-8?B?T3JwRUo4NXZ0RVJCekJpbXM2S3dMMnBxc2ZJakptdVA4MHpkK0wzNnB6MWRm?= =?utf-8?B?TWVZNklYczhYc1g2a2I5d3QzS3N4L21hT1lncGVYeTRnWUNBK2hZS3RKdnJM?= =?utf-8?B?RzhSTHBXaG5nMW1LY0kxR1Z3Wnhsc3lPLys1L1FMa3Naankwd2pkbmllRGNG?= =?utf-8?B?YUxkbG5LWm9PNVJLVWVaMGZRYUtIWUxRNWFhOU5pU3VrU25tT0FJOWhXWUo3?= =?utf-8?B?emJJRjNET3hhQ0ltRmJNQ2lxbmtpczVEbmNUeHFQZExyNEViU2NTalpVL3Nu?= =?utf-8?B?S0ZDbzVxb2txRjdJRU1wTFhzR0tIU3JxcEdEL0h3NVQ4VUNZemxOVXhVMGxo?= =?utf-8?B?ay9KR0Qxb1dVOUw1QmZrMHRjQnU4YWRSdkR6SVFzQzhBM2hWeUNHU0VUR3ph?= =?utf-8?B?U2U4QlkvNG5Vb3VNajZJRHVvWTJRQXg3WGExWHNVdDZqR21ySTQ3S0gvWm5L?= =?utf-8?B?SThDaDc5T2xpZDk5Y3RNMkdTTDgrajc1VlhKV05Fc08vRHRqNlhDdnh1WU8w?= =?utf-8?B?Wks0L0xtMHlvUkVmbXFJbXJQZitGaEZReW9FMXU4MXhTeHhPZDIyeGdRSStG?= =?utf-8?B?TlgySW10SDhoUWthcTBQeHdhbDFwQTVWYm5aTzU0bDhtYzhCUEhjU1JrMHZY?= =?utf-8?B?bEpqQ1BTdTlFdnVjSExpejBBTmhySnQ3UWxKVGZIVVNmQkk5Uy9CQ2VlaXJO?= =?utf-8?B?b1VlTjJFZldUVGFpRHVtZ1ZiMitOYyt4bGtxWlltSFJPTE9wbkpGbkxRQmpK?= =?utf-8?B?bUZLQnluNVBjOURYRmloVGwreFpsRGU1YVFQZ05PM3paUEtTZHJjWlZNNTc3?= =?utf-8?B?c2RUcU50S013d2cxN3dpR3RjOUxvRFlWUU5GaHh6M3pVVnc4T0VZbGlNQ0lX?= =?utf-8?B?U1pEQk8yV3cxVTFITDg0bFp3V0ZhQlcrcWp3RHdBMWZQZEpBRit4bzFoQ3Iy?= =?utf-8?B?NkxBZWYyWDA3S3NNOG5ZaXhyempBZzFBc3hZTGR6MlgwblVITnhhTENLY3JX?= =?utf-8?B?Y0xHVFErd0dwVW80R290dGhwaDNBaHNGakZqeEV0WW0wWG4zbjVrT292NlVK?= =?utf-8?B?eThmTkN1K0JiZVZuVGcxanczdXpMRG1Lc2oyMUkyRUc4RVJhUHM3TmV4VzF4?= =?utf-8?Q?Du9v3450Kk+crglSSo/oRnWdUsIjyeqz2b?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <35EA1F1D18692347ADC1B812F9E8D37B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f41136a-adcf-418c-a793-08d893c22976 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2020 17:22:20.0166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YVcVkYCOKxskzt/UIt2D3uXz+TMzIV01/eyceR1L8ytZQirGnpIKdpPBEC7pSl3l X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4895 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-yang-28.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 17:22:26 -0000 QWZ0ZXIgc29tZSBkaXNjdXNzaW9uIHdpdGggU3RlcGhhbmUsIHdlIGRlY2lkZWQgdGhlIE1heGlt dW0gU2VnbWVudCBEZXB0aCAoTVNEKSBpcyBhIHByb3BlcnR5IG9mIHRoZSB1bmRlcmx5aW5nIGhh cmR3YXJlIGFuZCBzaG91bGQgbm90IGJlIGNvbmZpZ3VyYWJsZS4gUGxlYXNlIGNvbW1lbnQgb24g dGhpcyBjaGFuZ2UuIFRoYXQgaXMgdGhlIG9ubHkgY2hhbmdlIGluIHRoZSAtMjggdmVyc2lvbi4g DQpUaGFua3MsDQpBY2VlDQoNCu+7v09uIDExLzI4LzIwLCAxMjoxOSBQTSwgInNwcmluZyBvbiBi ZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KICAg IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyBXRyBvZiB0aGUgSUVURi4N Cg0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBTZWdt ZW50IFJvdXRpbmcNCiAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFN0ZXBoYW5lIExpdGtv d3NraQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFjZWUgTGluZGVtDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQdXNocGFzaXMgU2Fya2FyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK ZWZmIFRhbnRzdXJhDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc3ByaW5nLXNy LXlhbmctMjgudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDQwDQogICAgCURhdGUgICAgICAg ICAgICA6IDIwMjAtMTEtMjgNCg0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3Igc2VnbWVudCByb3V0aW5nDQogICAgICAgY29u ZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uLCB3aGljaCBpcyB0byBiZSBhdWdtZW50ZWQgYnkgZGlm ZmVyZW50DQogICAgICAgc2VnbWVudCByb3V0aW5nIGRhdGEgcGxhbmVzLiAgVGhlIGRvY3VtZW50 IGFsc28gZGVmaW5lcyBhIFlBTkcgbW9kZWwNCiAgICAgICB0aGF0IGlzIGludGVuZGVkIHRvIGJl IHVzZWQgb24gbmV0d29yayBlbGVtZW50cyB0byBjb25maWd1cmUgb3INCiAgICAgICBvcGVyYXRl IHNlZ21lbnQgcm91dGluZyBNUExTIGRhdGEgcGxhbmUsIGFzIHdlbGwgYXMgc29tZSBnZW5lcmlj DQogICAgICAgY29udGFpbmVycyB0byBiZSByZXVzZWQgYnkgSUdQIHByb3RvY29sIG1vZHVsZXMg dG8gc3VwcG9ydCBzZWdtZW50DQogICAgICAgcm91dGluZy4NCg0KDQogICAgVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy8NCg0KICAgIFRo ZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy0yOA0KICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc3It eWFuZy0yOA0KDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXNwcmluZy1zci15YW5nLTI4DQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN Cg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgIHNwcmluZ0BpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== From nobody Mon Nov 30 02:47:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097613A03FC; Mon, 30 Nov 2020 02:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 7nVnKH5KMoYf; Mon, 30 Nov 2020 02:47:18 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10137.outbound.protection.outlook.com [40.107.1.137]) (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 D45B83A033F; Mon, 30 Nov 2020 02:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WHwaZaS+z/yIxMxr3g58FE9X9mFT0mc9BzrxQ6ItmJKqKRGIuYZrO+ACf1qs4H4q34mCOq6IUiM5SnSozkZ4X+1EQvwYr83Eh3LXCIXqTbZT5/D8/7rIKoI6UkdaI3o1lhh+zNq4SsLDfKIJhb/L8SGYeFVefRATpSucFC34ML2P+J/JiedJl9l6RZAqgG8f5hQd4kKah/+QQDgXWNGwzeGN/2pNxJuKJAEr/eM+7tSrGQVogR04Es/SW3kXM7LUnEE3YcV63wvexlc1wOQ9l08fdm8Iu/pFO5kujS5pK+RpOxhTtcrhMt38pmAqg0RYbWWSuB2ndiR9ZhHpZblm+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HUQFHx/Tyq2Fi6GWCqmNAVw4cb18+li8Ve7/6R3ApUE=; b=DlYL+AMOccIH3FQ6NGVw3UsPeeigq1LTL2PInr20dYDOyPzTVFnu62+EKrrFtO8n1vF22+NW6O4V1D3CQQe1x5dFEphV59kxcUpexpnrE9t1CDUZxtXc//I2j8ICR1cFIaapiCKueEwz2jb53++LJtFrt797O0edKYHyyeQQKlB01yPy6F/m8MPfcfEXZJlvlFa4l0vHeIHI9A0mXI88yV0YPiz/iMeQmI6s1U9mqG+1qK/2yY0JS/yLP+N1mLT4uJvNigK+J/pMyvNprdZZUoSsDG6AJ26oT0oe8u769qPx0jXdPX/whJoBgj3UVH4ajgT8G5l7N1pwbhwFhPxsmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HUQFHx/Tyq2Fi6GWCqmNAVw4cb18+li8Ve7/6R3ApUE=; b=oi1lhYMF0AGpvylaNFHaeNi3OFcjPTk2yhZHsEZkba5uYQu+QGBpVAVahnCbdSkrDw3RW2nWhpGk9GHSjjiADer9hxucbteZa9A+ndKhSPONZcZiLdl8froA4CgCmJmXPpuen7yCj3VQbimHQKm/G+OByTdxynRXaIVGihsDH0c= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6669.eurprd07.prod.outlook.com (2603:10a6:800:185::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Mon, 30 Nov 2020 10:47:10 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3632.016; Mon, 30 Nov 2020 10:47:10 +0000 To: "Acee Lindem (acee)" , "last-call@ietf.org" References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <5FBCD392.3050706@btconnect.com> <5FBF86B2.7020907@btconnect.com> <2E1DE08B-47AA-4D29-8ACD-30335BDFFCFE@cisco.com> Cc: "spring-chairs@ietf.org" , "spring@ietf.org" , Joel Halpern , "draft-ietf-spring-sr-yang@ietf.org" From: tom petch Message-ID: <5FC4CDA8.2030803@btconnect.com> Date: Mon, 30 Nov 2020 10:47:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <2E1DE08B-47AA-4D29-8ACD-30335BDFFCFE@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LNXP265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::31) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LNXP265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3611.20 via Frontend Transport; Mon, 30 Nov 2020 10:47:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dab2bb70-6cda-4c0b-67d6-08d8951d4a09 X-MS-TrafficTypeDiagnostic: VI1PR07MB6669: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1227; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xeeEmky50uNeKp99ojyM2bpfAiOHeC+gZOhNBmxVJ2JBaSvSFneT4LxmC6e3bPGn7Rtacm10h/InbIExJ4rDjkzVDxkCc5iUikzeEAeg7NPkCK+3Gx/8y8SEnyM7xb8JfMhHJWpt9ucbE6zT2rSH4J9NjyEg5rXtCaSYFmP8sKRIu3eqzLsPVrso4KGXRAA6Kot32lISqoJrpeINe8GgBcpdSpu7oPDhjCLUu1DIVHkPaTUUB2TRUVt5BHzutApm1JfN9sWNmX2Q+bdI0R2T6h8ErQMMLM6CmOqNCmn8HpxZKmpyTBp8/g2xnZmniOyTfglS8xDG0E8GpVT/CiNzDA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(346002)(396003)(366004)(52116002)(4326008)(86362001)(6666004)(26005)(66946007)(33656002)(66476007)(66556008)(8936002)(110136005)(5660300002)(8676002)(66574015)(16526019)(36756003)(83380400001)(53546011)(478600001)(6486002)(186003)(956004)(2616005)(316002)(16576012)(2906002)(54906003)(87266011); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?d0lhQmYvVnpENCtTMCtLaWFFNkVzMUNLK2Q1dGwraDFjTFdFZ25PQ1RTYk1o?= =?utf-8?B?R0QrdldpMW9qakZMbVpQbC9hc0duNjliRy9RbXZ3TnBWMUlZMG5ramV0RFVw?= =?utf-8?B?OU9mYW5JakhMWFdSd1pMdExzMU1wcXZxQjM3QzNGTFV5NHJKQzhUeEZ0cHhN?= =?utf-8?B?UjloZzVVZ3RzdWhUaUpiekFUQW9VL212U1FpTWx2cnFQTENiSjVGOG1LTE01?= =?utf-8?B?YnJzTnBSNU9qVzJxZWZFL2FyeSthdDg3L201dmpOQWFScUw4RHVMV3N1RTYw?= =?utf-8?B?bDcxR0t0Rkt0TkxFVTFUNFUxZFFQNm5pS2hqQysweDMwYmtDMzdJK3hFOTUx?= =?utf-8?B?bkF3aFRpeEs2R2tKdlpUNDVpZmYyZHpFMThDL3lKU1Y0Uzd6OXd2aytFVDI2?= =?utf-8?B?OGVyRVZiblpLRGx1MTR5VjBTZm1Mc2luUlk5NC9vYU1yUVB3dkJCQ0ZxYmdK?= =?utf-8?B?eG1xc3dDanhCSFdYeXlVendaeW82dlBha2hwRVhhYkM5WUlIcVVJbmovQU42?= =?utf-8?B?MHhjci9UVkxtbVNyVnlrNEpVSkxINE5TZWYwQ00xbHV0NEJpby94b3Uyc3Va?= =?utf-8?B?VXR1ZnZwaHI3anRHeEppSTlPOW1NbkVhT0FIMXN6UWZPc0J6WDlaVnE4dDRs?= =?utf-8?B?TDROZ2xLNDI1QWJ2d25wTmJEQWQyNjNOOE0wS1B2aEZ3clpjOEEvQkt4OG52?= =?utf-8?B?NXpSY0lqSTF5UVNiSXpSUHdoc29OUEVVajYyTmtGcXczblphOGhZL2hKYUNj?= =?utf-8?B?NmVsZVJYcXhKMC9QVUxXTjE5YlVsdW96VS96S2daeUp1dXZvSjQwNU5IUUZa?= =?utf-8?B?bDVJcXNSNy9MRXpVNG5aMDdQclZISWRTYWRIZE9SSGRJb1I1YmRIUTRjZERX?= =?utf-8?B?UDJPeTdaWFE5M1Q1RFI1SHNqZGs4MFJwVkVSNXRyVFQxd3B0L203N2VjdXNu?= =?utf-8?B?NElIVU5sSzZGL0E1Vk5ETHkwMDUvTE9ua1JnRk43bVZGZGJSaTNsSEhVRTJy?= =?utf-8?B?d0JjbDlDdE1sSnplQ0FmZ1FIT0ZWUnlrUXpWcjZBaWEzKzhQZmtuR3gyUENm?= =?utf-8?B?Y2U2bUxNNzVWeUV4NHhNQjN4M2V0RGN2aWQwTU5JRzdBSzJVMHBBYjFsNytp?= =?utf-8?B?RExla2dsTE5JTWRGU29FcXBlcFNoNmkwOVB6eno0WkxIaW96RDM1SC81VnNL?= =?utf-8?B?RlBaY1VwWUZlT3FVVjdoZ0lLNFpYK09SL3k1dno1Ykp2ekdGVHZ6bEpwK0Ro?= =?utf-8?B?SjRLZG10T25jVEpkT245UTBZeUpyVHAxaUZEd2tJNWxTeGZkVHovU2FZN1h3?= =?utf-8?Q?4LSLQtXMlLDbZChyggfPR+kr1pOHzmDKBP?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2020 10:47:10.0461 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-Network-Message-Id: dab2bb70-6cda-4c0b-67d6-08d8951d4a09 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AEylMdomS96TgXP0SyO/jqb0nIz6zinbBNpVoSb3H9sQbCdDXzdj0RrN9XjMroPw70wp5DCPPPA65fMQgAzplw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6669 Archived-At: Subject: Re: [spring] Last Call: (YANG Data Model for Segment Routing) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 10:47:20 -0000 On 27/11/2020 14:35, Acee Lindem (acee) wrote: > Hi Tom > Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:". Acee I was too slow to see -27 but have looked at -28:-) Yes I like the references to BGP. I do sense a reluctance to reference I-D from other WG with the potential delays that can cause so that e.g. 'weight' could reference an IDR I-D alongside the LSR ones but I am not too fussed about that. I do see a 'deptt' that might be 'depth' in a BGP reference to RFC 8814. I think that s.3 needs updating. I have done my homework and see the split in the YANG modules that came in with -15. I think that s.3 describes the old segment-routing when it had some data in it which it no longer has. The description clause in segment-routing also probably overstates the case for what it now is, just an anchor waiting to be augmented. I note that Table 1 omits the prefix defined in this I-D which I can live with. Tom Petch > Thanks, > Acee > > On 11/26/20, 5:43 AM, "tom petch" wrote: > > I have looked at -26 and it looks good apart from BGP. > > BGP gets a mention in passing but does not get the same treatment as the > protocols of the LSR WG. I am unclear whether or not this I-D is > intended to include networks using BGP or not with e.g. signalling of > MSD and would value a clarification in the I-D. > > I wonder about the final D in > Maximum SID Depth (MSD)D > in the YANG; I suspect that it is spurious. > > Tom Petch > > On 24/11/2020 09:34, tom petch wrote: >> On 23/11/2020 17:27, Acee Lindem (acee) wrote: >>> Hi Tom, >>> >>> See a couple responses inline enclosed in and . We are >>> addressing the rest of your comments. >>> >>> On 11/18/20, 7:39 AM, "tom petch" wrote: >>> >>> IANA Considerations does not register the module names used in >>> the modules >>> >>> >>> This is in the IANA considerations... >> >> >> Indeed; I do not see a registration of ietf-segment-routing-mpls! >> >>> This document registers a YANG module in the YANG Module Names >>> registry [RFC6020]. >>> >>> name: ietf-segment-routing-common >>> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common >>> prefix: sr-cmn >>> reference: RFC XXXX >>> >>> name: ietf-segment-routing >>> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing >>> prefix: sr >>> reference: RFC XXXX >>> >>> name: ietf-segment-routing >>> namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls >>> prefix: sr-mpls >>> reference: RFC XXXX >>> >>> >>> Examples are IPv4 only, IPv6 would be good >>> >>> BGP is included when it comes to defining a router-id but is ignored >>> everywhere else, such as signalling MSD, protocol extensions etc >>> >>> reference "RFC XXXX" would be improved by including the title in all >>> cases not just some >>> >>> the scheme http: appears in many places. It would be lovely if this >>> really was the scheme but I fear that it is not >>> >>> This is directly from the RFC 8407 template in Appendix B. What would >>> you suggest? >> >> >> Many I-D do now specify https: since that is now the only option >> supported by the IETF; I have seen this called for by an AD. >> >> >>> >>> >>> module srcmn >>> the upper bound must be larger >>> the value must be greater >>> consistency is good - I think greater is better >>> >>> 8.3 >>> operation states >>> usually operational >>> >>> two imports lack references >>> >>> typedef router-id >>> this is a well known type from RFC8394; it seems likely to >>> confuse to >>> redefine it with a related but different meaning >>> >>> leaf enabled >>> enables protocol extensions >>> which protocols? >>> >>> leaf protected >>> it is used to protect >>> how does it do that:-) >>> >>> enum dual >>> ... In this case will be advertised with backup flag set >>> What is the backup flag? It does not feature in RFC8660. Needs an >>> explanation and reference >>> >>> container link-msd >>> list link-msds >>> leaf msd >>> The usual YANG convention is for a list to be plural and the leaf >>> singular. You have the plural list but not the leaf. >>> >>> So you are asking for a change from "leaf msd" to "leaf link-msd"? >> >> >> Yes I would especially given node-msd. I wish that YANG Guidelines said >> more about container names. I think that having the same identifier for >> container, for list, for leaf (which I have seen in another I-D) >> will lead to mistakes so having a convention for list and leaf will >> reduce mistakes but having another for container would be even better. >> That said, I have yet to think of a good convention >> In passing, must link-msd be >= node-msd? >> >>> >>> >>> >>> And who needs the >>> container? This is mpls not a common module that might be >>> augmented so >>> what does the container give apart from complexity? >>> >>> list policy >>> leaf string >>> YANG string caters for very large items of very complex character >>> sets. >>> Is that desirable? >>> >>> IETF models normally do not limit identifiers. An individual >>> implementation could do this with a deviation. >> >> >> I know - I did see an AD challenge that, I think in IESG review, not >> long ago. SMI was better at this! >> >> Tom Petch >> >>> >>> >>> Thanks, >>> Acee >>> >>> leaf used >>> will used plus free equal size? >>> >>> Indicates if the binding is /instal/installed/ >>> >>> notification-segment-routing-global-srgb-collision >>> a mix of conflict and collision; consistency is good and I >>> prefer the >>> latter which is the name of the notification >>> >>> containing /s/a/ mapping >>> >>> ... sid collision >>> again consistency good, prefer collision to conflicting >>> >>> s.9 >>> I would have thought the srgb worthy of mention under sensitive >>> nodes >>> >>> Tom Petch >>> >>> >>> On 16/11/2020 19:32, The IESG wrote: >>>> >>>> The IESG has received a request from the Source Packet Routing >>> in Networking > From nobody Mon Nov 30 08:30:20 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957073A0E31; Mon, 30 Nov 2020 08:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 5uGpuxh-vm0q; Mon, 30 Nov 2020 08:30:07 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4FD473A0E24; Mon, 30 Nov 2020 08:30:06 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 142so18810268ljj.10; Mon, 30 Nov 2020 08:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4SdX+rqgQnpvAw8tP+WfjPTKrBzo+zhTSlLLmInIxCQ=; b=r3NhpmeRGkVzzeoJvLL07BX8xClFk8TE3Lg+Oc+rQw/Ig9/+5ddEfe0Owtqn51NtUV FFE4DiI4gaqXKatJJX5s/p13Ges2RL1cOhkcAqR8nFbPYyC+mumU495E+YwJFJpcGY8x duyxC9KXwPfA+HN98GyWDESBc+B+PzLlqkHwdsT963guKkCCGS3G8c0IAIjUkORsORa7 jxk94r7b0aIKH+i4hrsOsewG4W6eh/zGVWPThym6xd/yyjcq/huyLucluIk3dq4Y+Git TEfpm3aseRwq9p+2XqSVLcj4IOKP9CZfS1Ic9vAUWIisXkngI5hYbrYcNlfCqbyPdF90 ioug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SdX+rqgQnpvAw8tP+WfjPTKrBzo+zhTSlLLmInIxCQ=; b=QcX97groi+Bg6ypWI08B8DFH55V/9nj79N+jNWdZ67yVHfTTBy4DcxhLoEYr4rTFQJ 75+wayIwEMYQCXWPqnJLkfa+L1CNwMRDZ1LYoS9L1Rz3WySL+Pvis2GaY02zD6Wisk45 V2YOA6bVUL7maSlCu9PoIgZvFtZLTzm856fkqA2Y+89mRaXC4s+IsjyLPfbziqUNdL8+ 8lawa43kMU5fd21qqjK9GUDB7Ko8uqaOWPt4TK+LmAm8fVv1995pwW3k4w6zMTvyyM3S BeR6OMKY0GzMwpyfauBES/eXbHQwp+svvovU6pFRSv3WhxDS9iftyPL/6fcmMfWoB4ee G/hw== X-Gm-Message-State: AOAM5338U/I+Tso4aih9xD3WsDI+xHhjKH8Fu91sARMnn9qNAXP6UrKR LMpapPGGPw2D43tgTUTNcNIMyNhdYdNA5oekpd4= X-Google-Smtp-Source: ABdhPJxI+sjgfHLAMWZXrGAW7aNpmQc8AWa5TMEVCwCwUBpiAxHxBvkI4/nq9vnD4TbZ8y2blYaaK1ZYUHzvGcronTE= X-Received: by 2002:a2e:9694:: with SMTP id q20mr10300770lji.279.1606753804082; Mon, 30 Nov 2020 08:30:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 30 Nov 2020 08:29:51 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Gyan Mishra , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Greg Mirsky Content-Type: multipart/alternative; boundary="000000000000bbe3f005b55585a4" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 16:30:14 -0000 --000000000000bbe3f005b55585a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for the continued discussion. I appreciate your responses. I am still not convinced of the value these documents add. Please find my follow-up notes in-line below under the GIM2>> tag. Regards, Greg On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) wrote: > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with =E2=80=A6 > > > > > > *From: *Gyan Mishra > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky > *Cc: *IETF IPPM WG , James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > > > Hi Rakesh > > > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > > > Thanks > > > > Gyan > > > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > > > Agree. Will address the terms from RFC 5357 in the next revision. > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > =C2=B7 using a congruent path for active performance measurement, > e.g., TWAMP or TWAMP Light, may produce information that does not reflect > the condition experienced by the monitored flow. It seems that the > terminology should reflect the fundamental requirement of ensuring that > active OAM test packets are in-band with the monitored flow. > > =C2=B7 there are no technical requirements to justify using in-ba= nd > test packets for direct packet loss measurement. In fact, using the in-ba= nd > method for collecting in-profile counters leads to a waste of bandwidth, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet lo= ss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > Gyan> This may sound basic but is a very critical subject going down th= e > same lines of clarity in verbiage so their is no misunderstanding. > =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and i= f you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it=E2=80=99s the same path or congruent whi= ch is > vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality > as to the path being referenced in terms of in-band versus out-of-band. = I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > Ok, we will find an appropriate term for =E2=80=9Csending packets o= n the > same path as data traffic=E2=80=9D. > > Extending ICMP for direct-mode loss measurement is outside the scop= e > of this draft. But good to see the agreement for the direct in band packe= t > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use cas= e these four documents try to solve. I don't recall that I've stated that "direct in-band packet loss measurement" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any valid technical reason to re-open this and measure the direct packet loss in a slightly different way. I must point out that a claim that using fixed positions for the direct packet loss optimizes performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is clear that the proposed new method of direct packet loss measurement does not offer any significant benefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous. > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > > > > Gyan> Agreed > > > > There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of the proposal continues and the new version will be published soon. > > > > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > > > Gyan> Agreed 0 UDP MIMA security threats and that you need to thoroug= h > vetting of RFC 6936. > > > > Yes, will add in the next revision. Hope we can work together on > needed text. > > > > > > > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > > > > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RF= C 5357 > > > > Agree to use term test-packet from RFC 5357. > > > - several parts of the proposed protocol, e.g., Zero UDP checksum in > IPv6, require detailed security analysis, which is currently absent; > > > > Gyan> Agreed > > > > Please see previous reply. > > > > > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > > > Gyan> Completely Agree > > > > Please see previous reply. > > > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. Co= uld > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > > > Gyan> Agreed > > > > The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > > > > > - I believe that draft-gandhi-spring-twamp-srpm should be anchored at > IPPM WG as it does introduce the new PM protocol. > > > > > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > > > Since we don't have an IETF document that addressed these open questions, > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > The procedure for using the RFC 5357 defined messages in TWAMP Ligh= t > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same method of controlling a test session cannot be used for STAMP? > > > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > > > The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described = in > Appendix I of RFC 5357. > > > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > > > This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. > > > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > > > > If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > > > > Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > Gyan> Valid point > > Bidirectional SR tunnel may have an SR state but the statement abov= e > is that no PM (i.e. TWAMP Light) protocol session state is created for it= . > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one option. I am well-familiar with the implementation that uses the stateful mode. > > > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > > > > Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang > > > > - Further, in Section 3 the selection of UDP port explained as the > following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already supported in RFC 8762. Are you proposing a new protocol to duplicate the STAMP functionalities? > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode loss > measurement probe messages.=E2=80=9D > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > Gyan> Good point > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > > > > This would be, User Ports and Dynamic Ports ranges, which are defin= ed in [RFC6335 ]. Yes, we can add this= text. > > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > > > > If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It = is > better to use a different UDP port for processing efficiency in hardware. > > > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > > > Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm= . > > > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > > > As replied above. > > > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > > > As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > > > We can remove them if it is confusing. It is informational text (wa= s > added to address a review comment). > > > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > > > > The Yang model extensions are not in the scope of this draft. > > > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf. > > > > RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic of an active measurement method. Using out-of-band transport, e.g., SNMP queries, would be an example of a passive measurement method. > > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > > > Gyan> Good question > > Yes, it is unique in the domain. > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > > > > No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > > > It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > > > The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet loss measurement. For STAMP such a mechanism is clearly superfluous given the Direct Measurement TLV is already defined. > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > > > No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > > > Ack. > > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > > > Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > > > That field is specific to timestamps and would not apply to counter= s > for direct-mode loss measurement. > > > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > > > Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > > > As mentioned this is for links. > > > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > > > > There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected by HMAC as presented in figures 3 and 5. > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > > > > Right. > > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > > GIM>> So, you believe that proposing to use the method described in RFC > 8403 for the TWAMP packet is innovation? And what are the benefits of usi= ng > the TWAMP test packet format in the Loopback mode? > > > > Please see the draft. > > > - What is the rationale for setting TTL/Hop Limit fields always to 255 > for IPv4, MPLS, and IPv6 (per Section 4.3.1)? > > This is as defined in Section 4.2 of RFC 5357 (Bullet 4). > > GIM>> I believe you've misunderstood the text in RFC 5357. This bullet > specifies the behavior of a Session-Reflector. It is to try to read TTL > value of the received TWAMP test packet and copy the value in Sender TTL > field of the reflected packet. If the Session-Reflector cannot access the > TTL field, it MUST write 255 in the Sender TTL field. So, I think that my > questions still remains. > > > > Please see Section 4.2.1 of RFC 5357. > > > - Section 4.3.3 states that a zero-value UDP checksum may be used in > some scenarios. RFC 8085 allows that but in very specific cases that a= re > documented in detail in Section 3.4.1. Do you believe that the case of= this > protocol checks all the requirements for allowing the use of Zero UDP > checksum as specified in RFC 8085? Also, I believe that allowing the u= se of > Zero UDP checksum in some scenarios, this protocol introduces a securi= ty > threat that must be thoroughly analyzed in the Security Considerations > section. > > This is described in RFC 6936. It will be very specific to the UDP > port provisioned for TWAMP. We will add reference to RFC 6936 in Security > Section. > > GIM>> I don't think that the reference is sufficient for the > Securit Consideration. I'd expect some extended discussion on why using > zero UDP header checksum is not a security threat for *twamp-srpm protoc= ol. > > > > Please see reply above. > > > - Section 8 refers to "liveness monitoring of Links and SR Paths". > This appears as the replication of functionality provided by BFD/S-BFD > protocols. Is such comparison accurate? If it is, shouldn't the propos= al be > also reviewed by the BFD WG? > > TWAMP probe messages are used today for synthetic packet loss which > can also be used to detect connection loss (performance metric). The > section simply highlights this obvious metric. > > GIM>> Can you point to a document that has defined "TWAMP probe messages > are used today for synthetic packet loss"? Also, which document defines > loss of connectivity as a performance metric? Does *twamp-srpm proposes t= o > use the new protocol to detect the loss of path continuity? > > > > For example Y.1731 has such notion of connection loss. TWAMP is use= d > widely for synthetic packet loss and is well-known. There is no change in > protocol. This is reported metric. > > GIM2>> What are packet transmission frequencies authors envisioned for that mode? A single-digit millisecond? > > - I found the Security Section of the proposed protocol inadequately > terse and missing very important threats that this protocol introduces= in > the network. > > Other than referring RFC 6936 for zero checksum what else is missing= ? > Otherwise it is no different than RFC 8762 (STAMP). > > GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The us= e > of source IP addresses, as mentioned above, appears to be another securit= y > risk introduced by *-twamp-srpm drafts. > > > > There is no mention of Source IP address above. > > > - draft-gandhi-ippm-twamp-srpm > > As I understand it, the motivation for the Loss Measurement mode defined > in this specification is to collect "in-profile" counters. Is that correc= t? > Do you see as essential for this mode that the query messages are in-band > with the flow being profiled? In your opinion, how using an out-of-band > method of collecting these counters, e.g., by using ICMP multi-part messa= ge > extension per RFC 4884, could affect the accuracy comparing with the meth= od > in this protocol? How the impact changes if extended ICMP messages are > in-band with the profiled flow? > > Yes, they need to be in-band with the flow, to collect the counter > from the right forwarding paths for the flow. Discussion of using ICMP fo= r > direct-mode loss measurement is outside the scope of this draft. > > GIM2>> I think that the assumption "they need to be in-band with the flow= , to collect the counter from the right forwarding paths for the flow" is technically inaccurate. Otherwise, how SNMP queries could work for decades of networking history? > As mentioned earlier, I am not sure extending ICMP to do PM is a goo= d > option here. Both TWAMP and OWAMP are widely deployed today for delay and > synthetic loss measurement. > > GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend > RFC 4656 OWAMP as well? Also, what you see as the connection between usin= g > active measurement methods to measure packet delay and packet loss, on on= e > hand, and collecting packet counters? > > > > The Session-Sender test-packet is defined in OWAMP RFC and not TWAM= P > RFC. Other than timestamp and its format vs. counter and its format, the > messages and processing are the same. > > > > Thanks, > > Rakesh > > > > > > > - Section 3.1 introduces the new field, Sender Control Code. The > format of the packet, as I understand it, is presented in Figure 1. Wh= en > comparing with the format of Session-Sender's test packet defined in R= FC > 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields.= Are > these introduced by your proposal? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > - Also, it appears that the Sequence Number field in TWAMP > Session-Sender's test packet is absent in Figure 1. Is that intentiona= l? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > Thanks, > > Rakesh > > > > Regards, > > Greg > > Thanks > > > > Gyan > > > > On Thu, Oct 22, 2020 at 5:51 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for TWAMP > Light Messages*, *Loss Measurement Query Message Extensions*, and *Los= s > Measurement Response Message Extensions *were included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > - The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD > > > --000000000000bbe3f005b55585a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Rakesh,
    thank you for the continue= d discussion. I appreciate your responses. I am still not convinced of the = value these documents add. Please find my follow-up notes in-line=C2=A0belo= w under the GIM2>> tag.

    Regards,
    G= reg


    On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

    Thank you Gyan = and Greg for your review comments and discussions. Please see inline replie= s with <RG2>=E2=80=A6

    =C2=A0<= /u>

    =C2=A0

    From: Gyan Mishra <hayabusagsm@gmail.com= >
    Date: Wednesday, November 25, 2020 at 12:34 PM
    To: Greg Mirsky <gregimirsky@gmail.com>
    Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org= <spring-cha= irs@ietf.org>, = spring@ietf.org <spring@ietf.org>
    Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

    =C2=A0

    Hi Rakesh=C2=A0

    =C2=A0

    I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

    =C2=A0

    Thanks=C2=A0

    =C2=A0

    Gyan

    =C2=A0

    On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

    Hi Rakesh,

    thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

    Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

    Please see replies inline with <RG&= gt;=E2=80=A6

    =C2=A0

    From: ippm <ippm-bounces@ietf.org>= ;
    Date: Friday, November 6, 2020 at 11:18 AM
    To: James Guichard <james.n.guichard@futurewei.com>
    Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
    Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11    =

    Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

    I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

    Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

    • Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

    <RG> We are ok to change Sender to Session-Sender and Re= flector to Session-Reflector if it helps.

    =C2=A0

    GIM>> I believe that the consistency in termin= ology between the core RFC and what is intended as its extension is not onl= y helpful to a reader but, to the best of my understanding, is required for= IETF specifications. But I don't think that switching the terminology will fix the fundamental issue with the pro= posal. The operation that is required from the remote entity, whether it is= referred to as responder or Session-Reflector, is not defined in Appendix = I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior required, as described in the = draft, cannot be characterized as an extension of OWAMP, TWAMP, or TWAMP Li= ght but presents a completely new protocol that, if there's a need in t= he new PM OAM protocol, must be properly defined.

    =C2=A0

    =C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references requ= ired to understand the specification leading to confusion and misunderstanding of the specification.=C2=A0 The goal should be clear = and concise in terminology and verbiage.

    =C2=A0

    <RG2> Agr= ee. Will address the terms from RFC 5357 in the next revision.

    <RG> There are many existing RFCs that use term =E2=80= =9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongru= ent Path=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed d= ocuments, "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be = used interchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

    Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if= they have the same shape and size, or if one has the same shape and size as the mirror image of the other", it looks a= s the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet of an a= ctive OAM intended to monitor a flow over the SR tunnel is out-of-band rela= tive to that flow and will not produce any meaningful measurement. Of course, for the case of the extensions in d= rafts *-twamp-srpm, direct loss measurement can be performed, as informatio= n collected from node F and packets that collect the counters are not requi= red to be in-band with the monitored flow. So, this example, in my opinion, illustrates two of my concerns:<= /u>

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance m= easurement, e.g., TWAMP or TWAMP Light, may produce information that does n= ot reflect the condition experienced by the monitored flow. It seems that t= he terminology should reflect the fundamental requirement of ensuring that active OAM test packets are i= n-band with the monitored flow.

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify = using in-band test packets for direct packet loss measurement. In fact, usi= ng the in-band method for collecting in-profile counters leads to a waste o= f bandwidth, which may have a negative impact on services that require low-latency and/or low packet los= s. As demonstrated in this example, direct packet loss can be performed usi= ng an out-of-band mechanism, e.g., SNMP queries, Netconf notifications base= d on YANG data model.

    • Does the document solve a real problem?

    No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

    =C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agr= ee that for direct in band packet loss measurement can be done via existing= OAM mechanisme via ICMP.

    <RG2> Ok,= we will find an appropriate term for =E2=80=9Csending packets on the same path as data traffic=E2=80=9D.

    <RG2> Ext= ending ICMP for direct-mode loss measurement is outside the scope of this draft. But good to see the agreement for the direct in band packet= loss measurement to be done (albeit by some other means).

    =
    <= /div>
    GIM2>> I feel that you misunderstand my = position in regard to the use case these four documents try to solve. I don= 't recall that I've stated that "direct in-band packet loss me= asurement" requires any additional standardization work. The Direct Me= asurement TLV has solved that for STAMP and draft-ietf-ippm-stamp-option-tl= v is now in the RFC Editor's queue. I cannot find any valid technical r= eason to re-open this and measure the direct packet loss in a slightly diff= erent way. I must point out that a claim that using fixed positions for the= direct packet loss optimizes performance does not stand for cases (Section= 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when the return path is= specified in the Return Path TLV and, as I understand it, in some cases ev= en the second TLV, Node Address TLV, is used. Thus, it is clear that the pr= oposed new method of direct packet loss measurement does not offer any sign= ificant benefits comparing to the STAMP's Direct Measurement TLV and ap= pears nothing but superfluous.
    <= div>

    =

    <RG> There is a requirement to measure performance delay= as well as synthetic and direct-mode packet loss in segment-routing networ= ks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

    GIM>> I agree with the=C2=A0requirements you&#= 39;ve listed (though the=C2=A0SPRING WG OAM requirem= ents document=C2=A0has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to us= e OWAMP/TWAMP for exclusive direct packet loss measurement.=C2=A0=C2=A0<= /u>

    =C2=A0

    =C2=A0 =C2=A0 Gyan> Agreed

    =C2=A0

    <RG2> There is definitely a n= eed to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mecha= nisms are for MPLS networks. Note that there was an attempt to extend BFD for direct-mode loss measurem= ent for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03).<= /span>

    • Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

    <RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

    GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

    =C2=A0

    =C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA security th= reats and that you need to thorough vetting of RFC 6936.

    =C2=A0

    <RG2> Yes= , will add in the next revision. Hope we can work together on needed text.<= u>

    =C2=A0

    =C2=A0

    =C2=A0

    GIM>> I cannot find where RFC 5357 defines &qu= ot;the probe and response messages". Could you give a more specific re= ference or provide the text that, in your opinion, defines such messages? B= ut I'm more concerned with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to B= BF's=C2=A0TR-390, I'm have learned how different are existing imple= mentations of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

    =C2=A0

    =C2=A0 =C2=A0 Gyan> I don=E2=80=99t see the probe= a d response messages in TWAMP RFC 5357

    =C2=A0

    <RG2> Agr= ee to use term test-packet from RFC 5357.

    • several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, re= quire detailed security analysis, which is currently absent;<= /li>

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    =C2=A0

    <RG2> Ple= ase see previous reply.

    =C2=A0

    =C2=A0

    <RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

    GIM>>=C2=A0 I've noted above that a simple= reference does not sufficiently explains why the use of zero UDP checksum = in IPv6 header is not decremental, does not create a security risk for the = protocol. I believe that the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provid= ed in RFC 6936.

    =C2=A0

    =C2=A0 =C2=A0 Gyan> Completely Agree

    =C2=A0

    <RG2> Ple= ase see previous reply.

    =C2=A0

    • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
    <RG> This was to address your previous comment quoted as=
:
     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0 track is more appropriate for th= is specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS.

    GIM>> As explained in RFC 8545 "TWAMP Lig= ht is an idea", not a protocol. If anyone is interested in standardizi= ng an "extension", I'd expect that they first define the base= specification to which the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you point to the definition, for example, of the Authenticated mode i= n TWAMP Light in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0=

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

    =C2=A0

    <RG2> The= Appendix I of RFC 5357 does have information on the Authentication mode. A= s specified there, this is based on user configured parameters.

    =C2=A0

    =C2=A0

    • I believe that=C2=A0draft-gandhi-spring-twamp-srpm should be anchored at IP= PM WG as it does introduce the new PM protocol.

    =C2=A0 =C2=A0=C2=A0

    =C2=A0

    <RG> The = TWAMP Light extension draft-gandhi-= ippm-twamp-srpm is already in IPPM WG. The SPRING draf= t only defines SR PM procedures.

    =C2=A0

    Below, please find my detailed=C2=A0comments, questi= ons on these drafts:

    • draft-gandhi-spring-twamp-srpm

    I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

    =C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
    =C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
    =C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
    =C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
    =C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
    =C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
    =C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
    =C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
    =C2=A0 =C2=A0[TimDISCUSS].

    =C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
    =C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
    =C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
    =C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
    =C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
    =C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

    =C2=A0

    Since we don't have an IETF document that addres= sed these open questions, I don't think we can have a draft that propos= es extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> The= procedure for using the RFC 5357 defined messages in TWAMP Light configuration mode is defined in the corresponding spring drafts. It also = describes the provisioning model.

    <= /blockquote>
    <= div>GIM2>> If a return path can be provisioned for TWAMP Light, why t= he same method of controlling a test session cannot be used for STAMP?

    =C2=A0

    <RG> This was to address your previous comment quoted as=

     =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

    =C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

    =C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

    =C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

    =C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

    https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

    <RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

    <RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

    GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm def= inition of the Authenticated mode of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the discussion of = "extension" to TWAMP Light.

    =C2=A0

    <RG2> The= Authentication information is user-configured as shown in Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357.

    =C2=A0

    Now a number of more specific questions.

    draft-gandhi-spring-twamp-srpm:

    • In the Introduction it is stated that:

    =C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
    =C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
    =C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
    =C2=A0 =C2=A0control-channel signaling.

    I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

    =C2=A0

    <RG> The Appendix I of RFC 5357 has following text. We c=
an reword and match the exact text if you prefer.

    =
=C2=A0
    

    =
=E2=80=9CThis example eliminate=
s the need for the TWAMP-Control protocol, and
    

    =C2=A0=C2=A0 assumes that the Ses=
sion-Reflector is configured=E2=80=9D

    GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

    =C2=A0

    <RG2> Thi= s is the exact text from RFC 5357 Appendix I. Please go through the entire = Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussion.

    =C2=A0

    • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

    =C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
    =C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

    I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

    <RG> We can add the Appendix I as reference in the next = revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can ad= d this reference.

    GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0

    =C2=A0

    <RG2> If = approved, it is fine to have informational draft/RFC in a normative referen= ce. But RFC 5357 is PS.

    • In Section 2.3 describing the reference model is noted:
      • <= /ul>

      =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

      In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

      <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D= from the sentence?

    GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

    • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

    <RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

    GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.=C2=A0

    =C2=A0

    <RG2> Ok,= we can change Link to link in the next revision to avoid confusion.=

    • In Section 3 behavior of the reflector described as

    =C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
    =C2=A0 =C2=A0reflector node R5.

    That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

    =C2=A0Gyan> Valid point=C2=A0

    <RG2> Bid= irectional SR tunnel may have an SR state but the statement above is that no PM (i.e. TWAMP Light) protocol session state is created for it.= We can clarify in the next revision.

    GIM2>> So-called stateless Session-Reflector in TWAMP Light i= s only one option. I am well-familiar with the implementation that uses the= stateful mode.=C2=A0

    =C2=A0

    <RG> Quoting the text from Appendix I in RFC 5357. We ca= n quote the text as is.

    =E2=80=9CIn the case of TWAMP Lig=
ht, the Session-Reflector does not necessarily have knowledge of the sessio=
n state. =E2=80=9C

    GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way pac= ket loss measurement. If you require that the remote node does not maintain the state, the draft must define that as= part of the specifying the behavior of the protocol.

    =C2=A0

    <RG2> Ok,= we can discuss what information is to be maintained in that state on the r= eflector for synthetic packet loss. We can add appropriate text if you can help please.

    GIM2>> I don't see any reas= on to do that as that already defined in RFC 8762 and draft= -ietf-ippm-stamp-yang=C2=A0
    =

    =C2=A0<= /u>

    • Further, in Section 3 the selection of UDP port explained as the following:=

    =C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
    =C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
    =C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
    =C2=A0 =C2=A0measurement probe messages.

    To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

    =C2=A0Gyan> Agreed=C2=A0

    <RG2> Yes= , we can use port 862 for both delay and synthetic packet loss =E2=80=93 they are using the same test packet. There is no change proposed in the dr= aft.

    GIM2>> Packet delay= and synthetic packet loss measurements are already supported in RFC 8762. = Are you proposing a new protocol to duplicate the STAMP functionalities?
    <= div>

    <RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

    GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 4737 defines packet reordering metric), and packet duplication measur= ement.

    • Then the draft states that

    The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

    Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

    Gyan> Good point =C2=A0

    <RG> Please see section 6 in [RFC6335]. We can cite the = range which will be the same as used in [RFC8762]. This was also discussed = earlier.

    https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

    GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports ran= ge, a.k.a., Private or Ephemeral, then it seems that stating that explicitly would be the best way.=C2=A0

    =C2=A0

    <RG2> This would be, User Ports and Dynam=
ic Ports ranges, which are defined in [RFC6335]. Yes, we can add this text.

    =C2=A0

    • At the closing of the paragraph, we read that

    =C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
    =C2=A0 =C2=A0to limited hardware resources.

    Does a UDP port number pose PM functionality? How it= is assigned to the port number?

    <RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

    GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this= is the definition of a different from TWAMP Light PM OAM protocol.

    =C2=A0

    <RG2> If = we add a field in the packet then UDP port 862 may be used along with the n= ew field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficien= cy in hardware.

    =C2=A0<= /u>

    • Following the above-quoted text, in Section 3 is noted:
      • <= /ul>

      =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
      =C2=A0 =C2=A0sent as following:

      Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

      <RG> Probe messages follow the same procedure as defined= in RFC 4656 and RFC 5357.

    GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

    =C2=A0

    <RG2> Yes= , unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

    =C2=A0

    • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

    =C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
    =C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

    It is not clear what "the congruent path" = means. The definition of=C2=A0congruency in geometry tells us that an objec= t B is congruent=C2=A0to object A if it has the same shape and size, but is allowed to flip, slide or turn. How a path can be congruent to another = path?

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

    =C2=A0

    <RG2> As = replied above.

    =C2=A0<= /u>

    <RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

    GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that = the intention of the authors of the draft to use this protocol out-of-band?

    =C2=A0

    <RG2> As = replied above.

    • The last paragraph in Section 3 refers to work on iOAM:
      • <= /ul>

      =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
      =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
      =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
      =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
      =C2=A0 =C2=A0and are outside the scope of this document.

      Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

      <RG> As mentioned in the draft, IOAM is outside the scop= e.

    GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

    =C2=A0

    <RG2> We = can remove them if it is confusing. It is informational text (was added to = address a review comment).

    =C2=A0

    • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

    <RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

    GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.=C2=A0

    =C2=A0

    <RG2> The= Yang model extensions are not in the scope of this draft.

    =C2=A0

    • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

    <RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

    GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definit= ion of RFC 7799, passive measurement method and fetching counters can be done using numerous methods, e.g., SNMP, Netc= onf.

    =C2=A0

    <RG2> RFC= 7799 does not say using Test-packets to collect counters for direct-mod lo= ss measurement is passive.

    <= /div>
    GIM2>> Per RFC 7799, injecting in-= band test packets is the characteristic of an active measurement method. Us= ing out-of-band transport, e.g., SNMP queries, would be an example of a pas= sive measurement method.

    =C2=A0

    • Section 4.1.1 requires that

    =C2=A0 The Destination UDP port cannot be used as So= urce port, since
    =C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
    =C2=A0 =C2=A0query and response message.

    Does that imply that the Destination UDP port used f= or the Delay measurement is unique throughout the particular domain?=

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

    <RG2> Yes= , it is unique in the domain.

    <RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

    GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers bein= g underspecified.

    • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

    <RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.=

    GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.= =C2=A0

    =C2=A0

    <RG2> No,= it does not change anything for synthetic packet loss.

    • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

    <RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

    GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

    =C2=A0

    <RG2> It = is test-packet, we will use RFC 5357 term.

    • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
    <RG> Yes. Please see section 4.1.1 and quoted below:
    =E2=80=9CFor symmetrical size que=
ry and response messages as defined in [RFC6038],=E2=80=9D=

    GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us= nothing about that either (in part because RFC 6038 came later), I don't see that there's any certainty in wh= at is the sze of a test packet used in the direct-loss measurement.=C2=A0

    =C2=A0

    <RG2> The= test-packets as defined in these existing RFCs are used for delay and synt= hetic packet loss. The direct-mode test-packets are defined in this draft.

    GIM2>> This draft defines only a new = packet format for the direct packet loss measurement. For STAMP such a mech= anism is clearly superfluous given the Direct Measurement TLV is already de= fined.

    • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

    <RG> This= is same as TWAMP. There is no change.

    GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

    =C2=A0

    <RG2> No = change in existing in what is there in RFC 5357 and RFC 8186.=

    • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

    <RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

    GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

    =C2=A0

    <RG2> Ack= .

    • Section 4.1.1.1 stated that

    =C2=A0 =C2=A0A separate user-configured
    =C2=A0 =C2=A0destination UDP port is used for the delay measurement in
    =C2=A0 =C2=A0authentication mode due to the different probe message format.=

    Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

    <RG> Yes,= and Yes, and these are based on provisioning.

    GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

    =C2=A0

    <RG2> Som= e Session-Sender can use authenticated and some not. It is part of RFC 5357= .

    • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

    <RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

    GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected pa= cket does not have Sender's Error Estimate, nor Error Estimate of the reflector. And that, in my opinion, is another clear indic= ation that *twamp-srpm drafts define a new protocol, separate from OWAMP/TW= AMP.

    =C2=A0

    <RG2> Tha= t field is specific to timestamps and would not apply to counters for direc= t-mode loss measurement.

    =C2=A0

    • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
    • A couple of question to the following text in Section 4.1.3:<= /li>

    =C2=A0 =C2=A0The local and remote IP
    =C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
    =C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
    =C2=A0 =C2=A0routed.

      • What are the addresses of a link?

    <RG> I am= assuming this well-known (e.g. RFC 2328).

    GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

    =C2=A0

    <RG2> Ens= ure that packets are routed over the link.

      • In which scenarios an IPv6 LLA can be used?

    <RG> I am= assuming this is well-known (e.g. RFC 5613).

    GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

    =C2=A0

    <RG2> As = mentioned this is for links.

    =C2=A0

      • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

    <RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

    GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is se= curity threat.

    =C2=A0

    <RG2> The= re is no new threat like you have mentioned.

    GIM2>> Hmmm, but= how the integrity of TLVs proposed in=C2=A0draft-gandhi-ippm-stamp-srpm ca= n=C2=A0be protected? These are not protected by HMAC as presented in figure= s 3 and 5.

    • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

    <RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

    • Section 4.2.1 states that

    =C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
    =C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

    Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

    <RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

    GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to= reference behavior of TWAMP test packet? But the behavior of the TWAMP-Test protocol by itself is neither in-band, nor out-of-band. = It is the encapsulation of the TWAMP test packet that makes it either in-ba= nd or out-of-band.=C2=A0

    =C2=A0

    <RG2> Rig= ht.

    GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mod= e?

    =C2=A0

    <RG2> Ple= ase see the draft.

    • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

    <RG> This= is as defined in Section 4.2 of RFC 5357 (Bullet 4).<= /p>

    GIM>> I believe you've misunderstood the t= ext in RFC 5357. This bullet specifies the behavior of a Session-Reflector.= It is to try to read TTL value of the received TWAMP test packet and copy = the value in Sender TTL field of the reflected packet. If the Session-Reflector cannot access the TTL field, it MUST writ= e 255 in the Sender TTL field. So, I think that my questions still remains.=

    =C2=A0

    <RG2> Ple= ase see Section 4.2.1 of RFC 5357.

    • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

    <RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

    GIM>> I don't think that the reference is = sufficient for the Securit=C2=A0Consideration. I'd expect some extended= discussion on why using zero UDP header checksum is not a security threat = for *twamp-srpm=C2=A0 protocol.

    =C2=A0

    <RG2> Ple= ase see reply above.

    • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

    <RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

    GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the loss of path continuity?

    =C2=A0

    <RG2> For= example Y.1731 has such notion of connection loss. TWAMP is used widely fo= r synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.

    <= /div>
    =

    • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

    <RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

    GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts.=C2=A0<= u>

    =C2=A0

    <RG2> The= re is no mention of Source IP address above.

    • draft-gandhi-ippm-twamp-srpm

    As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part=C2=A0message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

    =C2=A0<RG2&g= t; Yes, they need to be in-band with the flow, to collect the counter from the right forwarding paths for the flow. Discussion of using ICMP for= direct-mode loss measurement is outside the scope of this draft.

    =
    • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP i= n Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender'= ;s test packet is absent in Figure 1. Is that intentional?

    <RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

    Thanks,<= u>

    Rakesh

    =C2=A0

    Regards,

    Greg

    =C2=A0Thanks=C2=A0

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gyan=C2=A0=

    =C2=A0

    On Thu, Oct 22, 2020 at 5:51 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    This message starts a 3 week WG= adoption call for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

    =C2=A0

    Some background: =C2=A0<= u>

    =C2=A0

    Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:<= /p>

    =C2=A0

    =C2=A0

    These conclusions were discussed with the authors of= =C2=A0https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:

    =C2=A0

    =C2=A0

    After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

    =C2=A0

    Finally, the chairs would like = to thank the authors for their efforts in this matter.=

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno, & Joel

    =C2=A0

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

    =C2=A0

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

    --

    =

    Gyan Mishra

    Network Solutions Architect=C2=A0

    M 301 502-1347
    13101 Columbia Pike=C2=A0
    Silver Spring, MD

    =C2=A0

    --000000000000bbe3f005b55585a4-- From nobody Mon Nov 30 09:00:46 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA153A0B6D; Mon, 30 Nov 2020 09:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=WTQIIMq9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kYxlJFVz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1bphxi6cPy3; Mon, 30 Nov 2020 09:00:38 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B813A0ECA; Mon, 30 Nov 2020 09:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20604; q=dns/txt; s=iport; t=1606755638; x=1607965238; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jblSL8lxeEGMs5uBaXdFmubZ/tsWseYZVvF7gQIGpCI=; b=WTQIIMq9DikugSDtkBcIBdwUs2EfWokKjLLmJz1QBY+mK/c7oXf3nKw9 LBrlugTNzr8vE3li4uz1ugz+vivSMINDNr6lFZFduZQZbqRM7AxvK1Qda mA789QnkTfwiIf5f4XFYrKtkKmMT490WzP3Rj1b5rxQBKvxs6R+EMOiSa 8=; X-IPAS-Result: =?us-ascii?q?A0ArBQCWJMVffZldJa1YChwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?g+BIwEuUXxaLy4KhDODSQONWYoWiX+EcYJTA1QLAQEBDQEBGAEMCAIEAQGEB?= =?us-ascii?q?kQCF4ISAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBhjwMhXIBAQEEAQEQL?= =?us-ascii?q?gEBKQMJAgEPAgEGAhEEAQEoBQICHwYLFAkIAgQBDQUIEweDBYF+UgUDLgEOk?= =?us-ascii?q?T2QawKBPIhpbwmBMIMEAQEFgTMBAwIOQYJ+DQuCEAmBOIJzik0bgUE/gRFDg?= =?us-ascii?q?lU+ghtCAQECAQGBLi8VFgkIglU3giyRA4odKJwXOFcKgnCJF4ZphhWFOYMdg?= =?us-ascii?q?SuIcpIkgjaTZYsHgnOSdQIEAgQFAg4BAQWBQyohgVlwFRohgjUBATIJRxcCD?= =?us-ascii?q?Y4hDBcUgzqFFIVEdAI1AgYBCQEBAwl8jWkBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3Ay4U67RReNFvl7l8E8ofeCBulJdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,382,1599523200"; d="scan'208,217";a="604121550" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 17:00:16 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AUH010Q027039 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2020 17:00:15 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:00:07 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:00:07 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 12:00:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NatiksmgFZMSxLG9VMJVXlDx+FYPwYF+IYZoLbi681Jn1/X6ROKUSlrnkH1mSb/jwH8j7Vez2VLtybURhOOe63StvJMlWEFP90e8oeWXwwtSAuLrSWQ1WLsr5BDTHkFfKJ39r0jtcpB4A59NOrmKo4pp1vzQvQhMsUG+SYJ8a4e5IJak31QCFy+3Y+H5hWqvw9/42FybB5wr6hXluaLlDJ6AMaILIg2JW7zSpN+gZ7OjOQmKUnOM+FL3+pljRtG0fF3MoAUtVofi5sCsshZOsq0jwKbF65dCXu46y5nfoINP/Cd+55JFth2RCmU8PscnJkqR12BE1wupnPF7bPt4zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jblSL8lxeEGMs5uBaXdFmubZ/tsWseYZVvF7gQIGpCI=; b=V/01jt7rKrBhiwZ0rtvQqmZGy4Do5P6ovEmP7pAkMAhsqADLeJc+Vc5RNjfLFyPdn2JLtbF0TjtKvYkxwqwQ/m4jEOkcat8sLT76RYWU6fbxxTdeXQYybPwCl/dqAEPdYLtId/OHV9FyhCzSe3eLV/6H5tOAiFyNJaM27XC4A2n+1SLNmoB4wi9H9y3f0GjebpOpsHm6wCLwYlZqdCtrbJQNZD9V2GH9TmrNUPEAQDdfcalzau9pFwCsoScAPO7Sujfm6fICQaeu5hLvXfV/eEn533LPTL7x/zOAi4zY8XVb0RUwAwzcWuRmCKeW/q4ULC2ublKCbCAisTmHucKg0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jblSL8lxeEGMs5uBaXdFmubZ/tsWseYZVvF7gQIGpCI=; b=kYxlJFVzulfVgEK75D6KUWitcZUjCIAvq1ce0sl+dkBNJcYH0J1tzVeRzxGBbahx6tZOS5wgb+IO4MpOHIWt/UY5gUb+Mg+iMiteLZTp9bPR9oKE6CUyeMgDQq0LSnEmQo/r8UZTUulrASsnDeg1rWKsv2RVxhVl2LyPvs1qW0A= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN7PR11MB2657.namprd11.prod.outlook.com (2603:10b6:406:b1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Mon, 30 Nov 2020 17:00:05 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::3ceb:c137:d13f:b30a]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::3ceb:c137:d13f:b30a%5]) with mapi id 15.20.3611.025; Mon, 30 Nov 2020 17:00:05 +0000 From: "Darren Dukes (ddukes)" To: Greg Mirsky , Weiqiang Cheng CC: srcomp , spring , "spring-chairs@ietf.org" Thread-Topic: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt Thread-Index: AQHWvuV8FltRqyE21UeaMjRY+2Qp/anYy4A6 Date: Mon, 30 Nov 2020 17:00:05 +0000 Message-ID: References: <08c001d6b8d3$010d08d0$03271a70$@com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [198.84.181.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 165b3a5a-de50-41ec-327a-08d8955162b6 x-ms-traffictypediagnostic: BN7PR11MB2657: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ythd75CSy4P+ZOovdrVipezzf+K9adPmVMbJROUyxKT2rKLu3pQCxj766xEd1TM8Jyf4H6L0x2h+2R322np+ad7ZnxM/2XBz17sfLLUPVcEKfGrHaLr+GYm4qcD8Iufh0NzLwo/j2esqOMJhX1Eut6vNKJi60QMy39+pNf4JgzPRRkIYabaOW8hm2Nb9ZL/rtQ3avt+qrMR2bWTHWuAzrQhBbysedPrSpdwM5RGWTb4XwSXIdGUPiGk9z5ceIY2xqQYHA1olEAd/VyOcglWD3swQjoN4mBpGksQ7IKYO/jPnYVUb0Z8SqCLjV/UDpVzNMrmpbf6jG2LvhqIYi6pvecyYgro50RdLEJjU7J3fXcJNXPP/Hi2uF13OFg1STnImjCtxMdpnJGQc6z9vbv00vQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(346002)(396003)(376002)(136003)(66476007)(66946007)(86362001)(9686003)(64756008)(478600001)(76116006)(7696005)(66446008)(66556008)(8676002)(966005)(26005)(91956017)(6506007)(83380400001)(53546011)(66574015)(71200400001)(186003)(4001150100001)(316002)(54906003)(52536014)(33656002)(4326008)(166002)(5660300002)(19627405001)(15650500001)(110136005)(55016002)(8936002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?gb2312?B?SEJlWmxDWWRqS0ZIV2dBRmN4WEU3SHZhUnNtT1FHUERaallUR2VzV09BVjNw?= =?gb2312?B?WC9acHBkdE1ncVpKV1BKSGZKeW1EMG9qVTRPeWhiQW5YZjROeHkrOVdhd29T?= =?gb2312?B?VzJjak16S0ZuTHVmWFc2bncxdnJTbnYyOEQ5cW12Mi9ock4ra01QdG9veTJZ?= =?gb2312?B?cHZWUXZjYks4T3Yva3M5eXQwemJoT1MyL284ZjlxTDNKQjNHOUdiNkZMMHpO?= =?gb2312?B?UXZGblJUaGlGQndYM0x2SWt0TTJGS2FLY1d2Y2trOUdoLzV0akFqTWVWbmlV?= =?gb2312?B?RWxOVkNvcUlSNkhIeTFLMEs2cHVra2RtbFUvU3lxMkw2NTdsYjNPVE1wbjBz?= =?gb2312?B?RXgwOHYzOERBTlRjaUdkS2RReUJiSnVNNFZFWDUrM01PdkQ3ZlZDUEFIdThE?= =?gb2312?B?L0RLaUh4dG8yL3liQVBHTXVmK04vQjE1OGk1M21pNC9tZUdJTTM3a2RTYXFP?= =?gb2312?B?cVRuZlVzVGI0N0JiYXJFYnpwaUxKLzMrdjBJUEFoYWZROUIxVjdxa0VJbkt4?= =?gb2312?B?eXFESjRoR0cyc3R2d2ZETzZ5OFNtRlZ6WXdoMnpUS29pMEVtTXY5NDJEalJ1?= =?gb2312?B?WURTbjVMUG5kY09LdXd2dUVmTTNMQkpMZ2tZbCtMUHpoa2hMSDBUbGtOQUZZ?= =?gb2312?B?UFZ0d0w5QlRHWEJ1a1lMZk1ZU1g0bnh4bklwUGxoSFQ2WjJPUHEzczhXS2Fl?= =?gb2312?B?U2xzTG5nZXZGeXFUWnpHODJsc2dhY0ZYTmVzdFhtcm1Tc1FKTFdRdE5aU0tn?= =?gb2312?B?VFpuY2RYUFE4eWVMQTlRNFliVTR6ZUtLM05qbm1aV0RsZ3R2dFNQK0lYZXhF?= =?gb2312?B?UzBZVGh0UjZTL29McHJpVHExdFljSFk0SDM1ZVNDN1JJRE5tQVdjaVZTNnJU?= =?gb2312?B?c0xYQ2RISjhCa3QvaS83N0JTK1A5TlZ5WlR2ZE1KZDROWTNpN2N4U1dxN1FD?= =?gb2312?B?T3cyNWdlOGQraDYwVWtLVGhwdmYzZ1Z0UnoreG84NWYyVFJXaDZlczVpMCtu?= =?gb2312?B?MjRRS1pjRjhjenRLT3lUdnM1VWk1aUI0cDArSDZ4RWZIZU43NnBHMTBGM3RW?= =?gb2312?B?TXZKbCswaGIvdjVMeXpGWFlxV01NbGJtaFl3b2dBZWJXLy9yVU9vbGFZc1JZ?= =?gb2312?B?UXlvOUNMUlhxZmtZUGR1cDkwY0tXMmtrK2tKdlBmNEE1endzWWVRQmJZM3Bi?= =?gb2312?B?Skxud1g0cEduZnVKZUFFRXZhTitJbWdTSy82NC8xb1dsZitabWRKMEd6SDNL?= =?gb2312?B?am5QQmhwa3pLUmJCa2d3Nmd5b3NSNE1QRUFMdDFIYWZkY3FWQXd3TDlTODdj?= =?gb2312?Q?3G3bYWarND6x0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081031C5348E18CC349F526C8FA0BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 165b3a5a-de50-41ec-327a-08d8955162b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 17:00:05.2083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: owILpHEaGf+rzWbI5CbUkVXWawOp+lO0NL/gmps4L4HycC1rzS1CZ/PL6zrgCf/1rJwzGH6cAug4ToezLl1XQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2657 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 17:00:41 -0000 --_000_BN6PR11MB4081031C5348E18CC349F526C8FA0BN6PR11MB4081namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 R3JlZywgdGhhbmsgeW91IGZvciB5b3VyIHRob3VnaHRmdWwgYW5hbHlzaXMgYW5kIGNvbW1lbnRz LiAgSaGvbSByZXBseWluZyBvbiBiZWhhbGYgb2YgbXlzZWxmIGFuZCBub3QgdGhlIGVudGlyZSBk ZXNpZ24gdGVhbS4NCg0KUGxlYXNlIHNlZSBpbmxpbmUgW0RdDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NClNlbnQ6IFRo dXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAyMCA5OjMyIFBNDQpUbzogV2VpcWlhbmcgQ2hlbmcgPGNo ZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPg0KQ2M6IHNyY29tcCA8c3Jjb21wQGlldGYub3Jn Pjsgc3ByaW5nIDxzcHJpbmdAaWV0Zi5vcmc+OyBzcHJpbmctY2hhaXJzQGlldGYub3JnIDxzcHJp bmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudC0wMC50eHQNCg0KSGkgV2VpcWlhbmcsIG1lbWJlcnMgb2YgdGhlIERULA0KdGhhbmsg eW91IGZvciB2b2x1bnRlZXJpbmcgeW91ciB0aW1lIGFuZCBleHBlcnRpc2UgdG8gdGhpcyBpbXBv cnRhbnQgZm9yIHRoZSBmdXJ0aGVyIGRldmVsb3BtZW50IG9mIHRoZSBTUiBwcm9qZWN0LiBQbGVh c2UgZmluZCBteSBub3RlcyBhbmQgcXVlc3Rpb25zIGJlbG93Og0KDQogICogICBteSBmaXJzdCBx dWVzdGlvbiBpcyBvbiB0aGUgaW50ZW5kZWQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBBcyBJIGNh biB1bmRlcnN0YW5kIGZyb20gdGhlIHRpdGxlLCBhYnN0cmFjdCwgdGhlIHNjb3BlIGlzICJ0aGUg cmVxdWlyZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3MgU1J2NiBTSUQgbGlzdHMiLiBX aGVuIEkgY29tcGFyZSB0aGF0IHdpdGggd2hhdCB3YXMgaW4gdGhlIGNoYXJ0ZXIgb2YgdGhlIERU IGluIHRoZSBhbm5vdW5jZW1lbnQgYnkgb3VyIGNoYWlyczxodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NwcmluZy91TDVjTEV1ZmlwbWxRUV93M1ZadmItcHpuZDQvPjoNCg0K IC4uLiB0aGUgcmVxdWlyZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8gY29tcHJlc3Npbmcgc2VnbWVu dCByb3V0aW5nIGluZm9ybWF0aW9uIGZvciB1c2Ugb3ZlciBJUHY2Lg0KVGhvdWdoIHRoZSBkaWZm ZXJlbmNlIGluIHRleHRzIG1pZ2h0IHNlZW1zIGFzIHNtYWxsLCB0aGUgc2NvcGVzIHRoZXkgaWRl bnRpZnkgZGlmZmVyIHNpZ25pZmljYW50bHkuIFRvIG1lLCBpdCBzZWVtcyBhcyB0aGUgc2NvcGUg b2YgdGhlIGRyYWZ0IGlzIHRhcmdldGVkIHRvIG9ubHkgb25lIHBvc3NpYmxlIHNvbHV0aW9uIHRv IHByb3ZpZGUgU1Igb3ZlciBJUHY2IGZ1bmN0aW9uYWxpdHksIHRoZSBTUkguIERvZXMgdGhlIERU IHBsYW4gdG8gZXhwYW5kIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgdG8gbWF0Y2ggaXQgdG8gaXRz IGNoYXJ0ZXI/DQpbRF0gSSBiZWxpZXZlIHRoaXMgd2FzIGFuc3dlcmVkIGluIHRoZSB3b3JraW5n IGdyb3VwIG1lZXRpbmcgYW5kIHByZXNlbnRhdGlvbiBieSBXZWlxaWFuZy4gIE1vdmluZyB0aGUg dGV4dCBpbiBBLjEgYmFjayB0byB0aGUgaW50cm9kdWN0aW9uIHNob3VsZCBtYWtlIHRoZSBnb2Fs cyBvZiB0aGUgZG9jdW1lbnQgY2xlYXIuDQoNCiAgKiAgIEl0IGFwcGVhcnMgdGhhdCBpbiBvcmRl ciB0byBxdWFsaWZ5IHdoZXRoZXIgYSBwcm9wb3NlZCBjb21wcmVzc2lvbiBtZXRob2QgY29tcGxp ZXMgd2l0aCB0aGUgcmVxdWlyZW1lbnQgaW4gMy4xLjIgYW4gYWdyZWVtZW50IGJ5IHRoZSBXRyBv biB0aGUgYmVuY2htYXJraW5nIG1ldGhvZCBpcyByZXF1aXJlZCBiZWNhdXNlIG1ldHJpY3MgbGlz dGVkLCBpbiBteSB2aWV3LCBhcmUgcGxhdGZvcm0tZGVwZW5kZW50Lg0KDQogICogICBUaG91Z2gg SSBjYW4gYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIHVzaW5nIFNIT1VMRCBpbiBy ZXF1aXJlbWVudCAzLjEuMywgSSBkb24ndCBmaW5kIGl0IHBhcnRpY3VsYXJseSBpbXBvcnRhbnQg dG8gYmUgaW5jbHVkZWQgaW4gdGhlIGxpc3QuIEFmdGVyIGFsbCwgaXQgaXMgYSBtYXR0ZXIgb2Yg dGhlIGFydCBvZiBpbXBsZW1lbnRhdGlvbi4NCg0KW0RdIEJvdGggMy4xLjIgYW5kIDMuMS4zIGV4 aXN0IHRvIGFsbG93IGZvciBjb21wYXJpc29uIG9mIHByb3Bvc2FscyBmb3J3YXJkaW5nIGFuZCBz dGF0ZSBlZmZpY2llbmN5LiAgVGhleSBhcmUgaW50ZW50aW9uYWxseSBub24tcHJlc2NyaXB0aXZl IHN0YXRpbmcgdGhhdCBhIKGwcHJvcG9zYWwgU0hPVUxEIG1pbmltaXplobEgc3RhdGUgb3IgcmVz b3VyY2VzIGR1cmluZyBmb3J3YXJkaW5nLiAgVGhleSBnaXZlIHRoZSB3b3JraW5nIGdyb3VwIHRo ZSBhYmlsaXR5IHRvIGlkZW50aWZ5IHByb3Bvc2FscyB0aGF0IHNpZ25pZmljYW50bHkgcmVkdWNl IGVmZmljaWVuY3kuICBGb3IgZXhhbXBsZSwgYSBzb2x1dGlvbiB0aGF0IHJlZHVjZXMgaGVhZGVy IHNpemUgYnkgZGlzdHJpYnV0aW5nIHBlciBmbG93IGZvcndhcmRpbmcgc3RhdGUgdG8gYWxsIG5v ZGVzIG1heSBjb21wcmVzcyB3ZWxsLCBidXQgYXQgdGhlIGV4cGVuc2Ugb2YgZWZmaWNpZW5jeS4N Cg0KICAqICAgSSB0aGluayBJIGNhbm5vdCBhZ3JlZSB0aGUgU0lEIHN1bW1hcml6YXRpb24gaXMg dGhlIG9ubHkgdmlhYmxlIHRlY2huaXF1ZSBmb3IgdGhlIGludGVyZG9tYWluIFNSLiBSZXBsYWNp bmcgTVVTVCB3aXRoIFNIT1VMRCBtaWdodCBiZSByZWFzb25hYmxlLCBBbmQgcHJlZmVyYWJseSBh ZGRpbmcgYW4gaW5mb3JtYXRpdmUgdGV4dCB0byBkZXNjcmliZSBhbHRlcm5hdGl2ZSBtZXRob2Rz IHRvIHN1cHBvcnQgdGhlIGludGVyZG9tYWluIFNSLg0KDQpbRF0gQWdncmVnYXRpb24gb3Igc3Vt bWFyaXphdGlvbiBpcyBub3QgdGhlIG9ubHkgdGVjaG5pcXVlIGZvciBpbnRlcmRvbWFpbiBTUi4g IEJpbmRpbmcgU0lEcyBhcmUgcmVxdWlyZWQgaW4gQS4zLCBhbmQgdGhlcmUgYXJlIG90aGVyIG1l dGhvZHMgYW4gb3BlcmF0b3IgY2FuIHVzZS4gIFRoZSBSYXRpb25hbGUgZG9lcyBkZXNjcmliZSBv bmUgb3RoZXIgb3B0aW9uIHRoYXQgcmVxdWlyZXMgYWRkaXRpb25hbCBTSURzIGluIGEgU0lEIGxp c3QuDQpIb3dldmVyLCB0aGUgZGVzaWduIHRlYW0gaGFzIGhlYXJkIGZyb20gb3BlcmF0b3JzIHRo YXQgc3VtbWFyaXphdGlvbiBpcyBhIHZlcnkgaW1wb3J0YW50IHBhcnQgb2YgU1J2NiBhbmQgdGhl aXIgU1J2NiBkZXBsb3ltZW50IHBsYW5zLiBUaGV5IGRvIG5vdCB3YW50IHRvIGxvc2UgdGhpcyBm dW5jdGlvbmFsaXR5IGZvciB0aGUgc2FrZSBvZiBjb21wcmVzc2lvbi4NCg0KDQogICogICBJIHRo aW5rIEkgdW5kZXJzdGFuZCB0aGUgaW50ZW50aW9uIG9mIHRoZSByZXF1aXJlbWVudCBpbiBTZWN0 aW9uIDQuMi4xIGJ1dCBJIG1heSBwcm9wb3NlIGV4cHJlc3NpbmcgaXQgZGlmZmVyZW50bHk6DQoN CkEgcGF0aCB0cmF2ZXJzZWQgdXNpbmcgYSBsaXN0IG9mIGNvbXByZXNzZWQgU0lEcyBNVVNUIGFs d2F5cyBiZSB0aGUgc2FtZSBhcyB0aGUgcGF0aCB0cmF2ZXJzZWQgdXNpbmcgdGhlIGxpc3Qgb2Yg dW5jb21wcmVzc2VkIFNJRHMgaWYgbm8gY29tcHJlc3Npb24gd2FzIGFwcGxpZWQuDQoNCltEXSBU aGlzIHNlZW1zIGxpa2UgcmVhc29uYWJsZSB0ZXh0DQoNCiAgKiAgIEkgdGhpbmsgdGhhdCB0aGUg dXNlIG9mIE1VU1QgaW4gcmVxdWlyZW1lbnQgNS4xIGlzIHRvbyBzdHJvbmcuIEZpcnN0bHksIHN1 Y2ggY29tcGF0aWJpbGl0eSBpcyBub3QgZXNzZW50aWFsIGluIGEgZ3JlZW5maWVsZCBzY2VuYXJp by4gU2Vjb25kbHksIHRoZSBjb250cm9sIHBsYW5lIGJhc2VkIHNvbHV0aW9uIG1pZ2h0IGJlIGVu dmlzaW9uZWQgdG8gY29vcmRpbmF0ZSB0aGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gU1IgZG9tYWlu cyB1c2luZyBTUnY2IGFuZCBub3QgdXNpbmcgdGhlIFNSdjYgdGVjaG5pcXVlLg0KDQpbRF0gNS4x IGRlc2NyaWJlcyBhIKGwc2hpcHMgaW4gdGhlIG5pZ2h0obEgZGVwbG95bWVudCBzY2VuYXJpbywg c3VjaCB0aGF0IGl0IG11c3QgYmUgcG9zc2libGUgdG8gaGF2ZSBub24tY29tcHJlc3NlZCBTUnY2 IHN1cHBvcnQgb24gYSBub2RlIGFzIHdlbGwgYXMgdGhlIGNvbXByZXNzaW9uIHNvbHV0aW9uLg0K DQpbRF0gSS5lLiB0aGUgY29tcHJlc3Npb24gc29sdXRpb24gTVVTVCBtYWtlIGl0IHBvc3NpYmxl IGZvciBhIG5vZGUgdG8gc3VwcG9ydCB0aGUgdW5jb21wcmVzc2VkIGNvbnRyb2wgcGxhbmUgYW5k IGRhdGEgcGxhbmUsIGFzIHdlbGwgYXMgdGhlIGNvbXByZXNzZWQgY29udHJvbCBwbGFuZSBhbmQg ZGF0YSBwbGFuZS4gSXQgZG9lcyBub3Qgc3RhdGUgdGhhdCBldmVyeSBub2RlIE1VU1Qgc3VwcG9y dCBib3RoIGF0IHRoZSBzYW1lIHRpbWUuIEdpdmVuIHRoaXMsIGRvZXMgeW91ciBvYmplY3Rpb24g dG8gTVVTVCBzdGlsbCBhcHBseT8NCg0KDQoNCkFuZCBpbiB0aGUgY29uY2x1c2lvbiwgb25jZSBh Z2FpbiwgbWFueSB0aGFua3MgdG8gYWxsIHRoZSBtZW1iZXJzIG9mIHRoZSBEZXNpZ24gVGVhbSBm b3IgdGhlIGpvYiB3ZWxsIGRvbmUuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFRodSwgTm92IDEy LCAyMDIwIGF0IDE6MDYgQU0gV2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFtb2Jp bGUuY29tPG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbT4+IHdyb3RlOg0KSGkg R3JvdXAsDQpBcyB5b3Uga25vdywgdGhlIFNQUklORyBXb3JraW5nIEdyb3VwIHNldCB1cCBhbiBT UiBjb21wcmVzc2lvbiBkZXNpZ24gdGVhbSBwcmlvciB0byBJRVRGMTA4Lg0KVGhlIGRlc2lnbiB0 ZWFtIGlzIHRvIHByb2R1Y2UgKHJvdWdoKSBjb25zZW5zdXMgKG9mIHRoZSBEVCkgb3V0cHV0cyB0 byB0aGUgV0cgb24gdHdvIHJlbGF0ZWQgdG9waWNzOg0KMSkgV2hhdCBhcmUgdGhlIHJlcXVpcmVt ZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzaW5nIHNlZ21lbnQgcm91dGluZyBpbmZvcm1h dGlvbiBmb3IgdXNlIG92ZXIgSVB2NjsNCjIpIEEgY29tcGFyaXNvbiBvZiBwcm9wb3NlZCBhcHBy b2FjaGVzIHRvIGNvbXByZXNzaW5nIHNlZ21lbnQgcm91dGluZyBpbmZvcm1hdGlvbiBmb3IgdXNl IG92ZXIgSVB2Ni4NCg0KV2l0aCBncmVhdCBlZmZvcnQgb2YgZGVzaWduIHRlYW0gbWVtYmVycywg RFQgaGF2ZSBmaW5pc2hlZCB0aGUgdmVyc2lvbiAtMDAgb2YgdGhlIHJlcXVpcmVtZW50cyBkb2N1 bWVudCBhbmQgaGF2ZSBzdWJtaXR0ZWQgaXQgdG8gZGF0YXRyYWNrZXIuDQoNClBsZWFzZSByZXZp ZXcgaXQgYW5kIGxldCdzIGtub3cgeW91ciBjb21tZW50cy4NCg0KQi5SLg0KV2VpcWlhbmcgQ2hl bmcNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0Kt6LLzcqxvOQ6 IDIwMjDE6jEx1MIyyNUgMTY6MzINCsrVvP7IyzogU2FuZGVyIFN0ZWZmYW5uOyBTSk0gU3RlZmZh bm47IFdlaXFpYW5nIENoZW5nDQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJl cXVpcmVtZW50LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlx aWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAg ICAgICAgICAgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50DQpS ZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBDb21wcmVzc2VkIFNSdjYgU0lEIExp c3QgUmVxdWlyZW1lbnRzDQpEb2N1bWVudCBkYXRlOiAgMjAyMC0xMC0zMA0KR3JvdXA6ICAgICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDEwDQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1zcmNvbXBkdC1zcHJp bmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNz aW9uLXJlcXVpcmVtZW50Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNy Y29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMA0KDQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRzIGZvciBzb2x1dGlvbnMgdG8g Y29tcHJlc3MgU1J2Ng0KICAgU0lEIGxpc3RzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcN Cg== --_000_BN6PR11MB4081031C5348E18CC349F526C8FA0BN6PR11MB4081namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Greg, thank you for your thoughtful analysis and comments.  I=A1=AFm r= eplying on behalf of myself and not the entire design team.

    Please see inline [D]

    From: spring <spring-bou= nces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com> Sent: Thursday, November 19, 2020 9:32 PM
    To: Weiqiang Cheng <chengweiqiang@chinamobile.com>
    Cc: srcomp <srcomp@ietf.org>; spring <spring@ietf.org>; = spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] FW: New Version Notification for draft-srcompd= t-spring-compression-requirement-00.txt
     
    Hi Weiqia= ng, members of the DT,
    thank you for volunteering your time and expertise to this important f= or the further development of the SR project. Please find my notes and ques= tions below:
    • my first question is on the intended scope of the document. As I can un= derstand from the title, abstract, the scope is "the requirements for = solutions to compress SRv6 SID lists". When I compare that with what w= as in the charter of the DT in the announcement by our chairs:
     ... the requirements for solutions to compressing segment routin= g information for use over IPv6.
    Though the difference in texts might seems as small, the scopes they i= dentify differ significantly. To me, it seems as the scope of the draft is = targeted to only one possible solution to provide SR over IPv6 functionalit= y, the SRH. Does the DT plan to expand the scope of the draft to match it to its charter?
    [D] I believe this was answered in the working group meeting and prese= ntation by Weiqiang.  Moving the text in A.1 back to the introduction = should make the goals of the document clear.
    • It appears that in order to qualify whether a proposed compression = ;method complies with the requirement in 3.1.2 an agreement by the WG on th= e benchmarking method is required because metrics listed, in my view, are p= latform-dependent.
    • Though I can appreciate your consideration and using SHOULD in requirem= ent 3.1.3, I don't find it particularly important to be included in the lis= t. After all, it is a matter of the art of implementation.
    [D] Both 3.1.2 and 3.1.3 exist to allow for comparison of proposals forward= ing and state efficiency.  They are intentionally non-prescriptive sta= ting that a =A1=B0proposal SHOULD minimize=A1=B1 state or resources during = forwarding.  They give the working group the ability to identify proposals that significantly reduce efficiency.  For exam= ple, a solution that reduces header size by distributing per flow forwardin= g state to all nodes may compress well, but at the expense of efficiency.
    • I think I cannot agree the SID summarization is the only viable techniq= ue for the interdomain SR. Replacing MUST with SHOULD might be reasonable, = And preferably adding an informative text to describe alternative methods t= o support the interdomain SR.
    [D] Aggregation or summarization is not the only technique for interdo= main SR.  Binding SIDs are required in A.3, and there are other method= s an operator can use.  The Rationale does describe one other option t= hat requires additional SIDs in a SID list.
    However, the design team has heard from operators that summarization i= s a very important part of SRv6 and their SRv6 deployment plans. They do no= t want to lose this functionality for the sake of compression.

    • I think I understand the intention of the requirement in Section 4.2.1 = but I may propose expressing it differently:
    A path tr= aversed using a list of compressed SIDs MUST always be the same as the path= traversed using the list of uncompressed SIDs if no compression was applie= d.

    [D] This seems like reasonable text
    • I think that the use of MUST in requirement 5.1 is too strong. Firstly,= such compatibility is not essential in a greenfield scenario. Secondly, th= e control plane based solution might be envisioned to coordinate the interw= orking between SR domains using SRv6 and not using the SRv6 technique.
    [D] 5.1 describes a =A1=B0ships in the night=A1=B1 deployment scenario, suc= h that it must be possible to have non-compressed SRv6 support on a node as= well as the compression solution.

    [D] I.e. the compression solution MUST make it possible for a node to = support the uncompressed control plane and data plane, as well as the compr= essed control plane and data plane. It does not state that every node MUST = support both at the same time. Given this, does your objection to MUST still apply?



    And in the conclusion, once again, many thanks to all the members of the De= sign Team for the job well done.

    Regards,
    Greg

    On Thu, Nov 12, 2020 at 1:06 AM Wei= qiang Cheng <chengweiqi= ang@chinamobile.com> wrote:
    Hi Group,
    As you know, the SPRING Working Group set up an SR compression design team = prior to IETF108.
    The design team is to produce (rough) consensus (of the DT) outputs to the = WG on two related topics:
    1) What are the requirements for solutions to compressing segment routing i= nformation for use over IPv6;
    2) A comparison of proposed approaches to compressing segment routing infor= mation for use over IPv6.

    With great effort of design team members, DT have finished the version -00 = of the requirements document and have submitted it to datatracker.

    Please review it and let's know your comments.

    B.R.
    Weiqiang Cheng


    -----=D3=CA=BC=FE=D4=AD=BC=FE-----
    =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
    =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA11=D4=C22=C8=D5 16:32
    =CA=D5=BC=FE=C8=CB: Sander Steffann; SJM Steffann; Weiqiang Cheng
    =D6=F7=CC=E2: New Version Notification for draft-srcompdt-spring-compressio= n-requirement-00.txt


    A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt<= br> has been successfully submitted by Weiqiang Cheng and posted to the
    IETF repository.

    Name:           draft-srcompdt-spring-compres= sion-requirement
    Revision:       00
    Title:          Compressed SRv6 SID List Requireme= nts
    Document date:  2020-10-30
    Group:          Individual Submission
    Pages:          10
    URL:            https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requireme= nt-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-srcompdt-spring-= compression-requirement/
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-srcompdt-spr= ing-compression-requirement
    Htmlized:       https://tools.ietf.org/html/draft-srcompdt-spring-compression-r= equirement-00


    Abstract:
       This document specifies requirements for solutions to compress= SRv6
       SID lists.




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

    The IETF Secretariat





    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --_000_BN6PR11MB4081031C5348E18CC349F526C8FA0BN6PR11MB4081namp_--