From nobody Fri Jan 3 03:32:33 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F8D1200D5 for ; Fri, 3 Jan 2020 03:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0hZlg3tC8TU for ; Fri, 3 Jan 2020 03:32:28 -0800 (PST) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4A212001E for ; Fri, 3 Jan 2020 03:32:28 -0800 (PST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (user=soudeh mech=PLAIN bits=0) by blaze.cs.jhu.edu (8.14.4/8.14.4) with ESMTP id 003BWLpw011765 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 3 Jan 2020 06:32:26 -0500 Received: by mail-vs1-f47.google.com with SMTP id g15so27144933vsf.1 for ; Fri, 03 Jan 2020 03:32:26 -0800 (PST) X-Gm-Message-State: APjAAAXaZ7b4iH1Sd1fHKMu+rTs3x8S13Q4xX+9jDvJHJmTNryjGe1fM +6RqlsAlHV/5QZbCSRgfcYx3C2fs+YZX3YUr0Zs= X-Google-Smtp-Source: APXvYqxQEE4cbSm9Li908iO0M2bOnJzTLAu5ckP9qGwTT1jKH2U6NoK6arBVkYWdL8kgjtAnWM9YfSHTj+yWyQOpIuw= X-Received: by 2002:a05:6102:227b:: with SMTP id v27mr32902698vsd.72.1578051141151; Fri, 03 Jan 2020 03:32:21 -0800 (PST) MIME-Version: 1.0 From: Soudeh Ghorbani Date: Fri, 3 Jan 2020 06:31:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: ippm@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4b371059b3aa959" Archived-At: Subject: [ippm] ACM SIGCOMM SOSR Software Systems Award X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 11:32:31 -0000 --000000000000b4b371059b3aa959 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACM SIGCOMM SOSR Software Systems Award https://conferences.sigcomm.org/sosr/2020/award.html The ACM SIGCOMM SOSR Software Systems Award is given to an individual or an institution to recognize the development of a software system that has had a significant impact on software-defined networking (SDN) research, implementations, and tools. The impact may be reflected in the widespread adoption of the system, or of its underlying concepts, by the wider SDN community, either in research projects, in the open-source community, or commercially. The award includes a prize of $1,000. The award is presented at the Symposium on SDN Research (SOSR) each year and the winner is invited to give a talk at the conference. Submission Instructions Nominations should be submitted by email to sosr-award@sigcomm.org on or before January 22nd, 2020 to be considered for this year's award. A nomination for the Software Systems Award that is not selected may be re-submitted in following years, but after three successive unsuccessful submissions, should not be re-submitted for at least one year. Each nomination should consist of the following items: - Name, affiliation, telephone number, and email address of the nominator (self-nominations are permitted). - Name, affiliation, telephone number, and email address of the nominee(s)= . - Name of the system being recognized, and (if possible) a URL with more information, source code, etc. - A short statement (200=E2=80=93500 words) explaining why the nominee des= erves the award. - Names and email addresses of 3-5 people who support the nomination. The awards committee may ask some or all of these people for statements of support. Selection Process The recipient of the award will be selected by a committee comprising the following members: - Three to four senior members of the SOSR community, selected by the SOSR steering committee, representing both academic and industrial perspectiv= es. - One member of the SOSR Steering Committee shall serve as an ex-officio member of the committee. Any committee member who has a conflict of interest with a nominee or who feels that their association with a nominee would interfere with their ability to be impartial shall be excluded from the relevant parts of the discussion. For the purposes of this selection process, conflicts of interest will include: Ph.D. and postdoc advisors and advisees, scientific collaborators and co-authors within the past two years, immediate family members, and any relationships that involve a significant financial interest such as employment, grants, consulting, advisory boards, etc. --000000000000b4b371059b3aa959 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

ACM SIGCOMM SOSR Sof= tware Systems Award


https://conferen= ces.sigcomm.org/sosr/2020/award.html


The ACM SIGCOMM SOSR Software Systems Award is given to = an individual or an institution to recognize the development of a software = system that has had a significant impact on software-defined networking (SD= N) research, implementations, and tools. The impact may be reflected in the= widespread adoption of the system, or of its underlying concepts, by the w= ider SDN community, either in research projects, in the open-source communi= ty, or commercially. The award includes a prize of $1,000. The award is pre= sented at the Symposium on SDN Research (SOSR) each year and the winner is = invited to give a talk at the conference.


Submission Instructions

Nominations shou= ld be submitted by email to sosr-award@sigcomm.org on or before January 22nd, 2020 = to be considered for this year's award.


A nomination for the Software Systems Award= that is not selected may be re-submitted in following years, but after thr= ee successive unsuccessful submissions, should not be re-submitted for at l= east one year.

E= ach nomination should consist of the following items:

  • Name, affiliation, telephone number, and email address o= f the nominator (self-nominations are permitted).

  • Name, affiliation, telephone = number, and email address of the nominee(s).

  • Name of the system being recogni= zed, and (if possible) a URL with more information, source code, etc.

  • A short s= tatement (200=E2=80=93500 words) explaining why the nominee deserves the aw= ard.

  • Names and email addresses of 3-5 people who support the nomination. The aw= ards committee may ask some or all of these people for statements of suppor= t.


Selection Process

The recipient of the award will be selected by a co= mmittee comprising the following members:

  • Three to four senior members of the SOSR community, selected by the SO= SR steering committee, representing both academic and industrial perspectiv= es.

  • = One member of the SOSR Steering Committee shall serve as an ex-officio memb= er of the committee.


Any committee member who has a conflict of interest with= a nominee or who feels that their association with a nominee would interfe= re with their ability to be impartial shall be excluded from the relevant p= arts of the discussion. For the purposes of this selection process, conflic= ts of interest will include: Ph.D. and postdoc advisors and advisees, scien= tific collaborators and co-authors within the past two years, immediate fam= ily members, and any relationships that involve a significant financial int= erest such as employment, grants, consulting, advisory boards, etc.<= /p>

--000000000000b4b371059b3aa959-- From nobody Mon Jan 6 04:15:45 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB24120801 for ; Mon, 6 Jan 2020 04:15:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157831294418.8076.10499240010667154676.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 04:15:44 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 12:15:44 -0000 Changed milestone "Submit a Standards Track draft defining a metric for unidirectional route assessment to the IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ippm/about/ From nobody Mon Jan 6 04:16:39 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 192ED120802 for ; Mon, 6 Jan 2020 04:16:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157831299810.8012.1324457354223185839.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 04:16:38 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 12:16:38 -0000 Changed milestone "Submit a Standards Track draft defining well-known ports for OWAMP and TWAMP to the IESG", set state to active from review, accepting new milestone. Changed milestone "Submit a Standards Track drafts defining a simple two-way active measurement protocol based on TWAMP-Test, and a YANG data model to control it, to the IESG", set state to active from review, accepting new milestone. Changed milestone "Submit a Standards Track document on Direct Export for IOAM", set state to active from review, accepting new milestone. Changed milestone "Submit a Standards Track document on Metrics and Methods for IP Capacity Measurement", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ippm/about/ From nobody Tue Jan 7 05:23:58 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 726AF1200E9; Tue, 7 Jan 2020 05:23:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <157840343137.20960.18411620966644385612@ietfa.amsl.com> Date: Tue, 07 Jan 2020 05:23:51 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-multipoint-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:23:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Multipoint Alternate Marking method for passive and hybrid performance monitoring Authors : Giuseppe Fioccola Mauro Cociglio Amedeo Sapio Riccardo Sisto Filename : draft-ietf-ippm-multipoint-alt-mark-04.txt Pages : 22 Date : 2020-01-07 Abstract: The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-multipoint-alt-mark-04 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-multipoint-alt-mark-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-multipoint-alt-mark-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 7 05:36:02 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDF212010D for ; Tue, 7 Jan 2020 05:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 n6qszGwFkbeA for ; Tue, 7 Jan 2020 05:35:57 -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 2B4441200E9 for ; Tue, 7 Jan 2020 05:35:57 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5B3EDEE5BE7110AAD975; Tue, 7 Jan 2020 13:35:52 +0000 (GMT) Received: from fraeml720-chm.china.huawei.com (10.206.15.16) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 Jan 2020 13:35:51 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml720-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 7 Jan 2020 14:35:51 +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.1713.004; Tue, 7 Jan 2020 14:35:51 +0100 From: Giuseppe Fioccola To: "tpauly@apple.com" , IETF IPPM WG CC: "MORTON, ALFRED C (AL)" , Tommy Pauly Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-multipoint-alt-mark Thread-Index: AQHVucf79YJuigAMPkqIz+MGclAltKffSB3w Date: Tue, 7 Jan 2020 13:35:51 +0000 Message-ID: <555df1b3f4eb4c43a52abe107cd79d28@huawei.com> References: <36BC36E1-2BE2-4DF6-8C04-F008B9F01BDC@apple.com> <4D7F4AD313D3FC43A053B309F97543CFA6F103AF@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.62.186] Content-Type: multipart/alternative; boundary="_000_555df1b3f4eb4c43a52abe107cd79d28huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:36:00 -0000 --_000_555df1b3f4eb4c43a52abe107cd79d28huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBUb21teSwgQWxsLA0KVGhhbmsgeW91IQ0KSSBoYXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0 ZWQgdmVyc2lvbiAoLTA0KSBvZiB0aGUgZHJhZnQgYW5kIGluY2x1ZGVkIEFsJ3MgY29tbWVudHMu DQpSZWdhcmRpbmcgdGhlIERvY3VtZW50IFNoZXBoZXJkIEkgd291bGQgbGlrZSB0byBzdWdnZXN0 IEFsIE1vcnRvbiBvciBUYWwgTWl6cmFoaSwgc2luY2UgdGhleSBnYXZlIHVzZWZ1bCBpbnB1dHMg YW5kIGNvbW1lbnRzIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIGRvY3VtZW50Lg0KDQpS ZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQpGcm9tOiB0cGF1bHlAYXBwbGUuY29tIFttYWlsdG86dHBh dWx5QGFwcGxlLmNvbV0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjMsIDIwMTkgODozNCBQTQ0K VG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPjsgSUVU RiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPg0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YWNt QHJlc2VhcmNoLmF0dC5jb20+OyBUb21teSBQYXVseSA8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJj LmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtpcHBtXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDog ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsNCg0KSGVsbG8gYWxsLA0KDQpUaGFu a3MgZm9yIHlvdXIgaW5wdXRzIGR1cmluZyB0aGUgbGFzdCBjYWxsISBXZSB3aWxsIHByb2dyZXNz IHRoZSBkb2N1bWVudCB0byB0aGUgSUVTRyBvbmNlIHdlIGdldCBhIERvY3VtZW50IFNoZXBoZXJk IHdyaXRlLXVwLg0KDQpBdXRob3JzLCBwbGVhc2UgcG9zdCBhbiB1cGRhdGUgb2YgdGhlIGRyYWZ0 IHRvIGluY2x1ZGUgQWwncyBjb21tZW50cyB3aGVuIHlvdSBjYW4uDQoNCldlIGFsc28gZG8gbmVl ZCBhIERvY3VtZW50IFNoZXBoZXJkIHRvIGNyZWF0ZSB0aGUgd3JpdGUtdXAgZm9yIHRoaXMgZHJh ZnQuIElmIGFueW9uZSBpbiB0aGUgZ3JvdXAgd2hvIGlzIG5vdCBhbiBhdXRob3Igb24gdGhpcyBk b2N1bWVudCB3b3VsZCBsaWtlIHRvIGJlIHRoZSBkb2N1bWVudCBzaGVwaGVyZCwgcGxlYXNlIHNl bmQgYW4gZW1haWwgdG8gdGhlIGNoYWlycyENCg0KQmVzdCwNClRvbW15DQoNCg0KT24gRGVjIDIy LCAyMDE5LCBhdCAyOjM0IFBNLCBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUuZmlvY2NvbGFA aHVhd2VpLmNvbTxtYWlsdG86Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbT4+IHdyb3RlOg0K DQpEZWFyIEFsLA0KVGhhbmsgeW91IGZvciB0aGUgc3VwcG9ydCBhbmQgZm9yIHRoZSBpbnB1dHMu DQpZb3VyIHN1Z2dlc3Rpb25zIGFyZSBvayBhbmQgSSB3aWxsIGFkZHJlc3MgdGhlbSBpbiB0aGUg bmV3IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4NCg0KUmVnYXJkcywNCg0KR2l1c2VwcGUNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KR2l1c2VwcGUgRmlvY2NvbGENCk1vYmls ZTogKzQ5LTE1MjIyODEyNDE4PHRlbDolM2NhJTIwaHJlZj0+Ij4xNTIyMjgxMjQxODx0ZWw6MTUy MjI4MTI0MTg+DQpFbWFpbDogZ2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbTxtYWlsdG86JTNj YSUyMGhyZWY9PiI+Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbTxtYWlsdG86Z2l1c2VwcGUu ZmlvY2NvbGFAaHVhd2VpLmNvbT4NCg0KDQpGcm9tOiBNT1JUT04sIEFMRlJFRCBDIChBTCk8YWNt QHJlc2VhcmNoLmF0dC5jb208bWFpbHRvOmFjbUByZXNlYXJjaC5hdHQuY29tPj4NClRvOiBUb21t eSBQYXVseTx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnRwYXVseT00 MGFwcGxlLmNvbUBkbWFyYy4uaWV0Zi5vcmc+PjtJRVRGIElQUE0gV0c8aXBwbUBpZXRmLm9yZzxt YWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFdvcmtpbmcgR3JvdXAg TGFzdCBDYWxsOiBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsNClRpbWU6 IDIwMTktMTItMjIgMTg6NDE6MDgNCg0KSGkgSVBQTSwNCg0KSSBoYXZlIHJldmlld2VkIHRoZSBs YXRlc3QgZHJhZnQgb2YgbXVsdGlwb2ludC1hbHQtbWFyaywNCmFzIHdlbGwgYXMgc2V2ZXJhbCBl YXJsaWVyIHZlcnNpb25zLg0KDQpJIGJlbGlldmUgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbiwgd2l0aCBhIGZldyBtaW5vcg0KY29tbWVudHMgYmVsb3cuDQoNCkFsDQoNCg0KICAg ICAgICAgIG11bHRpcG9pbnQtdG8tcG9pbnQNCiAgICAgICAgICAgICAgKy0tLS0tLSsNCiAgICAg ICAgICAtLS08PiAgUjEgIDw+DQogICAgICAgICAgICAgICstLS0tLS0rIFwNCiAgICAgICAgICAg ICAgICAgICAgICAgIFwgKy0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgIDw+ICBSNCAg PD4NCiAgICAgICAgICAgICAgICAgICAgICAgIC8gKy0tLS0tLSsgXA0KICAgICAgICAgICAgICAr LS0tLS0tKyAvICAgICAgICAgICAgXCArLS0tLS0tKw0KICAgICAgICAgIC0tLTw+ICBSMiAgPD4g ICAgICAgICAgICAgIDw+ICBSNCAgPD4tLS0NCiAgICAgICAgICAgICAgKy0tLS0tLSsgICAgICAg ICAgICAgIC8gKy0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSsgLw0K ICAgICAgICAgICAgICAgICAgICAgICAgIDw+ICBSNSAgPD4NCiAgICAgICAgICAgICAgICAgICAg ICAgIC8gKy0tLS0tLSsNCiAgICAgICAgICAgICAgKy0tLS0tLSsgLw0KICAgICAgICAgIC0tLTw+ ICBSMyAgPD4NCiAgICAgICAgICAgICAgKy0tLS0tLSsNCg0KSeKAmW0gZmFpcmx5IHN1cmUgdGhl IFJvdXRlciBvbiB0aGUgZmFyIHJpZ2h0IGlzIFI2IChGaWd1cmUgMSkuDQoNCkFsc28gdGhlIGxh c3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiAzIHJlYWRzOg0KICAgV2hpbGUgRUNNUCBmbG93IGlzIGlu IHNjb3BlIGJ5IGRlZmluaXRpb24sIHNpbmNlIGl0IGlzIGEgcG9pbnQtdG8tDQogICBtdWx0aXBv aW50IHVuaWNhc3QgZmxvdy4NClRoZXJlIGlzIGFuIGlzc3VlIHdpdGggdHdvIHBocmFzZXMgYmVn aW5uaW5nIOKAnFdoaWxl4oCdIGFuZCDigJxzaW5jZeKAnSwgbWF5YmUgdGhpcw0Kd2FzIG1lYW50 LCAocGx1cyB0aGUgcGhyYXNlIGluIGl0YWxpY3M/KToNCiAgIEFuIEVDTVAgZmxvdyBpcyBpbiBz Y29wZSBieSBkZWZpbml0aW9uLCBzaW5jZSBpdCBpcyBhIHBvaW50LXRvLQ0KICAgbXVsdGlwb2lu dCB1bmljYXN0IGZsb3csIF9vci9hbmQgYSBwb2ludC10by1wb2ludCBtdWx0aXBhdGggZmxvd18/ DQoNClNlY3Rpb24gNC4xDQoNCltJLUQuYW1mLWlwcG0tcm91dGU8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTAzI3JlZi1JLUQu YW1mLWlwcG0tcm91dGU+XSAgUmVmZXJlbmNlIG91dCBvZiBkYXRlLCBwbGVhc2UgdXNlIFdHIHZl cnNpb24uDQoNClNlY3Rpb24gNQ0KDQogICBBbmQgaW4gY2FzZSBvZiBubyBwYWNrZXQgbG9zcyBv Y2N1cnJpbmcgaW4gdGhlIG1hcmtpbmcgcGVyaW9kLCBpZiBhbGwNCiAgIHRoZSBpbnB1dCBhbmQg b3V0cHV0IHBvaW50cyBvZiB0aGUgbmV0d29yayBkb21haW4gdG8gYmUgbW9uaXRvcmVkIGFyZQ0K ICAgbWVhc3VyZW1lbnQgcG9pbnRzLCB0aGUgc3VtIG9mIHRoZSBudW1iZXIgb2YgcGFja2V0cyBv biBhbGwgdGhlDQogICBpbmdyZXNzIGludGVyZmFjZXMgYW5kIG9uIGFsbCB0aGUgZWdyZXNzIGlu dGVyZmFjZXMgaXMgdGhlIHNhbWUuDQpTdWdnZXN0DQogICBBbmQgaW4gY2FzZSBvZiBubyBwYWNr ZXQgbG9zcyBvY2N1cnJpbmcgaW4gdGhlIG1hcmtpbmcgcGVyaW9kLCBpZiBhbGwNCiAgIHRoZSBp bnB1dCBhbmQgb3V0cHV0IHBvaW50cyBvZiB0aGUgbmV0d29yayBkb21haW4gdG8gYmUgbW9uaXRv cmVkIGFyZQ0KICAgbWVhc3VyZW1lbnQgcG9pbnRzLCB0aGUgc3VtIG9mIHRoZSBudW1iZXIgb2Yg cGFja2V0cyBvbiBhbGwgdGhlDQogICBpbmdyZXNzIGludGVyZmFjZXMgX2VxdWFscyB0aGUgbnVt YmVyIG9uIGVncmVzcyBpbnRlcmZhY2VzIGZvciB0aGUgX21vbml0b3JlZF9mbG93Lg0KPT09PT09 PT09PT0NCiAgIEl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgTmV0d29yayBQYWNrZXQgTG9z cyAoZm9yIDEgZmxvdywgZm9yIDENCiAgIHBlcmlvZCk6IDw8SW4gYSBwYWNrZXQgbmV0d29yaywg dGhlIG51bWJlciBvZiBsb3N0IHBhY2tldHMgaXMgdGhlDQogICBudW1iZXIgb2YgcGFja2V0cyBj b3VudGVkIGJ5IHRoZSBpbnB1dCBub2RlcyBtaW51cyB0aGUgbnVtYmVyIG9mDQogICBwYWNrZXRz IGNvdW50ZWQgYnkgdGhlIG91dHB1dCBub2Rlcz4+Lg0KU3VnZ2VzdA0KICAgSXQgaXMgcG9zc2li bGUgdG8gZGVmaW5lIHRoZSBOZXR3b3JrIFBhY2tldCBMb3NzIChmb3IgMSBfbW9uaXRvcmVkX2Zs b3csIGZvciAxDQogICBwZXJpb2QpOiA8PEluIGEgcGFja2V0IG5ldHdvcmssIHRoZSBudW1iZXIg b2YgbG9zdCBwYWNrZXRzIGlzIHRoZQ0KICAgbnVtYmVyIG9mIHBhY2tldHMgY291bnRlZCBieSB0 aGUgaW5wdXQgbm9kZXMgbWludXMgdGhlIG51bWJlciBvZg0KICAgcGFja2V0cyBjb3VudGVkIGJ5 IHRoZSBvdXRwdXQgbm9kZXM+Pi4NCg0KU2VjdGlvbiAxMw0KDQpZb3UgY2FuIHByb2JhYmx5IGp1 c3Qgc2F5LCDigJxUaGlzIG1lbW8gbWFrZXMgbm8gcmVxdWVzdHMgb2YgSUFOQS7igJ0NCg0KDQpG cm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYuLm9yZ10gT24gQmVoYWxmIE9mIFRv bW15IFBhdWx5DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDksIDIwMTkgMzoxOCBQTQ0KVG86IElF VEYgSVBQTSBXRyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbaXBwbV0gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVs dGlwb2ludC1hbHQtbWFyaw0KDQpIZWxsbyBJUFBNLA0KDQpDb250aW51aW5nIG9uIGluIG91ciBs aXN0IG9mIExhc3QgQ2FsbHMsIHdlIGFyZSBub3cgYmVnaW5uaW5nIHRoZSBXb3JraW5nIEdyb3Vw IExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcms6DQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tbXVsdGlwb2ludC1hbHQt bWFyay0wMzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEaXBwbS0yRG11bHRpcG9pbnQt MkRhbHQtMkRtYXJrLTJEMDMmZD1Ed01GQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2Zz U3U4a1RJbHRWeUQxb0w3MmNCdyZtPUNyY1VIaUVOSXR1Z1h5VkM0RjZLbk4xZjBMRWNWM0Y2OHZp dHpsT2stMDQmcz04N1lKRG10R2Q4cTVINEdwTmQ3bDVTTXo2ZjVsS1UzNHhkZEZJUmRJN2pFJmU9 Pg0KDQpUaGUgTGFzdCBDYWxsIHdpbGwgZW5kIG9uIE1vbmRheSwgRGVjZW1iZXIgMjMuLi4gUGxl YXNlIHJlcGx5IHRvIGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+IHdpdGggeW91 ciByZXZpZXdzLCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IHRoaW5rIHRoaXMgZG9j dW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQpCZXN0LA0KVG9tbXkgKGFzIGNvLWNo YWlyKQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlw cG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== --_000_555df1b3f4eb4c43a52abe107cd79d28huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5EZWFyIFRvbW15LCBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBoYXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiAoLTA0KSBvZiB0 aGUgZHJhZnQgYW5kIGluY2x1ZGVkIEFsJ3MgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZGluZyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgQWwg TW9ydG9uIG9yIFRhbCBNaXpyYWhpLCBzaW5jZSB0aGV5IGdhdmUgdXNlZnVsIGlucHV0cyBhbmQg Y29tbWVudHMgZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZG9jdW1lbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRw YXVseUBhcHBsZS5jb20gW21haWx0bzp0cGF1bHlAYXBwbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgRGVjZW1iZXIgMjMsIDIwMTkgODozNCBQTTxicj4NCjxiPlRvOjwvYj4gR2l1 c2VwcGUgRmlvY2NvbGEgJmx0O2dpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20mZ3Q7OyBJRVRG IElQUE0gV0cgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNT1JUT04sIEFM RlJFRCBDIChBTCkgJmx0O2FjbUByZXNlYXJjaC5hdHQuY29tJmd0OzsgVG9tbXkgUGF1bHkgJmx0 O3RwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtpcHBtXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1pcHBtLW11 bHRpcG9pbnQtYWx0LW1hcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IZWxsbyBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgaW5wdXRzIGR1cmluZyB0aGUgbGFzdCBjYWxsISBXZSB3 aWxsIHByb2dyZXNzIHRoZSBkb2N1bWVudCB0byB0aGUgSUVTRyBvbmNlIHdlIGdldCBhIERvY3Vt ZW50IFNoZXBoZXJkIHdyaXRlLXVwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5BdXRob3JzPC9iPiwgcGxlYXNlIHBvc3QgYW4gdXBkYXRl IG9mIHRoZSBkcmFmdCB0byBpbmNsdWRlIEFsJ3MgY29tbWVudHMgd2hlbiB5b3UgY2FuLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5XZSBh bHNvIGRvIG5lZWQgYSBEb2N1bWVudCBTaGVwaGVyZDwvYj4gdG8gY3JlYXRlIHRoZSB3cml0ZS11 cCBmb3IgdGhpcyBkcmFmdC4gSWYgYW55b25lIGluIHRoZSBncm91cCB3aG8gaXMgbm90IGFuIGF1 dGhvciBvbiB0aGlzIGRvY3VtZW50IHdvdWxkIGxpa2UgdG8gYmUgdGhlIGRvY3VtZW50IHNoZXBo ZXJkLCBwbGVhc2Ugc2VuZCBhbiBlbWFpbCB0byB0aGUgY2hhaXJzITxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9tbXk8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIERlYyAyMiwgMjAxOSwgYXQgMjoz NCBQTSwgR2l1c2VwcGUgRmlvY2NvbGEgJmx0OzxhIGhyZWY9Im1haWx0bzpnaXVzZXBwZS5maW9j Y29sYUBodWF3ZWkuY29tIj5naXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBw dDtjb2xvcjojMzMzMzMzIj5EZWFyJm5ic3A7QWwsPGJyPg0KVGhhbmsmbmJzcDt5b3UmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDtzdXBwb3J0Jm5ic3A7YW5kJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 aW5wdXRzLjxicj4NCllvdXImbmJzcDtzdWdnZXN0aW9ucyZuYnNwO2FyZSZuYnNwO29rJm5ic3A7 YW5kJm5ic3A7SSZuYnNwO3dpbGwmbmJzcDthZGRyZXNzJm5ic3A7dGhlbSZuYnNwO2luJm5ic3A7 dGhlJm5ic3A7bmV3Jm5ic3A7cmV2aXNpb24mbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2RyYWZ0Ljxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KR2l1c2VwcGU8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Y29s b3I6IzMzMzMzMyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0K PC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjojMzMzMzMzIj48YnI+ DQpHaXVzZXBwZSZuYnNwO0Zpb2Njb2xhPGJyPg0KTW9iaWxlOiZuYnNwOyYjNDM7NDktPC9zcGFu PjxhIGhyZWY9InRlbDolM2NhJTIwaHJlZj0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0 O2NvbG9yOnB1cnBsZSI+MTUyMjI4MTI0MTg8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuMHB0O2NvbG9yOiMzMzMzMzMiPiZxdW90OyZndDs8L3NwYW4+PGEgaHJlZj0idGVsOjE1 MjIyODEyNDE4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjpwdXJwbGUiPjE1 MjIyODEyNDE4PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjoj MzMzMzMzIj4mbmJzcDsmbmJzcDs8YnI+DQpFbWFpbDombmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOiUzY2ElMjBocmVmPSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Y29sb3I6cHVy cGxlIj5naXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjBwdDtjb2xvcjojMzMzMzMzIj4mcXVvdDsmZ3Q7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjBwdDtjb2xvcjpwdXJwbGUiPmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2NvbG9yOiMzMzMzMzMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzo2LjBwdCAwaW4gMGluIDBpbjtjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCIgbmFtZT0iQW55T2ZmaWNl LUJhY2tncm91bmQtSW1hZ2UiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TU9SVE9OLCBBTEZSRUQgQyAo QUwpJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86YWNtQHJlc2VhcmNoLmF0dC5jb20iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5hY21AcmVzZWFyY2guYXR0LmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRvOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRvbW15IFBhdWx5Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHBhdWx5 PTQwYXBwbGUuY29tQGRtYXJjLi5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJw bGUiPnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OztJRVRGDQogSVBQTSBXRyZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlw cG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5pcHBtQGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5SZTogW2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFz dCBDYWxsOiBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcms8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaW1lOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIwMTktMTItMjIgMTg6NDE6 MDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIElQUE0s PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5JIGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCBkcmFmdCBvZiBtdWx0 aXBvaW50LWFsdC1tYXJrLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hcyB3ZWxsIGFzIHNldmVyYWwgZWFybGllciB2 ZXJzaW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYmVsaWV2ZSB0aGUgZHJhZnQgaXMgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCB3aXRoIGEgZmV3IG1pbm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmNvbW1lbnRzIGJlbG93 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+QWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlwb2ludC10by1wb2lu dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0mIzQzOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0tJmx0OyZndDsmbmJzcDsgUjEmbmJzcDsgJmx0OyZndDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tJiM0MzsgXDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgXCAmIzQzOy0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbHQ7Jmd0OyZuYnNwOyBSNCZuYnNwOyAmbHQ7Jmd0Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyAmIzQzOy0tLS0tLSYjNDM7IFw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tJiM0MzsgLyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBc ICYjNDM7LS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLSZsdDsmZ3Q7Jm5ic3A7IFIyJm5ic3A7ICZs dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsmZ3Q7Jm5ic3A7IFI0Jm5ic3A7ICZsdDsm Z3Q7LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLSYjNDM7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8gJiM0MzstLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0mIzQzOyAvPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Jmd0OyZuYnNwOyBSNSZu YnNwOyAmbHQ7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyAmIzQz Oy0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LSYjNDM7IC88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLSZsdDsmZ3Q7Jm5ic3A7IFIzJm5ic3A7ICZsdDsmZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLSYjNDM7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5J4oCZbSBmYWlybHkgc3VyZSB0aGUgUm91dGVyIG9uIHRoZSBmYXIgcmlnaHQgaXMg UjYgKEZpZ3VyZSAxKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsc28gdGhlIGxhc3Qgc2VudGVuY2Ugb2Yg U2VjdGlvbiAzIHJlYWRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hpbGUgRUNNUCBmbG93 IGlzIGluIHNjb3BlIGJ5IGRlZmluaXRpb24sIHNpbmNlIGl0IGlzIGEgcG9pbnQtdG8tPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBtdWx0aXBvaW50IHVuaWNhc3QgZmxvdy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ VGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0d28gcGhyYXNlcyBiZWdpbm5pbmcg4oCcV2hpbGXigJ0g YW5kIOKAnHNpbmNl4oCdLCBtYXliZSB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPndhcyBtZWFudCwgKHBsdXMg dGhlIHBocmFzZSBpbiBpdGFsaWNzPyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbiBFQ01Q IGZsb3cgaXMgaW4gc2NvcGUgYnkgZGVmaW5pdGlvbiwgc2luY2UgaXQgaXMgYSBwb2ludC10by08 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG11bHRpcG9pbnQgdW5pY2FzdCBmbG93LCBfb3IvPGk+ YW5kIGEgcG9pbnQtdG8tcG9pbnQgbXVsdGlwYXRoIGZsb3c8L2k+Xz88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlNlY3Rpb24gNC4xPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tbXVsdGlwb2lu dC1hbHQtbWFyay0wMyNyZWYtSS1ELmFtZi1pcHBtLXJvdXRlIiB0aXRsZT0iJnF1b3Q7QWR2YW5j ZWQgVW5pZGlyZWN0aW9uYWwgUm91dGUgQXNzZXNzbWVudCZxdW90OyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 cHVycGxlIj5JLUQuYW1mLWlwcG0tcm91dGU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dJm5ic3A7DQog UmVmZXJlbmNlIG91dCBvZiBkYXRlLCBwbGVhc2UgdXNlIFdHIHZlcnNpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5TZWN0aW9uIDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbmQgaW4gY2FzZSBv ZiBubyBwYWNrZXQgbG9zcyBvY2N1cnJpbmcgaW4gdGhlIG1hcmtpbmcgcGVyaW9kLCBpZiBhbGw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBpbnB1dCBhbmQgb3V0cHV0IHBvaW50cyBvZiB0 aGUgbmV0d29yayBkb21haW4gdG8gYmUgbW9uaXRvcmVkIGFyZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgbWVhc3VyZW1lbnQgcG9pbnRzLCB0aGUgc3VtIG9mIHRoZSBudW1iZXIgb2YgcGFja2V0 cyBvbiBhbGwgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbmdyZXNzIGludGVyZmFjZXMg YW5kIG9uIGFsbCB0aGUgZWdyZXNzIGludGVyZmFjZXMgaXMgdGhlIHNhbWUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlN1Z2dlc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFuZCBpbiBjYXNlIG9mIG5vIHBhY2tl dCBsb3NzIG9jY3VycmluZyBpbiB0aGUgbWFya2luZyBwZXJpb2QsIGlmIGFsbDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdGhlIGlucHV0IGFuZCBvdXRwdXQgcG9pbnRzIG9mIHRoZSBuZXR3b3Jr IGRvbWFpbiB0byBiZSBtb25pdG9yZWQgYXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtZWFz dXJlbWVudCBwb2ludHMsIHRoZSBzdW0gb2YgdGhlIG51bWJlciBvZiBwYWNrZXRzIG9uIGFsbCB0 aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluZ3Jlc3MgaW50ZXJmYWNlcyBfPGk+ZXF1YWxz IHRoZSBudW1iZXIgb24gZWdyZXNzIGludGVyZmFjZXMgZm9yIHRoZSBfbW9uaXRvcmVkX2Zsb3c8 L2k+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij49PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSXQg aXMgcG9zc2libGUgdG8gZGVmaW5lIHRoZSBOZXR3b3JrIFBhY2tldCBMb3NzIChmb3IgMSBmbG93 LCBmb3IgMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGVyaW9kKTogJmx0OyZsdDtJbiBhIHBh Y2tldCBuZXR3b3JrLCB0aGUgbnVtYmVyIG9mIGxvc3QgcGFja2V0cyBpcyB0aGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IG51bWJlciBvZiBwYWNrZXRzIGNvdW50ZWQgYnkgdGhlIGlucHV0IG5v ZGVzIG1pbnVzIHRoZSBudW1iZXIgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhY2tldHMg Y291bnRlZCBieSB0aGUgb3V0cHV0IG5vZGVzJmd0OyZndDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1Z2dlc3Q8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgTmV0 d29yayBQYWNrZXQgTG9zcyAoZm9yIDEgXzxpPm1vbml0b3JlZDwvaT5fZmxvdywgZm9yIDE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBlcmlvZCk6ICZsdDsmbHQ7SW4gYSBwYWNrZXQgbmV0d29y aywgdGhlIG51bWJlciBvZiBsb3N0IHBhY2tldHMgaXMgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBudW1iZXIgb2YgcGFja2V0cyBjb3VudGVkIGJ5IHRoZSBpbnB1dCBub2RlcyBtaW51cyB0 aGUgbnVtYmVyIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYWNrZXRzIGNvdW50ZWQgYnkg dGhlIG91dHB1dCBub2RlcyZndDsmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2VjdGlvbiAxMzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+WW91IGNhbiBwcm9iYWJseSBqdXN0IHNheSwg4oCcVGhpcyBtZW1vIG1ha2Vz IG5vIHJlcXVlc3RzIG9mIElBTkEu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlwcG0NCiBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLi5vcmddPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VG9tbXkgUGF1bHk8YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9u ZGF5LCBEZWNlbWJlciA5LCAyMDE5IDM6MTggUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklFVEYgSVBQTSBXRyAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 cHVycGxlIj5pcHBtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+W2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1maW9jY29sYS1p cHBtLW11bHRpcG9pbnQtYWx0LW1hcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBJUFBNLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29udGludWluZyBv biBpbiBvdXIgbGlzdCBvZiBMYXN0IENhbGxzLCB3ZSBhcmUgbm93IGJlZ2lubmluZyB0aGUgV29y a2luZyBHcm91cCBMYXN0IENhbGwgZm9yJm5ic3A7ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQt YWx0LW1hcms6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGll dGYtMkRpcHBtLTJEbXVsdGlwb2ludC0yRGFsdC0yRG1hcmstMkQwMyZhbXA7ZD1Ed01GQWcmYW1w O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFt cDttPUNyY1VIaUVOSXR1Z1h5VkM0RjZLbk4xZjBMRWNWM0Y2OHZpdHpsT2stMDQmYW1wO3M9ODdZ SkRtdEdkOHE1SDRHcE5kN2w1U016NmY1bEtVMzR4ZGRGSVJkSTdqRSZhbXA7ZT0iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyay0wMzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBM YXN0IENhbGwgd2lsbCBlbmQgb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGI+TW9uZGF5LCBEZWNlbWJlciAyMzwvYj4uLi4gUGxlYXNlIHJlcGx5IHRv PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pcHBtQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+d2l0aA0KIHlvdXIgcmV2aWV3cywgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90 IHlvdSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbW15IChhcyBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aXBw bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_555df1b3f4eb4c43a52abe107cd79d28huaweicom_-- From nobody Tue Jan 7 08:47:47 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF65D120879 for ; Tue, 7 Jan 2020 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 8nlj98gqC5Xh for ; Tue, 7 Jan 2020 08:47:43 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 9BBCA120867 for ; Tue, 7 Jan 2020 08:47:43 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 007GajsY040757 for ; Tue, 7 Jan 2020 08:47:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=z5TmFBZ/De78f4HO58zhqZXiGm3z+d8gC08NZBZJsYg=; b=Hqa4DGoVJ8zXCkxaO+62PAlXzvmHL00UejFgba+6RrrEEABi4SImnuERL7kNRYgfShrg hc2wlJravgMB44WxyuxZFFs7qNgoRw8WYYvyLQecd5PthYsJf2DOrSfAugkMI3InxGTe w3ht0aD5M7k+moEJN/Ni9gWzwWtMZWO5rSDH/NJT9ODciLG30MhNZwQf7HR2HRQ0MbKu HibSqEK3maN3bvVHPIanFfhO6+fANpTBTf04HYimT+lRVVCOEeP36MTCA+ogyaqKGvKR 1qsrvwxqfpATanlCLPemLGYLW0m16W9CwJSGopX1tAufd+xa6GhL4srZUk4To+bdKiKT bg== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xcmq5gqra-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 07 Jan 2020 08:47:41 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3Q00IUMXBBO260@ma1-mtap-s03.corp.apple.com> for ippm@ietf.org; Tue, 07 Jan 2020 08:47:41 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3Q00800X1R7500@nwk-mmpp-sz11.apple.com> for ippm@ietf.org; Tue, 07 Jan 2020 08:47:37 -0800 (PST) X-Va-A: X-Va-T-CD: X-Va-E-CD: X-Va-R-CD: X-Va-CD: 0 X-Va-ID: a4e7509d-aa06-43ee-9345-bec1d4ff5364 X-V-A: X-V-T-CD: 159681ac17b4bf28eab1955e26a63a9c X-V-E-CD: b8293722d771865aa62e431b7fdc830f X-V-R-CD: 9d703887aedc5263a7e8c27d8f4535ab X-V-CD: 0 X-V-ID: 6a023269-9b49-4223-8cdd-523ecb26d80f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-07_05:,, signatures=0 Received: from [17.230.168.32] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3Q00I12XBCIL60@nwk-mmpp-sz11.apple.com> for ippm@ietf.org; Tue, 07 Jan 2020 08:47:37 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_D3D28DB8-2C09-4762-A7FC-2EFF2D0104A2" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Message-id: Date: Tue, 07 Jan 2020 08:47:33 -0800 To: IETF IPPM WG X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-07_05:, , signatures=0 Archived-At: Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:47:46 -0000 --Apple-Mail=_D3D28DB8-2C09-4762-A7FC-2EFF2D0104A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello IPPM, Happy New Year! This email starts a working group last call for "Data = Fields for In-situ OAM" = (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). The last call will end on Tuesday, January 21. Please reply to = ippm@ietf.org with your reviews and comments. Please indicate whether = you think this document is ready for publication. Best, Tommy (as co-chair)= --Apple-Mail=_D3D28DB8-2C09-4762-A7FC-2EFF2D0104A2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello IPPM,

Happy New Year! This email starts a working group last call for "Data Fields for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).

The last call will end on Tuesday, January 21. Please reply to ippm@ietf.org with your reviews and comments. Please indicate whether you think this document is ready for publication.

Best,
Tommy (as co-chair)
--Apple-Mail=_D3D28DB8-2C09-4762-A7FC-2EFF2D0104A2-- From nobody Tue Jan 7 14:25:44 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C211200FD for ; Tue, 7 Jan 2020 14:25:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 GLv0-rjx8GPO for ; Tue, 7 Jan 2020 14:25:40 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2130.outbound.protection.outlook.com [40.107.223.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 C4ACD120025 for ; Tue, 7 Jan 2020 14:25:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=it/lBt31UCJHoQbrtE7ut7P56/aZtS9VzADoXNZmV8IyfNGfXCVVKbTWSM/VmFaoZlfBuuNeaTj6latam+oSX85/dNphwrbePzY89dTJ3ArN+DIU76iVMWefQIhesk2XFyhOww5NZMekC8VndwmOvrYHMn8SEqKXJr816ZBwRuzo3zsyY9sNvZBESl8d+Qa9v+YYXeM1l7B9/hDFwr5E53V2eaUj8lJTcnowobkrPwSiBhGHJTn+VKOdsZKhTkiitsiAIVtbZm4DqqJ515wg+RqjwXymYmr0fKj3/qgV1iuXubo0UgzCQu7HajN6rk8PdpPGG+CunHs07mVAC1dfKQ== 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=S9AjSXyiSiAkYO2aKOHaV/X/++mTSkjfq7bNFlJXrpg=; b=UmP53egfvIWhfUTi0NBiKBPINNJwaJlYUjVrYDPyLVZMmFnD0xSt4DS77sTzNZslJPc0wXYb6n2RF7ho1N3g4SN0T8CSyDkf+OMw0vXYE8zBYAXEj8S6OY7+kVx8/p68MxezSRFK5g/L/dRRuhDIbxukkdnQDyX3qQ2U9Y6NVGBrj/3s4QcpzlxmUrpPDMrd2JU+EHfmRr8W3kmLGtDrD1R20dtIdf5okTLopZe50/9TX+/rTu8SfIq3qVrQd1Haf1go2FuhMxq/QyNBvbK6hBkWm6qRraqdhNaUa7GJdp5eG7xD4qX4wkezJxR+QUYARz/c8/uPhVTI6bGtlGb5Og== 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=S9AjSXyiSiAkYO2aKOHaV/X/++mTSkjfq7bNFlJXrpg=; b=n4RF6hjG0CXz6FRkBhjEiMFwCHKFRNrn8aShVCTu7YKVsI19fCkpspL7cL3iErh5SanRPntkNk6qTvqeV22M9nnNnpXRYSE4Qg+gP29COI8WAjpdGYaZJObe73+6xYr0UOKFg+k3o4chyjSjwnBCcnvOt3q3I0FVfSlsFHwJQ1w= Received: from BYAPR13MB2485.namprd13.prod.outlook.com (52.135.228.19) by BYAPR13MB2263.namprd13.prod.outlook.com (52.135.228.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.4; Tue, 7 Jan 2020 22:25:37 +0000 Received: from BYAPR13MB2485.namprd13.prod.outlook.com ([fe80::61a4:f17f:156:4876]) by BYAPR13MB2485.namprd13.prod.outlook.com ([fe80::61a4:f17f:156:4876%7]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 22:25:37 +0000 From: Haoyu Song To: Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXpHWaysCQLfnkORVfHukaUXVaffwftA Date: Tue, 7 Jan 2020 22:25:36 +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: spf=none (sender IP is ) smtp.mailfrom=haoyu.song@futurewei.com; x-originating-ip: [12.111.81.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1fc68730-8a1c-473f-3760-08d793c08508 x-ms-traffictypediagnostic: BYAPR13MB2263: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(366004)(396003)(376002)(136003)(39850400004)(199004)(189003)(5660300002)(66476007)(66556008)(64756008)(33656002)(76116006)(66446008)(66946007)(186003)(86362001)(26005)(44832011)(71200400001)(52536014)(7696005)(53546011)(316002)(81166006)(2906002)(55016002)(110136005)(478600001)(81156014)(8676002)(9686003)(8936002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR13MB2263; H:BYAPR13MB2485.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: inuVPIoP9MjLqU2VSV1JkZMxE0zZUaa2mY/EQDmUgDaJ4vHAEOpWwjJtt/5uDafWw4qYgwtsJNuWwXkZZJ/22MftDA1EEcIz3ktmrEQvTuZFzhSdfAmSUMblUx9mokgGNwDfH2lC270jiNY9jGvwIDD5Aoptjg3v7Juj1P516NbQ/Jn8ru3CTSX+Dzl69g/iXxUNJx/Nm51FjbW+FRlRpomGrxuH5LEH7U+DTUAq44gB6OnTlrx1P7FLSuLYNcPfyp48cDfUy8IdZXUuSwp1Cxc7LxJv9YiLiZRnvfsu6GeG28wY7T7q7LL/XhFhCQe34fDjQCtk5K4wVElbXz1e1zjmI6t4u0wBjNiCtY9UE/3wtxZ3RYVZduEVsOBYda4a1QgcRKQFqdJsyxEn9AGyqVVjDbvkh4lGH30zG/Cwf+BuUNTDN/kk2Il0iQ4qZSDktIRsJQvJ59ONJo1u3+BJ2VDaCSspomhqQAq/IvawCCWjMibtPlcBBh13fsEx9tpLQyiSxwoNo5+/29F9EFNwuw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR13MB2485F7CBE0DC383BFD63B0B29A3F0BYAPR13MB2485namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fc68730-8a1c-473f-3760-08d793c08508 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 22:25:37.0007 (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: jah833MGQr4JMjZ3PRIKFh+T0Tr2ut/P1UeQaiWm2wg8lcArtVvO2ILc9rEzYv9bZHJk28/yivorPJfeS8VghA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2263 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 22:25:42 -0000 --_000_BYAPR13MB2485F7CBE0DC383BFD63B0B29A3F0BYAPR13MB2485namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPPM and IOAM authors, I have a question about the variable length opaque data field in the trace = option. Does that mean each node may add a variable length field (i.e., use= a different scheme ID)? "When this field is part of the data field but a node populating the field has no opaque state data to report, the Length must be set to 0 and the Schema ID must be set to 0xFFFFFF to mean no schema." >From the above description, it seems so. Then there's a problem. If each n= ode's data has different size, then one can't guarantee that the RemainingL= en is exactly 0 when the data overflow happens. Another issue: "If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the actual length added by each node. If IOAM-Trace-Type bit 22 is set, then the actual length added by a node would be (NodeLen + Opaque Data Length)." I think the "actual length added by a node would be (NodeLen+ size of opaqu= e state snapshot field). Because the opaque data is only a part of the opaq= ue state snapshot field, and (opaque data length + 4 byte)=3Dsize of opaqu= e state snapshot field. Some other places need similar clarification. Haoyu From: ippm On Behalf Of Tommy Pauly Sent: Tuesday, January 07, 2020 8:48 AM To: IETF IPPM WG Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21. Please reply to ippm@ietf.or= g with your reviews and comments. Please indicate whe= ther you think this document is ready for publication. Best, Tommy (as co-chair) --_000_BYAPR13MB2485F7CBE0DC383BFD63B0B29A3F0BYAPR13MB2485namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPPM and IOAM authors,

 

I have a question about the variable length opaque d= ata field in the trace option. Does that mean each node may add a variable = length field (i.e., use a different scheme ID)?

 

     “When this field is p= art of the data field but a node populating

      the field has no opaq= ue state data to report, the Length must be

      set to 0 and the Sche= ma ID must be set to 0xFFFFFF to mean no

      schema.”

 

From the above description, it seems so.  Then = there’s a problem. If each node’s data has different size, then= one can’t guarantee that the RemainingLen is exactly 0 when the data= overflow happens.

 

Another issue:

   

    “If IOAM-Trace-Type bi= t 22 is not set, then NodeLen specifies the

      actual length added b= y each node.  If IOAM-Trace-Type bit 22 is

      set, then the actual = length added by a node would be (NodeLen +

      Opaque Data Length).&= #8221;

 

I think the “actual length added by a node wou= ld be (NodeLen+ size of opaque state snapshot field). Because the opaqu= e data is only a part of the opaque state snapshot field, and  (opaque= data length + 4 byte)=3Dsize of opaque state snapshot field.  Some other places need similar clarification.

 

Haoyu

 

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Tommy Pauly
Sent: Tuesday, January 07, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

Happy New Year! This email starts a working group la= st call for "Data Fields for In-situ OAM" (https://datatracker.ietf.org/doc= /draft-ietf-ippm-ioam-data/).

 

The last call will end on Tuesday, January 21= . Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_BYAPR13MB2485F7CBE0DC383BFD63B0B29A3F0BYAPR13MB2485namp_-- From nobody Wed Jan 8 09:25:26 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07471208DD for ; Wed, 8 Jan 2020 09:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 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, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=apple.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 BZgf0z4HiLdp for ; Wed, 8 Jan 2020 09:25:24 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 2F6E31208D3 for ; Wed, 8 Jan 2020 09:25:24 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 008HLuIO022395; Wed, 8 Jan 2020 09:25:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=SV+hb1B3a6HyITj9hcdn/yGd2LopIL4F/I3eCtkoJ7M=; b=G4u75CMp61u8dXvhw/5B1VJW9y2fkZ/gg0ThsWC6jBHJfaDk17aTPiYDpCHk4GLmSS6u 19INYb7YT0QdIvp0SL+jeU4v/CTF9GA3idnmwH0CNMBwxv3auTu1UHZmvqLGuIIv3Z6h /JwIp+h8Odz6YyBJ6dLcVwo5EnEY5De4ltDMLbZbZYwj91IptSSyD1SKcB/PnX6GO8IM 4vz/vWn6VBzC9utiJzC/q5n50+uGoqtWYBos6/SO2hXPTiI4MWzjrCws0oA85VpCyQNY EliNSKcjE6/Wz3iBuSANCyRPUEJuoeanZAeIR1sEt9Jvuzat484YgzMgtUuITSTemXxc 1g== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2xd5gtpf2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 08 Jan 2020 09:25:10 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3S005XITPXPY80@ma1-mtap-s03.corp.apple.com>; Wed, 08 Jan 2020 09:25:09 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3S00500TNODN00@nwk-mmpp-sz11.apple.com>; Wed, 08 Jan 2020 09:25:09 -0800 (PST) X-Va-A: X-Va-T-CD: 6c06634650e4a4d5210b2d336c923947 X-Va-E-CD: f2258fc9d6634797bca3f996b47f2772 X-Va-R-CD: 3ed996b5a84b21ddcbc3e01366852b10 X-Va-CD: 0 X-Va-ID: 40878932-aa11-4390-a747-8f7e854284b1 X-V-A: X-V-T-CD: 6c06634650e4a4d5210b2d336c923947 X-V-E-CD: f2258fc9d6634797bca3f996b47f2772 X-V-R-CD: 3ed996b5a84b21ddcbc3e01366852b10 X-V-CD: 0 X-V-ID: 43cfcef2-3eb8-4e4c-9fa9-6fc6e591febd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-08_04:,, signatures=0 Received: from [17.230.130.162] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3S00653TOXDY00@nwk-mmpp-sz11.apple.com>; Wed, 08 Jan 2020 09:25:07 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <2B1D59E9-967A-49C0-BAF9-073CD8271B75@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_0E2D5DBB-BADE-45FB-AB01-0554F29B6577" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Wed, 08 Jan 2020 09:25:03 -0800 In-reply-to: <555df1b3f4eb4c43a52abe107cd79d28@huawei.com> Cc: IETF IPPM WG , "MORTON, ALFRED C (AL)" , Tal Mizrahi To: Giuseppe Fioccola References: <36BC36E1-2BE2-4DF6-8C04-F008B9F01BDC@apple.com> <4D7F4AD313D3FC43A053B309F97543CFA6F103AF@njmtexg5.research.att.com> <555df1b3f4eb4c43a52abe107cd79d28@huawei.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-08_04:, , signatures=0 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:25:26 -0000 --Apple-Mail=_0E2D5DBB-BADE-45FB-AB01-0554F29B6577 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Giuseppe! Tal has agreed to shepherd the document. Thanks very much to Tal! Best, Tommy > On Jan 7, 2020, at 5:35 AM, Giuseppe Fioccola = wrote: >=20 > Dear Tommy, All, > Thank you! > I have just posted an updated version (-04) of the draft and included = Al's comments. > Regarding the Document Shepherd I would like to suggest Al Morton or = Tal Mizrahi, since they gave useful inputs and comments during the = development of the document. > =20 > Regards, > =20 > Giuseppe > =C2=A0 <> > From: tpauly@apple.com [mailto:tpauly@apple.com]=20 > Sent: Monday, December 23, 2019 8:34 PM > To: Giuseppe Fioccola ; IETF IPPM WG = > Cc: MORTON, ALFRED C (AL) ; Tommy Pauly = > Subject: Re: [ippm] Working Group Last Call: = draft-ietf-ippm-multipoint-alt-mark > =20 > Hello all, > =20 > Thanks for your inputs during the last call! We will progress the = document to the IESG once we get a Document Shepherd write-up. > =20 > Authors, please post an update of the draft to include Al's comments = when you can. > =20 > We also do need a Document Shepherd to create the write-up for this = draft. If anyone in the group who is not an author on this document = would like to be the document shepherd, please send an email to the = chairs! > =20 > Best, > Tommy >=20 >=20 > On Dec 22, 2019, at 2:34 PM, Giuseppe Fioccola = > = wrote: > =20 > Dear Al, > Thank you for the support and for the inputs. > Your suggestions are ok and I will address them in the new revision of = the draft. >=20 > Regards, >=20 > Giuseppe >=20 >=20 >=20 > Giuseppe Fioccola > Mobile: +49-15222812418 ">15222812418 = =20 > Email: giuseppe.fioccola@huawei.com = ">giuseppe.fioccola@huawei.com = >=20 > =20 > From: MORTON, ALFRED C (AL)> > To: Tommy Pauly>;IETF IPPM = WG> > Subject: Re: [ippm] Working Group Last Call: = draft-fioccola-ippm-multipoint-alt-mark > Time: 2019-12-22 18:41:08 > =20 > Hi IPPM, > =20 > I have reviewed the latest draft of multipoint-alt-mark, > as well as several earlier versions. > =20 > I believe the draft is ready for publication, with a few minor > comments below. > =20 > Al > =20 > =20 > multipoint-to-point > +------+ > ---<> R1 <> > +------+ \ > \ +------+ > <> R4 <> > / +------+ \ > +------+ / \ +------+ > ---<> R2 <> <> R4 <>--- > +------+ / +------+ > +------+ / > <> R5 <> > / +------+ > +------+ / > ---<> R3 <> > +------+ > =20 > I=E2=80=99m fairly sure the Router on the far right is R6 (Figure 1). > =20 > Also the last sentence of Section 3 reads: > While ECMP flow is in scope by definition, since it is a point-to- > multipoint unicast flow. > There is an issue with two phrases beginning =E2=80=9CWhile=E2=80=9D = and =E2=80=9Csince=E2=80=9D, maybe this > was meant, (plus the phrase in italics?): > An ECMP flow is in scope by definition, since it is a point-to- > multipoint unicast flow, _or/and a point-to-point multipath flow_? > =20 > Section 4.1 > =20 > [I-D.amf-ippm-route = ] Reference out of date, please use WG version. > =20 > Section 5 > =20 > And in case of no packet loss occurring in the marking period, if = all > the input and output points of the network domain to be monitored = are > measurement points, the sum of the number of packets on all the > ingress interfaces and on all the egress interfaces is the same. > Suggest > And in case of no packet loss occurring in the marking period, if = all > the input and output points of the network domain to be monitored = are > measurement points, the sum of the number of packets on all the > ingress interfaces _equals the number on egress interfaces for the = _monitored_flow. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > It is possible to define the Network Packet Loss (for 1 flow, for 1 > period): < number of packets counted by the input nodes minus the number of > packets counted by the output nodes>>. > Suggest > It is possible to define the Network Packet Loss (for 1 = _monitored_flow, for 1 > period): < number of packets counted by the input nodes minus the number of > packets counted by the output nodes>>. > =20 > Section 13 > =20 > You can probably just say, =E2=80=9CThis memo makes no requests of = IANA.=E2=80=9D > =20 > =20 > From: ippm [mailto:ippm-bounces@ietf..org] On Behalf Of Tommy Pauly > Sent: Monday, December 9, 2019 3:18 PM > To: IETF IPPM WG > > Subject: [ippm] Working Group Last Call: = draft-fioccola-ippm-multipoint-alt-mark > =20 > Hello IPPM, > =20 > Continuing on in our list of Last Calls, we are now beginning the = Working Group Last Call for draft-ietf-ippm-multipoint-alt-mark: > =20 > https://tools.ietf.org/html/draft-ietf-ippm-multipoint-alt-mark-03 = > =20 > The Last Call will end on Monday, December 23... Please reply to = ippm@ietf.org with your reviews, and indicate = whether or not you think this document is ready for publication. > =20 > Best, > Tommy (as co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = --Apple-Mail=_0E2D5DBB-BADE-45FB-AB01-0554F29B6577 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Giuseppe!

Tal has agreed to shepherd the document. Thanks very much to = Tal!

Best,
Tommy

On Jan = 7, 2020, at 5:35 AM, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:

Dear Tommy, All,
Thank you!
I have just posted an = updated version (-04) of the draft and included Al's comments.
Regarding the Document = Shepherd I would like to suggest Al Morton or Tal Mizrahi, since they = gave useful inputs and comments during the development of the = document.
 
Regards,
 
Giuseppe
From: tpauly@apple.com [mailto:tpauly@apple.com] 
Sent: Monday, December 23, 2019 = 8:34 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; IETF IPPM WG <ippm@ietf.org>
Cc: MORTON, ALFRED C (AL) = <acm@research.att.com>; Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
Subject: Re: [ippm] Working Group = Last Call: draft-ietf-ippm-multipoint-alt-mark
 
Hello all,
 
Thanks for your inputs during the last = call! We will progress the document to the IESG once we get a Document = Shepherd write-up.
 
Authors, please post = an update of the draft to include Al's comments when you can.
 
We also do need a Document Shepherd to create the write-up for = this draft. If anyone in the group who is not an author on this document = would like to be the document shepherd, please send an email to the = chairs!
 
Best,
Tommy


On Dec 22, 2019, at 2:34 PM, Giuseppe = Fioccola <giuseppe.fioccola@huawei.com> wrote:
 

Dear Al,
Thank you for the support and for=  the inputs.
Your suggestions are ok and I wil= l address them in the new revision of&n= bsp;the draft.

Regards,

Giuseppe


Giuseppe Fioccola
Mobile: +49-15222812418">15222812418  
Email: giuseppe.fioccola@huawei.com">giuseppe.fioccola@huawei.com

 
From: MORTON, ALFRED C (AL)<acm@research.att.com>
To: Tommy Pauly<tpauly=3D40apple.com@dmarc.ietf.org>;IETF IPPM WG<ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: = draft-fioccola-ippm-multipoint-alt-mark
Time: 2019-12-22 18:41:08
 
Hi IPPM,
 
I have reviewed the latest draft of = multipoint-alt-mark,
as well as several earlier versions.
 
I believe the draft is ready for publication, with a few = minor
comments = below.
 
Al
 
 
          = multipoint-to-point
          &nb= sp;   +------+
          = ---<>  R1  <>
          &nb= sp;   +------+ \
          &nb= sp;            = ; \ +------+
          &nb= sp;  =            <>=   R4  <>
          &nb= sp;            = ; / +------+ \
          &nb= sp;   +------+ = /            \ = +------+
          = ---<>  R2  = <>           =    <>  R4  <>---
          &nb= sp;   = +------+           =    / +------+
          &nb= sp;            = ;   +------+ /
          &nb= sp;    =           <> = R5  <>
          &nb= sp;            = ; / +------+
          &nb= sp;   +------+ /
          = ---<>  R3  <>
          &nb= sp;   +------+
 
I=E2=80=99m fairly sure the Router = on the far right is R6 (Figure 1).
 
Also the last sentence of Section 3 reads:
   While ECMP flow is in = scope by definition, since it is a point-to-
   multipoint unicast = flow.
There is an = issue with two phrases beginning =E2=80=9CWhile=E2=80=9D and = =E2=80=9Csince=E2=80=9D, maybe this
was meant, (plus the phrase in = italics?):
   An = ECMP flow is in scope by definition, since it is a point-to-
   multipoint unicast = flow, _or/and a point-to-point multipath = flow_?
 
Section 4.1
 
[I-D.amf-ippm-route]  Reference out of date, please use WG = version.
 
Section 5
 
   And in case of no packet loss occurring in the = marking period, if all
   the input and output points of the network = domain to be monitored are
   measurement points, the sum of the number of = packets on all the
   ingress interfaces and on all the egress = interfaces is the same.
Suggest
   And in case of no packet loss occurring in the = marking period, if all
   the input and output points of the network = domain to be monitored are
   measurement points, the sum of the number of = packets on all the
   ingress interfaces _equals the = number on egress interfaces for the _monitored_flow.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   It is = possible to define the Network Packet Loss (for 1 flow, for 1
   period): <<In a = packet network, the number of lost packets is the
   number of packets = counted by the input nodes minus the number of
   packets counted by the = output nodes>>.
Suggest
   It is possible to define the Network Packet Loss = (for 1 _monitored_flow, for 1
   period): <<In a = packet network, the number of lost packets is the
   number of packets = counted by the input nodes minus the number of
   packets counted by the = output nodes>>.
 
Section 13
 
You can probably just say, =E2=80=9CThis memo makes no = requests of IANA.=E2=80=9D
 
 
From: ippm [mailto:ippm-bounces@ietf..org] On Behalf = Of Tommy Pauly
Sent: Monday, December 9, 2019 = 3:18 PM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] Working Group Last = Call: draft-fioccola-ippm-multipoint-alt-mark
 
Hello IPPM,
 
Continuing on in our list of Last Calls, we are now beginning = the Working Group Last Call = for draft-ietf-ippm-multipoint-alt-mark:
 
https://tools.ietf.org/html/draft-ietf-ippm-multipoint-alt-mark= -03
 
The Last Call will end = on Monday,= December 23... Please reply to ippm@ietf.org with your reviews, and = indicate whether or not you think this document is ready for = publication.
 
Best,
Tommy (as co-chair)
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_0E2D5DBB-BADE-45FB-AB01-0554F29B6577-- From nobody Thu Jan 9 03:23:01 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B10120113 for ; Thu, 9 Jan 2020 03:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 QUBLmDm5BkZd for ; Thu, 9 Jan 2020 03:22:57 -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 14F0A1200E3 for ; Thu, 9 Jan 2020 03:22:57 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B2DCC7CEA22711EACF33; Thu, 9 Jan 2020 11:22:54 +0000 (GMT) Received: from fraeml713-chm.china.huawei.com (10.206.15.32) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 9 Jan 2020 11:22:54 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 9 Jan 2020 12:22:53 +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.1713.004; Thu, 9 Jan 2020 12:22:53 +0100 From: Giuseppe Fioccola To: "tpauly@apple.com" CC: IETF IPPM WG , "MORTON, ALFRED C (AL)" , Tal Mizrahi Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-multipoint-alt-mark Thread-Index: AQHVucf79YJuigAMPkqIz+MGclAltKffSB3wgAHEr4CAAT2CAA== Date: Thu, 9 Jan 2020 11:22:53 +0000 Message-ID: <8792066c31a54ab08bb3caaee5b2ed58@huawei.com> References: <36BC36E1-2BE2-4DF6-8C04-F008B9F01BDC@apple.com> <4D7F4AD313D3FC43A053B309F97543CFA6F103AF@njmtexg5.research.att.com> <555df1b3f4eb4c43a52abe107cd79d28@huawei.com> <2B1D59E9-967A-49C0-BAF9-073CD8271B75@apple.com> In-Reply-To: <2B1D59E9-967A-49C0-BAF9-073CD8271B75@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.62.186] Content-Type: multipart/alternative; boundary="_000_8792066c31a54ab08bb3caaee5b2ed58huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:23:00 -0000 --_000_8792066c31a54ab08bb3caaee5b2ed58huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBuZXdzIFRvbW15ISBUaGFua3MgYSBsb3QgVGFsIGZvciB5b3VyIGhlbHAhDQpCZXN0IFJl Z2FyZHMsDQoNCkdpdXNlcHBlDQoNCkZyb206IHRwYXVseUBhcHBsZS5jb20gW21haWx0bzp0cGF1 bHlAYXBwbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDgsIDIwMjAgNjoyNSBQTQ0K VG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPg0KQ2M6 IElFVEYgSVBQTSBXRyA8aXBwbUBpZXRmLm9yZz47IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YWNt QHJlc2VhcmNoLmF0dC5jb20+OyBUYWwgTWl6cmFoaSA8dGFsLm1penJhaGkucGhkQGdtYWlsLmNv bT4NClN1YmplY3Q6IFJlOiBbaXBwbV0gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWll dGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrDQoNClRoYW5rcywgR2l1c2VwcGUhDQoNClRhbCBo YXMgYWdyZWVkIHRvIHNoZXBoZXJkIHRoZSBkb2N1bWVudC4gVGhhbmtzIHZlcnkgbXVjaCB0byBU YWwhDQoNCkJlc3QsDQpUb21teQ0KDQoNCk9uIEphbiA3LCAyMDIwLCBhdCA1OjM1IEFNLCBHaXVz ZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbTxtYWlsdG86Z2l1c2Vw cGUuZmlvY2NvbGFAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpEZWFyIFRvbW15LCBBbGwsDQpUaGFu ayB5b3UhDQpJIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uICgtMDQpIG9mIHRo ZSBkcmFmdCBhbmQgaW5jbHVkZWQgQWwncyBjb21tZW50cy4NClJlZ2FyZGluZyB0aGUgRG9jdW1l bnQgU2hlcGhlcmQgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgQWwgTW9ydG9uIG9yIFRhbCBNaXpy YWhpLCBzaW5jZSB0aGV5IGdhdmUgdXNlZnVsIGlucHV0cyBhbmQgY29tbWVudHMgZHVyaW5nIHRo ZSBkZXZlbG9wbWVudCBvZiB0aGUgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQoNCkdpdXNlcHBlDQoN CkZyb206IHRwYXVseUBhcHBsZS5jb208bWFpbHRvOnRwYXVseUBhcHBsZS5jb20+IFttYWlsdG86 dHBhdWx5QGFwcGxlLmNvbV0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjMsIDIwMTkgODozNCBQ TQ0KVG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPG1h aWx0bzpnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPj47IElFVEYgSVBQTSBXRyA8aXBwbUBp ZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpDYzogTU9SVE9OLCBBTEZSRUQgQyAoQUwp IDxhY21AcmVzZWFyY2guYXR0LmNvbTxtYWlsdG86YWNtQHJlc2VhcmNoLmF0dC5jb20+PjsgVG9t bXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86dHBhdWx5 PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbaXBwbV0gV29ya2lu ZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrDQoN CkhlbGxvIGFsbCwNCg0KVGhhbmtzIGZvciB5b3VyIGlucHV0cyBkdXJpbmcgdGhlIGxhc3QgY2Fs bCEgV2Ugd2lsbCBwcm9ncmVzcyB0aGUgZG9jdW1lbnQgdG8gdGhlIElFU0cgb25jZSB3ZSBnZXQg YSBEb2N1bWVudCBTaGVwaGVyZCB3cml0ZS11cC4NCg0KQXV0aG9ycywgcGxlYXNlIHBvc3QgYW4g dXBkYXRlIG9mIHRoZSBkcmFmdCB0byBpbmNsdWRlIEFsJ3MgY29tbWVudHMgd2hlbiB5b3UgY2Fu Lg0KDQpXZSBhbHNvIGRvIG5lZWQgYSBEb2N1bWVudCBTaGVwaGVyZCB0byBjcmVhdGUgdGhlIHdy aXRlLXVwIGZvciB0aGlzIGRyYWZ0LiBJZiBhbnlvbmUgaW4gdGhlIGdyb3VwIHdobyBpcyBub3Qg YW4gYXV0aG9yIG9uIHRoaXMgZG9jdW1lbnQgd291bGQgbGlrZSB0byBiZSB0aGUgZG9jdW1lbnQg c2hlcGhlcmQsIHBsZWFzZSBzZW5kIGFuIGVtYWlsIHRvIHRoZSBjaGFpcnMhDQoNCkJlc3QsDQpU b21teQ0KDQoNCg0KT24gRGVjIDIyLCAyMDE5LCBhdCAyOjM0IFBNLCBHaXVzZXBwZSBGaW9jY29s YSA8Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbTxtYWlsdG86Z2l1c2VwcGUuZmlvY2NvbGFA aHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpEZWFyIEFsLA0KVGhhbmsgeW91IGZvciB0aGUgc3VwcG9y dCBhbmQgZm9yIHRoZSBpbnB1dHMuDQpZb3VyIHN1Z2dlc3Rpb25zIGFyZSBvayBhbmQgSSB3aWxs IGFkZHJlc3MgdGhlbSBpbiB0aGUgbmV3IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4NCg0KUmVnYXJk cywNCg0KR2l1c2VwcGUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpH aXVzZXBwZSBGaW9jY29sYQ0KTW9iaWxlOiArNDktMTUyMjI4MTI0MTg8dGVsOiUzY2ElMjBocmVm PT4iPjE1MjIyODEyNDE4PHRlbDoxNTIyMjgxMjQxOD4NCkVtYWlsOiBnaXVzZXBwZS5maW9jY29s YUBodWF3ZWkuY29tPG1haWx0bzolM2NhJTIwaHJlZj0+Ij5naXVzZXBwZS5maW9jY29sYUBodWF3 ZWkuY29tPG1haWx0bzpnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPg0KDQoNCg0KRnJvbTog TU9SVE9OLCBBTEZSRUQgQyAoQUwpPGFjbUByZXNlYXJjaC5hdHQuY29tPG1haWx0bzphY21AcmVz ZWFyY2guYXR0LmNvbT4+DQpUbzogVG9tbXkgUGF1bHk8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzp0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuLmlldGYub3JnPj47SUVU RiBJUFBNIFdHPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtpcHBtXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtZmlvY2NvbGEtaXBwbS1t dWx0aXBvaW50LWFsdC1tYXJrDQpUaW1lOiAyMDE5LTEyLTIyIDE4OjQxOjA4DQoNCkhpIElQUE0s DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IGRyYWZ0IG9mIG11bHRpcG9pbnQtYWx0LW1h cmssDQphcyB3ZWxsIGFzIHNldmVyYWwgZWFybGllciB2ZXJzaW9ucy4NCg0KSSBiZWxpZXZlIHRo ZSBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24sIHdpdGggYSBmZXcgbWlub3INCmNvbW1l bnRzIGJlbG93Lg0KDQpBbA0KDQoNCiAgICAgICAgICBtdWx0aXBvaW50LXRvLXBvaW50DQogICAg ICAgICAgICAgICstLS0tLS0rDQogICAgICAgICAgLS0tPD4gIFIxICA8Pg0KICAgICAgICAgICAg ICArLS0tLS0tKyBcDQogICAgICAgICAgICAgICAgICAgICAgICBcICstLS0tLS0rDQogICAgICAg ICAgICAgICAgICAgICAgICA8PiAgUjQgIDw+DQogICAgICAgICAgICAgICAgICAgICAgICAvICst LS0tLS0rIFwNCiAgICAgICAgICAgICAgKy0tLS0tLSsgLyAgICAgICAgICAgIFwgKy0tLS0tLSsN CiAgICAgICAgICAtLS08PiAgUjIgIDw+ICAgICAgICAgICAgICA8PiAgUjQgIDw+LS0tDQogICAg ICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAgICAvICstLS0tLS0rDQogICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0rIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICA8PiAgUjUg IDw+DQogICAgICAgICAgICAgICAgICAgICAgICAvICstLS0tLS0rDQogICAgICAgICAgICAgICst LS0tLS0rIC8NCiAgICAgICAgICAtLS08PiAgUjMgIDw+DQogICAgICAgICAgICAgICstLS0tLS0r DQoNCknigJltIGZhaXJseSBzdXJlIHRoZSBSb3V0ZXIgb24gdGhlIGZhciByaWdodCBpcyBSNiAo RmlndXJlIDEpLg0KDQpBbHNvIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24gMyByZWFkczoN CiAgIFdoaWxlIEVDTVAgZmxvdyBpcyBpbiBzY29wZSBieSBkZWZpbml0aW9uLCBzaW5jZSBpdCBp cyBhIHBvaW50LXRvLQ0KICAgbXVsdGlwb2ludCB1bmljYXN0IGZsb3cuDQpUaGVyZSBpcyBhbiBp c3N1ZSB3aXRoIHR3byBwaHJhc2VzIGJlZ2lubmluZyDigJxXaGlsZeKAnSBhbmQg4oCcc2luY2Xi gJ0sIG1heWJlIHRoaXMNCndhcyBtZWFudCwgKHBsdXMgdGhlIHBocmFzZSBpbiBpdGFsaWNzPyk6 DQogICBBbiBFQ01QIGZsb3cgaXMgaW4gc2NvcGUgYnkgZGVmaW5pdGlvbiwgc2luY2UgaXQgaXMg YSBwb2ludC10by0NCiAgIG11bHRpcG9pbnQgdW5pY2FzdCBmbG93LCBfb3IvYW5kIGEgcG9pbnQt dG8tcG9pbnQgbXVsdGlwYXRoIGZsb3dfPw0KDQpTZWN0aW9uIDQuMQ0KDQpbSS1ELmFtZi1pcHBt LXJvdXRlPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tbXVsdGlw b2ludC1hbHQtbWFyay0wMyNyZWYtSS1ELmFtZi1pcHBtLXJvdXRlPl0gIFJlZmVyZW5jZSBvdXQg b2YgZGF0ZSwgcGxlYXNlIHVzZSBXRyB2ZXJzaW9uLg0KDQpTZWN0aW9uIDUNCg0KICAgQW5kIGlu IGNhc2Ugb2Ygbm8gcGFja2V0IGxvc3Mgb2NjdXJyaW5nIGluIHRoZSBtYXJraW5nIHBlcmlvZCwg aWYgYWxsDQogICB0aGUgaW5wdXQgYW5kIG91dHB1dCBwb2ludHMgb2YgdGhlIG5ldHdvcmsgZG9t YWluIHRvIGJlIG1vbml0b3JlZCBhcmUNCiAgIG1lYXN1cmVtZW50IHBvaW50cywgdGhlIHN1bSBv ZiB0aGUgbnVtYmVyIG9mIHBhY2tldHMgb24gYWxsIHRoZQ0KICAgaW5ncmVzcyBpbnRlcmZhY2Vz IGFuZCBvbiBhbGwgdGhlIGVncmVzcyBpbnRlcmZhY2VzIGlzIHRoZSBzYW1lLg0KU3VnZ2VzdA0K ICAgQW5kIGluIGNhc2Ugb2Ygbm8gcGFja2V0IGxvc3Mgb2NjdXJyaW5nIGluIHRoZSBtYXJraW5n IHBlcmlvZCwgaWYgYWxsDQogICB0aGUgaW5wdXQgYW5kIG91dHB1dCBwb2ludHMgb2YgdGhlIG5l dHdvcmsgZG9tYWluIHRvIGJlIG1vbml0b3JlZCBhcmUNCiAgIG1lYXN1cmVtZW50IHBvaW50cywg dGhlIHN1bSBvZiB0aGUgbnVtYmVyIG9mIHBhY2tldHMgb24gYWxsIHRoZQ0KICAgaW5ncmVzcyBp bnRlcmZhY2VzIF9lcXVhbHMgdGhlIG51bWJlciBvbiBlZ3Jlc3MgaW50ZXJmYWNlcyBmb3IgdGhl IF9tb25pdG9yZWRfZmxvdy4NCj09PT09PT09PT09DQogICBJdCBpcyBwb3NzaWJsZSB0byBkZWZp bmUgdGhlIE5ldHdvcmsgUGFja2V0IExvc3MgKGZvciAxIGZsb3csIGZvciAxDQogICBwZXJpb2Qp OiA8PEluIGEgcGFja2V0IG5ldHdvcmssIHRoZSBudW1iZXIgb2YgbG9zdCBwYWNrZXRzIGlzIHRo ZQ0KICAgbnVtYmVyIG9mIHBhY2tldHMgY291bnRlZCBieSB0aGUgaW5wdXQgbm9kZXMgbWludXMg dGhlIG51bWJlciBvZg0KICAgcGFja2V0cyBjb3VudGVkIGJ5IHRoZSBvdXRwdXQgbm9kZXM+Pi4N ClN1Z2dlc3QNCiAgIEl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgTmV0d29yayBQYWNrZXQg TG9zcyAoZm9yIDEgX21vbml0b3JlZF9mbG93LCBmb3IgMQ0KICAgcGVyaW9kKTogPDxJbiBhIHBh Y2tldCBuZXR3b3JrLCB0aGUgbnVtYmVyIG9mIGxvc3QgcGFja2V0cyBpcyB0aGUNCiAgIG51bWJl ciBvZiBwYWNrZXRzIGNvdW50ZWQgYnkgdGhlIGlucHV0IG5vZGVzIG1pbnVzIHRoZSBudW1iZXIg b2YNCiAgIHBhY2tldHMgY291bnRlZCBieSB0aGUgb3V0cHV0IG5vZGVzPj4uDQoNClNlY3Rpb24g MTMNCg0KWW91IGNhbiBwcm9iYWJseSBqdXN0IHNheSwg4oCcVGhpcyBtZW1vIG1ha2VzIG5vIHJl cXVlc3RzIG9mIElBTkEu4oCdDQoNCg0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0Bp ZXRmLi5vcmddIE9uIEJlaGFsZiBPZiBUb21teSBQYXVseQ0KU2VudDogTW9uZGF5LCBEZWNlbWJl ciA5LCAyMDE5IDM6MTggUE0NClRvOiBJRVRGIElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc8bWFpbHRv OmlwcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxs OiBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsNCg0KSGVsbG8gSVBQTSwN Cg0KQ29udGludWluZyBvbiBpbiBvdXIgbGlzdCBvZiBMYXN0IENhbGxzLCB3ZSBhcmUgbm93IGJl Z2lubmluZyB0aGUgV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtaXBwbS1t dWx0aXBvaW50LWFsdC1tYXJrOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJE aWV0Zi0yRGlwcG0tMkRtdWx0aXBvaW50LTJEYWx0LTJEbWFyay0yRDAzJmQ9RHdNRkFnJmM9TEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1DcmNVSGlFTkl0 dWdYeVZDNEY2S25OMWYwTEVjVjNGNjh2aXR6bE9rLTA0JnM9ODdZSkRtdEdkOHE1SDRHcE5kN2w1 U016NmY1bEtVMzR4ZGRGSVJkSTdqRSZlPT4NCg0KVGhlIExhc3QgQ2FsbCB3aWxsIGVuZCBvbiBN b25kYXksIERlY2VtYmVyIDIzLi4uIFBsZWFzZSByZXBseSB0byBpcHBtQGlldGYub3JnPG1haWx0 bzppcHBtQGlldGYub3JnPiB3aXRoIHlvdXIgcmV2aWV3cywgYW5kIGluZGljYXRlIHdoZXRoZXIg b3Igbm90IHlvdSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4N Cg0KQmVzdCwNClRvbW15IChhcyBjby1jaGFpcikNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZzxt YWlsdG86aXBwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbQ0KDQo= --_000_8792066c31a54ab08bb3caaee5b2ed58huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Hb29kIG5ld3MgVG9tbXkhIFRoYW5rcyBhIGxvdCBUYWwgZm9yIHlvdXIgaGVscCE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRwYXVseUBhcHBsZS5jb20gW21h aWx0bzp0cGF1bHlAYXBwbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFu dWFyeSA4LCAyMDIwIDY6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEdpdXNlcHBlIEZpb2Njb2xhICZs dDtnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBJ UFBNIFdHICZsdDtpcHBtQGlldGYub3JnJmd0OzsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpICZsdDth Y21AcmVzZWFyY2guYXR0LmNvbSZndDs7IFRhbCBNaXpyYWhpICZsdDt0YWwubWl6cmFoaS5waGRA Z21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2lwcG1dIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyazxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgR2l1c2VwcGUh PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWwgaGFzIGFn cmVlZCB0byBzaGVwaGVyZCB0aGUgZG9jdW1lbnQuIFRoYW5rcyB2ZXJ5IG11Y2ggdG8gVGFsITxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9t bXk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiA3 LCAyMDIwLCBhdCA1OjM1IEFNLCBHaXVzZXBwZSBGaW9jY29sYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20iPmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWFyIFRvbW15LCBBbGwsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiAo LTA0KSBvZiB0aGUgZHJhZnQgYW5kIGluY2x1ZGVkIEFsJ3MgY29tbWVudHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZGluZyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgSSB3 b3VsZCBsaWtlIHRvIHN1Z2dlc3QgQWwgTW9ydG9uIG9yIFRhbCBNaXpyYWhpLCBzaW5jZSB0aGV5 IGdhdmUgdXNlZnVsIGlucHV0cyBhbmQgY29tbWVudHMgZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBv ZiB0aGUgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ R2l1c2VwcGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzp0 cGF1bHlAYXBwbGUuY29tIj50cGF1bHlAYXBwbGUuY29tPC9hPg0KIFs8YSBocmVmPSJtYWlsdG86 dHBhdWx5QGFwcGxlLmNvbSI+bWFpbHRvOnRwYXVseUBhcHBsZS5jb208L2E+XTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBE ZWNlbWJlciAyMywgMjAxOSA4OjM0IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5HaXVzZXBwZSBGaW9jY29sYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20iPmdpdXNlcHBlLmZpb2Nj b2xhQGh1YXdlaS5jb208L2E+Jmd0OzsgSUVURiBJUFBNIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NT1JUT04sIEFMRlJF RCBDIChBTCkgJmx0OzxhIGhyZWY9Im1haWx0bzphY21AcmVzZWFyY2guYXR0LmNvbSI+YWNtQHJl c2VhcmNoLmF0dC5jb208L2E+Jmd0OzsgVG9tbXkgUGF1bHkgJmx0OzxhIGhyZWY9Im1haWx0bzp0 cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmciPnRwYXVseT00MGFwcGxlLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbaXBwbV0gV29ya2luZyBHcm91cCBM YXN0IENhbGw6IGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGVsbG8gYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIGlu cHV0cyBkdXJpbmcgdGhlIGxhc3QgY2FsbCEgV2Ugd2lsbCBwcm9ncmVzcyB0aGUgZG9jdW1lbnQg dG8gdGhlIElFU0cgb25jZSB3ZSBnZXQgYSBEb2N1bWVudCBTaGVwaGVyZCB3cml0ZS11cC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+QXV0aG9yczwvYj4sIHBsZWFzZSBwb3N0IGFuIHVw ZGF0ZSBvZiB0aGUgZHJhZnQgdG8gaW5jbHVkZSBBbCdzIGNvbW1lbnRzIHdoZW4geW91IGNhbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+V2UgYWxzbyBkbyBuZWVkIGEgRG9jdW1lbnQg U2hlcGhlcmQ8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPnRvIGNyZWF0ZSB0aGUgd3JpdGUtdXAgZm9yIHRoaXMgZHJhZnQuIElmIGFueW9uZSBpbiB0 aGUgZ3JvdXAgd2hvIGlzIG5vdCBhbiBhdXRob3Igb24gdGhpcyBkb2N1bWVudCB3b3VsZCBsaWtl IHRvIGJlIHRoZSBkb2N1bWVudCBzaGVwaGVyZCwgcGxlYXNlIHNlbmQNCiBhbiBlbWFpbCB0byB0 aGUgY2hhaXJzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9t bXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIERlYyAyMiwgMjAxOSwgYXQgMjozNCBQTSwg R2l1c2VwcGUgRmlvY2NvbGEgJmx0OzxhIGhyZWY9Im1haWx0bzpnaXVzZXBwZS5maW9jY29sYUBo dWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5naXVzZXBwZS5maW9jY29sYUBo dWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xv cjojMzMzMzMzIj5EZWFyJm5ic3A7QWwsPGJyPg0KVGhhbmsmbmJzcDt5b3UmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDtzdXBwb3J0Jm5ic3A7YW5kJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7aW5wdXRz Ljxicj4NCllvdXImbmJzcDtzdWdnZXN0aW9ucyZuYnNwO2FyZSZuYnNwO29rJm5ic3A7YW5kJm5i c3A7SSZuYnNwO3dpbGwmbmJzcDthZGRyZXNzJm5ic3A7dGhlbSZuYnNwO2luJm5ic3A7dGhlJm5i c3A7bmV3Jm5ic3A7cmV2aXNpb24mbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2RyYWZ0Ljxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KR2l1c2VwcGU8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Y29s b3I6IzMzMzMzMyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0K PC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjojMzMzMzMzIj48YnI+ DQpHaXVzZXBwZSZuYnNwO0Zpb2Njb2xhPGJyPg0KTW9iaWxlOiZuYnNwOyYjNDM7NDktPC9zcGFu PjxhIGhyZWY9InRlbDolM2NhJTIwaHJlZj0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0 O2NvbG9yOnB1cnBsZSI+MTUyMjI4MTI0MTg8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuMHB0O2NvbG9yOiMzMzMzMzMiPiZxdW90OyZndDs8L3NwYW4+PGEgaHJlZj0idGVsOjE1 MjIyODEyNDE4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjpwdXJwbGUiPjE1 MjIyODEyNDE4PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtjb2xvcjoj MzMzMzMzIj4mbmJzcDsmbmJzcDs8YnI+DQpFbWFpbDombmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOiUzY2ElMjBocmVmPSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Y29sb3I6cHVy cGxlIj5naXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjBwdDtjb2xvcjojMzMzMzMzIj4mcXVvdDsmZ3Q7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjBwdDtjb2xvcjpwdXJwbGUiPmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2NvbG9yOiMzMzMzMzMiPjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzo2LjBwdCAwaW4gMGluIDBp bjtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCIgbmFtZT0iQW55T2ZmaWNlLUJhY2tncm91bmQtSW1hZ2UiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPk1PUlRPTiwgQUxGUkVEIEMgKEFMKSZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmFjbUByZXNlYXJjaC5hdHQuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+YWNt QHJlc2VhcmNoLmF0dC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U b21teSBQYXVseSZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBk bWFyYy4uaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj50cGF1bHk9NDBh cHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7 SUVURg0KIElQUE0gV0cmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aXBwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtpcHBtXSBXb3JraW5nIEdyb3VwIExh c3QgQ2FsbDogZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGltZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4y MDE5LTEyLTIyIDE4OjQxOjA4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBJUFBNLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBoYXZlIHJldmlld2VkIHRoZSBs YXRlc3QgZHJhZnQgb2YgbXVsdGlwb2ludC1hbHQtbWFyayw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+YXMgd2VsbCBhcyBzZXZlcmFsIGVhcmxpZXIgdmVyc2lvbnMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGJlbGlldmUgdGhlIGRyYWZ0IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbiwgd2l0aCBhIGZldyBtaW5vcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5jb21tZW50cyBiZWxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpcG9pbnQtdG8tcG9pbnQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tJiM0Mzs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLSZsdDsmZ3Q7Jm5ic3A7IFIxJm5ic3A7ICZsdDsmZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LSYjNDM7IFw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFwgJiM0MzstLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyZndDsmbmJzcDsgUjQmbmJzcDsgJmx0OyZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8gJiM0MzstLS0t LS0mIzQzOyBcPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tLS0tLSYjNDM7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCAmIzQzOy0tLS0tLSYjNDM7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLS0mbHQ7Jmd0OyZuYnNwOyBSMiZuYnNwOyAmbHQ7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7Jmd0OyZuYnNwOyBSNCZuYnNwOyAmbHQ7Jmd0Oy0tLTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0m IzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvICYjNDM7LS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tJiM0MzsgLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jmx0OyZndDsmbmJzcDsgUjUmbmJzcDsgJmx0OyZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8gJiM0MzstLS0tLS0m IzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLS0tLS0mIzQzOyAvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0mbHQ7Jmd0OyZuYnNw OyBSMyZuYnNwOyAmbHQ7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SeKAmW0gZmFpcmx5IHN1cmUgdGhlIFJvdXRlciBvbiB0aGUgZmFy IHJpZ2h0IGlzIFI2IChGaWd1cmUgMSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5BbHNvIHRoZSBsYXN0IHNlbnRlbmNlIG9mIFNlY3Rpb24gMyByZWFkczo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoaWxlIEVDTVAgZmxvdyBp cyBpbiBzY29wZSBieSBkZWZpbml0aW9uLCBzaW5jZSBpdCBpcyBhIHBvaW50LXRvLTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbXVsdGlwb2ludCB1bmljYXN0IGZsb3cu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZXJlIGlzIGFuIGlzc3VlIHdpdGggdHdvIHBo cmFzZXMgYmVnaW5uaW5nIOKAnFdoaWxl4oCdIGFuZCDigJxzaW5jZeKAnSwgbWF5YmUgdGhpczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij53YXMgbWVhbnQsIChwbHVzIHRoZSBwaHJhc2UgaW4g aXRhbGljcz8pOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQW4gRUNN UCBmbG93IGlzIGluIHNjb3BlIGJ5IGRlZmluaXRpb24sIHNpbmNlIGl0IGlzIGEgcG9pbnQtdG8t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtdWx0aXBvaW50IHVuaWNh c3QgZmxvdywgX29yLzxpPmFuZCBhIHBvaW50LXRvLXBvaW50IG11bHRpcGF0aCBmbG93PC9pPl8/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5TZWN0aW9uIDQuMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Wzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDMjcmVmLUktRC5hbWYtaXBwbS1yb3V0ZSIg dGl0bGU9IiZxdW90O0FkdmFuY2VkIFVuaWRpcmVjdGlvbmFsIFJvdXRlIEFzc2Vzc21lbnQmcXVv dDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOnB1cnBsZSI+SS1ELmFtZi1pcHBtLXJvdXRlPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+XSZuYnNwOw0KIFJlZmVyZW5jZSBvdXQgb2YgZGF0ZSwgcGxlYXNlIHVzZSBXRyB2 ZXJzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2Vj dGlvbiA1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgQW5kIGluIGNhc2Ugb2Ygbm8gcGFja2V0IGxvc3Mgb2NjdXJyaW5nIGluIHRoZSBt YXJraW5nIHBlcmlvZCwgaWYgYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyB0aGUgaW5wdXQgYW5kIG91dHB1dCBwb2ludHMgb2YgdGhlIG5ldHdvcmsgZG9tYWluIHRv IGJlIG1vbml0b3JlZCBhcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IG1lYXN1cmVtZW50IHBvaW50cywgdGhlIHN1bSBvZiB0aGUgbnVtYmVyIG9mIHBhY2tldHMgb24g YWxsIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW5ncmVzcyBp bnRlcmZhY2VzIGFuZCBvbiBhbGwgdGhlIGVncmVzcyBpbnRlcmZhY2VzIGlzIHRoZSBzYW1lLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWdnZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBBbmQgaW4gY2FzZSBvZiBubyBwYWNrZXQgbG9zcyBvY2N1cnJpbmcg aW4gdGhlIG1hcmtpbmcgcGVyaW9kLCBpZiBhbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHRoZSBpbnB1dCBhbmQgb3V0cHV0IHBvaW50cyBvZiB0aGUgbmV0d29yayBk b21haW4gdG8gYmUgbW9uaXRvcmVkIGFyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgbWVhc3VyZW1lbnQgcG9pbnRzLCB0aGUgc3VtIG9mIHRoZSBudW1iZXIgb2YgcGFj a2V0cyBvbiBhbGwgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBp bmdyZXNzIGludGVyZmFjZXMgXzxpPmVxdWFscyB0aGUgbnVtYmVyIG9uIGVncmVzcyBpbnRlcmZh Y2VzIGZvciB0aGUgX21vbml0b3JlZF9mbG93PC9pPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEl0 IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgTmV0d29yayBQYWNrZXQgTG9zcyAoZm9yIDEgZmxv dywgZm9yIDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBlcmlvZCk6 ICZsdDsmbHQ7SW4gYSBwYWNrZXQgbmV0d29yaywgdGhlIG51bWJlciBvZiBsb3N0IHBhY2tldHMg aXMgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBudW1iZXIgb2Yg cGFja2V0cyBjb3VudGVkIGJ5IHRoZSBpbnB1dCBub2RlcyBtaW51cyB0aGUgbnVtYmVyIG9mPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYWNrZXRzIGNvdW50ZWQgYnkg dGhlIG91dHB1dCBub2RlcyZndDsmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWdn ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJdCBpcyBwb3NzaWJs ZSB0byBkZWZpbmUgdGhlIE5ldHdvcmsgUGFja2V0IExvc3MgKGZvciAxIF88aT5tb25pdG9yZWQ8 L2k+X2Zsb3csIGZvciAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBw ZXJpb2QpOiAmbHQ7Jmx0O0luIGEgcGFja2V0IG5ldHdvcmssIHRoZSBudW1iZXIgb2YgbG9zdCBw YWNrZXRzIGlzIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbnVt YmVyIG9mIHBhY2tldHMgY291bnRlZCBieSB0aGUgaW5wdXQgbm9kZXMgbWludXMgdGhlIG51bWJl ciBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGFja2V0cyBjb3Vu dGVkIGJ5IHRoZSBvdXRwdXQgbm9kZXMmZ3Q7Jmd0Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlY3Rpb24gMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPllvdSBjYW4gcHJvYmFibHkganVzdCBzYXksIOKAnFRoaXMg bWVtbyBtYWtlcyBubyByZXF1ZXN0cyBvZiBJQU5BLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5pcHBtDQogWzxh IGhyZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi4ub3JnIj5tYWlsdG86aXBwbS1ib3VuY2Vz QGlldGYuLm9yZzwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+VG9tbXkgUGF1bHk8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBEZWNlbWJlciA5 LCAyMDE5IDM6MTggUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklFVEYgSVBQTSBXRyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5pcHBtQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W2lwcG1d IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQt YWx0LW1hcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBJUFBNLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29udGludWluZyBvbiBpbiBvdXIgbGlz dCBvZiBMYXN0IENhbGxzLCB3ZSBhcmUgbm93IGJlZ2lubmluZyB0aGUgV29ya2luZyBHcm91cCBM YXN0IENhbGwgZm9yJm5ic3A7ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcms6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v cmdfaHRtbF9kcmFmdC0yRGlldGYtMkRpcHBtLTJEbXVsdGlwb2ludC0yRGFsdC0yRG1hcmstMkQw MyZhbXA7ZD1Ed01GQWcmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3JmFtcDttPUNyY1VIaUVOSXR1Z1h5VkM0RjZLbk4xZjBMRWNWM0Y2OHZp dHpsT2stMDQmYW1wO3M9ODdZSkRtdEdkOHE1SDRHcE5kN2w1U016NmY1bEtVMzR4ZGRGSVJkSTdq RSZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyay0wMzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBMYXN0IENhbGwg d2lsbCBlbmQgb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGI+TW9uZGF5LCBEZWNlbWJlciAyMzwvYj4uLi4gUGxlYXNlIHJlcGx5IHRvPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpp cHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pcHBtQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ d2l0aA0KIHlvdXIgcmV2aWV3cywgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSB0aGlu ayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRvbW15IChhcyBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aXBwbUBpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBw bTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_8792066c31a54ab08bb3caaee5b2ed58huaweicom_-- From nobody Thu Jan 9 12:20:14 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D99120871; Thu, 9 Jan 2020 12:20:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ippm-chairs@ietf.org, ietf@kuehlewind.net, tpauly@apple.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157860120832.11758.1340724181031843220.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 12:20:08 -0800 Archived-At: Subject: [ippm] ippm - New Meeting Session Request for IETF 107 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:20:12 -0000 A new meeting session request has just been submitted by Tommy Pauly, a Chair of the ippm working group. --------------------------------------------------------- Working Group Name: IP Performance Measurement Area Name: Transport Area Session Requester: Tommy Pauly Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: httpbis taps quic intarea maprg panrg tsvarea tsvwg capport Technology Overlap: 6man bfd bmwg v6ops opsec spring Key Participant Conflict: mpls People who must be present: Alfred Channon Morton Frank Brockners Brian Trammell Mirja Kuehlewind Bill Cerveny Giuseppe Fioccola Tommy Pauly Greg Mirsky <gregimirsky@gmail.com>> Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jan 20 23:33:56 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B476120096 for ; Mon, 20 Jan 2020 23:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mellanox.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_U0kESOl4Da for ; Mon, 20 Jan 2020 23:33:49 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (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 1B2C21200B6 for ; Mon, 20 Jan 2020 23:33:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cwI7FNl89qCQZJES1OovrhgSSvzZ09nnR3kqMMG60+RvYG4nhkRBWYShK/gpqzfymA879S7ZKDSC19SStHU/8QkXfgVJb6KN9m8ElLo6NzOFp6W+iajQSTD5oRcHs+orxmYPOTfrJdj3bzQvccatT2ky+zOXTU7wY+USjP0zV0MWIgTosu4nfoQV1z7ztPHA5SzjnynbWWWdw0j8e4VDZonwcEgMK845Jum4XAPA5JUXRJdSz9fY5TSs1ywvDQlwZLCchwqdfi3vU80fLT+O/FO7ZiDhdpy09cC3yLUawIQbpnHIQ4hhYjoWJqNe9tPFDewmb3NUuTtjUY4KhDKjgQ== 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=HDTtIGB2CWEadrQu+8/VYgS8KQlW/e0RTLEfFoPiGto=; b=JWjjPAxhbCyVW2Crj9EZ0BWWSoBp1adidtTTpQtrsB4Jh2c7RcGC4VQKO0NWdifoz9eLPOX1cbiFUgrt4FriR9ohRSV3GAjmPjDyIPanHqNeRcwwYvJVJWzELt2cKCgO2DGDUDTAyfnGYUfyv2A+CkbLFN1fhg1NcV1PhlPkOotpng+zRaIxkhnDmthOeHfNwoxA4ris/F+X2/mdXQuiW6fDAok+Erfxkt9I4SKCzmpMtkatWS+1xQKE3tTQuXl76KGeI8MmjDD93IkIosDX7umUTH+aKb2e9/5iuOF/ePFOUzNGkWTd41VkkC7nniNn8Lzd1WYk52I5eH5oYAi9XQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HDTtIGB2CWEadrQu+8/VYgS8KQlW/e0RTLEfFoPiGto=; b=H9+pKX9oWAhQD1sgMO5DoI4q5vzv2IxmWhZ+zKSpDI9sleUpJIUqjp+f3SMLkBKAMD6xP6L6HM9lFLnqwxcP2Q+yXjyeN4QGXN+2nB/L/sCcaCe7jct0Pb4hmYVq3xK/arJtA5bjo6xWrdT1BEzvDppImt1oql8ZZ1oERZm++z8= Received: from AM6PR05MB4118.eurprd05.prod.outlook.com (52.135.166.159) by AM6PR05MB5736.eurprd05.prod.outlook.com (20.178.94.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Tue, 21 Jan 2020 07:33:46 +0000 Received: from AM6PR05MB4118.eurprd05.prod.outlook.com ([fe80::b04c:eac4:d537:c943]) by AM6PR05MB4118.eurprd05.prod.outlook.com ([fe80::b04c:eac4:d537:c943%6]) with mapi id 15.20.2644.026; Tue, 21 Jan 2020 07:33:46 +0000 From: Barak Gafni To: Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXo3ge3BF3mFOkSl30CtIqgmY6f0zM2Q Date: Tue, 21 Jan 2020 07:33:19 +0000 Deferred-Delivery: Tue, 21 Jan 2020 07:33:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: he-IL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gbarak@mellanox.com; x-originating-ip: [69.209.31.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 66ff4554-3874-43d4-a273-08d79e443fea x-ms-traffictypediagnostic: AM6PR05MB5736: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(346002)(376002)(136003)(189003)(199004)(66446008)(66556008)(478600001)(66946007)(26005)(8936002)(110136005)(71200400001)(66476007)(186003)(53546011)(6506007)(6666004)(76116006)(64756008)(81156014)(81166006)(86362001)(316002)(8676002)(9326002)(55016002)(4744005)(5660300002)(52536014)(33656002)(2906002)(9686003)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB5736; H:AM6PR05MB4118.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n3bzZP3IX1stIz4zqhgcLC0bl/U7Dyz7eqEyzQowtWf7ztU5yP320SzkOaLZsV7fofIdelegAHw9MfVh0zYiF6TZL2fRsCQrnQjcLoVEW53hM621ifcqs14n670AwfOJgxACjYXDsVYTqJSUElKo7K99S8jbNxrvixWTj9rghE9WhpHRazOBGNmqLsG7pFzzquTvygDQ6N+JCN5hD0688RFdM44v7GCh2pxg5GXPa/CDxuHcX+5JhnKwFcYBidrtanp7Xu71xM3XSt8RXWxUJ2E62DVspRWRI7KInxeL/t/PCjekZzpg9LgbBxh2NXu9KYI1ffDajm4kSuqMVNO8lE6fTsHg5VgJ0BFvUVLThVY0cYQ3E/HxmkSrlU7ZSMxLvUBpgeFicjHEKur7tGebAeTcP2hiKuK08V0pE/Mq/1kYJsI6gFQOKKqiwV4SN0bFg/9OSjO0InZWgvF6tHornMJnCsmOEusisNklevPlFvUV6JmGrHxA9+th6XbKVgwwB8t5BtN740lSUCnDQwinhg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR05MB41186C7C242F4EF6ED1DDFECB90D0AM6PR05MB4118eurp_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66ff4554-3874-43d4-a273-08d79e443fea X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 07:33:46.2081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3HeSjrXb1GWdJhmgXyzp4gDAwKBlH6NzcEw893tITE79YaRWdTAMgNhX2btJ5b1+M17vbMSXOVmpkA+X+QXhfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB5736 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 07:33:55 -0000 --_000_AM6PR05MB41186C7C242F4EF6ED1DDFECB90D0AM6PR05MB4118eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Few comments to consider: 1. Queue depth format - In order to align the standardization of units a= cross the route, as done for time measurements for example, I would suggest= to direct implementations towards reporting Bytes, rather than keeping it = open for interpretation by the implementors. 2. Additional measurements to consider - amount of Bytes transmitted by = a port, rate of transmission of a port. Thanks, Barak From: ippm On Behalf Of Tommy Pauly Sent: Tuesday, January 7, 2020 8:48 AM To: IETF IPPM WG Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21. Please reply to ippm@ietf.or= g with your reviews and comments. Please indicate whe= ther you think this document is ready for publication. Best, Tommy (as co-chair) --_000_AM6PR05MB41186C7C242F4EF6ED1DDFECB90D0AM6PR05MB4118eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Few comments to consider:

  1. Queue depth format – In order to align the standardization of u= nits across the route, as done for time measurements for example, I would s= uggest to direct implementations towards reporting Bytes, rather than keeping it open for interpretation by the implementors.=
  2. Additional measurements to consider – amount of= Bytes transmitted by a port, rate of transmission of a port.

 

Thanks,

Barak

 

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

Happy New Year! This email starts a working group la= st call for "Data Fields for In-situ OAM" (https://datatracker.ietf.org/doc/draft-= ietf-ippm-ioam-data/).

 

The last call will end on Tuesday, January 21= . Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_AM6PR05MB41186C7C242F4EF6ED1DDFECB90D0AM6PR05MB4118eurp_-- From nobody Tue Jan 21 05:41:00 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3B91200E5 for ; Tue, 21 Jan 2020 05:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.399 X-Spam-Level: X-Spam-Status: No, score=-14.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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=jCQAzF3H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Fx/W0i0i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWPfRJJ8fxvU for ; Tue, 21 Jan 2020 05:40:52 -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 C71A912007C for ; Tue, 21 Jan 2020 05:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11379; q=dns/txt; s=iport; t=1579614051; x=1580823651; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=h0C4mjzpx2beRJCZ7G/MNrAGb+mhNDtc9ygkawRn+Yk=; b=jCQAzF3HtwKG4HwseqPUEVV779bamwvosrlOvVHo4/bTX61RHFqlbbpH +R6Q0rWfOFxDuRphx2vN2R48hSZDfE5o9ed6SK7zXTs1TEDnsiGxT34gc VUIQ7MT1iHSBh3qbAPDrgXMQacE1dGFwya8/mI7kEnrc3JKOfgfkoBNY5 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AYj3zShxtqek2oabXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuLA1f8J/3sYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAgBV/iZe/5xdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYEkL1AFbFggBAsqhXCBaAOLAU6CEZMshGKBQoEQA1Q?= =?us-ascii?q?JAQEBDAEBIgsCAQGBY4JdAoISJDcGDgIDDQEBBAEBAQIBBQRthTcMhV4BAQE?= =?us-ascii?q?BAxILEBMBATgPAgEIEAEEAQEoBzIUCQgCBAESCBqCfwQCgX1NAy4BAgyiNgK?= =?us-ascii?q?BOYhhgieCfwEBBYEvARNBgwIDFYIMAwaBOAGFGoZ5GoFBP4ERR4JMPoJkAgI?= =?us-ascii?q?BARiBFAESASErCYMMgiyNbohDmSUKgjmHPY8PgkeICpAmjl6IYZIlAgQCBAU?= =?us-ascii?q?CDgEBBYFoIw1acXAVgycTPRgNh10kg3OFFIU/dAIBAQGBJIo2gjIBAQ?= X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="scan'208,217";a="409908741" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 13:40:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LDeowE004874 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 13:40:50 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:40:49 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 08:40:48 -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.1473.3 via Frontend Transport; Tue, 21 Jan 2020 07:40:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nPoCYk3/oeu/OhKQc/7GM/H0Ws70NBzBQn7x04HPVy/QZrU8skReCt1IUULYOLARb5RUGeHIiS7EQM+SnQPNputTEZiWb6G8k/fcuDHTFM1R/ovWARVtFS32jKtOmqzseKb/RsD/Q2F8cu/J/1XLwS5hSanbQSDkHg7+iD5Sv5ftl7Kz2M+g3OcapTz3JNgQdXRmqK/3Tk6SeodjBahoAaeALwHoqlEhxKOQGcfrt9ovcXTPkvKy8Z9AaicuiEEv20pz16SoyLKvt7/FK+zQM1BxaWWS1HrbSUVbzXbhUGKMQHQ0bo1OVWeT0Md8kMGKuEI1FrEpX5933lOE1qke7g== 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=4PWORfZob5LrnlAW0K7m7uFImqOuER2vTOBleN50d0M=; b=QObTQx5tzc08HBmPCxD+J5n1g7Ju9iqWTWZ6SI8GGdBBXMvFPwpWZzI5yx6zJavIu56HywGpZc4BOji8sBArnSm6OmMoxt6eM1PAt573RqvynNTvM76NAfR+3RVmmt+RpZ3L8q0+M21jdM/28Y4MXSmSJQk4KXdYfMGP889jdT2fFUop0W8yhUBM62b6gx41z3wBCryEjskOMRKjgQa58cnbAwR2cq/UwzO/bNRmLNJxUdXXB1IM9ViEnNclz4vdB4FV70fysWEe31I6Ltv6EXxk9wUMzgsFFeD2lBMbw8unks4MCVHz+gdbhCLRSp6y3WY7L5I9Jd3T/Lx6YntiOA== 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=4PWORfZob5LrnlAW0K7m7uFImqOuER2vTOBleN50d0M=; b=Fx/W0i0ibirB8lkVeym5FRr97GEAqLKkS4wbOqr0D4Uty4Ee8ZyK9dEL+VGheXVtkXwjWUD7MHWLuxHA8O4l78ot+kt4dc90oBqgdvx5Q+Vo20AJAhBt5dV3s0/yZ+6TU8WGCbQHy5F2cJDxQ5i3iuP0uN0ddkUz0adD6FOpXSs= Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.228.31) by BYAPR11MB3576.namprd11.prod.outlook.com (20.178.206.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.21; Tue, 21 Jan 2020 13:40:46 +0000 Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::e4af:d550:3094:46cf]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::e4af:d550:3094:46cf%4]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 13:40:46 +0000 From: "Frank Brockners (fbrockne)" To: Haoyu Song , Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXo6Tdne2RKNvUiZXnvcjdbYaaffx88AgBVrsXA= Date: Tue, 21 Jan 2020 13:40:46 +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: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com; x-originating-ip: [2001:420:44f0:1252:f96f:9d6:18a4:35e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0fab1aa1-867c-47be-4836-08d79e77851c x-ms-traffictypediagnostic: BYAPR11MB3576: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(199004)(189003)(71200400001)(7696005)(5660300002)(110136005)(52536014)(316002)(86362001)(64756008)(66556008)(66946007)(66476007)(66446008)(76116006)(81156014)(33656002)(9686003)(81166006)(186003)(8676002)(8936002)(478600001)(53546011)(6506007)(55016002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3576; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q7qOdqa/irdGAdsuaxnvErlbhlDKkErpVLYW/s1oZX//69gbnW4Zl+oQ567yYjw0E59nTYf2KnHw+60R5Caatw6CHKyv2W1UJsQHvC8kyIazyxHUs76bAxv59L4FpttsbJQiLkLN8MXrKxhoHtAER2RoRW+FApV5VDJ8O1ZgSR5oE5/eb9NJS5/keebOgKsh7CEWq8oIO5sFzn4JRjCJXR/n7/M+4e/ZvyTD0qNeaS++sLm5IKPJpx1cSgyzxpaYZuXUb/mSyInGzYulHtY01Osv6KL5ZJ0Y6uey/YmBvTSgJHqhy91a83xjOVxiVl/eR9sTcMAepLLYAkRa5dyhpx2L+bA+JX6grrMJazIPzElhPygpL0ssspCDGHwFzgh9aNpkdG3vKQXuhMQGB3xyV6K1jgBvBN+wPYklznmJVv368iZJt0qNKoWLcP1RwAhXuxBPzMt4vnWyj37TJREoQlNYoiFsq3+i7CtrHgNjF9NLz53gExH7dhkzrKiu7jxSEr5ROYxpKuo1DifS1EitOA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB25840E74A3C28FFE27F29ACBDA0D0BYAPR11MB2584namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0fab1aa1-867c-47be-4836-08d79e77851c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 13:40:46.6445 (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: xXow9SGc4E8WnP3DeHDSzwz3hypDDazrF9DKlGqV8q52nz3qBR10U24lGyWqzeJYRJpgRwzBvqY8BViKeZBgLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3576 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:40:57 -0000 --_000_BYAPR11MB25840E74A3C28FFE27F29ACBDA0D0BYAPR11MB2584namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Haoyu, Thanks. Please see inline ("...FB"). From: ippm On Behalf Of Haoyu Song Sent: Dienstag, 7. Januar 2020 23:26 To: Tommy Pauly ; IETF IPPM WG Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data IPPM and IOAM authors, I have a question about the variable length opaque data field in the trace = option. Does that mean each node may add a variable length field (i.e., use= a different scheme ID)? "When this field is part of the data field but a node populating the field has no opaque state data to report, the Length must be set to 0 and the Schema ID must be set to 0xFFFFFF to mean no schema." >From the above description, it seems so. Then there's a problem. If each n= ode's data has different size, then one can't guarantee that the RemainingL= en is exactly 0 when the data overflow happens. ...FB: Could you detail the problem a bit more: Why would the remaining len= gth need to be exactly 0 in case of a data overflow? If RemainingLen < (Nod= eLen + sizeof(opaque snapshot)) in 4 octet units, then a node would not add= data. Another issue: "If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the actual length added by each node. If IOAM-Trace-Type bit 22 is set, then the actual length added by a node would be (NodeLen + Opaque Data Length)." I think the "actual length added by a node would be (NodeLen+ size of opaqu= e state snapshot field). Because the opaque data is only a part of the opaq= ue state snapshot field, and (opaque data length + 4 byte)=3Dsize of opaqu= e state snapshot field. Some other places need similar clarification. ...FB: Thanks. It makes sense to harmonize the description and at the same = time, make it more specific - i.e. match it to what is already used in sec= tion 4.4.1, i.e. "NodeLen + sizeof(opaque snapshot)" in 4 octet units. Cheers, Frank Haoyu From: ippm > On Behalf = Of Tommy Pauly Sent: Tuesday, January 07, 2020 8:48 AM To: IETF IPPM WG > Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21.. Please reply to ippm@ietf.o= rg with your reviews and comments. Please indicate wh= ether you think this document is ready for publication. Best, Tommy (as co-chair) --_000_BYAPR11MB25840E74A3C28FFE27F29ACBDA0D0BYAPR11MB2584namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Haoyu,

 

Thanks. Please see inline (“…FB”).=

 

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Haoyu Song
Sent: Dienstag, 7. Januar 2020 23:26
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IP= PM WG <ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

IPPM and IOAM authors,

 

I have a question about the variable length opaque d= ata field in the trace option. Does that mean each node may add a variable = length field (i.e., use a different scheme ID)?

 

     “When this field is p= art of the data field but a node populating

      the field has no opaq= ue state data to report, the Length must be

      set to 0 and the Sche= ma ID must be set to 0xFFFFFF to mean no

      schema.”

 

From the above description, it seems so.  Then = there’s a problem. If each node’s data has different size, then= one can’t guarantee that the RemainingLen is exactly 0 when the data= overflow happens.

 

…FB: Could you detail the problem a bit = more: Why would the remaining length need to be exactly 0 in case of a data= overflow? If RemainingLen < (NodeLen + sizeof(opaque snapshot)) in = 4 octet units, then a node would not add data.

 

Another issue:

   

    “If IOAM-Trace-Type bi= t 22 is not set, then NodeLen specifies the

      actual length added b= y each node.  If IOAM-Trace-Type bit 22 is

      set, then the actual = length added by a node would be (NodeLen +

      Opaque Data Length).&= #8221;

 

I think the “ac= tual length added by a node would be (NodeLen+ size of opaque state sna= pshot field). Because the opaque data is only a part of the opaque state sn= apshot field, and  (opaque data length + 4 byte)=3Dsize of opaque state snapshot field.  Some other places need similar clari= fication.

…FB: Than= ks. It makes sense to harmonize the description and at the same time, make = it more specific – i.e. match it  to what is already used in sec= tion 4.4.1, i.e. “NodeLen + sizeof(opaque snapshot)” in 4 octet units.

Cheers, Frank

 

Haoyu

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, January 07, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org<= /a>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

 

The last call will end on Tuesday, January 21= .. Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_BYAPR11MB25840E74A3C28FFE27F29ACBDA0D0BYAPR11MB2584namp_-- From nobody Tue Jan 21 05:53:45 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE631200F7 for ; Tue, 21 Jan 2020 05:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.399 X-Spam-Level: X-Spam-Status: No, score=-14.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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=AgbOCo+w; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QtEgpCiw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8SQ4u2Gb2Wn for ; Tue, 21 Jan 2020 05:53:40 -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 3C9CB1200E5 for ; Tue, 21 Jan 2020 05:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12170; q=dns/txt; s=iport; t=1579614820; x=1580824420; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2xb6GqvtfTBhg0OebmRsFyslldPZ5HRLtOVBRBGYcOQ=; b=AgbOCo+wCJHOlrlOwfwetFO3XpmxbxAKRZEmaas4gyeTJ3GnMejv8C9r 2xD03lEMItuXTIieW6/wxvIRFNrJS4nbXrXngFxjTGP9O6Tcjw/8FJqFW KqlBF8eqW+oWtMKS6lYiQsVV5YvOUU1VSOw4hhbwXy+vzmkIxiJyqshuV U=; IronPort-PHdr: =?us-ascii?q?9a23=3AAB2aghHDx7l8vDGvgjkZ4Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efDgdSsxH8JPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAgBYASde/4gNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYEkL1AFbFggBAsqhXCBaAOLAU6CEZMshGKBQoEQA1Q?= =?us-ascii?q?JAQEBDAEBIgsCAQGBY4JdAoISJDcGDgIDDQEBBAEBAQIBBQRthTcMhV4BAQE?= =?us-ascii?q?BAxILEBMBATIGDwIBCA4CAQQBASgHMhQJCAIEARIIGoJ/BAKBfU0DLgECDKI?= =?us-ascii?q?+AoE5iGGCJ4J/AQEFgUNBgn0DFYIMAwaBOAGFGoZ5GoFBP4ERR4JMPoJkAgI?= =?us-ascii?q?BARiBFAESASErCYMMgiyNPDKIQ5gvdgqCOYc9hUOJTIJHiAqQJo5eiGGSJQI?= =?us-ascii?q?EAgQFAg4BAQWBaCMNHT1xcBWDJxM9GA2HXSQJGoNQhRSFP3QCAQEBgSSKNoI?= =?us-ascii?q?yAQE?= X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="scan'208,217";a="420378978" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 13:53:39 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LDrclD015530 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 13:53:39 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:53:38 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:53:37 -0600 Received: from NAM10-BN7-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.1473.3 via Frontend Transport; Tue, 21 Jan 2020 07:53:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DHUWB7wGTKCfIuTqEDaA6nvhu8sv5sg9vzN/NMGxu0W/u8d5Hkvx0z+5fKv3i283TaQZUxd7PjFZH88JxGKJAplXLaw89YUWotZ+uwq5o2sQXTi7LIG8ILtjU1WALpCS3EKwZsNFx28pEpV3XvnqXICgbAshrKjR7cAiazItFh0dgXThjs5BcZaQ7ULvJwj4BoA3aDGRtTQiZK9j3v8gOgZ5N4zgpID+uaRldbs02bFqdfsfqeXCzyeyIIYNdgbQ1LDJCBXAkyed8/pzBTYK6OZ1ACpGZz80bdKxYboz6iaz0NgrohWYs6TmojyFq8wcummYQjrJQHAWXv7sA3jncg== 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=Bnf1RSG+/qsLy4d6oko2I3i18H+tZujKpW07gVjD2n0=; b=V1G1Wi5pRpzzlj0xX443UtQlVjCUZgScyNIR9BuWUaQaZYTv6H0dTWB8uQ7GggS1D3jijqMmRYq80oAgDm1p3EEP4vrA5uptET6h2u5pW7FiaGQEmiMHnInlPxfNM//i2McAj/s4ewHNch/r8WH/BoPee9g9YNYREm8c4kvy4sk0PawAAJN5gVxAMQq9X25wpok2SDvKVr8dy6QZRPeB+qsGCa+2AF2+ww//LLdvn0RWNdqrKPBsw7DDSqsFRPipZxV00h5aL1KHP3D/n8F2P641QBnwqdP/JQY36vMXqqqYb/B4ysaRShbYI4/qW9oTTS6h8cryxVjFgPEH/zUlPw== 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=Bnf1RSG+/qsLy4d6oko2I3i18H+tZujKpW07gVjD2n0=; b=QtEgpCiwCf36iJhA7hjKvhCbpC/cFKpirxwWRniRaITyuM+C4k/foi6w769StjMIQIl8Me699zwfEn3sjuKcw6E6cXZXqzV9ug0/8l4Hp3v9blKF5jj0Vtr87XizCTYP+o+8tHPlCWbShMfmL2a42As+fyBSDvia9mHZeWMTtjA= Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.228.31) by BYAPR11MB3367.namprd11.prod.outlook.com (20.177.127.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Tue, 21 Jan 2020 13:53:36 +0000 Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::e4af:d550:3094:46cf]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::e4af:d550:3094:46cf%4]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 13:53:36 +0000 From: "Frank Brockners (fbrockne)" To: Barak Gafni , Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXo6Tdne2RKNvUiZXnvcjdbYaaf0zyWAgABmt0A= Date: Tue, 21 Jan 2020 13:53:36 +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: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com; x-originating-ip: [2001:420:44f0:1252:f96f:9d6:18a4:35e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36ce5000-e666-4639-856e-08d79e794fe5 x-ms-traffictypediagnostic: BYAPR11MB3367: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(189003)(199004)(8676002)(186003)(9686003)(8936002)(478600001)(81166006)(33656002)(76116006)(81156014)(53546011)(55016002)(2906002)(6506007)(86362001)(110136005)(71200400001)(52536014)(7696005)(5660300002)(316002)(66946007)(66476007)(66556008)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3367; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EGNMtCgSjv+iWhSfspeP8hyjkWDftkVGpHnb8JhR4YzroYeGSHJo0k+YMNSWt3obvL3TkadCREnE4oKbwruk8qgJ8iwl13mkYvOMkRND97G18vhT/n7IgOJSFpWWZDm7G/a4tTiU/Pw7AQRxywMPOXchwyn3LffyBn6qtNSv1pIIg5UxIJMCDoWMQL/7lyYJIkt1D251+F6srPYPSgDV5Bto0OFtM4ET2dQvmgkSQ9P30qL2Qi6YpitYc4EIcfVS+JJw0l/28Oyotwcs2nYgRke6IiurxHXqinxy0rRQ9ElhZumYxqf6pUSmwcajgvVESItU9YldNGpfZYJ20kSooBCFMycdmOi1nM+kQ91QZfR06z4qivXMlZoAFKZUzauxE0wgCmZh7mSJQ5S39QpqQb5yBc0WsR5+bT2wa6uevhiB29xnMjnCpf75HKGCleaVpZ8ioVG53cPYUce/w8Tp6fMEOAU8TK8dSK75Hu2BTzhxZl7wV33tDcgE5kwBpo/55LFEtwg+1P7+Qcec32iYog== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB25848EA4F9DF47CADA5D7763DA0D0BYAPR11MB2584namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 36ce5000-e666-4639-856e-08d79e794fe5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 13:53:36.2979 (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: XW49xLgPwjkSIEgzuYR+dQ/AMeE8uTsPXxZsUrLSZgtOBbKKejh47U3yeXEDLA1xSsFgN4YExPjVVOeOp7Dg4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3367 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:53:43 -0000 --_000_BYAPR11MB25848EA4F9DF47CADA5D7763DA0D0BYAPR11MB2584namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barak, Thanks. Please see inline ("...FB"). From: ippm On Behalf Of Barak Gafni Sent: Dienstag, 21. Januar 2020 08:33 To: Tommy Pauly ; IETF IPPM WG Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hi, Few comments to consider: 1. Queue depth format - In order to align the standardization of units a= cross the route, as done for time measurements for example, I would suggest= to direct implementations towards reporting Bytes, rather than keeping it = open for interpretation by the implementors. ...FB: As you know, the original rationale used throughout IOAM is to avoid= forcing the data producer (e.g. the forwarding ASIC) to translate a counte= r into a specific unit, which could be costly. One would rather do the tran= sformation on the receiver of the data than on the sender of the data. At t= his point you'd probably argue that for time, we also specify the format/un= it - though for time, we have 3 options available, and one of which is expe= cted to be supported by the source natively, hence the "exception". 1. Additional measurements to consider - amount of Bytes transmitted by = a port, rate of transmission of a port. ...FB: The data fields currently defined in the draft are considered a "bas= eline" - i.e. a set that everyone agrees with. We all know there have been = proposals for other data fields in the past - but those proposals never got= broader momentum. One can always leverage the opaque state snapshot to car= ry deployment specific data. So in order to add those two additional data f= ields to the draft at this stage, we'd need to get a good understanding of = how common the need for the two additional data fields is. Who else would s= ee a need? What would be the use-cases? Thanks, Frank Thanks, Barak From: ippm > On Behalf = Of Tommy Pauly Sent: Tuesday, January 7, 2020 8:48 AM To: IETF IPPM WG > Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21.. Please reply to ippm@ietf.o= rg with your reviews and comments. Please indicate wh= ether you think this document is ready for publication. Best, Tommy (as co-chair) --_000_BYAPR11MB25848EA4F9DF47CADA5D7763DA0D0BYAPR11MB2584namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barak,

 

Thanks. Please see inline (“…FB”).=

 

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Barak Gafni
Sent: Dienstag, 21. Januar 2020 08:33
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IP= PM WG <ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

Hi,

Few comments to consider:

  1. Queue depth format – In order to align the standardization of u= nits across the route, as done for time measurements for example, I would s= uggest to direct implementations towards reporting Bytes, rather than keeping it open for interpretation by the implementors.=

…FB: As you know, the original rationale= used throughout IOAM is to avoid forcing the data producer (e.g. the forwa= rding ASIC) to translate a counter into a specific unit, which could be cos= tly. One would rather do the transformation on the receiver of the data than on the sender of the data. At this point = you’d probably argue that for time, we also specify the format/unit &= #8211; though for time, we have 3 options available, and one of which is ex= pected to be supported by the source natively, hence the “exception”.

  1. Additional measurements to consider – amount of Bytes transmitt= ed by a port, rate of transmission of a port.

…FB: The data fields currently defined i= n the draft are considered a “baseline” – i.e. a set that= everyone agrees with. We all know there have been proposals for other data= fields in the past – but those proposals never got broader momentum. One can always leverage the opaque state snapshot to carry deplo= yment specific data. So in order to add those two additional data fields to= the draft at this stage, we’d need to get a good understanding of ho= w common the need for the two additional data fields is. Who else would see a need? What would be the use-cases?

 

Thanks, Frank

 

Thanks,

Barak

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org<= /a>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

 

The last call will end on Tuesday, January 21= .. Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_BYAPR11MB25848EA4F9DF47CADA5D7763DA0D0BYAPR11MB2584namp_-- From nobody Tue Jan 21 09:15:45 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26D5120044 for ; Tue, 21 Jan 2020 09:15: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 7gfqViUOv5ia for ; Tue, 21 Jan 2020 09:15:38 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2112.outbound.protection.outlook.com [40.107.92.112]) (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 E00D41201E5 for ; Tue, 21 Jan 2020 09:15:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WhZYexU8wbOKdAPt7DDQePvEuZhGeeJZ8LmGnMViostSuoGUulxFFL308F3htLZI66crAzYNzbd55O2rEE8MHRnXIxOzgwy5pYf6SeCYbzuqEXBEq7SBCDcYxJVH2yW6weLU3lvAtDxAH6pmJJWTE0SFN1V8sREj+/ixCcxMoABBmxhMyDCZS4fy2tUStM8iVm6/6wBveVhPRCSgbBlQkL+HjtF5rfowL2VXzYUmziKqZpGRkOCmfsYMqJzkB2ZhrBv+32Ai2M4xRGsc/Nm1DWFv87jbtUeMDDUZ9HJq7fD8fvnCYA6P56O3DfMHaWj/29/fBNYtC0USCho4dII6kw== 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=YT4i+R9wtypP6OLdY7PWZMMWYz3xZuMAtW3moGeF0vA=; b=krXXU7Du7dbFj97zkh0pTCkrjsnTaLUDqMOTmnZsewXtAV62Y+8szGmGTahsNbe9EzDgnlFxaBtkSzlgdreTNY+4AlbSDlz5Cd4cT1CQcutCrrUbLgUI+T7Klqs9b2iL8eYMIungqGE31aMkKhZnePdyTg1OjEqVZ/0iHGEriMCchWwUmjeNNvwmsSAVcyDqno+0rEoGymwJUrwkoAph99CtYfjNlWeG+uDjA/l5mzf8b/fYX7ZkOeVJzL6pIZbD1J5CsAX9NloQcZDodkubrdy02+2PH2Y64GLbyDfwdM8R6wemMaJAGU7CnweYgXiARnc3UB/p2wZF/6mJGNrwTA== 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=YT4i+R9wtypP6OLdY7PWZMMWYz3xZuMAtW3moGeF0vA=; b=jfls0jqVQ8sr3ZW1saDL+phAydYGJaj/yYAFw00WYThmqeVQBo0iXcDrElYzA7N1jQW29mpqm3fJ3x4+MQY38dhe7uDjxt16K0uUow3oRJ36HSb7+V8yuO5vEQDwylFp1EW7rZIYm6kgFqKLmjV0qnC0PhyZqqQP95rh16CZMHA= Received: from BYAPR13MB2485.namprd13.prod.outlook.com (52.135.228.19) by BYAPR13MB2312.namprd13.prod.outlook.com (52.135.224.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.12; Tue, 21 Jan 2020 17:15:35 +0000 Received: from BYAPR13MB2485.namprd13.prod.outlook.com ([fe80::61a4:f17f:156:4876]) by BYAPR13MB2485.namprd13.prod.outlook.com ([fe80::61a4:f17f:156:4876%7]) with mapi id 15.20.2665.017; Tue, 21 Jan 2020 17:15:35 +0000 From: Haoyu Song To: "Frank Brockners (fbrockne)" , Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXpHWaysCQLfnkORVfHukaUXVaffwftAgBVz1ACAADpFoA== Date: Tue, 21 Jan 2020 17:15:35 +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: spf=none (sender IP is ) smtp.mailfrom=haoyu.song@futurewei.com; x-originating-ip: [12.111.81.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9534c8c9-99a3-4f5c-fc84-08d79e9587a6 x-ms-traffictypediagnostic: BYAPR13MB2312: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(39840400004)(396003)(366004)(346002)(199004)(189003)(52536014)(53546011)(7696005)(5660300002)(86362001)(6506007)(66556008)(66476007)(26005)(76116006)(33656002)(110136005)(66446008)(64756008)(186003)(55016002)(66946007)(9686003)(71200400001)(316002)(8676002)(81156014)(44832011)(2906002)(8936002)(81166006)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR13MB2312; H:BYAPR13MB2485.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kHW+ythgAfRt9VQuj/TPiQjE3aZPWttPpe3TS+ln0eB1AnPHA3D/hql31qDeWP+ndie/0nttmEXDwlKnUsg/OKxqLqvJOjH+RT+Hjk2ry1mxD9e5F3Ia7MZ3K6KyBYwNT7wV4bzGg0ZhYPOWoJJg98ANU1HhFpy1KIvwhDbJg+H3bedYE5MZwNxC5wkwYYr6WbrLX1eJDmBAwK3DujePbME/z2JYn2a2LtAyx3pXHyGIX/txmHlaKLbALYrbh+yz/XBA5GrTtqR+cY4Dvze97DqaHv1/F6ggrFpQ+4Qm5aY7RKOT7QeS6xFPiTBopNYquZ6+dycEJqT0xEXVDPmyPVaCnrGiftTDxKVpLt3mPksdz6A6BavLlCb9VArkk6J1as0eGU5SFGavDN0lVr2XF2An/uSvLTAxcIKYX9rRjCe7EKG/FX1nW+8dYc+YT5dgxAMjzzsMHmE2A3tqLyzc531vjWU51q8xasQmz+QiF6mnimdH3TUPea4jiofV2ifqEx2BDxw5qPsWSpgb6hMUiQ== x-ms-exchange-antispam-messagedata: tfnWgb1qjTdAovb+wlHeBZpHV9RnXBF8+5t3HHU61vLkZo8A1573vEIArJQRRNgL1by9RzzWDI7CnViHXSF6Ii6v5z3wTvx8wZcmv/xaT3hZA6z1RO1A0vFli+ec6vzM7RDl06pVyWmzJoDjFh8nXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR13MB2485E7B39DE7165D829E03BF9A0D0BYAPR13MB2485namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9534c8c9-99a3-4f5c-fc84-08d79e9587a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 17:15:35.7968 (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: fQQ4dVXDdrtZS+xL8U20/ZRbxfLMuRlxWnFMOG38wZ7IJ76Dhtw0Gt4nclArkZPdE5crdYnqfjvpa559Y5wbTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2312 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 17:15:43 -0000 --_000_BYAPR13MB2485E7B39DE7165D829E03BF9A0D0BYAPR13MB2485namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline From: Frank Brockners (fbrockne) Sent: Tuesday, January 21, 2020 5:41 AM To: Haoyu Song ; Tommy Pauly ; IETF IPPM WG Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Haoyu, Thanks. Please see inline ("...FB"). From: ippm > On Behalf = Of Haoyu Song Sent: Dienstag, 7. Januar 2020 23:26 To: Tommy Pauly >; IETF IPPM WG > Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data IPPM and IOAM authors, I have a question about the variable length opaque data field in the trace = option. Does that mean each node may add a variable length field (i.e., use= a different scheme ID)? "When this field is part of the data field but a node populating the field has no opaque state data to report, the Length must be set to 0 and the Schema ID must be set to 0xFFFFFF to mean no schema." >From the above description, it seems so. Then there's a problem. If each n= ode's data has different size, then one can't guarantee that the RemainingL= en is exactly 0 when the data overflow happens. ...FB: Could you detail the problem a bit more: Why would the remaining len= gth need to be exactly 0 in case of a data overflow? If RemainingLen < (Nod= eLen + sizeof(opaque snapshot)) in 4 octet units, then a node would not add= data. [HS] According to the draft text, "RemainingLen: 7-bit unsigned integer. = This field specifies the data space in multiples of 4-octets remaining for recording the node data, before the node data list is considered to have overflowed. When RemainingLen reaches 0, nodes are no longer allowed to add node data. ", so I assume that the Remaining length of 0 means no mor= e data can be added. Also, "NodeLen" is fixed but the size of snapshot is not, which make= s each node probably add different number of bytes. This will make it difficult to find the location for new data inserti= on in the pre-allocated trace mode. Another issue: "If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the actual length added by each node. If IOAM-Trace-Type bit 22 is set, then the actual length added by a node would be (NodeLen + Opaque Data Length)." I think the "actual length added by a node would be (NodeLen+ size of opaqu= e state snapshot field). Because the opaque data is only a part of the opaq= ue state snapshot field, and (opaque data length + 4 byte)=3Dsize of opaqu= e state snapshot field. Some other places need similar clarification. ...FB: Thanks. It makes sense to harmonize the description and at the same = time, make it more specific - i.e. match it to what is already used in sec= tion 4.4.1, i.e. "NodeLen + sizeof(opaque snapshot)" in 4 octet units. Cheers, Frank Haoyu From: ippm > On Behalf = Of Tommy Pauly Sent: Tuesday, January 07, 2020 8:48 AM To: IETF IPPM WG > Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21.. Please reply to ippm@ietf.o= rg with your reviews and comments. Please indicate wh= ether you think this document is ready for publication. Best, Tommy (as co-chair) --_000_BYAPR13MB2485E7B39DE7165D829E03BF9A0D0BYAPR13MB2485namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline

 

From: Frank Brockners (fbrockne) <fbrockne= @cisco.com>
Sent: Tuesday, January 21, 2020 5:41 AM
To: Haoyu Song <haoyu.song@futurewei.com>; Tommy Pauly <tpa= uly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org> Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

Haoyu,

 

Thanks. Please see inline (“…FB”).=

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Haoyu Song
Sent: Dienstag, 7. Januar 2020 23:26
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

IPPM and IOAM authors,

 

I have a question about the variable length opaque d= ata field in the trace option. Does that mean each node may add a variable = length field (i.e., use a different scheme ID)?

 

     “When this field is p= art of the data field but a node populating

      the field has no opaq= ue state data to report, the Length must be

      set to 0 and the Sche= ma ID must be set to 0xFFFFFF to mean no

      schema.”

 

From the above description, it seems so.  Then = there’s a problem. If each node’s data has different size, then= one can’t guarantee that the RemainingLen is exactly 0 when the data= overflow happens.

 

…FB: Could you detail the problem a bit = more: Why would the remaining length need to be exactly 0 in case of a data= overflow? If RemainingLen < (NodeLen + sizeof(opaque snapshot)) in = 4 octet units, then a node would not add data.

 

[HS] According to the dr= aft text,  “RemainingLen:  7-bit unsigned integer.  Th= is field specifies the data

    =   space in multiples of 4-octets remaining for recording the node=

    =   data, before the node data list is considered to have overflowed.

   &nb= sp;  When RemainingLen reaches 0, nodes are no longer allowed to a= dd

    =   node data. “, so I assume that the Remaining length of 0 means= no more data can be added.

 

    =   Also, “NodeLen”  is fixed but the size of snapshot = is not, which makes each node probably add different number of bytes.

    =   This will make it difficult to find the location for new data i= nsertion in the pre-allocated trace mode.

 

 

 

 

 

Another issue:

   

    “If IOAM-Trace-Type bi= t 22 is not set, then NodeLen specifies the

      actual length added b= y each node.  If IOAM-Trace-Type bit 22 is

      set, then the actual = length added by a node would be (NodeLen +

      Opaque Data Length).&= #8221;

 

I think the “ac= tual length added by a node would be (NodeLen+ size of opaque state sna= pshot field). Because the opaque data is only a part of the opaque state sn= apshot field, and  (opaque data length + 4 byte)=3Dsize of opaque state snapshot field.  Some other places need similar clari= fication.

…FB: Than= ks. It makes sense to harmonize the description and at the same time, make = it more specific – i.e. match it  to what is already used in sec= tion 4.4.1, i.e. “NodeLen + sizeof(opaque snapshot)” in 4 octet units.

Cheers, Frank

 

Haoyu

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, January 07, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org<= /a>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

 

The last call will end on Tuesday, January 21= .. Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_BYAPR13MB2485E7B39DE7165D829E03BF9A0D0BYAPR13MB2485namp_-- From nobody Tue Jan 21 11:09:23 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12AB1200A4 for ; Tue, 21 Jan 2020 11:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mellanox.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 64BAH-mWk2AC for ; Tue, 21 Jan 2020 11:09:18 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150047.outbound.protection.outlook.com [40.107.15.47]) (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 1C7CA120830 for ; Tue, 21 Jan 2020 11:09:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y5pI3dlHeU6uK0T3vFNwXrr0f00ymqF/48T1h9rGNGKLX0g4ZDoSI4hTEYFBYVCdr2fq7323NZvF9Gxl0bv7+qI0pr8YCAaNi0r1AQvrPmjLkW/M0I0CurSuYostieAqYstgXYsvQbtWIA9nAnfRBizpGGgBOQy4J/Un6zzcddVba1ycqqhpvVSQMlc0oAHRao6vMaCnNLioEArl0HUY+Qk+cbIrF2hVjfKRpYPabgYpzx7qzmxfCmhLkeLFmM0fd1H4p13ls3Ff7S+7cwD5u2bGRFxKpEkPwM66sqYctPUKR1fvw7XMFch2uOmNXelnsALZysLyrVsvrK0gJQTxgQ== 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=m06AhNcUjGdTMitAhhWVNpMR3Ov02MxhMFDQsbn70oM=; b=Ka/yxp9AAxdhOQJwu1nuBzYFq3ux5IRAY35hcRc4TyHwlLJx1pLmq133sM+a3yDGbtKyQcYGWSItJU5cJivmthTsHbEMyd5K3IYgKV+PnetDrEDlX1LbGosYM2gIPmThkpDCSvYSFWCjJH0VKUNyzXMzlRS7fTj//e1TSYibDDBkcZA8yTQWNifKWXEUX6c7uU90y4swEW9SlYu2HLOvI4EBBsmDsRiOd5UP/nZF3XrRuVi6i5LwyAgJaIXr9FMyQU2RSRO/Npc4b+hWYr48cdBwe+MqMBCy5WdvuHIGTgRPwPLuZDnucwUo3acOIOSjIfw5eyWJk1w3jHMeJ6N7CA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m06AhNcUjGdTMitAhhWVNpMR3Ov02MxhMFDQsbn70oM=; b=PiKEqiMuokizzUZzfRp17ZijbWWcv2jVTD0DpPid4P9zj6U3EhsEqdOaCXpnlsHwQnrC/SnojAani5Gj0RqGWeCODess/wA5QAjkedlJSWRb01iaVG41/ttJ7JLX8LzzQKg6v6Wh6p86HHJabX+swnk2ydXUDJ+vaU+3Eu806E4= Received: from AM6PR05MB4118.eurprd05.prod.outlook.com (52.135.166.159) by AM6PR05MB4184.eurprd05.prod.outlook.com (52.135.166.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.21; Tue, 21 Jan 2020 19:09:16 +0000 Received: from AM6PR05MB4118.eurprd05.prod.outlook.com ([fe80::b04c:eac4:d537:c943]) by AM6PR05MB4118.eurprd05.prod.outlook.com ([fe80::b04c:eac4:d537:c943%6]) with mapi id 15.20.2644.026; Tue, 21 Jan 2020 19:09:16 +0000 From: Barak Gafni To: "Frank Brockners (fbrockne)" , Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXo3ge3BF3mFOkSl30CtIqgmY6f0zM2QgABsmACAAFcWQA== Date: Tue, 21 Jan 2020 19:08:53 +0000 Deferred-Delivery: Tue, 21 Jan 2020 19:08:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: he-IL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gbarak@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b78997df-c6e0-49df-26f9-08d79ea568da x-ms-traffictypediagnostic: AM6PR05MB4184: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(189003)(199004)(478600001)(110136005)(81156014)(81166006)(9686003)(8676002)(316002)(7696005)(33656002)(8936002)(2906002)(26005)(71200400001)(55016002)(86362001)(186003)(5660300002)(52536014)(6506007)(53546011)(6666004)(66556008)(66476007)(66946007)(76116006)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB4184; H:AM6PR05MB4118.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 06kuycWteh33Yaip7UFk5wyOBgYBMCjFkwueXDYg9nTZml26YJRV2bF/X9o1SMUVseWJ1OvBuK+QtIHD2+nqM225NhIkLt4dD5LCJZ1VNP0MzhlYWRAr+6Z2THe6wt1XOLqvZs5Mx5XytMu3riqMWKrhwMr4WdVSpURnJ0CmyQTlT/oOmi1pgVDr7Vm0C7y8/ldpcebpITYsWcHnS92TjSh3HHuohlHMozoMu3guJJAnSEWdh79FYjafTqUNf9ie4pKIu+VHZkPzy2SS1UwJ2zefd0cIv0EWHLpIh4tUZaBjpVlQazMpABXpflPUpKByfOzefsiaM0kfpLjirCWvS9eBN2xt9yAHmL+G2SI3ZBHW2HtpbnegtTXn2OhPN4QvpQriAx3ZxQiHr+YHe32nVngWH+eB9WNi04PRU4MUuvS2Yl5Fp1qWphpPN+qyH4H0F4ojQlXv+NWQucDFx3DMBk2zWSGtbM7WvhrJNKIC4CcL4Zbuu9/52u5dp7VOO/fq42OjQ+ieKWwYtKV7ijwsgA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR05MB4118B744754A50D56E777994B90D0AM6PR05MB4118eurp_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: b78997df-c6e0-49df-26f9-08d79ea568da X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 19:09:16.0785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RUm8zWJUaJXltSeCSVlHGS7hWasLILGCXU1OUFgpK+lOlSDvazXBMdmBbiBrF6UgEjNK6XAjnXjsGYAo8wncXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB4184 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 19:09:23 -0000 --_000_AM6PR05MB4118B744754A50D56E777994B90D0AM6PR05MB4118eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PSB under [BG] Thanks, Barak From: Frank Brockners (fbrockne) Sent: Tuesday, January 21, 2020 5:54 AM To: Barak Gafni ; Tommy Pauly ; IETF IPPM WG Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Barak, Thanks. Please see inline ("...FB"). From: ippm > On Behalf = Of Barak Gafni Sent: Dienstag, 21. Januar 2020 08:33 To: Tommy Pauly >; IETF IPPM WG > Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hi, Few comments to consider: 1. Queue depth format - In order to align the standardization of units a= cross the route, as done for time measurements for example, I would suggest= to direct implementations towards reporting Bytes, rather than keeping it = open for interpretation by the implementors. ...FB: As you know, the original rationale used throughout IOAM is to avoid= forcing the data producer (e.g. the forwarding ASIC) to translate a counte= r into a specific unit, which could be costly. One would rather do the tran= sformation on the receiver of the data than on the sender of the data. At t= his point you'd probably argue that for time, we also specify the format/un= it - though for time, we have 3 options available, and one of which is expe= cted to be supported by the source natively, hence the "exception". [BG] Agree, forcing this reporting method may be too much for some implemen= tation that we don't want to prevent from supporting IOAM. Hence, my sugges= tion is to use SHOULD, which can drive better interoperability going forwar= d without prevent current implementations from being compatible. 1. Additional measurements to consider - amount of Bytes transmitted by = a port, rate of transmission of a port. ...FB: The data fields currently defined in the draft are considered a "bas= eline" - i.e. a set that everyone agrees with. We all know there have been = proposals for other data fields in the past - but those proposals never got= broader momentum. One can always leverage the opaque state snapshot to car= ry deployment specific data. So in order to add those two additional data f= ields to the draft at this stage, we'd need to get a good understanding of = how common the need for the two additional data fields is. Who else would s= ee a need? What would be the use-cases? [BG] Would be great to have the list further comment on that Thanks, Frank Thanks, Barak From: ippm > On Behalf = Of Tommy Pauly Sent: Tuesday, January 7, 2020 8:48 AM To: IETF IPPM WG > Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Hello IPPM, Happy New Year! This email starts a working group last call for "Data Field= s for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-d= ata/). The last call will end on Tuesday, January 21.. Please reply to ippm@ietf.o= rg with your reviews and comments. Please indicate wh= ether you think this document is ready for publication. Best, Tommy (as co-chair) --_000_AM6PR05MB4118B744754A50D56E777994B90D0AM6PR05MB4118eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PSB under [BG]

 

Thanks,

Barak

 

From: Frank Brockners (fbrockne) <fbrockne= @cisco.com>
Sent: Tuesday, January 21, 2020 5:54 AM
To: Barak Gafni <gbarak@mellanox.com>; Tommy Pauly <tpauly= =3D40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

Barak,

 

Thanks. Please see inline (“…FB”).=

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Barak Gafni
Sent: Dienstag, 21. Januar 2020 08:33
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

 

Hi,

Few comments to consider:

  1. Queue depth format – In order to align the standardization of u= nits across the route, as done for time measurements for example, I would s= uggest to direct implementations towards reporting Bytes, rather than keeping it open for interpretation by the implementors.=

…FB: As you know, the original rationale= used throughout IOAM is to avoid forcing the data producer (e.g. the forwa= rding ASIC) to translate a counter into a specific unit, which could be cos= tly. One would rather do the transformation on the receiver of the data than on the sender of the data. At this point = you’d probably argue that for time, we also specify the format/unit &= #8211; though for time, we have 3 options available, and one of which is ex= pected to be supported by the source natively, hence the “exception”.

[BG] Agree, forcing this reporting method may = be too much for some implementation that we don’t want to prevent fro= m supporting IOAM. Hence, my suggestion is to use SHOULD, which can drive b= etter interoperability going forward without prevent current implementations from being compatible.<= /p>

  1. Additional measurements to consider – amount of Bytes transmitt= ed by a port, rate of transmission of a port.

…FB: The data fields currently defined i= n the draft are considered a “baseline” – i.e. a set that= everyone agrees with. We all know there have been proposals for other data= fields in the past – but those proposals never got broader momentum. One can always leverage the opaque state snapshot to carry deplo= yment specific data. So in order to add those two additional data fields to= the draft at this stage, we’d need to get a good understanding of ho= w common the need for the two additional data fields is. Who else would see a need? What would be the use-cases?

[BG] Would be great to have the list further c= omment on that

 

Thanks, Frank

 

Thanks,

Barak

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org<= /a>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

 

Hello IPPM,

 

 

The last call will end on Tuesday, January 21= .. Please reply to ippm@ietf.org with your reviews and co= mments. Please indicate whether you think this document is ready for public= ation.

 

Best,

Tommy (as co-chair)

--_000_AM6PR05MB4118B744754A50D56E777994B90D0AM6PR05MB4118eurp_-- From nobody Tue Jan 21 14:30:22 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7B12006F for ; Tue, 21 Jan 2020 14:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=neutral reason="invalid (public key: invalid data)" header.d=barefootnetworks.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 bKzbJHOkiqQW for ; Tue, 21 Jan 2020 14:30:17 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 D2EB012007A for ; Tue, 21 Jan 2020 14:30:16 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id f129so5071164wmf.2 for ; Tue, 21 Jan 2020 14:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barefootnetworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W/LgoCmkgC0UTSIcZRGGTXMu0CcjP3bieZmd0J2W4Rc=; b=IC2BAkD6vhw75TQ8+tZ4wWkHoT3OMYnueVT122oxEIAw3qKymoBUKJ/7TQADt9fspp 81EVWI2q0fd+D4rniYzqEhJToFhd8Y9qCe/yZGf83Bj6WFU04ae3wTb+eqff+Kq0MRJf SI7ErBsNKOhrZhobCnbevY/5dEqhDlXs13BmI= 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=W/LgoCmkgC0UTSIcZRGGTXMu0CcjP3bieZmd0J2W4Rc=; b=gTgKTBjikJKaNBjAsQxTEn1GQPKiCepRNZ5z3NxsQ4wHnhYDZQkkqXZ+7+uQdzAf5+ SLv8hUT6xik2xEsn6GmmiOrkPhGTGyfFviL8vZfXXhfNjZY2iciDHHgRbeoqKZItW9xs bljXHLoLYKsQWhxh5nV0M3KGf/nYn6WKIV/jpcUiOq6fzhcMyicgL4c8iMHBsrRhvuCz NdKN0YX7uPWfwJ2EIShaMCRYE38++oygRcylUC6kcQSHqecxrcrLOzzoac97nyA+nB2Z yP1rFTP7eYkPAjW/dPK4ItGDIV6YpLouiot7bjdx5heTTQVlwHJHElLm4+mVXUvsYavz 4CmQ== X-Gm-Message-State: APjAAAVUkJ1GvR5E2B1G9WPfDdoA8bo0bYoaF/RexnRYAWa2TEL/BTM2 YCIgcKISaGc8p0heQ45I81pa0w2U2ltEhaXK3z6qvg== X-Google-Smtp-Source: APXvYqx9na/3Xk9v6HJAAwVZdwL4laNEkxlGQODBNS+4G0OpSOdkX21FvwXYjNxWV8/F6Mfn+4ZiLLCOzW99qUuaKwQ= X-Received: by 2002:a1c:a404:: with SMTP id n4mr466203wme.109.1579645815364; Tue, 21 Jan 2020 14:30:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mickey Spiegel Date: Tue, 21 Jan 2020 14:30:04 -0800 Message-ID: To: Barak Gafni Cc: "Frank Brockners (fbrockne)" , Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000b2314e059cadf353" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 22:30:21 -0000 --000000000000b2314e059cadf353 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inline comments under [MS] On Tue, Jan 21, 2020 at 11:09 AM Barak Gafni wrote: > PSB under [BG] > > > > Thanks, > > Barak > > > > *From:* Frank Brockners (fbrockne) > *Sent:* Tuesday, January 21, 2020 5:54 AM > *To:* Barak Gafni ; Tommy Pauly 40apple.com@dmarc.ietf.org>; IETF IPPM WG > *Subject:* RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data > > > > Barak, > > > > Thanks. Please see inline (=E2=80=9C=E2=80=A6FB=E2=80=9D). > > > > *From:* ippm *On Behalf Of *Barak Gafni > *Sent:* Dienstag, 21. Januar 2020 08:33 > *To:* Tommy Pauly ; IETF IPPM WG < > ippm@ietf.org> > *Subject:* Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data > > > > Hi, > > Few comments to consider: > > 1. Queue depth format =E2=80=93 In order to align the standardization = of units > across the route, as done for time measurements for example, I would > suggest to direct implementations towards reporting Bytes, rather than > keeping it open for interpretation by the implementors. > > *=E2=80=A6FB: As you know, the original rationale used throughout IOAM is= to avoid > forcing the data producer (e.g. the forwarding ASIC) to translate a count= er > into a specific unit, which could be costly. One would rather do the > transformation on the receiver of the data than on the sender of the data= . > At this point you=E2=80=99d probably argue that for time, we also specify= the > format/unit =E2=80=93 though for time, we have 3 options available, and o= ne of > which is expected to be supported by the source natively, hence the > =E2=80=9Cexception=E2=80=9D.* > > *[BG] Agree, forcing this reporting method may be too much for some > implementation that we don=E2=80=99t want to prevent from supporting IOAM= . Hence, > my suggestion is to use SHOULD, which can drive better interoperability > going forward without prevent current implementations from being > compatible.* > [MS] There are several possible use cases for IOAM. Much of the initial work has been motivated by flow monitoring use cases, where switches and routers embed or export metadata relating to packets in a flow, at line rate for massively scaled data centers. At the receiver, typically the exported metadata is processed and analyzed in software. In such a scenario, in order to enable IOAM to work across as wide a range of devices as possible, it makes sense to use the design philosophy that Frank stated above: Allow the data producer to generate metadata in whatever units it wants, and normalize at the receiver where the exported metadata is processed and analyzed. For such use cases, I believe that standardization of units should not be a goal, not even as a recommendation. [MS] There may be other use cases where standardization of units makes sense. Rather than constrain all use cases, my suggestion would be to define recommendations specific to such use cases, perhaps using the concept of profiles that Tal has proposed. > 1. Additional measurements to consider =E2=80=93 amount of Bytes trans= mitted > by a port, rate of transmission of a port. > > [MS] I support the addition of the amount of bytes transmitted by a port. However, I wonder whether this should be the amount of bytes transmitted on the entire port, or the amount of bytes transmitted using a specific queue on the port? Mickey > > 1. > > *=E2=80=A6FB: The data fields currently defined in the draft are consider= ed a > =E2=80=9Cbaseline=E2=80=9D =E2=80=93 i.e. a set that everyone agrees with= . We all know there have > been proposals for other data fields in the past =E2=80=93 but those prop= osals > never got broader momentum. One can always leverage the opaque state > snapshot to carry deployment specific data. So in order to add those two > additional data fields to the draft at this stage, we=E2=80=99d need to g= et a good > understanding of how common the need for the two additional data fields i= s. > Who else would see a need? What would be the use-cases?* > > *[BG] Would be great to have the list further comment on that* > > > > *Thanks, Frank* > > > > Thanks, > > Barak > > > > *From:* ippm *On Behalf Of *Tommy Pauly > *Sent:* Tuesday, January 7, 2020 8:48 AM > *To:* IETF IPPM WG > *Subject:* [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data > > > > Hello IPPM, > > > > Happy New Year! This email starts a working group last call for "Data > Fields for In-situ OAM" ( > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ > > ). > > > > The last call will end on *Tuesday, January 21*... Please reply to > ippm@ietf.org with your reviews and comments. Please indicate whether you > think this document is ready for publication. > > > > Best, > > Tommy (as co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000b2314e059cadf353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline comments under [MS]

On Tue, Jan 21, 2020 at 11:= 09 AM Barak Gafni <gbarak@mellano= x.com> wrote:

PSB under [BG]

=C2=A0

Thanks,

Barak

=C2=A0

From: Frank Brockners (fbrockne) <fbrockne@cisco.com>
Sent: Tuesday, January 21, 2020 5:54 AM
To: Barak Gafni <gbarak@mellanox.com>; Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.= org>; IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

=C2=A0

Barak,

=C2=A0

Thanks. Please see inline (=E2=80=9C=E2=80=A6FB=E2= =80=9D).

=C2=A0

From: ippm <ippm-bounces@ietf.org> On Behalf Of Barak Gafni
Sent: Dienstag, 21. Januar 2020 08:33
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF = IPPM WG <ippm@ietf.or= g>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-da= ta

=C2=A0

Hi,

Few comments to consider:

  1. Queue depth format =E2=80=93 In order to alig= n the standardization of units across the route, as done for time measureme= nts for example, I would suggest to direct implementations towards reportin= g Bytes, rather than keeping it open for interpretation by the implementors.=

=E2=80=A6FB: As you know, the original rationa= le used throughout IOAM is to avoid forcing the data producer (e.g. the for= warding ASIC) to translate a counter into a specific unit, which could be c= ostly. One would rather do the transformation on the receiver of the data than on the sender of the data. At this point = you=E2=80=99d probably argue that for time, we also specify the format/unit= =E2=80=93 though for time, we have 3 options available, and one of which i= s expected to be supported by the source natively, hence the =E2=80=9Cexception=E2=80=9D.

[BG] Agree, forcing this reporting method may = be too much for some implementation that we don=E2=80=99t want to prevent f= rom supporting IOAM. Hence, my suggestion is to use SHOULD, which can drive= better interoperability going forward without prevent current implementations from being compatible.


[MS] There are several possible = use cases for IOAM. Much of the initial work has been motivated by flow mon= itoring use cases, where switches and routers embed or export metadata rela= ting to packets in a flow, at line rate for massively scaled data centers. = At the receiver, typically the exported metadata is processed and analyzed = in software. In such a scenario, in order to enable IOAM to work across as = wide a range of devices as possible, it makes sense to use the design philo= sophy that Frank stated above: Allow the data producer to generate metadata= in whatever units it wants, and normalize at the receiver where the export= ed metadata is processed and analyzed. For such use cases, I believe that s= tandardization of units should not be a goal, not even as a recommendation.=

[MS] There may be other use cases where standardi= zation of units makes sense.=C2=A0Rather than constrain all use cases, my s= uggestion would be to define recommendations specific to such use cases, pe= rhaps using the concept of profiles that Tal has proposed.

<= div>

  1. Additional measurements to consider =E2=80=93= amount of Bytes transmitted by a port, rate of transmission of a port.

[MS] I support the= addition of the amount of bytes transmitted by a port. However, I wonder w= hether this should be the amount of bytes transmitted on the entire port, o= r the amount of bytes transmitted using a specific queue on the port?
=

Mickey

=C2=A0

=E2=80=A6FB: The data fields currently defined= in the draft are considered a =E2=80=9Cbaseline=E2=80=9D =E2=80=93 i.e. a = set that everyone agrees with. We all know there have been proposals for ot= her data fields in the past =E2=80=93 but those proposals never got broader momentum. One can always leverage the opaque state snapshot to carry deplo= yment specific data. So in order to add those two additional data fields to= the draft at this stage, we=E2=80=99d need to get a good understanding of = how common the need for the two additional data fields is. Who else would see a need? What would be the use-cases?=

[BG] Would be great to have the list further c= omment on that

=C2=A0

Thanks, Frank

=C2=A0

Thanks,

Barak

=C2=A0

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

=C2=A0

Hello IPPM,

=C2=A0

Happy New Year! This email starts a working group la= st call for "Data Fields for In-situ OAM" (https://datatracker= .ietf.org/doc/draft-ietf-ippm-ioam-data/).

=C2=A0

The last call will end on Tuesday, January 21= ... Please reply to ippm@ietf.org with y= our reviews and comments. Please indicate whether you think this document i= s ready for publication.

=C2=A0

Best,

Tommy (as co-chair)

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000b2314e059cadf353-- From nobody Tue Jan 21 15:32:40 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501D412002E for ; Tue, 21 Jan 2020 15:32:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=mellanox.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 J_bwGu0V_7bO for ; Tue, 21 Jan 2020 15:32:36 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (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 BCADC12004E for ; Tue, 21 Jan 2020 15:32:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tr/FclrW8BFwgmpfR6WFkziOzmUdUruBrTTC8OJhRsKGtKQPVMUbriMi84QcKnlSsQxFQXtnnp5gGjy9k/QXJO4LuGaF+dZJF4FbJJNWSLKvSkUBkKLkvtDBIf6IuJFvQSe62YoSGc+EP6789YmgyNC+GqFuol5EukZ5emGqnjglMw5k9m8ixXi/SAEpUcxgOkZ+VR4ebjqKzcHOIH3pHvP5byQ+s/yOr/ziO3A/Cz08s4oZ8/gWzjtsYHCWM1pdueNIIxaMy2WBObmHnAwDMIrxwJBDjOnZ4f/8uThng8t+II+Una2ln+A8r//ul2MH5HPqLkUAyvk2iFIg6ia3kQ== 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=gEmNGXZM5c/HOQs+kYgpkaJTwhsvpoHNLo3fVOX94Qk=; b=QYj96wiPHuKd2q1YD2YBpVxYCqW0jpw9Ob01MqsfeOJzRKmPCs0rndxC0Bg2a+CnICXAmHkHMRUN5H63vuCQd4+ECaA4WI7Er50hck6pOFbalQgShVx4RA9tJAPrWQ5QB+uWZO4tSNYPrIQcmtJ9CrTB+3RPGyPo807NXto+LXHrWx/9+hlpM8O627SRapKI8ijUAByRXyFMdFdPEm960+hrO4+g2TSR6FqSwleDP2p2+hJSRo81+DBIdCTLW3obgsfKVLAyUQ6cNuuASS64Z6HmuvP1bpiWy4UHuGAVjlhCaTUZ7q7IAt0uoStlIbgq1UH51yZosb5/MY58c//6zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gEmNGXZM5c/HOQs+kYgpkaJTwhsvpoHNLo3fVOX94Qk=; b=jpCuWPVwTQdpm6FFXhzCftgLPDuIHNsBaxe26P0tgx83yBETdIxyeQAuSik8w0EmjWk9dXS4rCloN59reNAPLIiSqHefXrsYWHRgkPCxP2cHpbVwjB/2rygSEA7FTZ5BdzeuWVEyBr6ekWWLTlh3sugUTKlAzBNeR2wfOuTJ7Vs= Received: from VI1PR05MB4125.eurprd05.prod.outlook.com (10.171.182.140) by VI1PR05MB6208.eurprd05.prod.outlook.com (20.178.123.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Tue, 21 Jan 2020 23:32:33 +0000 Received: from VI1PR05MB4125.eurprd05.prod.outlook.com ([fe80::1cc6:124d:7fd7:c835]) by VI1PR05MB4125.eurprd05.prod.outlook.com ([fe80::1cc6:124d:7fd7:c835%6]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 23:32:33 +0000 From: Barak Gafni To: Mickey Spiegel CC: "Frank Brockners (fbrockne)" , Tommy Pauly , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data Thread-Index: AQHVxXo3ge3BF3mFOkSl30CtIqgmY6f0zM2QgABsmACAAFcWQIAAOTcAgAAOlNA= Date: Tue, 21 Jan 2020 23:32:24 +0000 Deferred-Delivery: Tue, 21 Jan 2020 23:31:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: he-IL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gbarak@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3c26838b-1a28-4135-31d9-08d79eca30c4 x-ms-traffictypediagnostic: VI1PR05MB6208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(199004)(189003)(86362001)(52536014)(71200400001)(33656002)(6916009)(7696005)(966005)(53546011)(5660300002)(6506007)(316002)(66446008)(8676002)(2906002)(186003)(26005)(66946007)(66476007)(76116006)(66556008)(6666004)(64756008)(9686003)(54906003)(8936002)(55016002)(81156014)(4326008)(81166006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB6208; H:VI1PR05MB4125.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8AZWNswu7rzYNEz8Zz5s2f1t/Fs54yU6ViFtcx84i+O1EnlqcXAix3CKSHCpz722utOxUzBZXchUAdiyHTG/wjyul+pCFneaSn0a0Dp7YCANfVwcYEqfY4/As4CU0nau4Ol0+HjagFoT2PgXMgLiyq+B14ATvN4wYangzzEl69XHFM1+QPVN6TfdlM/nRRLAvl00+mTkWTQg1POLaj+UJxSHhhr+1SSgAcTKujcKkvBZS8JAyTrDxQOa5XdpZCxZOr6dUT17A7uJTySreOsQPEb78MDgPWsjXLJfpIAh+FdSR1YHIZrkODmpB/1vPA7yPxHWYwetCtuHaFgU9pLopk81unX0Q4CA6EqVaKp70i6UJNdVVkBqjitH5EWOQrYNsM6FtA2UrA5EAq5EC8j4hJoELETNHx4lbfjyC3CxjINArj/OfbGSWaMY+SaMpHd+rTKZFpNQVh53nOuF/sYM6DRBiw/FXcEGvOGIhzjI3hw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR05MB41258589F71B3D29BD6BA581B90D0VI1PR05MB4125eurp_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c26838b-1a28-4135-31d9-08d79eca30c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 23:32:33.3891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vdvnKkNsZeXwdhUmc2Mq3Ln3B4fME6AfTU+CN2Vk5pz37NJgElK/hS+ryKh3NoWJdI2DWu/QPu/2oLqMuO+fJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB6208 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 23:32:39 -0000 --_000_VI1PR05MB41258589F71B3D29BD6BA581B90D0VI1PR05MB4125eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgYWNjb3JkaW5nIHRvIHRoZXNlIGNvbW1lbnRzIHdlIGFyZSBjb252ZXJn aW5nIHRvd2FyZHMgYWdyZWVtZW50LiDigJxTSE9VTETigJ0gZG9lc27igJl0IHByZWNsdWRlIGFu eSBpbXBsZW1lbnRhdGlvbiBoZW5jZSBpdCBrZWVwcyB0aGUgUkZDIGluY2x1c2l2ZSBmb3IgZGV2 aWNlcyB0aGF0IGNhbuKAmXQgYWxpZ24gdG8gQnl0ZXMuIFdoaWxlIGFzIHdlIGFsbCBoZXJlIGZv ciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBzaW1wbGljaXR5IG9mIHRoZSBkZXNpZ25zLCByZWNvbW1l bmRpbmcgdGhlIGluZHVzdHJ5IHRvIGFsaWduIGl0c2VsZiB0b3dhcmRzIHN0YW5kYXJkIHVuaXQg b2YgbWVhc3VyZW1lbnQgaXMgZGVzaXJlZCBmcm9tIGEgc3RhbmRhcmRzIGJvZHkgcGVyc3BlY3Rp dmUuIFNvIEkgYmVsaWV2ZSB0aGF0IGl0IGlzIGFsaWduZWQgd2l0aCB5b3VyIGNvbW1lbnRzLiBB cyB5b3UgZGVub3RlLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgc3RhbmRhcmRpemF0aW9uIG9mIHVu aXRzIG1ha2Ugc2Vuc2UsIHdoaWxlIGl0IGRvZXNu4oCZdCBodXJ0IG90aGVyIGNhc2VzLg0KSW4g YWRkaXRpb24sIGZyb20gYSBwZXJzb25hbCBvYnNlcnZhdGlvbiwgdGhlIG1hcmtldCBpbmNsdWRl cyBtYW55IGtpbmRzIG9mIEFTSUNzIGltcGxlbWVudGVkIGFzIHBhcnQgb2Ygc3dpdGNoaW5nIGFu ZCByb3V0aW5nIHN5c3RlbXMuIFNvbWUgQVNJQyB2ZW5kb3JzIGFyZSByZXBvcnRpbmcgdGhlaXIg QVNJQyDigJxjZWxs4oCdIHNpemVzIHdoaWxlIHNvbWUgbm90LCBzb21lIHN5c3RlbS9OT1MgdmVu ZG9ycyByZXBvcnQgdGhlIEFTSUMgdGhleSBhcmUgdXNpbmcgYW5kIHNvbWUgbm90LiBJdCBtYXkg YmUgaGFyZCBpbiBtYW55IGVudmlyb25tZW50cyB0byBxdWVyeSB0aGUgZGV2aWNlcyBpbiBvcmRl ciB0byBrbm93IHRoaXMgZGF0YSwgYW5kIHRoZW4gcHJvY2VzcyBhY2NvcmRpbmcuIFRoZSBzdWdn ZXN0ZWQgZGlyZWN0aW9uIHNpbXBsaWZpZXMgYWxsIHRoaXMgb3BlcmF0aW9uYWwgYXNwZWN0cyB3 aGVuIHBvc3NpYmxlLiBBbmQgaW4gdGhlIG1lYW53aGlsZSwgYXMgc3RhdGVkIGFib3ZlLCBkb2Vz buKAmXQgcHJlY2x1ZGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMuDQoNClRoYW5rcywNCkJhcmFr DQoNCkZyb206IE1pY2tleSBTcGllZ2VsIDxtc3BpZWdlbEBiYXJlZm9vdG5ldHdvcmtzLmNvbT4N ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjEsIDIwMjAgMjozMCBQTQ0KVG86IEJhcmFrIEdhZm5p IDxnYmFyYWtAbWVsbGFub3guY29tPg0KQ2M6IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxm YnJvY2tuZUBjaXNjby5jb20+OyBUb21teSBQYXVseSA8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJj LmlldGYub3JnPjsgSUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtp cHBtXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0YQ0K DQpJbmxpbmUgY29tbWVudHMgdW5kZXIgW01TXQ0KDQpPbiBUdWUsIEphbiAyMSwgMjAyMCBhdCAx MTowOSBBTSBCYXJhayBHYWZuaSA8Z2JhcmFrQG1lbGxhbm94LmNvbTxtYWlsdG86Z2JhcmFrQG1l bGxhbm94LmNvbT4+IHdyb3RlOg0KUFNCIHVuZGVyIFtCR10NCg0KVGhhbmtzLA0KQmFyYWsNCg0K RnJvbTogRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNvbTxtYWls dG86ZmJyb2NrbmVAY2lzY28uY29tPj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjEsIDIwMjAg NTo1NCBBTQ0KVG86IEJhcmFrIEdhZm5pIDxnYmFyYWtAbWVsbGFub3guY29tPG1haWx0bzpnYmFy YWtAbWVsbGFub3guY29tPj47IFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj47IElFVEYgSVBQTSBX RyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW2lw cG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhDQoN CkJhcmFrLA0KDQpUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lICjigJzigKZGQuKAnSkuDQoNCkZy b206IGlwcG0gPGlwcG0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnPj4gT24gQmVoYWxmIE9mIEJhcmFrIEdhZm5pDQpTZW50OiBEaWVuc3RhZywgMjEuIEphbnVh ciAyMDIwIDA4OjMzDQpUbzogVG9tbXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj47IElFVEYg SVBQTSBXRyA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlwcG0taW9hbS1k YXRhDQoNCkhpLA0KRmV3IGNvbW1lbnRzIHRvIGNvbnNpZGVyOg0KDQogIDEuICBRdWV1ZSBkZXB0 aCBmb3JtYXQg4oCTIEluIG9yZGVyIHRvIGFsaWduIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgdW5p dHMgYWNyb3NzIHRoZSByb3V0ZSwgYXMgZG9uZSBmb3IgdGltZSBtZWFzdXJlbWVudHMgZm9yIGV4 YW1wbGUsIEkgd291bGQgc3VnZ2VzdCB0byBkaXJlY3QgaW1wbGVtZW50YXRpb25zIHRvd2FyZHMg cmVwb3J0aW5nIEJ5dGVzLCByYXRoZXIgdGhhbiBrZWVwaW5nIGl0IG9wZW4gZm9yIGludGVycHJl dGF0aW9uIGJ5IHRoZSBpbXBsZW1lbnRvcnMuDQrigKZGQjogQXMgeW91IGtub3csIHRoZSBvcmln aW5hbCByYXRpb25hbGUgdXNlZCB0aHJvdWdob3V0IElPQU0gaXMgdG8gYXZvaWQgZm9yY2luZyB0 aGUgZGF0YSBwcm9kdWNlciAoZS5nLiB0aGUgZm9yd2FyZGluZyBBU0lDKSB0byB0cmFuc2xhdGUg YSBjb3VudGVyIGludG8gYSBzcGVjaWZpYyB1bml0LCB3aGljaCBjb3VsZCBiZSBjb3N0bHkuIE9u ZSB3b3VsZCByYXRoZXIgZG8gdGhlIHRyYW5zZm9ybWF0aW9uIG9uIHRoZSByZWNlaXZlciBvZiB0 aGUgZGF0YSB0aGFuIG9uIHRoZSBzZW5kZXIgb2YgdGhlIGRhdGEuIEF0IHRoaXMgcG9pbnQgeW91 4oCZZCBwcm9iYWJseSBhcmd1ZSB0aGF0IGZvciB0aW1lLCB3ZSBhbHNvIHNwZWNpZnkgdGhlIGZv cm1hdC91bml0IOKAkyB0aG91Z2ggZm9yIHRpbWUsIHdlIGhhdmUgMyBvcHRpb25zIGF2YWlsYWJs ZSwgYW5kIG9uZSBvZiB3aGljaCBpcyBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIHNv dXJjZSBuYXRpdmVseSwgaGVuY2UgdGhlIOKAnGV4Y2VwdGlvbuKAnS4NCltCR10gQWdyZWUsIGZv cmNpbmcgdGhpcyByZXBvcnRpbmcgbWV0aG9kIG1heSBiZSB0b28gbXVjaCBmb3Igc29tZSBpbXBs ZW1lbnRhdGlvbiB0aGF0IHdlIGRvbuKAmXQgd2FudCB0byBwcmV2ZW50IGZyb20gc3VwcG9ydGlu ZyBJT0FNLiBIZW5jZSwgbXkgc3VnZ2VzdGlvbiBpcyB0byB1c2UgU0hPVUxELCB3aGljaCBjYW4g ZHJpdmUgYmV0dGVyIGludGVyb3BlcmFiaWxpdHkgZ29pbmcgZm9yd2FyZCB3aXRob3V0IHByZXZl bnQgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgZnJvbSBiZWluZyBjb21wYXRpYmxlLg0KDQpbTVNd IFRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmxlIHVzZSBjYXNlcyBmb3IgSU9BTS4gTXVjaCBvZiB0 aGUgaW5pdGlhbCB3b3JrIGhhcyBiZWVuIG1vdGl2YXRlZCBieSBmbG93IG1vbml0b3JpbmcgdXNl IGNhc2VzLCB3aGVyZSBzd2l0Y2hlcyBhbmQgcm91dGVycyBlbWJlZCBvciBleHBvcnQgbWV0YWRh dGEgcmVsYXRpbmcgdG8gcGFja2V0cyBpbiBhIGZsb3csIGF0IGxpbmUgcmF0ZSBmb3IgbWFzc2l2 ZWx5IHNjYWxlZCBkYXRhIGNlbnRlcnMuIEF0IHRoZSByZWNlaXZlciwgdHlwaWNhbGx5IHRoZSBl eHBvcnRlZCBtZXRhZGF0YSBpcyBwcm9jZXNzZWQgYW5kIGFuYWx5emVkIGluIHNvZnR3YXJlLiBJ biBzdWNoIGEgc2NlbmFyaW8sIGluIG9yZGVyIHRvIGVuYWJsZSBJT0FNIHRvIHdvcmsgYWNyb3Nz IGFzIHdpZGUgYSByYW5nZSBvZiBkZXZpY2VzIGFzIHBvc3NpYmxlLCBpdCBtYWtlcyBzZW5zZSB0 byB1c2UgdGhlIGRlc2lnbiBwaGlsb3NvcGh5IHRoYXQgRnJhbmsgc3RhdGVkIGFib3ZlOiBBbGxv dyB0aGUgZGF0YSBwcm9kdWNlciB0byBnZW5lcmF0ZSBtZXRhZGF0YSBpbiB3aGF0ZXZlciB1bml0 cyBpdCB3YW50cywgYW5kIG5vcm1hbGl6ZSBhdCB0aGUgcmVjZWl2ZXIgd2hlcmUgdGhlIGV4cG9y dGVkIG1ldGFkYXRhIGlzIHByb2Nlc3NlZCBhbmQgYW5hbHl6ZWQuIEZvciBzdWNoIHVzZSBjYXNl cywgSSBiZWxpZXZlIHRoYXQgc3RhbmRhcmRpemF0aW9uIG9mIHVuaXRzIHNob3VsZCBub3QgYmUg YSBnb2FsLCBub3QgZXZlbiBhcyBhIHJlY29tbWVuZGF0aW9uLg0KDQpbTVNdIFRoZXJlIG1heSBi ZSBvdGhlciB1c2UgY2FzZXMgd2hlcmUgc3RhbmRhcmRpemF0aW9uIG9mIHVuaXRzIG1ha2VzIHNl bnNlLiBSYXRoZXIgdGhhbiBjb25zdHJhaW4gYWxsIHVzZSBjYXNlcywgbXkgc3VnZ2VzdGlvbiB3 b3VsZCBiZSB0byBkZWZpbmUgcmVjb21tZW5kYXRpb25zIHNwZWNpZmljIHRvIHN1Y2ggdXNlIGNh c2VzLCBwZXJoYXBzIHVzaW5nIHRoZSBjb25jZXB0IG9mIHByb2ZpbGVzIHRoYXQgVGFsIGhhcyBw cm9wb3NlZC4NCg0KDQogIDEuICBBZGRpdGlvbmFsIG1lYXN1cmVtZW50cyB0byBjb25zaWRlciDi gJMgYW1vdW50IG9mIEJ5dGVzIHRyYW5zbWl0dGVkIGJ5IGEgcG9ydCwgcmF0ZSBvZiB0cmFuc21p c3Npb24gb2YgYSBwb3J0Lg0KDQpbTVNdIEkgc3VwcG9ydCB0aGUgYWRkaXRpb24gb2YgdGhlIGFt b3VudCBvZiBieXRlcyB0cmFuc21pdHRlZCBieSBhIHBvcnQuIEhvd2V2ZXIsIEkgd29uZGVyIHdo ZXRoZXIgdGhpcyBzaG91bGQgYmUgdGhlIGFtb3VudCBvZiBieXRlcyB0cmFuc21pdHRlZCBvbiB0 aGUgZW50aXJlIHBvcnQsIG9yIHRoZSBhbW91bnQgb2YgYnl0ZXMgdHJhbnNtaXR0ZWQgdXNpbmcg YSBzcGVjaWZpYyBxdWV1ZSBvbiB0aGUgcG9ydD8NCg0KTWlja2V5DQoNCg0KDQogIDEuDQrigKZG QjogVGhlIGRhdGEgZmllbGRzIGN1cnJlbnRseSBkZWZpbmVkIGluIHRoZSBkcmFmdCBhcmUgY29u c2lkZXJlZCBhIOKAnGJhc2VsaW5l4oCdIOKAkyBpLmUuIGEgc2V0IHRoYXQgZXZlcnlvbmUgYWdy ZWVzIHdpdGguIFdlIGFsbCBrbm93IHRoZXJlIGhhdmUgYmVlbiBwcm9wb3NhbHMgZm9yIG90aGVy IGRhdGEgZmllbGRzIGluIHRoZSBwYXN0IOKAkyBidXQgdGhvc2UgcHJvcG9zYWxzIG5ldmVyIGdv dCBicm9hZGVyIG1vbWVudHVtLiBPbmUgY2FuIGFsd2F5cyBsZXZlcmFnZSB0aGUgb3BhcXVlIHN0 YXRlIHNuYXBzaG90IHRvIGNhcnJ5IGRlcGxveW1lbnQgc3BlY2lmaWMgZGF0YS4gU28gaW4gb3Jk ZXIgdG8gYWRkIHRob3NlIHR3byBhZGRpdGlvbmFsIGRhdGEgZmllbGRzIHRvIHRoZSBkcmFmdCBh dCB0aGlzIHN0YWdlLCB3ZeKAmWQgbmVlZCB0byBnZXQgYSBnb29kIHVuZGVyc3RhbmRpbmcgb2Yg aG93IGNvbW1vbiB0aGUgbmVlZCBmb3IgdGhlIHR3byBhZGRpdGlvbmFsIGRhdGEgZmllbGRzIGlz LiBXaG8gZWxzZSB3b3VsZCBzZWUgYSBuZWVkPyBXaGF0IHdvdWxkIGJlIHRoZSB1c2UtY2FzZXM/ DQpbQkddIFdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgdGhlIGxpc3QgZnVydGhlciBjb21tZW50IG9u IHRoYXQNCg0KVGhhbmtzLCBGcmFuaw0KDQpUaGFua3MsDQpCYXJhaw0KDQpGcm9tOiBpcHBtIDxp cHBtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJl aGFsZiBPZiBUb21teSBQYXVseQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSA3LCAyMDIwIDg6NDgg QU0NClRvOiBJRVRGIElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+ Pg0KU3ViamVjdDogW2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlw cG0taW9hbS1kYXRhDQoNCkhlbGxvIElQUE0sDQoNCkhhcHB5IE5ldyBZZWFyISBUaGlzIGVtYWls IHN0YXJ0cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciAiRGF0YSBGaWVsZHMgZm9yIElu LXNpdHUgT0FNIiAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p cHBtLWlvYW0tZGF0YS88aHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFm dC1pZXRmLWlwcG0taW9hbS1kYXRhJTJGJmRhdGE9MDIlN0MwMSU3Q2diYXJhayU0MG1lbGxhbm94 LmNvbSU3Qzk3OGIxYjU0MDI2YjQ4ODE0MGE4MDhkNzllYzE3Y2ZlJTdDYTY1Mjk3MWM3ZDJlNGQ5 YmE2YTRkMTQ5MjU2ZjQ2MWIlN0MwJTdDMCU3QzYzNzE1MjQyNjE3Njk1MjQzMCZzZGF0YT1ZTTJj SVFrSjd4dHZxanEzdkJkdCUyQllXJTJCVThjYmEyanRram16c0RXdzFRSSUzRCZyZXNlcnZlZD0w PikuDQoNClRoZSBsYXN0IGNhbGwgd2lsbCBlbmQgb24gVHVlc2RheSwgSmFudWFyeSAyMS4uLiBQ bGVhc2UgcmVwbHkgdG8gaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4gd2l0aCB5 b3VyIHJldmlld3MgYW5kIGNvbW1lbnRzLiBQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgdGhp bmsgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCkJlc3QsDQpUb21t eSAoYXMgY28tY2hhaXIpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08aHR0cHM6 Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGaXBwbSZkYXRhPTAyJTdDMDEl N0NnYmFyYWslNDBtZWxsYW5veC5jb20lN0M5NzhiMWI1NDAyNmI0ODgxNDBhODA4ZDc5ZWMxN2Nm ZSU3Q2E2NTI5NzFjN2QyZTRkOWJhNmE0ZDE0OTI1NmY0NjFiJTdDMCU3QzAlN0M2MzcxNTI0MjYx NzY5NTI0MzAmc2RhdGE9UzVISU9VaW14OCUyQlNwdzM5TFpuSldMRTlnUk8xcmZhenElMkY0V09I b3NReTglM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_VI1PR05MB41258589F71B3D29BD6BA581B90D0VI1PR05MB4125eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjkxODEw NDA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MTU2MzUzOTA7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MTExMTU1Njc3MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTgxNTYzNTM5MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNDE5NjQz NTU2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODE1NjM1MzkwO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhhdCBhY2NvcmRp bmcgdG8gdGhlc2UgY29tbWVudHMgd2UgYXJlIGNvbnZlcmdpbmcgdG93YXJkcyBhZ3JlZW1lbnQu IOKAnFNIT1VMROKAnSBkb2VzbuKAmXQgcHJlY2x1ZGUgYW55IGltcGxlbWVudGF0aW9uIGhlbmNl IGl0IGtlZXBzIHRoZSBSRkMgaW5jbHVzaXZlIGZvciBkZXZpY2VzIHRoYXQgY2Fu4oCZdCBhbGln biB0byBCeXRlcy4gV2hpbGUgYXMgd2UgYWxsIGhlcmUgZm9yIGludGVyb3BlcmFiaWxpdHkNCiBh bmQgc2ltcGxpY2l0eSBvZiB0aGUgZGVzaWducywgcmVjb21tZW5kaW5nIHRoZSBpbmR1c3RyeSB0 byBhbGlnbiBpdHNlbGYgdG93YXJkcyBzdGFuZGFyZCB1bml0IG9mIG1lYXN1cmVtZW50IGlzIGRl c2lyZWQgZnJvbSBhIHN0YW5kYXJkcyBib2R5IHBlcnNwZWN0aXZlLiBTbyBJIGJlbGlldmUgdGhh dCBpdCBpcyBhbGlnbmVkIHdpdGggeW91ciBjb21tZW50cy4gQXMgeW91IGRlbm90ZSwgdGhlcmUg YXJlIGNhc2VzIHdoZXJlIHN0YW5kYXJkaXphdGlvbg0KIG9mIHVuaXRzIG1ha2Ugc2Vuc2UsIHdo aWxlIGl0IGRvZXNu4oCZdCBodXJ0IG90aGVyIGNhc2VzLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIGFkZGl0aW9uLCBmcm9tIGEgcGVyc29uYWwgb2JzZXJ2YXRpb24s IHRoZSBtYXJrZXQgaW5jbHVkZXMgbWFueSBraW5kcyBvZiBBU0lDcyBpbXBsZW1lbnRlZCBhcyBw YXJ0IG9mIHN3aXRjaGluZyBhbmQgcm91dGluZyBzeXN0ZW1zLiBTb21lIEFTSUMgdmVuZG9ycyBh cmUgcmVwb3J0aW5nIHRoZWlyIEFTSUMg4oCcY2VsbOKAnSBzaXplcyB3aGlsZSBzb21lIG5vdCwg c29tZSBzeXN0ZW0vTk9TIHZlbmRvcnMgcmVwb3J0DQogdGhlIEFTSUMgdGhleSBhcmUgdXNpbmcg YW5kIHNvbWUgbm90LiBJdCBtYXkgYmUgaGFyZCBpbiBtYW55IGVudmlyb25tZW50cyB0byBxdWVy eSB0aGUgZGV2aWNlcyBpbiBvcmRlciB0byBrbm93IHRoaXMgZGF0YSwgYW5kIHRoZW4gcHJvY2Vz cyBhY2NvcmRpbmcuIFRoZSBzdWdnZXN0ZWQgZGlyZWN0aW9uIHNpbXBsaWZpZXMgYWxsIHRoaXMg b3BlcmF0aW9uYWwgYXNwZWN0cyB3aGVuIHBvc3NpYmxlLiBBbmQgaW4gdGhlIG1lYW53aGlsZSwg YXMgc3RhdGVkDQogYWJvdmUsIGRvZXNu4oCZdCBwcmVjbHVkZSBjdXJyZW50IGltcGxlbWVudGF0 aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmFyYWs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE1pY2tleSBTcGllZ2VsICZsdDttc3BpZWdlbEBiYXJlZm9vdG5ldHdvcmtzLmNvbSZndDsg PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjEsIDIwMjAgMjozMCBQTTxicj4N CjxiPlRvOjwvYj4gQmFyYWsgR2FmbmkgJmx0O2diYXJha0BtZWxsYW5veC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSAmbHQ7ZmJyb2NrbmVAY2lzY28u Y29tJmd0OzsgVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs7IElFVEYgSVBQTSBXRyAmbHQ7aXBwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtpcHBtXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1pcHBt LWlvYW0tZGF0YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZSBj b21tZW50cyB1bmRlciBbTVNdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEphbiAyMSwgMjAyMCBhdCAxMTowOSBBTSBCYXJhayBHYWZuaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdiYXJha0BtZWxsYW5veC5jb20iPmdiYXJha0BtZWxsYW5veC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QU0IgdW5kZXIgW0JHXTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QmFyYWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBGcmFuayBCcm9j a25lcnMgKGZicm9ja25lKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmZicm9ja25lQGNpc2NvLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyMSwgMjAyMCA1OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBC YXJhayBHYWZuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdiYXJha0BtZWxsYW5veC5jb20iIHRhcmdl dD0iX2JsYW5rIj5nYmFyYWtAbWVsbGFub3guY29tPC9hPiZndDs7IFRvbW15IFBhdWx5ICZsdDt0 cGF1bHk9PGEgaHJlZj0ibWFpbHRvOjQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgSUVURiBJUFBNIFdH ICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1A aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2lwcG1dIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmFyYWssPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lICjigJzigKZGQuKAnSkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBpcHBtICZsdDs8YSBocmVmPSJtYWls dG86aXBwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbS1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmFyYWsgR2Fmbmk8YnI+DQo8Yj5T ZW50OjwvYj4gRGllbnN0YWcsIDIxLiBKYW51YXIgMjAyMCAwODozMzxicj4NCjxiPlRvOjwvYj4g VG9tbXkgUGF1bHkgJmx0OzxhIGhyZWY9Im1haWx0bzp0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OzsgSUVURiBJUFBNIFdHICZsdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2lwcG1dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWlwcG0t aW9hbS1kYXRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGks PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZldyBjb21tZW50cyB0byBj b25zaWRlcjo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClF1ZXVlIGRlcHRoIGZv cm1hdCDigJMgSW4gb3JkZXIgdG8gYWxpZ24gdGhlIHN0YW5kYXJkaXphdGlvbiBvZiB1bml0cyBh Y3Jvc3MgdGhlIHJvdXRlLCBhcyBkb25lIGZvciB0aW1lIG1lYXN1cmVtZW50cyBmb3IgZXhhbXBs ZSwgSSB3b3VsZCBzdWdnZXN0IHRvIGRpcmVjdCBpbXBsZW1lbnRhdGlvbnMgdG93YXJkcyByZXBv cnRpbmcgQnl0ZXMsIHJhdGhlciB0aGFuIGtlZXBpbmcgaXQgb3BlbiBmb3IgaW50ZXJwcmV0YXRp b24gYnkgdGhlIGltcGxlbWVudG9ycy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PGk+4oCmRkI6IEFzIHlvdSBrbm93LCB0aGUgb3JpZ2luYWwgcmF0aW9u YWxlIHVzZWQgdGhyb3VnaG91dCBJT0FNIGlzIHRvIGF2b2lkIGZvcmNpbmcgdGhlIGRhdGEgcHJv ZHVjZXIgKGUuZy4gdGhlIGZvcndhcmRpbmcgQVNJQykgdG8gdHJhbnNsYXRlIGEgY291bnRlciBp bnRvIGEgc3BlY2lmaWMgdW5pdCwNCiB3aGljaCBjb3VsZCBiZSBjb3N0bHkuIE9uZSB3b3VsZCBy YXRoZXIgZG8gdGhlIHRyYW5zZm9ybWF0aW9uIG9uIHRoZSByZWNlaXZlciBvZiB0aGUgZGF0YSB0 aGFuIG9uIHRoZSBzZW5kZXIgb2YgdGhlIGRhdGEuIEF0IHRoaXMgcG9pbnQgeW914oCZZCBwcm9i YWJseSBhcmd1ZSB0aGF0IGZvciB0aW1lLCB3ZSBhbHNvIHNwZWNpZnkgdGhlIGZvcm1hdC91bml0 IOKAkyB0aG91Z2ggZm9yIHRpbWUsIHdlIGhhdmUgMyBvcHRpb25zIGF2YWlsYWJsZSwgYW5kDQog b25lIG9mIHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBieSB0aGUgc291cmNlIG5h dGl2ZWx5LCBoZW5jZSB0aGUg4oCcZXhjZXB0aW9u4oCdLjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltCR10gQWdyZWUsIGZvcmNpbmcgdGhpcyBy ZXBvcnRpbmcgbWV0aG9kIG1heSBiZSB0b28gbXVjaCBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbiB0 aGF0IHdlIGRvbuKAmXQgd2FudCB0byBwcmV2ZW50IGZyb20gc3VwcG9ydGluZyBJT0FNLiBIZW5j ZSwgbXkgc3VnZ2VzdGlvbiBpcyB0byB1c2UgU0hPVUxELA0KIHdoaWNoIGNhbiBkcml2ZSBiZXR0 ZXIgaW50ZXJvcGVyYWJpbGl0eSBnb2luZyBmb3J3YXJkIHdpdGhvdXQgcHJldmVudCBjdXJyZW50 IGltcGxlbWVudGF0aW9ucyBmcm9tIGJlaW5nIGNvbXBhdGlibGUuPC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPltNU10gVGhlcmUgYXJlIHNldmVyYWwgcG9zc2libGUgdXNlIGNh c2VzIGZvciBJT0FNLiBNdWNoIG9mIHRoZSBpbml0aWFsIHdvcmsgaGFzIGJlZW4gbW90aXZhdGVk IGJ5IGZsb3cgbW9uaXRvcmluZyB1c2UgY2FzZXMsIHdoZXJlIHN3aXRjaGVzIGFuZCByb3V0ZXJz IGVtYmVkIG9yIGV4cG9ydCBtZXRhZGF0YSByZWxhdGluZyB0byBwYWNrZXRzIGluIGEgZmxvdywg YXQgbGluZSByYXRlIGZvciBtYXNzaXZlbHkNCiBzY2FsZWQgZGF0YSBjZW50ZXJzLiBBdCB0aGUg cmVjZWl2ZXIsIHR5cGljYWxseSB0aGUgZXhwb3J0ZWQgbWV0YWRhdGEgaXMgcHJvY2Vzc2VkIGFu ZCBhbmFseXplZCBpbiBzb2Z0d2FyZS4gSW4gc3VjaCBhIHNjZW5hcmlvLCBpbiBvcmRlciB0byBl bmFibGUgSU9BTSB0byB3b3JrIGFjcm9zcyBhcyB3aWRlIGEgcmFuZ2Ugb2YgZGV2aWNlcyBhcyBw b3NzaWJsZSwgaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIHRoZSBkZXNpZ24gcGhpbG9zb3BoeSB0aGF0 DQogRnJhbmsgc3RhdGVkIGFib3ZlOiBBbGxvdyB0aGUgZGF0YSBwcm9kdWNlciB0byBnZW5lcmF0 ZSBtZXRhZGF0YSBpbiB3aGF0ZXZlciB1bml0cyBpdCB3YW50cywgYW5kIG5vcm1hbGl6ZSBhdCB0 aGUgcmVjZWl2ZXIgd2hlcmUgdGhlIGV4cG9ydGVkIG1ldGFkYXRhIGlzIHByb2Nlc3NlZCBhbmQg YW5hbHl6ZWQuIEZvciBzdWNoIHVzZSBjYXNlcywgSSBiZWxpZXZlIHRoYXQgc3RhbmRhcmRpemF0 aW9uIG9mIHVuaXRzIHNob3VsZCBub3QgYmUgYSBnb2FsLA0KIG5vdCBldmVuIGFzIGEgcmVjb21t ZW5kYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltNU10gVGhlcmUgbWF5IGJlIG90aGVyIHVzZSBjYXNlcyB3aGVyZSBzdGFuZGFyZGl6 YXRpb24gb2YgdW5pdHMgbWFrZXMgc2Vuc2UuJm5ic3A7UmF0aGVyIHRoYW4gY29uc3RyYWluIGFs bCB1c2UgY2FzZXMsIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gZGVmaW5lIHJlY29tbWVuZGF0 aW9ucyBzcGVjaWZpYyB0byBzdWNoIHVzZSBjYXNlcywgcGVyaGFwcyB1c2luZyB0aGUgY29uY2Vw dCBvZiBwcm9maWxlcyB0aGF0IFRhbA0KIGhhcyBwcm9wb3NlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPG9sIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPg0KQWRkaXRpb25hbCBtZWFzdXJlbWVudHMgdG8gY29uc2lkZXIg 4oCTIGFtb3VudCBvZiBCeXRlcyB0cmFuc21pdHRlZCBieSBhIHBvcnQsIHJhdGUgb2YgdHJhbnNt aXNzaW9uIG9mIGEgcG9ydC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltNU10g SSBzdXBwb3J0IHRoZSBhZGRpdGlvbiBvZiB0aGUgYW1vdW50IG9mIGJ5dGVzIHRyYW5zbWl0dGVk IGJ5IGEgcG9ydC4gSG93ZXZlciwgSSB3b25kZXIgd2hldGhlciB0aGlzIHNob3VsZCBiZSB0aGUg YW1vdW50IG9mIGJ5dGVzIHRyYW5zbWl0dGVkIG9uIHRoZSBlbnRpcmUgcG9ydCwgb3IgdGhlIGFt b3VudCBvZiBieXRlcyB0cmFuc21pdHRlZCB1c2luZyBhIHNwZWNpZmljIHF1ZXVlIG9uIHRoZSBw b3J0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NaWNrZXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8b2wgc3RhcnQ9IjIiIHR5cGU9IjEiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8bzpwPiZu YnNwOzwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+4oCmRkI6 IFRoZSBkYXRhIGZpZWxkcyBjdXJyZW50bHkgZGVmaW5lZCBpbiB0aGUgZHJhZnQgYXJlIGNvbnNp ZGVyZWQgYSDigJxiYXNlbGluZeKAnSDigJMgaS5lLiBhIHNldCB0aGF0IGV2ZXJ5b25lIGFncmVl cyB3aXRoLiBXZSBhbGwga25vdyB0aGVyZSBoYXZlIGJlZW4gcHJvcG9zYWxzIGZvciBvdGhlciBk YXRhDQogZmllbGRzIGluIHRoZSBwYXN0IOKAkyBidXQgdGhvc2UgcHJvcG9zYWxzIG5ldmVyIGdv dCBicm9hZGVyIG1vbWVudHVtLiBPbmUgY2FuIGFsd2F5cyBsZXZlcmFnZSB0aGUgb3BhcXVlIHN0 YXRlIHNuYXBzaG90IHRvIGNhcnJ5IGRlcGxveW1lbnQgc3BlY2lmaWMgZGF0YS4gU28gaW4gb3Jk ZXIgdG8gYWRkIHRob3NlIHR3byBhZGRpdGlvbmFsIGRhdGEgZmllbGRzIHRvIHRoZSBkcmFmdCBh dCB0aGlzIHN0YWdlLCB3ZeKAmWQgbmVlZCB0byBnZXQgYSBnb29kDQogdW5kZXJzdGFuZGluZyBv ZiBob3cgY29tbW9uIHRoZSBuZWVkIGZvciB0aGUgdHdvIGFkZGl0aW9uYWwgZGF0YSBmaWVsZHMg aXMuIFdobyBlbHNlIHdvdWxkIHNlZSBhIG5lZWQ/IFdoYXQgd291bGQgYmUgdGhlIHVzZS1jYXNl cz88L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5b QkddIFdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgdGhlIGxpc3QgZnVydGhlciBjb21tZW50IG9uIHRo YXQ8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4m bmJzcDs8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 aT5UaGFua3MsIEZyYW5rPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhcmFrPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gaXBwbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRvbW15IFBhdWx5PGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEphbnVhcnkgNywgMjAyMCA4OjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBJRVRGIElQUE0g V0cgJmx0OzxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBw bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtpcHBtXSBXb3JraW5nIEdy b3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0YTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvIElQUE0sPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFwcHkgTmV3IFllYXIhIFRoaXMgZW1h aWwgc3RhcnRzIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yICZxdW90O0RhdGEgRmllbGRz IGZvciBJbi1zaXR1IE9BTSZxdW90OyAoPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhJTJGJmFtcDtkYXRhPTAyJTdD MDElN0NnYmFyYWslNDBtZWxsYW5veC5jb20lN0M5NzhiMWI1NDAyNmI0ODgxNDBhODA4ZDc5ZWMx N2NmZSU3Q2E2NTI5NzFjN2QyZTRkOWJhNmE0ZDE0OTI1NmY0NjFiJTdDMCU3QzAlN0M2MzcxNTI0 MjYxNzY5NTI0MzAmYW1wO3NkYXRhPVlNMmNJUWtKN3h0dnFqcTN2QmR0JTJCWVclMkJVOGNiYTJq dGtqbXpzRFd3MVFJJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0YS88L2E+KS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBsYXN0IGNhbGwgd2lsbCBlbmQgb24NCjxiPlR1ZXNkYXksIEphbnVhcnkgMjE8L2I+Li4u IFBsZWFzZSByZXBseSB0byA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KaXBwbUBpZXRmLm9yZzwvYT4gd2l0aCB5b3VyIHJldmlld3MgYW5kIGNvbW1lbnRz LiBQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ub21teSAoYXMgY28tY2hhaXIpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaXBwbSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMy5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGaXBwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDZ2JhcmFr JTQwbWVsbGFub3guY29tJTdDOTc4YjFiNTQwMjZiNDg4MTQwYTgwOGQ3OWVjMTdjZmUlN0NhNjUy OTcxYzdkMmU0ZDliYTZhNGQxNDkyNTZmNDYxYiU3QzAlN0MwJTdDNjM3MTUyNDI2MTc2OTUyNDMw JmFtcDtzZGF0YT1TNUhJT1VpbXg4JTJCU3B3MzlMWm5KV0xFOWdSTzFyZmF6cSUyRjRXT0hvc1F5 OCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR05MB41258589F71B3D29BD6BA581B90D0VI1PR05MB4125eurp_-- From nobody Tue Jan 21 15:57:08 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137EB1200FA for ; Tue, 21 Jan 2020 15:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lNEUOtQXfMuI for ; Tue, 21 Jan 2020 15:57:02 -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 666DD1200A1 for ; Tue, 21 Jan 2020 15:57:02 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id j1so4763466lja.2 for ; Tue, 21 Jan 2020 15:57:02 -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=xnxa8ZngwoHVmdvi7nG/uaMNiyhijcurLsQ8xWoMgts=; b=UeqewLHyUCqYAYgJ4gApKS+cbxTkafQzaoZ2WNUj+z32xZSm/FgY249HBj3/ntZt2p L44ZMR+21+tOmm61MIJbd2K4rewTl576zzceaSz6GtE3siAU5TFhms59Q/SIwFo5kA2H ZCk9BHzrmHITGflF32UlhWc3cNx8c4nfwlG237+V4HzfXEkcxc5+9En53wQtP4783qno i5ur2P8q/Cbpo3igvrVtIUuo/QnBxRmAJMicLo/pkzSBqdVDb6AXZ5kf348Zp/nLleh1 vXM7/wOxlpIHFIdAJZH887Vjtv+za8bQeNoJJYcIInwVXtjFuG1ewMhV32x+rr7wlBDE H0DQ== 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=xnxa8ZngwoHVmdvi7nG/uaMNiyhijcurLsQ8xWoMgts=; b=CuYlNFvIpK15k4fI+NiJi33CGwKEY09hyKYQCVvpYgAHWBTHRbeF2387/sbcvx6m07 xHfthWLTENsglZHYW+JZf+BRxaCBbcDd9rvTsLXLn2fOTSoGvKvKzW4KoxqoBl+oJfJG Nx+3buZrMjTX4Y+qHD5mnWCLltCfpIfbOlYWXKivIbBrMDjeQNQrLCAjPW6rot9aQyaQ tDdBN5CwB8AVCSIODJaMllL8PIMOst1O6O43VxaFh4wnJecy4ifMhAVcKp6lodlquMxN k5v9w4FFkBRmKJZrdScq/MHFjy05Q4yeLvAMorNUY8A7EW2SvUg2XHIxXjF9kZYjpKP+ Yhkg== X-Gm-Message-State: APjAAAV4PYskdRT8Oo8it4ncElEhesjOTvNC0N86jA+bT/dvdJMjSpfe +bOHOoBEfqsJG0c0dKhTyGyzpjpnLkx/aWUIpD/GSoTZ X-Google-Smtp-Source: APXvYqy7oWvZ2Hlrwd7ItqNrvU9RqPC+ClKHMz6zYFjEsIllfPUppJ3wV0h1UkPCbI5oT72AefB28r8eJpwVVUOxpd4= X-Received: by 2002:a2e:81d0:: with SMTP id s16mr18100659ljg.166.1579651019814; Tue, 21 Jan 2020 15:56:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 21 Jan 2020 15:56:49 -0800 Message-ID: To: Tommy Pauly Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000e7ba93059caf29a6" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 23:57:06 -0000 --000000000000e7ba93059caf29a6 Content-Type: text/plain; charset="UTF-8" Dear All, please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM WG Last Call: - In Abstract and Section 3, Segment Routing is characterized, among other networking technologies, as a transport. RFC 8402 defines Segment Routing as a method to leverage the source routing paradigm. Where else could the Segment Routing be defined as transport? - Also, "native IPv6" is mentioned in the Abstract as transport. Could it be just a reference to IPv6? What is the significance of singling out "native IPv6"? - Introduction section explains the "in-situ" term as The term "in-situ" refers to the fact that the OAM data is added to the data packets rather than is being sent within packets specifically dedicated to OAM. But with the introduction of Loopback and Direct Export as iOAM behaviors, iOAM data are not added to the data packet. And how these new iOAM functions affect the definition of IOAM control points in Section 3? - I-D.lapukhov-dataplane-probe referenced as describing "recent active probing mechanisms". That could have been the case in 2016 when the draft was last time updated. But has expired and has not been discussed or worked for 3.5 years. - In regard to the control over iOAM, text in Section 3 states "It SHOULD be possible to enable IOAM on a selected set of traffic ..." Does that mean that not providing the selective enabling of iOAM is an acceptable option? - Further in Section 3, the requirement for encapsulation independence is using SHOULD "Data formats for IOAM SHOULD be defined in a transport-independent manner." What are the examples of exceptions? - section 4.4 introduces the notion of an "iOAM capable node". Which of iOAM objects are expected to be supported by the iOAM capable node? If a node doesn't support a sub-set of iOAM data types, would it still be considered as iOAM capable? - Section 4.4.1 I'm having a hard time figuring how the presence of Opaque State Snapshot space can be deduced. The explanation in NodeLen is not clear to me. - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only in part of the latter specifying that the format is wide. What is the length on data identified by Bit 0? - Hop_limit in Section 4.4.2 is defined as This is copied from the lower layer, e.g., TTL value in IPv4 header or hop limit field from IPv6 header of the packet when the packet is ready for transmission. What is the value of Hop_Limit field if the lower level does not include TTL/Hop Limit field? - Four octets are allocated for timestamp subseconds in Section 4.4.2. Both PTP and NTP have formats that can provide a higher resolution of a timestamp. That likely to be useful where a higher resolution of time measurement, e.g. delay variation is needed (for example, URLLC applications of 5G, TSN or DetNet). Can iOAM data be extended in the future to support a different length of the subsecond field? - What was the rationale to choose nanoseconds as the unit for transit delay? - How future proof is allocating four octets to express the length of an egress queue (queue depth)? What should be the value if an iOAM node cannot write the local value in four octets? - Similar to the questions above but in regard to the buffer occupancy field. - Checksum Complement may be practical but it raises serious security issues. I couldn't find these being identified and discussed in the document. - Section 5 defers the specification of the particular timestamp format used in the given iOAM Namespace to the management plane. Does that mean that all nodes in the given iOAM Domain must support the same format? In other words, timestamps collected in the domain required to be in the homogeneous format - either all in NTP, all in PTP, or all in POSIX. That looks like unnecessary complexity and limitation and may cause lower accuracy of time measurement as an iOAM node may be required to transform from its native time format into the format chosen by the management plane. Regards, Greg On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly wrote: > Hello IPPM, > > Happy New Year! This email starts a working group last call for "Data > Fields for In-situ OAM" ( > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). > > The last call will end on *Tuesday, January 21*. Please reply to > ippm@ietf.org with your reviews and comments. Please indicate whether you > think this document is ready for publication. > > Best, > Tommy (as co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000e7ba93059caf29a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
please consider my comments to=C2=A0draft-ie= tf-ippm-ioam-data as part of IPPM WG Last Call:
  • In Abstra= ct and Section 3, Segment Routing is characterized, among other networking = technologies, as a transport. RFC 8402 defines Segment Routing as a method = to leverage the source routing paradigm. Where else could the Segment Routi= ng be defined as transport?
  • Also, "native IPv6" is mentio= ned in the Abstract as transport. Could it be just a reference to IPv6? Wha= t is the significance of singling out "native IPv6"?
  • Intr= oduction section explains the "in-situ" term as
=C2=A0 = =C2=A0The term "in-situ" refers to the fact that the OAM
=C2=A0 =C2=A0data is added to the data packets rather than is being sent = within
=C2=A0 =C2=A0packets specifically dedicated to OAM.
<= /blockquote>
But with the introduction of Loopback and Direct Export as iOAM behav= iors, iOAM data are not added to the data packet. And how these new iOAM fu= nctions affect the definition of IOAM control points in Section 3?
  • I-D.lapukhov-dataplane-probe referenced as describing &qu= ot;recent active probing mechanisms". That could have been the case in= 2016 when the draft was last time updated. But has expired and has not bee= n discussed or worked for 3.5 years.
  • In regard to the control o= ver iOAM, text in Section 3 states "It SHOULD be possible to enable IO= AM on a selected set of traffic ..." Does that mean that not providing= the selective enabling of iOAM is an acceptable option?
  • Further in= Section 3, the requirement for encapsulation independence is using SHOULD = "Data formats for IOAM SHOULD be defined in a transport-independent ma= nner." What are the examples of exceptions?
  • section 4.4 introd= uces the notion of an "iOAM capable node". Which of iOAM objects = are expected to be supported by the iOAM capable node? If a node doesn'= t support a sub-set of iOAM data types, would it still be considered as iOA= M capable?
  • Section 4.4.1 I'm having a hard time figuring how th= e presence of=C2=A0Opaque State Snapshot space can be deduced. The explanat= ion in NodeLen is not clear to me.
  • The definitions of Bit 0 and Bit= 8 of=C2=A0IOAM-Trace-Type differ only in part of the latter specifying tha= t the format is wide. What is the length on data identified by Bit 0?
    • <= li>Hop_limit in Section 4.4.2 is defined as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This = is copied from the lower
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer, e.g., = TTL value in IPv4 header or hop limit field from
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0IPv6 header of the packet when the packet is ready for
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission.
What is the value of Hop_Li= mit field if the lower level does not include TTL/Hop Limit field?
  • Four octets are allocated for timestamp subseconds in Secti= on 4.4.2. Both PTP and NTP have formats that can provide a higher resolutio= n of a timestamp. That likely to be useful where a higher resolution of tim= e measurement, e.g. delay variation is needed (for example, URLLC applicati= ons of 5G, TSN or DetNet). Can iOAM data be extended in the future to suppo= rt a different length of the subsecond field?
  • What was the rational= e to choose nanoseconds as the unit for transit delay?
  • How future p= roof is allocating four octets to express the length of an egress queue (qu= eue depth)? What should be the value if an iOAM node cannot write the local= value in four octets?
  • Similar to the questions above but in regard= to the buffer occupancy field.
  • Checksum Complement may be practica= l but it raises serious security issues. I couldn't find these being id= entified and discussed in the document.
  • Section 5 defers the specif= ication of the particular timestamp format used in the given iOAM Namespace= to the management plane. Does that mean that all nodes in the given iOAM D= omain must support the same format? In other words, timestamps collected in= the domain required to be in the homogeneous format - either all in NTP, a= ll in PTP, or all in POSIX. That looks like unnecessary complexity and limi= tation and may cause lower accuracy of time measurement as an iOAM node may= be required to transform from its native time format into the format chose= n by the management plane.
Regards,
Greg

On Tu= e, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
Hello IPPM,

Happy New Year! This email st= arts a working group last call for "Data Fields for In-situ OAM" = (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/= ).

The last call will end on Tuesday, Janua= ry 21. Please reply to ippm@ietf.org with your reviews and comments. Please indicate whethe= r you think this document is ready for publication.

Best,
Tommy (as co-chair)
__________________________= _____________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000e7ba93059caf29a6-- From nobody Tue Jan 21 17:53:08 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1BC120888 for ; Tue, 21 Jan 2020 17:53:03 -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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: invalid data)" header.d=barefootnetworks.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 5vYfbYi-XN14 for ; Tue, 21 Jan 2020 17:53:01 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 86E801207FE for ; Tue, 21 Jan 2020 17:53:01 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id 20so5464662wmj.4 for ; Tue, 21 Jan 2020 17:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barefootnetworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B8J3JTT9XYfDGJTxmG7RJG6JicfncKtAN4XewP/fJvg=; b=eSmHrZr3qmy4dpNKLdUMQLxcXjK8Vw4ZC3JAwia8cWY3sew45FyRya+ZPWexv/8Qe8 Wk0phAgyDbVlnOaG+kVl++EKr9iDPJXNRj0piYtUS3lFovFsOUZ8yg8oZ+0dHPmU/2FK hxYRCQY6SL/SjB4f5AwVb0rXYtCbyHaFlOh64= 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=B8J3JTT9XYfDGJTxmG7RJG6JicfncKtAN4XewP/fJvg=; b=bUpT/OGUaTFCaJLz28wQC1VDCZeRm8Vt4hk8W1MhWu8R6HBoRFCs6gqoXbIxl7pdRJ lHaEmVU1WhoC469z7pDnFvsGlbmoRlrjfyARV3Ak+8g73xcmK5Tx/To22zWZObNQm3AQ s0WofnWB5FxLKcE+C4ehxs8pqXgcWm7YHwhpvUYFIUVtZVCPR+BJRZegj/v5qq6zlK8H 3yFEoGDPfuqXy7GE3sZX3DX2AsxOTD97eLBbWu3P3wno1fD2kR+zNGz7EW8ED+fSYQns fjrQlhjYbWeI4N90xN0kEwHtdvL3YhmRu+NHvbz4AhXFs1UC2+uj/1QEg1D50bBZeaoX JISA== X-Gm-Message-State: APjAAAWemal6Fo/iS5BkOSRSjf8XA7rJ+HFVCS5toIZrAnBla1Zj3yKO zTSKaNBWiqzs7QgsarzhyBHuDvezMydrSEEaVoHCWw== X-Google-Smtp-Source: APXvYqxKNccLG7AaIYovUjtwDmvn8L7NCQZSSZZCMFbnJ/7o+34dAreEUlo3seWXdzEDjs8PpZ5vO/Bgq5i/Ti7ABTI= X-Received: by 2002:a1c:dcd5:: with SMTP id t204mr36900wmg.34.1579657980023; Tue, 21 Jan 2020 17:53:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mickey Spiegel Date: Tue, 21 Jan 2020 17:52:48 -0800 Message-ID: To: Tommy Pauly Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000c43c55059cb0c8e0" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 01:53:07 -0000 --000000000000c43c55059cb0c8e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe this draft is ready for publication, after addressing my comments below. Comments: Section 4.6 IOAM Edge-to-Edge Option-Type In the trace option, the timestamp specifies =E2=80=9Cthe time at which the= packet was received by the node.=E2=80=9D In the edge-to-edge option, it specifies a timestamp =E2=80=9Cfor the trans= mission of the frame=E2=80=9D. Why are these different? Wouldn=E2=80=99t it make more sense to use the time when the packet was rec= eived, in order to determine the overall time that the packet spends in the IOAM domain? Section 4.4.1 Pre-allocated and Incremental Trace Option-Types Text along the following lines should be added somewhere in this section: An IOAM transit node (that is not an IOAM encapsulating node or IOAM decapsulating node) MUST NOT modify any of the fields in the fixed size =E2=80=9Ctrace option header=E2=80=9D, other than =E2=80=9Cflags=E2=80=9D a= nd =E2=80=9CRemainingLen=E2=80=9D, i.e. an IOAM transit node MUST NOT modify the Namespace-ID, NodeLen, IOAM-Trace-Type, or Reserved fields. The =E2=80=9CReserved=E2=80=9D field in Section 4.4.1 just says =E2=80=9CMu= st be zero=E2=80=9D. That should be expanded upon: An IOAM encapsulating node MUST set the value to zero upon transmission. IOAM transit nodes must ignore the received value. The =E2=80=9CNode data List [n]=E2=80=9D description is a little confusing,= particularly the first sentence. Aside from the first sentence, the rest of this text, as well as the =E2=80=9CRemainingLen=E2=80=9D definition, imply that a =E2=80=9Cnode data = element=E2=80=9D (i.e. list item) contains all of the IOAM-Data-Fields that a particular node adds to the trace option. This implies that the IOAM-Trace-Type bits (collectively) determine which data fields are included in each node data element. Any reference to the =E2=80=9Cn-th node data in the node data list=E2=80=9D= is misleading at best, more likely incorrect. That sentence should just be removed. The last sentence before the =E2=80=9CIOAM-Trace-Type=E2=80=9D bit definiti= ons could be moved into the =E2=80=9CNode data List [n]=E2=80=9D definition instead: The order of packing the data fields in each node data element follows the bit order of the IOAM-Trace-Type field Section 7.4 IOAM Trace-Flags Registry This section should specify that Bits 1 through 3 are available for assignment. A process needs to be selected for assignment of these values, probably RFC Required. Section 8 Security Considerations There is text present about "immediate export" mode. This should probably be moved to the DEX draft. Section 9 Acknowledgements There is text present about "immediate export" mode that should be removed. Mickey Spiegel Barefoot Networks, an Intel company On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly wrote: > Hello IPPM, > > Happy New Year! This email starts a working group last call for "Data > Fields for In-situ OAM" ( > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). > > The last call will end on *Tuesday, January 21*. Please reply to > ippm@ietf.org with your reviews and comments. Please indicate whether you > think this document is ready for publication. > > Best, > Tommy (as co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000c43c55059cb0c8e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe this draft is ready for publication, after = addressing my comments below.

Comments:
=
Section 4.6 IOAM Edge-to-Edge Option-Type

In the trace option, the timestamp specifies =E2=80=9Cthe ti= me at which the packet was received by the node.=E2=80=9D
<= div>

In the edge-to-edge option, it specifies a timestamp =E2=80=9C= for the transmission of the frame=E2=80=9D.

Why are these different?

Wouldn=E2=80=99t it make more sense to use the time when the p= acket was received, in order to determine the overall time that the packet = spends in the IOAM domain?


Section 4.4.1 Pre-a= llocated and Incremental Trace Option-Types

Text a= long the following lines should be added somewhere in this section:

An IOAM transit node (that is not an IOAM encapsulating node o= r IOAM decapsulating node) MUST NOT modify any of the fields in the fixed s= ize =E2=80=9Ctrace option header=E2=80=9D, other than =E2=80=9Cflags=E2=80= =9D and =E2=80=9CRemainingLen=E2=80=9D, i.e. an IOAM transit node MUST NOT = modify the Namespace-ID, NodeLen, IOAM-Trace-Type, or Reserved fields.

<= /div>

The =E2=80=9CReserved=E2=80=9D field in Section 4.4.1 just say= s =E2=80=9CMust be zero=E2=80=9D. That should be expanded upon:


An IOAM encapsulating node MUST set the value to = zero upon transmission. IOAM transit nodes must ignore the received value.<= /p>


The =E2=80=9CNode data List [n]=E2=80=9D description is a litt= le confusing, particularly the first sentence.

Aside from the first sentence, the rest of this text, as well = as the =E2=80=9CRemainingLen=E2=80=9D definition, imply that a =E2=80=9Cnod= e data element=E2=80=9D (i.e. list item) contains all of the IOAM-Data-Fiel= ds that a particular node adds to the trace option.

This im= plies that the IOAM-Trace-Type bits (collectively) determine which data fie= lds are included in each node data element.

Any reference = to the =E2=80=9Cn-th node data in the node data list=E2=80=9D is misleading= at best, more likely incorrect. That sentence should just be removed.

The last sentence before the =E2=80=9CIOAM-Trace-Type=E2=80=9D= bit definitions could be moved into the =E2=80=9CNode data List [n]=E2=80= =9D definition instead:


The order of packing the data fields in each node data ele= ment follows the bit order of the IOAM-Trace-Type field


Section 7.4 IOAM Trace-Flags Registry

=
This section should specify that Bits 1 through 3 are available = for assignment.
A process needs to be selected for assignment of = these values, probably RFC Required.

Section 8 Sec= urity Considerations

There is text present about &= quot;immediate export" mode.
This should probably be moved t= o the DEX draft.

Section 9 Acknowledgements
<= div>
There is text present about "immediate export"= mode that should be removed.

Mickey Spiegel
Ba= refoot Networks, an Intel company


On Tue, Jan 7, 2020 at 8:47= AM Tommy Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org> wrote:
Hello I= PPM,

Happy New Year! This email starts a working group l= ast call for "Data Fields for In-situ OAM" (https:= //datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).

<= /div>
The last call will end on Tuesday, January 21. Please repl= y to ippm@ietf.org w= ith your reviews and comments. Please indicate whether you think this docum= ent is ready for publication.

Best,
Tomm= y (as co-chair)
_______________________________________________<= br> ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000c43c55059cb0c8e0-- From nobody Tue Jan 21 22:52:09 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5CE12006B for ; Tue, 21 Jan 2020 22:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G3kV8rXwejF for ; Tue, 21 Jan 2020 22:52:05 -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 93EE5120013 for ; Tue, 21 Jan 2020 22:52:04 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id i23so4433780lfo.7 for ; Tue, 21 Jan 2020 22:52:04 -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=rkNFCsXkqaN/B85VfxepJ8xkDKMmoVOFs+XZNvUMjgo=; b=e3h+Y8/btxioMM5Q7l9AG09z6PhxUB0HnC491JlDIRcQ1GEh9ETkqrHwu+ybc14LsZ Vb+Fc/Y8AHhgsOkZ+XMr3ONCuKQLxCXfWu9W91pcaIrBQ0iYK0O8LNkrP1peujhRK+lj LhjPa4Lft53qZzllmoLspgk+O0x0D4BDFW7l5MSQk0JU6TcI2HhkfkM2XEZXcvg5pLHX D5bPbNPfmv/g3OKNReGHxY7wGVW/AeMIppiO3sKMYRyNyyzunQbd/n3XG5mETdy0g/Sx ZXWi6orVSvBsg8HKD/ZE0ME/eflZ1mI6WYKQt67deM+rg9q43Adj6WtVbNb5UeefejdR XyjA== 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=rkNFCsXkqaN/B85VfxepJ8xkDKMmoVOFs+XZNvUMjgo=; b=C6fRNLLwVlpCrTHA6ErN6iAjVB8RmqQq2QPdpOvRkCeGEDPpkyyFIqkgCXaLmOKW9W RO2hFINtxfSCAtYaFXdnpibObR9pb3kMM4gP4QgwcBuCSTd9HFoLMB7wEJwk7g1uo+GD q2pkkNUVRjzGtTwzuOnYoxb68wPIPyr2n1nhy3d9DWcQ21ieot6By1go/xjtt5XW9Yzq rufQiz193+NzFjlZaUjKULVM9kGfJkYAN7IbGytdjmVHYtEhc5v8bVO7b1hNuUcRxVgt jylYQZXIUCnEMAu8ny9HsgtC0PCYLmQ0VPnNs0OWjvPDsazi4iVxZYoGYw0uUBdRhyen P6ig== X-Gm-Message-State: APjAAAVK+bNBqDLJJmFIfz4dkE7q4PTTZ/BoglVxXK9K7ly6hHFFc+d5 lbqYSrkb57K0qhpZKpjtd3JPFF95O1WUV82HF9CFyQ== X-Google-Smtp-Source: APXvYqzjx5sN1l2GSsTqvCot24qadyDWXRHm5OQtwrQJV05+JCmYvrLC6cF2u2Kvz22SAOLT5Mk9Umc0cOZcyaQo49w= X-Received: by 2002:ac2:4945:: with SMTP id o5mr867020lfi.93.1579675922746; Tue, 21 Jan 2020 22:52:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 21 Jan 2020 22:51:49 -0800 Message-ID: To: Tommy Pauly Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000003c4fc1059cb4f65b" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 06:52:07 -0000 --0000000000003c4fc1059cb4f65b Content-Type: text/plain; charset="UTF-8" Dear All, I'd like to add a note on the scope of the Security Considerations section. While it discusses the potential use of iOAM as the new DDOS attack vector, I didn't find a discussion of the protection of integrity and confidentiality of collected data. As I understand, please correct me if I've missed that in other sections of the document, all data is collected and transported in the clear text, no provisions for authentication or encryption except for Proof-of-Transit. I think that in addition to stressing the importance of protecting the integrity of clock synchronization and of the management plane, possible ways of protecting integrity and, possibly, the confidentiality of collected data must be discussed in the document. Regards, Greg On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky wrote: > Dear All, > please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM > WG Last Call: > > - In Abstract and Section 3, Segment Routing is characterized, among > other networking technologies, as a transport. RFC 8402 defines Segment > Routing as a method to leverage the source routing paradigm. Where else > could the Segment Routing be defined as transport? > - Also, "native IPv6" is mentioned in the Abstract as transport. Could > it be just a reference to IPv6? What is the significance of singling out > "native IPv6"? > - Introduction section explains the "in-situ" term as > > The term "in-situ" refers to the fact that the OAM > data is added to the data packets rather than is being sent within > packets specifically dedicated to OAM. > > But with the introduction of Loopback and Direct Export as iOAM behaviors, > iOAM data are not added to the data packet. And how these new iOAM > functions affect the definition of IOAM control points in Section 3? > > > - I-D.lapukhov-dataplane-probe referenced as describing "recent active > probing mechanisms". That could have been the case in 2016 when the draft > was last time updated. But has expired and has not been discussed or worked > for 3.5 years. > - In regard to the control over iOAM, text in Section 3 states "It > SHOULD be possible to enable IOAM on a selected set of traffic ..." Does > that mean that not providing the selective enabling of iOAM is an > acceptable option? > - Further in Section 3, the requirement for encapsulation independence > is using SHOULD "Data formats for IOAM SHOULD be defined in a > transport-independent manner." What are the examples of exceptions? > - section 4.4 introduces the notion of an "iOAM capable node". Which > of iOAM objects are expected to be supported by the iOAM capable node? If a > node doesn't support a sub-set of iOAM data types, would it still be > considered as iOAM capable? > - Section 4.4.1 I'm having a hard time figuring how the presence > of Opaque State Snapshot space can be deduced. The explanation in NodeLen > is not clear to me. > - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only in > part of the latter specifying that the format is wide. What is the length > on data identified by Bit 0? > - Hop_limit in Section 4.4.2 is defined as > > This is copied from the lower > layer, e.g., TTL value in IPv4 header or hop limit field from > IPv6 header of the packet when the packet is ready for > transmission. > What is the value of Hop_Limit field if the lower level does not include > TTL/Hop Limit field? > > > - Four octets are allocated for timestamp subseconds in Section 4.4.2. > Both PTP and NTP have formats that can provide a higher resolution of a > timestamp. That likely to be useful where a higher resolution of time > measurement, e.g. delay variation is needed (for example, URLLC > applications of 5G, TSN or DetNet). Can iOAM data be extended in the future > to support a different length of the subsecond field? > - What was the rationale to choose nanoseconds as the unit for transit > delay? > - How future proof is allocating four octets to express the length of > an egress queue (queue depth)? What should be the value if an iOAM node > cannot write the local value in four octets? > - Similar to the questions above but in regard to the buffer occupancy > field. > - Checksum Complement may be practical but it raises serious security > issues. I couldn't find these being identified and discussed in the > document. > - Section 5 defers the specification of the particular timestamp > format used in the given iOAM Namespace to the management plane. Does that > mean that all nodes in the given iOAM Domain must support the same format? > In other words, timestamps collected in the domain required to be in the > homogeneous format - either all in NTP, all in PTP, or all in POSIX. That > looks like unnecessary complexity and limitation and may cause lower > accuracy of time measurement as an iOAM node may be required to transform > from its native time format into the format chosen by the management plane. > > Regards, > Greg > > On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> Hello IPPM, >> >> Happy New Year! This email starts a working group last call for "Data >> Fields for In-situ OAM" ( >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >> >> The last call will end on *Tuesday, January 21*. Please reply to >> ippm@ietf.org with your reviews and comments. Please indicate whether >> you think this document is ready for publication. >> >> Best, >> Tommy (as co-chair) >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > --0000000000003c4fc1059cb4f65b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I'd like to add a note on the scope of t= he Security Considerations section. While it discusses the potential use of= iOAM as the new DDOS attack vector, I didn't find a discussion of the = protection of integrity and confidentiality of collected data. As I underst= and, please correct me if I've missed that in other sections of the=C2= =A0document, all data is collected and transported in the clear text, no pr= ovisions for authentication or encryption except for Proof-of-Transit. I th= ink that in addition to stressing the importance of protecting the integrit= y of clock synchronization and of the management plane, possible ways of pr= otecting integrity and, possibly, the confidentiality of collected data mus= t be discussed in the document.

Regards,
Greg

On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,please consider my comments to=C2=A0draft-ietf-ippm-ioam-data as part of = IPPM WG Last Call:
  • In Abstract and Section 3, Segment Rou= ting is characterized, among other networking technologies, as a transport.= RFC 8402 defines Segment Routing as a method to leverage the source routin= g paradigm. Where else could the Segment Routing be defined as transport?
  • Also, "native IPv6" is mentioned in the Abstract as transp= ort. Could it be just a reference to IPv6? What is the significance of sing= ling out "native IPv6"?
  • Introduction section explains the= "in-situ" term as
=C2=A0 =C2=A0The term "in-= situ" refers to the fact that the OAM
=C2=A0 =C2=A0data is a= dded to the data packets rather than is being sent within
=C2=A0 = =C2=A0packets specifically dedicated to OAM.
But with the= introduction of Loopback and Direct Export as iOAM behaviors, iOAM data ar= e not added to the data packet. And how these new iOAM functions affect the= definition of IOAM control points in Section 3?
  • = I-D.lapukhov-dataplane-probe referenced as describing "recent active p= robing mechanisms". That could have been the case in 2016 when the dra= ft was last time updated. But has expired and has not been discussed or wor= ked for 3.5 years.
  • In regard to the control over iOAM, text in = Section 3 states "It SHOULD be possible to enable IOAM on a selected s= et of traffic ..." Does that mean that not providing the selective ena= bling of iOAM is an acceptable option?
  • Further in Section 3, the re= quirement for encapsulation independence is using SHOULD "Data formats= for IOAM SHOULD be defined in a transport-independent manner." What a= re the examples of exceptions?
  • section 4.4 introduces the notion of= an "iOAM capable node". Which of iOAM objects are expected to be= supported by the iOAM capable node? If a node doesn't support a sub-se= t of iOAM data types, would it still be considered as iOAM capable?
    • Section 4.4.1 I'm having a hard time figuring how the presence of=C2= =A0Opaque State Snapshot space can be deduced. The explanation in NodeLen i= s not clear to me.
  • The definitions of Bit 0 and Bit 8 of=C2=A0IOAM-= Trace-Type differ only in part of the latter specifying that the format is = wide. What is the length on data identified by Bit 0?
  • Hop_limit in = Section 4.4.2 is defined as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is copied = from the lower
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer, e.g., TTL value = in IPv4 header or hop limit field from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0IPv6 header of the packet when the packet is ready for
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0transmission.
What is the value of Hop_Limit field i= f the lower level does not include TTL/Hop Limit field?
  • Four octets are allocated for timestamp subseconds in Section 4.4.2. B= oth PTP and NTP have formats that can provide a higher resolution of a time= stamp. That likely to be useful where a higher resolution of time measureme= nt, e.g. delay variation is needed (for example, URLLC applications of 5G, = TSN or DetNet). Can iOAM data be extended in the future to support a differ= ent length of the subsecond field?
  • What was the rationale to choose= nanoseconds as the unit for transit delay?
  • How future proof is all= ocating four octets to express the length of an egress queue (queue depth)?= What should be the value if an iOAM node cannot write the local value in f= our octets?
  • Similar to the questions above but in regard to the buf= fer occupancy field.
  • Checksum Complement may be practical but it ra= ises serious security issues. I couldn't find these being identified an= d discussed in the document.
  • Section 5 defers the specification of = the particular timestamp format used in the given iOAM Namespace to the man= agement plane. Does that mean that all nodes in the given iOAM Domain must = support the same format? In other words, timestamps collected in the domain= required to be in the homogeneous format - either all in NTP, all in PTP, = or all in POSIX. That looks like unnecessary complexity and limitation and = may cause lower accuracy of time measurement as an iOAM node may be require= d to transform from its native time format into the format chosen by the ma= nagement plane.
    • Regards,
    Greg

    On Tue, Jan 7, 2= 020 at 8:47 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
    <= /div>
    Hello IPPM,
    Happy New Year! This email starts a working group last call= for "Data Fields for In-situ OAM" (https://datatr= acker.ietf.org/doc/draft-ietf-ippm-ioam-data/).

    The last call will end on Tuesday, January 21. Please reply to ippm@ietf.org with your= reviews and comments. Please indicate whether you think this document is r= eady for publication.

    Best,
    Tommy (as co= -chair)
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --0000000000003c4fc1059cb4f65b-- From nobody Wed Jan 22 00:33:11 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E0B120013 for ; Wed, 22 Jan 2020 00:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUKGLHtzwjXa for ; Wed, 22 Jan 2020 00:33:07 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 242F41200A4 for ; Wed, 22 Jan 2020 00:33:07 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id b19so5846719wmj.4 for ; Wed, 22 Jan 2020 00:33:07 -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=xqsvjZvm08wVkvCTxa1AeGvJtzRy99If2xxomOngDEY=; b=tEyri+DPZ6yixfVO/c2wJd2hFNqw4XnRj5RwR5Nap8lfxcqnZou7ilVe+XVeEPfGBX ItpOhGPyre3bcWAp6N91tnmGyykRAex1zxhh3ohxbulEPAEOIvNRHvbSgiwN+UA5GsKI 1ztZxVDL1mTO6m63LBz1xHXSmdVM7U5WM+CKRL/yBUQeQnZquEmE3dRfseIi209Eb9SS yOs0fch1tMdO28B8xTL8BuORgwDlhPNk/3DEwkCkUuDI3W9pnSDA0x4FtQQSGLk6MENO oYhYs/PuoQKfIe3lRoVCB6lTsgrmQeviidbmbxSu38SAzHulhV6jq/ALkVUl+zKQ65It irUA== 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=xqsvjZvm08wVkvCTxa1AeGvJtzRy99If2xxomOngDEY=; b=gy5KZFNIkPIIrEPPnxl+ICon5mZ3v411su2jI25itA1+vuQmyBmJSqIeM8aYrjKc1T 0WkVDQIqkJyPF9k8EIVp1W9ZlLn+e4wgeqNZNMprTdIRaHxDu5JR+sTDR+++USC01a0I NDX5S/MTg3duRpw8as1ic6Gerd/y1wc8OEOSQ/SdF2l85AcrbYB8kjKFi/uLDXifsxCP omiWP444zE7kLa+wmoEH3Wpa5upUtjT0ePJ4gI79KEH9T4uGbR2b1rofA0CHSUwfz2w4 n6KkT+EJ9+icXZQgcmukJwhw9v85CRf2HO+BsBNuc9au7oUYCr5ThFN7nwSFoczKLV9t KSAA== X-Gm-Message-State: APjAAAVzFh6rCUbhxFnBjI7C2EJNTZ6aKE8AzdLTguzluYfq9rq4+ySK jTh1J77lW6/sUIqRCOyuzEl9DtVMp1fnyAuHr57RAivEuFs= X-Google-Smtp-Source: APXvYqwiadrfTYgZyN3ZSS9LlV5m5/+S0a1D1LHWaTaMjWmrE72xM7Qo1LOplUbI6iU2D94SZavfLk+9IcFc3XEKd08= X-Received: by 2002:a1c:6809:: with SMTP id d9mr1664385wmc.70.1579681985593; Wed, 22 Jan 2020 00:33:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 22 Jan 2020 10:32:54 +0200 Message-ID: To: Greg Mirsky Cc: Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000009c04c0059cb65f21" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 08:33:09 -0000 --0000000000009c04c0059cb65f21 Content-Type: text/plain; charset="UTF-8" Hi Greg, Thanks for this comment. In the context of "confidentiality", since we are talking about OAM information, the correct context here is reconnaissance. Recon and its implications are indeed discussed in the Security Considerations section on the third paragraph. Regarding integrity protection, the first paragraph of the Security Considerations section discusses the consequences of compromising the integrity of IOAM. In my opinion the current Security Considerations section covers the main threats related to IOAM, and also explains the rationale of not including explicit security mechanisms (the last paragraph of the section). You make a good point that we did not explicitly use the terms "confidentiality" and "integrity", and I will suggest new text that explicitly refers to these terms in the relevant context of the section. Cheers, Tal. On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky wrote: > Dear All, > I'd like to add a note on the scope of the Security Considerations > section. While it discusses the potential use of iOAM as the new DDOS > attack vector, I didn't find a discussion of the protection of integrity > and confidentiality of collected data. As I understand, please correct me > if I've missed that in other sections of the document, all data is > collected and transported in the clear text, no provisions for > authentication or encryption except for Proof-of-Transit. I think that in > addition to stressing the importance of protecting the integrity of clock > synchronization and of the management plane, possible ways of protecting > integrity and, possibly, the confidentiality of collected data must be > discussed in the document. > > Regards, > Greg > > On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky wrote: > >> Dear All, >> please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM >> WG Last Call: >> >> - In Abstract and Section 3, Segment Routing is characterized, among >> other networking technologies, as a transport. RFC 8402 defines Segment >> Routing as a method to leverage the source routing paradigm. Where else >> could the Segment Routing be defined as transport? >> - Also, "native IPv6" is mentioned in the Abstract as transport. >> Could it be just a reference to IPv6? What is the significance of singling >> out "native IPv6"? >> - Introduction section explains the "in-situ" term as >> >> The term "in-situ" refers to the fact that the OAM >> data is added to the data packets rather than is being sent within >> packets specifically dedicated to OAM. >> >> But with the introduction of Loopback and Direct Export as iOAM >> behaviors, iOAM data are not added to the data packet. And how these new >> iOAM functions affect the definition of IOAM control points in Section 3? >> >> >> - I-D.lapukhov-dataplane-probe referenced as describing "recent >> active probing mechanisms". That could have been the case in 2016 when the >> draft was last time updated. But has expired and has not been discussed or >> worked for 3.5 years. >> - In regard to the control over iOAM, text in Section 3 states "It >> SHOULD be possible to enable IOAM on a selected set of traffic ..." Does >> that mean that not providing the selective enabling of iOAM is an >> acceptable option? >> - Further in Section 3, the requirement for encapsulation >> independence is using SHOULD "Data formats for IOAM SHOULD be defined in a >> transport-independent manner." What are the examples of exceptions? >> - section 4.4 introduces the notion of an "iOAM capable node". Which >> of iOAM objects are expected to be supported by the iOAM capable node? If a >> node doesn't support a sub-set of iOAM data types, would it still be >> considered as iOAM capable? >> - Section 4.4.1 I'm having a hard time figuring how the presence >> of Opaque State Snapshot space can be deduced. The explanation in NodeLen >> is not clear to me. >> - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only >> in part of the latter specifying that the format is wide. What is the >> length on data identified by Bit 0? >> - Hop_limit in Section 4.4.2 is defined as >> >> This is copied from the lower >> layer, e.g., TTL value in IPv4 header or hop limit field from >> IPv6 header of the packet when the packet is ready for >> transmission. >> What is the value of Hop_Limit field if the lower level does not include >> TTL/Hop Limit field? >> >> >> - Four octets are allocated for timestamp subseconds in Section >> 4.4.2. Both PTP and NTP have formats that can provide a higher resolution >> of a timestamp. That likely to be useful where a higher resolution of time >> measurement, e.g. delay variation is needed (for example, URLLC >> applications of 5G, TSN or DetNet). Can iOAM data be extended in the future >> to support a different length of the subsecond field? >> - What was the rationale to choose nanoseconds as the unit for >> transit delay? >> - How future proof is allocating four octets to express the length of >> an egress queue (queue depth)? What should be the value if an iOAM node >> cannot write the local value in four octets? >> - Similar to the questions above but in regard to the buffer >> occupancy field. >> - Checksum Complement may be practical but it raises serious security >> issues. I couldn't find these being identified and discussed in the >> document. >> - Section 5 defers the specification of the particular timestamp >> format used in the given iOAM Namespace to the management plane. Does that >> mean that all nodes in the given iOAM Domain must support the same format? >> In other words, timestamps collected in the domain required to be in the >> homogeneous format - either all in NTP, all in PTP, or all in POSIX. That >> looks like unnecessary complexity and limitation and may cause lower >> accuracy of time measurement as an iOAM node may be required to transform >> from its native time format into the format chosen by the management plane. >> >> Regards, >> Greg >> >> On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly > 40apple.com@dmarc.ietf.org <40apple.com@dmarc..ietf.org>> wrote: >> >>> Hello IPPM, >>> >>> Happy New Year! This email starts a working group last call for "Data >>> Fields for In-situ OAM" ( >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >>> >>> The last call will end on *Tuesday, January 21*. Please reply to >>> ippm@ietf.org with your reviews and comments. Please indicate whether >>> you think this document is ready for publication. >>> >>> Best, >>> Tommy (as co-chair) >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >> _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --0000000000009c04c0059cb65f21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Greg,

    Thanks for this comment.
    =

    In the context of "confidentiality", since we= are talking about OAM information, the correct context here is=C2=A0reconn= aissance. Recon and its implications are indeed discussed in the Security C= onsiderations section on the third paragraph.

    Rega= rding integrity protection, the first paragraph of the Security Considerati= ons section discusses the consequences of compromising the integrity of IOA= M.

    In my opinion the current Security Consideratio= ns section covers the main threats related to IOAM, and also explains the r= ationale of not including explicit security mechanisms (the last paragraph = of the section).

    You make a good point that we did= not explicitly use the terms "confidentiality" and "integri= ty", and I will suggest new text that explicitly refers to these terms= in the relevant context of the section.

    Cheers,
    Tal.




    <= div class=3D"gmail_quote">
    On Wed, Jan= 22, 2020 at 8:52 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Dear All,
    I'd like to add = a note on the scope of the Security Considerations section. While it discus= ses the potential use of iOAM as the new DDOS attack vector, I didn't f= ind a discussion of the protection of integrity and confidentiality of coll= ected data. As I understand, please correct me if I've missed that in o= ther sections of the=C2=A0document, all data is collected and transported i= n the clear text, no provisions for authentication or encryption except for= Proof-of-Transit. I think that in addition to stressing the importance of = protecting the integrity of clock synchronization and of the management pla= ne, possible ways of protecting integrity and, possibly, the confidentialit= y of collected data must be discussed in the document.

    =
    Regards,
    Greg

    On Tue, Jan 21, 2020 at 3:56 PM Greg Mirs= ky <gregimirs= ky@gmail.com> wrote:
    Dear All,
    please consider my comments to= =C2=A0draft-ietf-ippm-ioam-data as part of IPPM WG Last Call:
  • In Abstract and Section 3, Segment Routing is characterized, among oth= er networking technologies, as a transport. RFC 8402 defines Segment Routin= g as a method to leverage the source routing paradigm. Where else could the= Segment Routing be defined as transport?
  • Also, "native IPv6&q= uot; is mentioned in the Abstract as transport. Could it be just a referenc= e to IPv6? What is the significance of singling out "native IPv6"= ?
  • Introduction section explains the "in-situ" term as
    • =C2=A0 =C2=A0The term "in-situ" refers to the fact th= at the OAM
    =C2=A0 =C2=A0data is added to the data packets rather = than is being sent within
    =C2=A0 =C2=A0packets specifically dedic= ated to OAM.
    But with the introduction of Loopback and Di= rect Export as iOAM behaviors, iOAM data are not added to the data packet. = And how these new iOAM functions affect the definition of IOAM control poin= ts in Section 3?
    • I-D.lapukhov-dataplane-probe ref= erenced as describing "recent active probing mechanisms". That co= uld have been the case in 2016 when the draft was last time updated. But ha= s expired and has not been discussed or worked for 3.5 years.
    • I= n regard to the control over iOAM, text in Section 3 states "It SHOULD= be possible to enable IOAM on a selected set of traffic ..." Does tha= t mean that not providing the selective enabling of iOAM is an acceptable o= ption?
    • Further in Section 3, the requirement for encapsulation inde= pendence is using SHOULD "Data formats for IOAM SHOULD be defined in a= transport-independent manner." What are the examples of exceptions?
    • section 4.4 introduces the notion of an "iOAM capable node"= ;. Which of iOAM objects are expected to be supported by the iOAM capable n= ode? If a node doesn't support a sub-set of iOAM data types, would it s= till be considered as iOAM capable?
    • Section 4.4.1 I'm having a = hard time figuring how the presence of=C2=A0Opaque State Snapshot space can= be deduced. The explanation in NodeLen is not clear to me.
    • The def= initions of Bit 0 and Bit 8 of=C2=A0IOAM-Trace-Type differ only in part of = the latter specifying that the format is wide. What is the length on data i= dentified by Bit 0?
    • Hop_limit in Section 4.4.2 is defined as
      • = =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is copied from the lower
      =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0layer, e.g., TTL value in IPv4 header or hop limit fiel= d from
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 header of the packet when = the packet is ready for
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission.<= br>What is the value of Hop_Limit field if the lower level does not include= TTL/Hop Limit field?
      • Four octets are allocated for= timestamp subseconds in Section 4.4.2. Both PTP and NTP have formats that = can provide a higher resolution of a timestamp. That likely to be useful wh= ere a higher resolution of time measurement, e.g. delay variation is needed= (for example, URLLC applications of 5G, TSN or DetNet). Can iOAM data be e= xtended in the future to support a different length of the subsecond field?=
      • What was the rationale to choose nanoseconds as the unit for trans= it delay?
      • How future proof is allocating four octets to express the= length of an egress queue (queue depth)? What should be the value if an iO= AM node cannot write the local value in four octets?
      • Similar to the= questions above but in regard to the buffer occupancy field.
      • Check= sum Complement may be practical but it raises serious security issues. I co= uldn't find these being identified and discussed in the document.
        • <= li>Section 5 defers the specification of the particular timestamp format us= ed in the given iOAM Namespace to the management plane. Does that mean that= all nodes in the given iOAM Domain must support the same format? In other = words, timestamps collected in the domain required to be in the homogeneous= format - either all in NTP, all in PTP, or all in POSIX. That looks like u= nnecessary complexity and limitation and may cause lower accuracy of time m= easurement as an iOAM node may be required to transform from its native tim= e format into the format chosen by the management plane.
      Rega= rds,
      Greg

    On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpa= uly=3D40ap= ple.com@dmarc.ietf.org> wrote:
    Hello IPPM,

    Happy New Year! T= his email starts a working group last call for "Data Fields for In-sit= u OAM" (https://datatracker.ietf.org/doc/draft-ietf-ipp= m-ioam-data/).

    The last call will end on Tu= esday, January 21. Please reply to ippm@ietf.org with your reviews and comments. Please ind= icate whether you think this document is ready for publication.
    <= br>
    Best,
    Tommy (as co-chair)
    ______________= _________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --0000000000009c04c0059cb65f21-- From nobody Wed Jan 22 00:40:13 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1174120013 for ; Wed, 22 Jan 2020 00:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT6XdR4IHQ6W for ; Wed, 22 Jan 2020 00:40:08 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 79CD812008B for ; Wed, 22 Jan 2020 00:40:08 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id a5so5896841wmb.0 for ; Wed, 22 Jan 2020 00:40:08 -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=q+zB+IDTJ7priQkG5sasyIB7LGY0Hvlvfl7W0Cg1ptY=; b=o+poojOazcfO62cWeh3WA3n+9dUb16y5mFiQ+hYmz+bhM6d/Dl6sdnMEgC3ybfYWtX 63s1i9jEUi/hxbG8enm5O2+JFHQSzYoxeVirGEA6WrGgbrvgCYalwa8VZY4FPbQcMyHu Lkmz63IUQ7OLfm94dy654BP0d840VBCZgZaTcGmbdLX89KqV3MUOqnxL5dV6fUuuN8FA aKxMvELLimNlsNtQXkz12CSem/ptNJ8/2b2knhmX4eya5R2epmSv2eg9ZMZZniH9Iqhq LlIaX6ceSg63nEZX4yocIkUrckeHOFQGV5r/cjLrlQN4fG4yJl+dBfiU0dGahfRcAfR/ D0og== 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=q+zB+IDTJ7priQkG5sasyIB7LGY0Hvlvfl7W0Cg1ptY=; b=Vjek7Jq++EFQYUbQTo2ZhUCENFQXy/IO1L+ugf2hKifwaHwvse6jm5yO4gFIK2V6NI vy+zFv6uRED38spYioduBf8iKdM9/DLrBBTQG8NnSy5MlOYsa3Kvruz8neaNzfs+j+oG LwhwptesJE1cBDW1UWDNjzHuU/SKFkWmUrRcDZDmux/tO0D7EBfvZjFyEixQ6e7XWQ/D kud/TtQS3fJLHn4qU6m/UfC7y1iKFMkeXfw3hnELsOdGkpCpSTC5P7yel4AfC6WEMuH1 cTwZIRXGVBCR6KxW9fCMfNS9WHVCrjTf14qrkan4/nCiTrGw4E5A8+Oy1pIOfNkFdD1O 275g== X-Gm-Message-State: APjAAAUG5TLnT7GGCvXc7s3hm41ZUr2vuYf3Jl3Url8Lkr//dvwcqTBS mH7AZn2RMp+KYWz/2dJofsb1KGidaW7j2RMudyo= X-Google-Smtp-Source: APXvYqwn1b4Svg+liS/azZLUNYJ3ADPcj8esgBg2ek4MtXqmIrBiIRfnF29LBgU73xf7A3RkwAuzEjUZcJFMCMj+ov0= X-Received: by 2002:a1c:7901:: with SMTP id l1mr1671708wme.67.1579682407025; Wed, 22 Jan 2020 00:40:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 22 Jan 2020 10:39:56 +0200 Message-ID: To: Greg Mirsky Cc: Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000ba9055059cb67833" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 08:40:11 -0000 --000000000000ba9055059cb67833 Content-Type: text/plain; charset="UTF-8" Hi Greg, Regarding your comment: "Checksum Complement may be practical but it raises serious security issues. I couldn't find these being identified and discussed in the document." I am not sure I understand the serious security issues. In my opinion the Checksum Complement does not affect security in any way. The following text regarding the Checksum Complement from RFC 7820 summarizes this point: It is important to emphasize that the scheme described in this document does not increase the protocol's vulnerability to MITM attacks; a MITM attacker who maliciously modifies a packet and its Checksum Complement is logically equivalent to a MITM attacker who modifies a packet and its UDP Checksum field. Cheers, Tal. On Wed, Jan 22, 2020 at 1:57 AM Greg Mirsky wrote: > Dear All, > please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM > WG Last Call: > > - In Abstract and Section 3, Segment Routing is characterized, among > other networking technologies, as a transport. RFC 8402 defines Segment > Routing as a method to leverage the source routing paradigm. Where else > could the Segment Routing be defined as transport? > - Also, "native IPv6" is mentioned in the Abstract as transport. Could > it be just a reference to IPv6? What is the significance of singling out > "native IPv6"? > - Introduction section explains the "in-situ" term as > > The term "in-situ" refers to the fact that the OAM > data is added to the data packets rather than is being sent within > packets specifically dedicated to OAM. > > But with the introduction of Loopback and Direct Export as iOAM behaviors, > iOAM data are not added to the data packet. And how these new iOAM > functions affect the definition of IOAM control points in Section 3? > > > - I-D.lapukhov-dataplane-probe referenced as describing "recent active > probing mechanisms". That could have been the case in 2016 when the draft > was last time updated. But has expired and has not been discussed or worked > for 3.5 years. > - In regard to the control over iOAM, text in Section 3 states "It > SHOULD be possible to enable IOAM on a selected set of traffic ..." Does > that mean that not providing the selective enabling of iOAM is an > acceptable option? > - Further in Section 3, the requirement for encapsulation independence > is using SHOULD "Data formats for IOAM SHOULD be defined in a > transport-independent manner." What are the examples of exceptions? > - section 4.4 introduces the notion of an "iOAM capable node". Which > of iOAM objects are expected to be supported by the iOAM capable node? If a > node doesn't support a sub-set of iOAM data types, would it still be > considered as iOAM capable? > - Section 4.4.1 I'm having a hard time figuring how the presence > of Opaque State Snapshot space can be deduced. The explanation in NodeLen > is not clear to me. > - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only in > part of the latter specifying that the format is wide. What is the length > on data identified by Bit 0? > - Hop_limit in Section 4.4.2 is defined as > > This is copied from the lower > layer, e.g., TTL value in IPv4 header or hop limit field from > IPv6 header of the packet when the packet is ready for > transmission. > What is the value of Hop_Limit field if the lower level does not include > TTL/Hop Limit field? > > > - Four octets are allocated for timestamp subseconds in Section 4.4.2. > Both PTP and NTP have formats that can provide a higher resolution of a > timestamp. That likely to be useful where a higher resolution of time > measurement, e.g. delay variation is needed (for example, URLLC > applications of 5G, TSN or DetNet). Can iOAM data be extended in the future > to support a different length of the subsecond field? > - What was the rationale to choose nanoseconds as the unit for transit > delay? > - How future proof is allocating four octets to express the length of > an egress queue (queue depth)? What should be the value if an iOAM node > cannot write the local value in four octets? > - Similar to the questions above but in regard to the buffer occupancy > field. > - Checksum Complement may be practical but it raises serious security > issues. I couldn't find these being identified and discussed in the > document. > - Section 5 defers the specification of the particular timestamp > format used in the given iOAM Namespace to the management plane. Does that > mean that all nodes in the given iOAM Domain must support the same format? > In other words, timestamps collected in the domain required to be in the > homogeneous format - either all in NTP, all in PTP, or all in POSIX. That > looks like unnecessary complexity and limitation and may cause lower > accuracy of time measurement as an iOAM node may be required to transform > from its native time format into the format chosen by the management plane. > > Regards, > Greg > > On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> Hello IPPM, >> >> Happy New Year! This email starts a working group last call for "Data >> Fields for In-situ OAM" ( >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >> >> The last call will end on *Tuesday, January 21*. Please reply to >> ippm@ietf.org with your reviews and comments. Please indicate whether >> you think this document is ready for publication. >> >> Best, >> Tommy (as co-chair) >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000ba9055059cb67833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Greg,

    Regarding your comment: "= Checksum Complement may be practical but it raises serious security issues.= I couldn't find these being identified and discussed in the document.&= quot;

    I am not sure I understand the serious secur= ity issues.=C2=A0
    In my opinion the Checksum Complement does=C2= =A0 not affect security in any way.
    The following text regarding = the Checksum Complement from RFC 7820 summarizes this point:

    =
    =C2=A0 =C2=A0It is important to emphasize that the scheme descri= bed in this
    =C2=A0 =C2=A0document does not increase the protocol's v= ulnerability to MITM
    =C2=A0 =C2=A0attacks; a MITM attacker who malicious= ly modifies a packet and its
    =C2=A0 =C2=A0Checksum Complement is logical= ly equivalent to a MITM attacker who
    =C2=A0 =C2=A0modifies a packet and = its UDP Checksum field.

    Cheers,
    Tal.=


    On Wed, Jan 22, 2020 at 1:57 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
    =
    De= ar All,
    please consider my comments to=C2=A0draft-ietf-ippm-ioam-data a= s part of IPPM WG Last Call:
    • In Abstract and Section 3, S= egment Routing is characterized, among other networking technologies, as a = transport. RFC 8402 defines Segment Routing as a method to leverage the sou= rce routing paradigm. Where else could the Segment Routing be defined as tr= ansport?
    • Also, "native IPv6" is mentioned in the Abstract= as transport. Could it be just a reference to IPv6? What is the significan= ce of singling out "native IPv6"?
    • Introduction section ex= plains the "in-situ" term as
    =C2=A0 =C2=A0The term= "in-situ" refers to the fact that the OAM
    =C2=A0 =C2= =A0data is added to the data packets rather than is being sent within
    =
    =C2=A0 =C2=A0packets specifically dedicated to OAM.
    =
    = But with the introduction of Loopback and Direct Export as iOAM behaviors, = iOAM data are not added to the data packet. And how these new iOAM function= s affect the definition of IOAM control points in Section 3?
    • I-D.lapukhov-dataplane-probe referenced as describing "rec= ent active probing mechanisms". That could have been the case in 2016 = when the draft was last time updated. But has expired and has not been disc= ussed or worked for 3.5 years.
    • In regard to the control over iO= AM, text in Section 3 states "It SHOULD be possible to enable IOAM on = a selected set of traffic ..." Does that mean that not providing the s= elective enabling of iOAM is an acceptable option?
    • Further in Secti= on 3, the requirement for encapsulation independence is using SHOULD "= Data formats for IOAM SHOULD be defined in a transport-independent manner.&= quot; What are the examples of exceptions?
    • section 4.4 introduces t= he notion of an "iOAM capable node". Which of iOAM objects are ex= pected to be supported by the iOAM capable node? If a node doesn't supp= ort a sub-set of iOAM data types, would it still be considered as iOAM capa= ble?
    • Section 4.4.1 I'm having a hard time figuring how the pres= ence of=C2=A0Opaque State Snapshot space can be deduced. The explanation in= NodeLen is not clear to me.
    • The definitions of Bit 0 and Bit 8 of= =C2=A0IOAM-Trace-Type differ only in part of the latter specifying that the= format is wide. What is the length on data identified by Bit 0?
    • Ho= p_limit in Section 4.4.2 is defined as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 This= is copied from the lower
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer, e.g.,= TTL value in IPv4 header or hop limit field from
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0IPv6 header of the packet when the packet is ready for
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission.
    What is the value of Hop_Li= mit field if the lower level does not include TTL/Hop Limit field?
    • Four octets are allocated for timestamp subseconds in Secti= on 4.4.2. Both PTP and NTP have formats that can provide a higher resolutio= n of a timestamp. That likely to be useful where a higher resolution of tim= e measurement, e.g. delay variation is needed (for example, URLLC applicati= ons of 5G, TSN or DetNet). Can iOAM data be extended in the future to suppo= rt a different length of the subsecond field?
    • What was the rational= e to choose nanoseconds as the unit for transit delay?
    • How future p= roof is allocating four octets to express the length of an egress queue (qu= eue depth)? What should be the value if an iOAM node cannot write the local= value in four octets?
    • Similar to the questions above but in regard= to the buffer occupancy field.
    • Checksum Complement may be practica= l but it raises serious security issues. I couldn't find these being id= entified and discussed in the document.
    • Section 5 defers the specif= ication of the particular timestamp format used in the given iOAM Namespace= to the management plane. Does that mean that all nodes in the given iOAM D= omain must support the same format? In other words, timestamps collected in= the domain required to be in the homogeneous format - either all in NTP, a= ll in PTP, or all in POSIX. That looks like unnecessary complexity and limi= tation and may cause lower accuracy of time measurement as an iOAM node may= be required to transform from its native time format into the format chose= n by the management plane.
    Regards,
    Greg

    On Tu= e, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> = wrote:
    Hell= o IPPM,

    Happy New Year! This email starts a working grou= p last call for "Data Fields for In-situ OAM" (htt= ps://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).

    _____________________________________________= __
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000ba9055059cb67833-- From nobody Fri Jan 24 10:59:36 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597B412004C; Fri, 24 Jan 2020 10:59:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-ippm-metric-registry@ietf.org, ippm-chairs@ietf.org, ietf@wjcerveny.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157989237435.22132.15269428217200226195.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2020 10:59:34 -0800 Archived-At: Subject: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-metric-registry-23: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:59:34 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ippm-metric-registry-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT. In Section 7.1.2, I would recommend the following change for clarity: OLD Spec: an immutable document, for RFCs, the RFC number and major section number that specifies this Registry entry in the form RFCXXXXsecY, such as RFC7799sec3. NEW Spec: an immutable document identifier combined with a document section identifier. For RFCs, this consists of the RFC number and major section number that specifies this Registry entry in the form RFCXXXXsecY, such as RFC7799sec3. From nobody Sat Jan 25 16:30:18 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F9012007C for ; Sat, 25 Jan 2020 16:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fgefe9S0dSEd for ; Sat, 25 Jan 2020 16:30:14 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8DA120044 for ; Sat, 25 Jan 2020 16:30:13 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id x7so6871470ljc.1 for ; Sat, 25 Jan 2020 16:30:13 -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=I0ZugLPRWOLwI09sgo0MYsPfBmsEU+xWVBCShDblHYk=; b=Pa1B9T2KVaWhgomiC+32sGwXsn7IucVBC5P/eVeMcJW+KX8O57mY1e9HLCUDSqBHV4 k27ubSjcNsyWAmHfgYQPYlO2XM3Lr0fXVo0rcKjLRqeliG48wK/0KkckFwEF7z402mQe UAxHLaPPtd1OSu7zOYeqLY9AjQ8c6Eww+xGr4fLoEjfh5aDOvh375bU7vBJh1HYf3pxz TWqU1nCQ9yDiJNv7GmMfw4ibFi2x51nRpucWtCcEiCdOI20C1KFSp5+blsWVOslHpRP9 A1K8W92tbbJ4lLxbGNC/RwgJ5iQRgip51n7yMaFyiDhYksyJvNLRI8q/XoDSeHQE1+nu 5rEQ== 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=I0ZugLPRWOLwI09sgo0MYsPfBmsEU+xWVBCShDblHYk=; b=CyPMTXA9rexLEs8OsRIn5YOKlnh0bxKtX6A2LBKMp/doh+zoynyqdcj1z5M8J6qJHI Qj5N1VJRD6ENVIEA1fMyQ/a3xN3XCh1e7wP9+otHKpxr85bSsbYmcxM8gJbw5nkxxVfA oczWPKlmgA7/Zi198gnCFmzQx04DwvT1DFdi5v9g5mp/ZFvsS9xILKAbQxGO9PSn3Phk 18+Ojg6kw+QzehLTDlv0nIDmA4kjrX3mOBTy7kCU/griRyFLQx22N7HS4F2zBwVlHpU3 c1JN0/KAbitjbMJtxODqazhCnfGqKknJIeW3x/YBLWxrBvcGIPCgjOPQaROEtIBJaA7a 1KHw== X-Gm-Message-State: APjAAAU5J1jY+AFQGIFeE+gAi6d7PhTTbBbUl17h2FKdzlTvoKX/1bhC LGp3prV6XgtB7W3A4Z5KzOn0+a4QpxbF5ReN0Rc= X-Google-Smtp-Source: APXvYqzUeGvQJ7U1mqLThAJE6Xfhez53jF3iY6aaXsAvhsYMt1E+mVrMw7JugYYmH3rfLPm2ectpfT3lyEPmjCVYgLY= X-Received: by 2002:a2e:88c4:: with SMTP id a4mr6424542ljk.174.1579998611489; Sat, 25 Jan 2020 16:30:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sat, 25 Jan 2020 16:30:01 -0800 Message-ID: To: Tal Mizrahi Cc: Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000fbc8e1059d0017a1" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 00:30:17 -0000 --000000000000fbc8e1059d0017a1 Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for your quick response to my comments. Please find my follow-up notes in-line tagged GIM>>. Best regards, Greg On Wed, Jan 22, 2020 at 12:33 AM Tal Mizrahi wrote: > Hi Greg, > > Thanks for this comment. > > In the context of "confidentiality", since we are talking about OAM > information, the correct context here is reconnaissance. Recon and its > implications are indeed discussed in the Security Considerations section on > the third paragraph. > GIM>> I find the text that you've referring too terse: The data elements of IOAM can be used for network reconnaissance, allowing attackers to collect information about network paths, performance, queue states, buffer occupancy and other information. True, you name the problem but I don't see any discussion of how to mitigate the risk of an intruder obtaining very sensitive information. What mechanisms can be used to protect the confidentiality of data? Also, I've noticed the text that, I think, should not be in the document in WG Last Call phase: Note that in case IOAM is used in "immediate export" mode (reference to be added in a future revision) ... This is a simple editorial change but I'd appreciate it being done. And as we discuss confidentiality, I believe that I-D.ietf-sfc-proof-of-transit must be in the normative list since the security measures and mechanisms discussed in that draft are applicable to this specification as well. > > Regarding integrity protection, the first paragraph of the Security > Considerations section discusses the consequences of compromising the > integrity of IOAM. > GIM>> I am not sure that I can interpret the first paragraph in the same manner as you. (As a side note, since RFC 7276 is used as the source of information, I think it should be in the normative list of references). My understanding of the first paragraph is that it explains that iOAM may be used to produce a false-negative and/or false-positive view of the network state. But I don't find any discussion on how to protect, how to make it more difficult for an attacker to manipulate with or alter iOAM data. > > In my opinion the current Security Considerations section covers the main > threats related to IOAM, and also explains the rationale of not including > explicit security mechanisms (the last paragraph of the section). > GIM>> On this I do agree. Security Considerations section names threats. But I believe that it as well should include recommendations, options of mitigating these risks, risk introduced specifically by iOAM transporting information in data packets. > > You make a good point that we did not explicitly use the terms > "confidentiality" and "integrity", and I will suggest new text that > explicitly refers to these terms in the relevant context of the section. > > Cheers, > Tal. > > > > > On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky wrote: > >> Dear All, >> I'd like to add a note on the scope of the Security Considerations >> section. While it discusses the potential use of iOAM as the new DDOS >> attack vector, I didn't find a discussion of the protection of integrity >> and confidentiality of collected data. As I understand, please correct me >> if I've missed that in other sections of the document, all data is >> collected and transported in the clear text, no provisions for >> authentication or encryption except for Proof-of-Transit. I think that in >> addition to stressing the importance of protecting the integrity of clock >> synchronization and of the management plane, possible ways of protecting >> integrity and, possibly, the confidentiality of collected data must be >> discussed in the document. >> >> Regards, >> Greg >> >> On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky >> wrote: >> >>> Dear All, >>> please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM >>> WG Last Call: >>> >>> - In Abstract and Section 3, Segment Routing is characterized, among >>> other networking technologies, as a transport. RFC 8402 defines Segment >>> Routing as a method to leverage the source routing paradigm. Where else >>> could the Segment Routing be defined as transport? >>> - Also, "native IPv6" is mentioned in the Abstract as transport. >>> Could it be just a reference to IPv6? What is the significance of singling >>> out "native IPv6"? >>> - Introduction section explains the "in-situ" term as >>> >>> The term "in-situ" refers to the fact that the OAM >>> data is added to the data packets rather than is being sent within >>> packets specifically dedicated to OAM. >>> >>> But with the introduction of Loopback and Direct Export as iOAM >>> behaviors, iOAM data are not added to the data packet. And how these new >>> iOAM functions affect the definition of IOAM control points in Section 3? >>> >>> >>> - I-D.lapukhov-dataplane-probe referenced as describing "recent >>> active probing mechanisms". That could have been the case in 2016 when the >>> draft was last time updated. But has expired and has not been discussed or >>> worked for 3.5 years. >>> - In regard to the control over iOAM, text in Section 3 states "It >>> SHOULD be possible to enable IOAM on a selected set of traffic ..." Does >>> that mean that not providing the selective enabling of iOAM is an >>> acceptable option? >>> - Further in Section 3, the requirement for encapsulation >>> independence is using SHOULD "Data formats for IOAM SHOULD be defined in a >>> transport-independent manner." What are the examples of exceptions? >>> - section 4.4 introduces the notion of an "iOAM capable node". Which >>> of iOAM objects are expected to be supported by the iOAM capable node? If a >>> node doesn't support a sub-set of iOAM data types, would it still be >>> considered as iOAM capable? >>> - Section 4.4.1 I'm having a hard time figuring how the presence >>> of Opaque State Snapshot space can be deduced. The explanation in NodeLen >>> is not clear to me. >>> - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only >>> in part of the latter specifying that the format is wide. What is the >>> length on data identified by Bit 0? >>> - Hop_limit in Section 4.4.2 is defined as >>> >>> This is copied from the lower >>> layer, e.g., TTL value in IPv4 header or hop limit field from >>> IPv6 header of the packet when the packet is ready for >>> transmission. >>> What is the value of Hop_Limit field if the lower level does not include >>> TTL/Hop Limit field? >>> >>> >>> - Four octets are allocated for timestamp subseconds in Section >>> 4.4.2. Both PTP and NTP have formats that can provide a higher resolution >>> of a timestamp. That likely to be useful where a higher resolution of time >>> measurement, e.g. delay variation is needed (for example, URLLC >>> applications of 5G, TSN or DetNet). Can iOAM data be extended in the future >>> to support a different length of the subsecond field? >>> - What was the rationale to choose nanoseconds as the unit for >>> transit delay? >>> - How future proof is allocating four octets to express the length >>> of an egress queue (queue depth)? What should be the value if an iOAM node >>> cannot write the local value in four octets? >>> - Similar to the questions above but in regard to the buffer >>> occupancy field. >>> - Checksum Complement may be practical but it raises serious >>> security issues. I couldn't find these being identified and discussed in >>> the document. >>> - Section 5 defers the specification of the particular timestamp >>> format used in the given iOAM Namespace to the management plane. Does that >>> mean that all nodes in the given iOAM Domain must support the same format? >>> In other words, timestamps collected in the domain required to be in the >>> homogeneous format - either all in NTP, all in PTP, or all in POSIX. That >>> looks like unnecessary complexity and limitation and may cause lower >>> accuracy of time measurement as an iOAM node may be required to transform >>> from its native time format into the format chosen by the management plane. >>> >>> Regards, >>> Greg >>> >>> On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly >> 40apple.com@dmarc.ietf.org <40apple.com@dmarc..ietf.org>> wrote: >>> >>>> Hello IPPM, >>>> >>>> Happy New Year! This email starts a working group last call for "Data >>>> Fields for In-situ OAM" ( >>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >>>> >>>> The last call will end on *Tuesday, January 21*. Please reply to >>>> ippm@ietf.org with your reviews and comments. Please indicate whether >>>> you think this document is ready for publication. >>>> >>>> Best, >>>> Tommy (as co-chair) >>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >>> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > --000000000000fbc8e1059d0017a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tal,
    thank you for your quick resp= onse to my comments. Please find my follow-up notes in-line tagged GIM>&= gt;.

    Best regards,
    Greg

    <= div class=3D"gmail_quote">
    On Wed, Jan= 22, 2020 at 12:33 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
    Hi Greg,

    Thanks for this comment.

    In the context of &quo= t;confidentiality", since we are talking about OAM information, the co= rrect context here is=C2=A0reconnaissance. Recon and its implications are i= ndeed discussed in the Security Considerations section on the third paragra= ph.
    GIM>> I find the text that you'v= e referring too terse:
    =C2=A0 =C2=A0The data elements of IOAM can= be used for network reconnaissance,
    =C2=A0 =C2=A0allowing attackers to = collect information about network paths,
    =C2=A0 =C2=A0performance, queue= states, buffer occupancy and other information.
    True, you na= me the problem but I don't see any discussion of how to mitigate the ri= sk of an intruder obtaining very sensitive information. What mechanisms can= be used to protect the confidentiality of data?

    A= lso, I've noticed the text that, I think, should not be in the document= in WG Last Call phase:
    =C2=A0 =C2=A0Note that in case IOAM is us= ed in "immediate export" mode (reference
    =C2=A0 =C2=A0to be ad= ded in a future revision) ...
    This is a simple editorial chan= ge but I'd appreciate it being done.

    And as we= discuss confidentiality, I believe that I-D.ietf-sfc-proof-of-transit must= be in the normative list since the security measures and mechanisms discus= sed in that draft are applicable to this specification as well.

    Regarding integrity protection, the first paragraph of the Security C= onsiderations section discusses the consequences of compromising the integr= ity of IOAM.
    GIM>> I am not sure that I = can interpret the first paragraph in the same manner as you. (As a side not= e, since RFC 7276 is used as the source of information, I think it should b= e in the normative list of references). My understanding of the first parag= raph is that it explains that iOAM may be used to produce a false-negative = and/or false-positive view of the network state. But I don't find any d= iscussion on how to protect, how to make it more difficult for an attacker = to manipulate with or alter iOAM data.

    In my opinion the c= urrent Security Considerations section covers the main threats related to I= OAM, and also explains the rationale of not including explicit security mec= hanisms (the last paragraph of the section).
    G= IM>> On this I do agree. Security Considerations section names threat= s. But I believe that it as well should include recommendations, options of= mitigating these risks, risk introduced specifically by iOAM transporting = information in data packets.

    You make a good point that = we did not explicitly use the terms "confidentiality" and "i= ntegrity", and I will suggest new text that explicitly refers to these= terms in the relevant context of the section.

    Che= ers,
    Tal.




    On We= d, Jan 22, 2020 at 8:52 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Dear All,<= div>I'd like to add a note on the scope of the Security Considerations = section. While it discusses the potential use of iOAM as the new DDOS attac= k vector, I didn't find a discussion of the protection of integrity and= confidentiality of collected data. As I understand, please correct me if I= 've missed that in other sections of the=C2=A0document, all data is col= lected and transported in the clear text, no provisions for authentication = or encryption except for Proof-of-Transit. I think that in addition to stre= ssing the importance of protecting the integrity of clock synchronization a= nd of the management plane, possible ways of protecting integrity and, poss= ibly, the confidentiality of collected data must be discussed in the docume= nt.

    Regards,
    Greg

    On Tue, Jan 21, 2= 020 at 3:56 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Dear All,
    please c= onsider my comments to=C2=A0draft-ietf-ippm-ioam-data as part of IPPM WG La= st Call:
    • In Abstract and Section 3, Segment Routing is ch= aracterized, among other networking technologies, as a transport. RFC 8402 = defines Segment Routing as a method to leverage the source routing paradigm= . Where else could the Segment Routing be defined as transport?
    • Als= o, "native IPv6" is mentioned in the Abstract as transport. Could= it be just a reference to IPv6? What is the significance of singling out &= quot;native IPv6"?
    • Introduction section explains the "in-= situ" term as
    =C2=A0 =C2=A0The term "in-situ"= refers to the fact that the OAM
    =C2=A0 =C2=A0data is added to th= e data packets rather than is being sent within
    =C2=A0 =C2=A0pack= ets specifically dedicated to OAM.
    But with the introduct= ion of Loopback and Direct Export as iOAM behaviors, iOAM data are not adde= d to the data packet. And how these new iOAM functions affect the definitio= n of IOAM control points in Section 3?
    • I-D.lapukh= ov-dataplane-probe referenced as describing "recent active probing mec= hanisms". That could have been the case in 2016 when the draft was las= t time updated. But has expired and has not been discussed or worked for 3.= 5 years.
    • In regard to the control over iOAM, text in Section 3 = states "It SHOULD be possible to enable IOAM on a selected set of traf= fic ..." Does that mean that not providing the selective enabling of i= OAM is an acceptable option?
    • Further in Section 3, the requirement = for encapsulation independence is using SHOULD "Data formats for IOAM = SHOULD be defined in a transport-independent manner." What are the exa= mples of exceptions?
    • section 4.4 introduces the notion of an "= iOAM capable node". Which of iOAM objects are expected to be supported= by the iOAM capable node? If a node doesn't support a sub-set of iOAM = data types, would it still be considered as iOAM capable?
    • Section 4= .4.1 I'm having a hard time figuring how the presence of=C2=A0Opaque St= ate Snapshot space can be deduced. The explanation in NodeLen is not clear = to me.
    • The definitions of Bit 0 and Bit 8 of=C2=A0IOAM-Trace-Type d= iffer only in part of the latter specifying that the format is wide. What i= s the length on data identified by Bit 0?
    • Hop_limit in Section 4.4.= 2 is defined as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is copied from the low= er
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer, e.g., TTL value in IPv4 head= er or hop limit field from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 header= of the packet when the packet is ready for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0transmission.
    What is the value of Hop_Limit field if the lower le= vel does not include TTL/Hop Limit field?
    • Four octe= ts are allocated for timestamp subseconds in Section 4.4.2. Both PTP and NT= P have formats that can provide a higher resolution of a timestamp. That li= kely to be useful where a higher resolution of time measurement, e.g. delay= variation is needed (for example, URLLC applications of 5G, TSN or DetNet)= . Can iOAM data be extended in the future to support a different length of = the subsecond field?
    • What was the rationale to choose nanoseconds a= s the unit for transit delay?
    • How future proof is allocating four o= ctets to express the length of an egress queue (queue depth)? What should b= e the value if an iOAM node cannot write the local value in four octets?
    • Similar to the questions above but in regard to the buffer occupancy = field.
    • Checksum Complement may be practical but it raises serious s= ecurity issues. I couldn't find these being identified and discussed in= the document.
    • Section 5 defers the specification of the particular= timestamp format used in the given iOAM Namespace to the management plane.= Does that mean that all nodes in the given iOAM Domain must support the sa= me format? In other words, timestamps collected in the domain required to b= e in the homogeneous format - either all in NTP, all in PTP, or all in POSI= X. That looks like unnecessary complexity and limitation and may cause lowe= r accuracy of time measurement as an iOAM node may be required to transform= from its native time format into the format chosen by the management plane= .
    Regards,
    Greg

    On Tue, Jan 7, 2020 at 8:47 AM= Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
    Hello IPPM,

    Happy New Year! This email starts a working group last call for "Da= ta Fields for In-situ OAM" (https://datatracker.ietf.or= g/doc/draft-ietf-ippm-ioam-data/).

    The last ca= ll will end on Tuesday, January 21. Please reply to ippm@ietf.org with your reviews and = comments. Please indicate whether you think this document is ready for publ= ication.

    Best,
    Tommy (as co-chair)
    =
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000fbc8e1059d0017a1-- From nobody Sun Jan 26 06:07:47 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657A12006B; Sun, 26 Jan 2020 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5C0t_ANvIluz; Sun, 26 Jan 2020 06:07:39 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B6205120043; Sun, 26 Jan 2020 06:07:39 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00QE5hao040060; Sun, 26 Jan 2020 09:07:36 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 2xs3gdpgnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Jan 2020 09:07:36 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 00QE7Ycq000678; Sun, 26 Jan 2020 08:07:35 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [135.46.181.176]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 00QE7Rk3000585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Jan 2020 08:07:27 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [127.0.0.1]) by zlp30493.vci.att.com (Service) with ESMTP id 23F814009E79; Sun, 26 Jan 2020 14:07:27 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30493.vci.att.com (Service) with ESMTP id 03CFA4009E6F; Sun, 26 Jan 2020 14:07:26 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 00QE7QXB012704; Sun, 26 Jan 2020 08:07:26 -0600 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 00QE7Htw012202; Sun, 26 Jan 2020 08:07:18 -0600 Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-green.research.att.com (Postfix) with ESMTP id 41649E2F2A; Sun, 26 Jan 2020 09:07:03 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0468.000; Sun, 26 Jan 2020 09:07:16 -0500 From: "MORTON, ALFRED C (AL)" To: Alissa Cooper , The IESG CC: "draft-ietf-ippm-metric-registry@ietf.org" , "ippm-chairs@ietf.org" , "ietf@wjcerveny.com" , "ippm@ietf.org" Thread-Topic: Alissa Cooper's No Objection on draft-ietf-ippm-metric-registry-23: (with COMMENT) Thread-Index: AQHV0uh04lr8uxY6nEy26R5OoGiWHaf8/bMw Date: Sun, 26 Jan 2020 14:07:16 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F1BBCA@njmtexg5.research.att.com> References: <157989237435.22132.15269428217200226195.idtracker@ietfa.amsl.com> In-Reply-To: <157989237435.22132.15269428217200226195.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.44.176.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-26_01:2020-01-24, 2020-01-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 malwarescore=0 bulkscore=0 adultscore=0 priorityscore=1501 spamscore=0 mlxscore=0 impostorscore=0 clxscore=1011 suspectscore=0 mlxlogscore=915 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001260124 Archived-At: Subject: Re: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-metric-registry-23: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 14:07:42 -0000 VGhhbmtzIEFsaXNzYSwgSSBoYXZlIG1hZGUgeW91ciByZWNvbW1lbmRlZCBjaGFuZ2UgaW4gdGhl IA0Kd29ya2luZyB0ZXh0IHZlcnNpb24uDQoNCkFsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQWxpc3NhIENvb3BlciB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3Jl cGx5QGlldGYub3JnXQ0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjQsIDIwMjAgMjowMCBQTQ0K PiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLWlwcG0tbWV0 cmljLXJlZ2lzdHJ5QGlldGYub3JnOyBpcHBtLWNoYWlyc0BpZXRmLm9yZzsNCj4gaWV0ZkB3amNl cnZlbnkuY29tOyBpcHBtQGlldGYub3JnDQo+IFN1YmplY3Q6IEFsaXNzYSBDb29wZXIncyBObyBP YmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pcHBtLW1ldHJpYy1yZWdpc3RyeS0NCj4gMjM6ICh3aXRo IENPTU1FTlQpDQo+IA0KPiBBbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWlwcG0tbWV0cmljLXJlZ2lzdHJ5LTIz OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAz QV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1sJmQ9 RHdJQ2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcy Y0J3Jm09dnpHb3VRM3ZKaVNnM3Q5UlhDVmhhbmp5WHdkRHoNCj4gMmh2ZFh0bDBwZWxaUjgmcz1S WlF1Z1pHczZkcTRSOGxubkJJcGN5LWJQUUFCT1BkMXRmR2pjaHBrZGo4JmU9DQo+IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRp ZXRmLTJEaXBwbS0yRG1ldHJpYy0NCj4gMkRyZWdpc3RyeV8mZD1Ed0lDYVEmYz1MRllaLQ0KPiBv OV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT12ekdvdVEzdkppU2cz dDlSWENWaGFuanlYd2REeg0KPiAyaHZkWHRsMHBlbFpSOCZzPUhJbC1xYU0zRXZ6Mm5JSVlCNlRj cVJma1o3WU5vTVJzSENGWjdNWGNta0UmZT0NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIGFkZHJlc3Npbmcg bXkgRElTQ1VTUyBhbmQgQ09NTUVOVC4NCj4gDQo+IEluIFNlY3Rpb24gNy4xLjIsIEkgd291bGQg cmVjb21tZW5kIHRoZSBmb2xsb3dpbmcgY2hhbmdlIGZvciBjbGFyaXR5Og0KPiANCj4gT0xEDQo+ IFNwZWM6IGFuIGltbXV0YWJsZSBkb2N1bWVudCwgZm9yIFJGQ3MsIHRoZSBSRkMgbnVtYmVyIGFu ZCBtYWpvciBzZWN0aW9uDQo+IG51bWJlcg0KPiB0aGF0IHNwZWNpZmllcyB0aGlzIFJlZ2lzdHJ5 IGVudHJ5IGluIHRoZSBmb3JtIFJGQ1hYWFhzZWNZLCBzdWNoIGFzDQo+IFJGQzc3OTlzZWMzLg0K PiANCj4gTkVXDQo+IFNwZWM6IGFuIGltbXV0YWJsZSBkb2N1bWVudCBpZGVudGlmaWVyIGNvbWJp bmVkIHdpdGggYSBkb2N1bWVudCBzZWN0aW9uDQo+IGlkZW50aWZpZXIuIEZvciBSRkNzLCB0aGlz IGNvbnNpc3RzIG9mIHRoZSBSRkMgbnVtYmVyIGFuZCBtYWpvciBzZWN0aW9uDQo+IG51bWJlcg0K PiB0aGF0IHNwZWNpZmllcyB0aGlzIFJlZ2lzdHJ5IGVudHJ5IGluIHRoZSBmb3JtIFJGQ1hYWFhz ZWNZLCBzdWNoIGFzDQo+IFJGQzc3OTlzZWMzLg0KPiANCg0K From nobody Sun Jan 26 23:47:41 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893F12001E; Sun, 26 Jan 2020 23:47:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <158011125724.30586.174948030935161363@ietfa.amsl.com> Date: Sun, 26 Jan 2020 23:47:37 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-flags-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 07:47:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : In-situ OAM Flags Authors : Tal Mizrahi Frank Brockners Shwetha Bhandari Ramesh Sivakolundu Carlos Pignataro Aviv Kfir Barak Gafni Mickey Spiegel Jennifer Lemon Filename : draft-ietf-ippm-ioam-flags-01.txt Pages : 10 Date : 2020-01-26 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document presents new flags in the IOAM Trace Option headers. Specifically, the document defines the Loopback and Active flags. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-ioam-flags-01 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-flags-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 27 00:05:49 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F078912010F for ; Mon, 27 Jan 2020 00:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tp9tyespWe6L for ; Mon, 27 Jan 2020 00:05:46 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 C0E7C12001E for ; Mon, 27 Jan 2020 00:05:45 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id w15so9959790wru.4 for ; Mon, 27 Jan 2020 00:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TicN+H7GiD+yK542MDBJy3BQlBUhwwh+gKjNijyD70Y=; b=ns2ZMV2pn0uKsY9n8+X4AuFTzdkE+F8SvCQtKZ+J9GBYmEegZGuaS1tikIZ4u/fUN7 gqmqgvJDtTzYa7F8wMILggXpQPmXa8n4mXCCPGoQHXYbF0NljTqWZ97FmgaqOLI8TLCu KuAK2HX4vn+/9K9URqQHHoL9ZPg2PLInB1LiPgrT4jtiSXrwp4zwENmS7vrDtiLrM/yz 6Ml9kjlxW0M0gl9EbYQRHcCDhGS5z1Ygl84vkPLXUNxR7Sr251liZ/FPjaXywaghGo1P GKKsUKZLYa6AzC2bFS67Xpep3+SdTMdKCCMGnRBh58vvBaqqQstKfHtaZTRzGHd/O+ZW WGOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TicN+H7GiD+yK542MDBJy3BQlBUhwwh+gKjNijyD70Y=; b=hWthQq6DXqMQk58a9D6SvOBFfQIFbO0MZMS0I52yCA1HCsHbhGoenaZ516gQFiYrmJ t6FNk4fA78vR7D74G7BxVaBSiU3h34H1GYitgqlzM9dRmx3/t/06UVpeQ9uC0a3C9dYW 8k8Y5InJOIyqPnsNggVBdxGIIl3S4IYclmQDalu/0mUMIMpTG9wtdNrWdZm2VSXbuDKY DDf6cnSq8tSQ5iVEEBJSUjbPfizewtZdmXrPwMr0hoxvXR22St7ODiwpaXKOML3jBa6e wDYEvsprviB9TueSkfGW5AxBcBYNHWbhH/tfXHlD0MsCjgwAwvXURK40SKiX5jsXuSWE gHdg== X-Gm-Message-State: APjAAAV2SfTArlb5blyL3DQymzmMlFzvX/N99FzT0neVhaIURddoOAtt MRPI3HoyQO5VrsA4dwmjLGLMbap1EFrjZ6bJPlutbRym//c= X-Google-Smtp-Source: APXvYqybSr2N9ZaFN3n7FBHGNXVYJuWayQWGEXtG6drIzAG/Vo0Ur9IhE2ycpzKCxUmehGT0CDpEn3vvR0oB2QT2vsU= X-Received: by 2002:adf:dfd2:: with SMTP id q18mr21123284wrn.152.1580112343982; Mon, 27 Jan 2020 00:05:43 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Mon, 27 Jan 2020 10:05:33 +0200 Message-ID: To: IETF IPPM WG , Tal Mizrahi Content-Type: multipart/alternative; boundary="000000000000f7e548059d1a9223" Archived-At: Subject: [ippm] Flag draft: updated version X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 08:05:48 -0000 --000000000000f7e548059d1a9223 Content-Type: text/plain; charset="UTF-8" Hi, A new version has been posted: https://tools.ietf.org/html/draft-ietf-ippm-ioam-flags-01 Several issues about the flag draft have been discussed in IETF 106 and in the IOAM virtual meetings since IETF 106. While not all issues have been concluded yet, we are releasing this version to allow for some discussion before IETF 107. Please let us know if there are any comments. Main changes since the previous version: - The Security Considerations section has been updated with further discussion regarding mitigating amplification attacks, in two main aspects: rate limiting, and data minimization (a single data field). - Various clarifications about the loopback flag have been added. - Text has been added to clarify the purpose of the active flag. Main open issue: - Loopback: it was noted that incorporating IOAM data is not necessary on the reverse path when a packet is looped back. The problem is how to indicate to transit nodes that they should not push IOAM data into a looped back packet on the reverse path. There are a few possible solutions: (1) By defining a new flag that indicates this is a loopback on the reverse path. (2) By defining a new IOAM type that indicates this is a loopback on the reverse path. (3) By clearing the RemainingLen field, thus preventing nodes from pushing more data fields. Cheers, Tal. --000000000000f7e548059d1a9223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    A new version has been= posted:
    https://tools.ietf.org/html/draft-ietf-ippm-ioam-flags-01
    Several issues about the flag draft have been discussed in IETF 106 and i= n the IOAM virtual meetings since IETF 106. While not all issues have been = concluded yet, we are releasing this version to allow for some discussion b= efore IETF 107.

    Please let us know if there are any comments.
    Main changes since the previous version:
    - The Security Considerations = section has been updated with further discussion regarding mitigating ampli= fication attacks, in two main aspects: rate limiting, and data minimization= (a single data field).
    - Various clarifications about the loopback flag= have been added.
    - Text has been added to clarify the purpose of the ac= tive flag.

    Main open issue:
    - Loopback: it was noted that incorpo= rating IOAM data is not necessary on the reverse path when a packet is loop= ed back. The problem is how to indicate to transit nodes that they should n= ot push IOAM data into a looped back packet on the reverse path. There are = a few possible solutions: (1) By defining a new flag that indicates this is= a loopback on the reverse path. (2) By defining a new IOAM type that indic= ates this is a loopback on the reverse path. (3) By clearing the RemainingL= en field, thus preventing nodes from pushing more data fields.

    Cheer= s,
    Tal.
    --000000000000f7e548059d1a9223-- From nobody Mon Jan 27 00:52:45 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2753112012E for ; Mon, 27 Jan 2020 00:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zikre-2cD5eM for ; Mon, 27 Jan 2020 00:52:39 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 4394D1201EA for ; Mon, 27 Jan 2020 00:52:39 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id t14so6081842wmi.5 for ; Mon, 27 Jan 2020 00:52: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=4vr/VEPI1s3PH1A1NE7nrBK0UKElK4r6jv5AZL3ygN8=; b=poXVf9DfBTUdsq1Ypq4pSpcG9QgrSjLUpAgl/+KP+v6kL9LFUvvQBfAZ9/35BI+MB2 AeLp1OVhS8399zCSm/P7eYoFh+z+DAbGyem89k/JCQFQHnq0zaurZD73c2QpH6gm/pwH kbiuydQ/srGUEInvtPJY1b7V7p9OdGGLmNCZi0FpI1hP5o+ujsFtyWP9WMuVvULhySN5 dDr5yw6O4J4ehpqRycDUX6muvIKruxNNhSH6Vokf0ykSMOXnG0E9BgEDIHuIX5EoMAQY Vv4O9zzVPqLkTx8b4KXdIj4Xz3HzubcMFkSGhFUWYVTDInP1UF1zS1HNXoQCEHg6to+s 4ucQ== 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=4vr/VEPI1s3PH1A1NE7nrBK0UKElK4r6jv5AZL3ygN8=; b=JhY4qg6a6zACK9qjry2ZoGbFFClff0gKbwJGFSGxvtOmNp6RDZRk0TFOhetc3EnEqu nA2TYVTggb85rY7XxDZkhOefHljUzVSSAetPK6DksQG6qLQzVLrGGClSOYH+vOBTeWT5 JA2NwAMZhCCaWve09Twm5uZSQK7tQGfGzuR4o4xQvdmX3rMhnXWgyLVsbrD8AbVgbv01 IUJzgfF9oCGYCOI73seHddn5inieySVshmY5eDazqZH69X1F/Z7AIW56VFPEIQJhif71 eCEhgpEMu5Ow7B1wEs8QVoF349W3249c7evX+BhggQG8UQni4kP4TEcYWOVyf0huxUqe J8QA== X-Gm-Message-State: APjAAAUBvkKVz+Lw1Eo1QYKgdtKmwyojrAMIhGPNv1KE6ujBP2v1bQLe Q/hXlo+21mX84a9A/kZ9MC5S1DE5qejHEdHsvzRe2ErvhRg= X-Google-Smtp-Source: APXvYqxvNZ2ZHcyiOHOsdZ/zXjwPcOFbG4pZwF1csvQ6vZZVRfW4v/LEvZ8RgcsUWPXPjOOVi/ZnsP9i6FshHMSWcgA= X-Received: by 2002:a1c:960c:: with SMTP id y12mr12468794wmd.9.1580115157713; Mon, 27 Jan 2020 00:52:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Mon, 27 Jan 2020 10:52:26 +0200 Message-ID: To: Greg Mirsky Cc: Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000ae057a059d1b3ab7" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 08:52:43 -0000 --000000000000ae057a059d1b3ab7 Content-Type: text/plain; charset="UTF-8" Hi Greg, Many thanks for the comments. Your point is well taken regarding the term "immediate export", and regarding clarifying the connection to integrity and confidentiality. There is a fundamental assumption in this draft that since IOAM is deployed in confined administrative domains, it significantly limits the scope of all the threats that are described in this section. Therefore this draft does not define any specific security mechanisms. This was a basic assumption throughout the process, and therefore the security considerations does not define any security mechanisms. However, I added some text that further clarifies this point. The following pull request includes my suggested changes to the Security Considerations following your comments: https://github.com/inband-oam/ietf/pull/146 Cheers, Tal. On Sun, Jan 26, 2020 at 2:30 AM Greg Mirsky wrote: > Hi Tal, > thank you for your quick response to my comments. Please find my follow-up > notes in-line tagged GIM>>. > > Best regards, > Greg > > On Wed, Jan 22, 2020 at 12:33 AM Tal Mizrahi > wrote: > >> Hi Greg, >> >> Thanks for this comment. >> >> In the context of "confidentiality", since we are talking about OAM >> information, the correct context here is reconnaissance. Recon and its >> implications are indeed discussed in the Security Considerations section on >> the third paragraph. >> > GIM>> I find the text that you've referring too terse: > The data elements of IOAM can be used for network reconnaissance, > allowing attackers to collect information about network paths, > performance, queue states, buffer occupancy and other information. > True, you name the problem but I don't see any discussion of how to > mitigate the risk of an intruder obtaining very sensitive information. What > mechanisms can be used to protect the confidentiality of data? > > Also, I've noticed the text that, I think, should not be in the document > in WG Last Call phase: > Note that in case IOAM is used in "immediate export" mode (reference > to be added in a future revision) ... > This is a simple editorial change but I'd appreciate it being done. > > And as we discuss confidentiality, I believe that > I-D.ietf-sfc-proof-of-transit must be in the normative list since the > security measures and mechanisms discussed in that draft are applicable to > this specification as well. > >> >> Regarding integrity protection, the first paragraph of the Security >> Considerations section discusses the consequences of compromising the >> integrity of IOAM. >> > GIM>> I am not sure that I can interpret the first paragraph in the same > manner as you. (As a side note, since RFC 7276 is used as the source of > information, I think it should be in the normative list of references). My > understanding of the first paragraph is that it explains that iOAM may be > used to produce a false-negative and/or false-positive view of the network > state. But I don't find any discussion on how to protect, how to make it > more difficult for an attacker to manipulate with or alter iOAM data. > >> >> In my opinion the current Security Considerations section covers the main >> threats related to IOAM, and also explains the rationale of not including >> explicit security mechanisms (the last paragraph of the section). >> > GIM>> On this I do agree. Security Considerations section names threats. > But I believe that it as well should include recommendations, options of > mitigating these risks, risk introduced specifically by iOAM transporting > information in data packets. > >> >> You make a good point that we did not explicitly use the terms >> "confidentiality" and "integrity", and I will suggest new text that >> explicitly refers to these terms in the relevant context of the section. >> >> Cheers, >> Tal. >> >> >> >> >> On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky >> wrote: >> >>> Dear All, >>> I'd like to add a note on the scope of the Security Considerations >>> section. While it discusses the potential use of iOAM as the new DDOS >>> attack vector, I didn't find a discussion of the protection of integrity >>> and confidentiality of collected data. As I understand, please correct me >>> if I've missed that in other sections of the document, all data is >>> collected and transported in the clear text, no provisions for >>> authentication or encryption except for Proof-of-Transit. I think that in >>> addition to stressing the importance of protecting the integrity of clock >>> synchronization and of the management plane, possible ways of protecting >>> integrity and, possibly, the confidentiality of collected data must be >>> discussed in the document. >>> >>> Regards, >>> Greg >>> >>> On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky >>> wrote: >>> >>>> Dear All, >>>> please consider my comments to draft-ietf-ippm-ioam-data as part of >>>> IPPM WG Last Call: >>>> >>>> - In Abstract and Section 3, Segment Routing is characterized, >>>> among other networking technologies, as a transport. RFC 8402 defines >>>> Segment Routing as a method to leverage the source routing paradigm. Where >>>> else could the Segment Routing be defined as transport? >>>> - Also, "native IPv6" is mentioned in the Abstract as transport. >>>> Could it be just a reference to IPv6? What is the significance of singling >>>> out "native IPv6"? >>>> - Introduction section explains the "in-situ" term as >>>> >>>> The term "in-situ" refers to the fact that the OAM >>>> data is added to the data packets rather than is being sent within >>>> packets specifically dedicated to OAM. >>>> >>>> But with the introduction of Loopback and Direct Export as iOAM >>>> behaviors, iOAM data are not added to the data packet. And how these new >>>> iOAM functions affect the definition of IOAM control points in Section 3? >>>> >>>> >>>> - I-D.lapukhov-dataplane-probe referenced as describing "recent >>>> active probing mechanisms". That could have been the case in 2016 when the >>>> draft was last time updated. But has expired and has not been discussed or >>>> worked for 3.5 years. >>>> - In regard to the control over iOAM, text in Section 3 states "It >>>> SHOULD be possible to enable IOAM on a selected set of traffic ..." Does >>>> that mean that not providing the selective enabling of iOAM is an >>>> acceptable option? >>>> - Further in Section 3, the requirement for encapsulation >>>> independence is using SHOULD "Data formats for IOAM SHOULD be defined in a >>>> transport-independent manner." What are the examples of exceptions? >>>> - section 4.4 introduces the notion of an "iOAM capable node". >>>> Which of iOAM objects are expected to be supported by the iOAM capable >>>> node? If a node doesn't support a sub-set of iOAM data types, would it >>>> still be considered as iOAM capable? >>>> - Section 4.4.1 I'm having a hard time figuring how the presence >>>> of Opaque State Snapshot space can be deduced. The explanation in NodeLen >>>> is not clear to me. >>>> - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only >>>> in part of the latter specifying that the format is wide. What is the >>>> length on data identified by Bit 0? >>>> - Hop_limit in Section 4.4.2 is defined as >>>> >>>> This is copied from the lower >>>> layer, e.g., TTL value in IPv4 header or hop limit field from >>>> IPv6 header of the packet when the packet is ready for >>>> transmission. >>>> What is the value of Hop_Limit field if the lower level does not >>>> include TTL/Hop Limit field? >>>> >>>> >>>> - Four octets are allocated for timestamp subseconds in Section >>>> 4.4.2. Both PTP and NTP have formats that can provide a higher resolution >>>> of a timestamp. That likely to be useful where a higher resolution of time >>>> measurement, e.g. delay variation is needed (for example, URLLC >>>> applications of 5G, TSN or DetNet). Can iOAM data be extended in the future >>>> to support a different length of the subsecond field? >>>> - What was the rationale to choose nanoseconds as the unit for >>>> transit delay? >>>> - How future proof is allocating four octets to express the length >>>> of an egress queue (queue depth)? What should be the value if an iOAM node >>>> cannot write the local value in four octets? >>>> - Similar to the questions above but in regard to the buffer >>>> occupancy field. >>>> - Checksum Complement may be practical but it raises serious >>>> security issues. I couldn't find these being identified and discussed in >>>> the document. >>>> - Section 5 defers the specification of the particular timestamp >>>> format used in the given iOAM Namespace to the management plane. Does that >>>> mean that all nodes in the given iOAM Domain must support the same format? >>>> In other words, timestamps collected in the domain required to be in the >>>> homogeneous format - either all in NTP, all in PTP, or all in POSIX. That >>>> looks like unnecessary complexity and limitation and may cause lower >>>> accuracy of time measurement as an iOAM node may be required to transform >>>> from its native time format into the format chosen by the management plane. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly >>> 40apple.com@dmarc.ietf.org <40apple.com@dmarc..ietf.org>> wrote: >>>> >>>>> Hello IPPM, >>>>> >>>>> Happy New Year! This email starts a working group last call for "Data >>>>> Fields for In-situ OAM" ( >>>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >>>>> >>>>> The last call will end on *Tuesday, January 21*. Please reply to >>>>> ippm@ietf.org with your reviews and comments. Please indicate whether >>>>> you think this document is ready for publication. >>>>> >>>>> Best, >>>>> Tommy (as co-chair) >>>>> _______________________________________________ >>>>> ippm mailing list >>>>> ippm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>> >>>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >> --000000000000ae057a059d1b3ab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Greg,

    Many thanks for the comments.<= /div>
    Your point is well taken regarding the term "immediate expor= t", and regarding clarifying the connection to integrity and confident= iality.
    There is a fundamental assumption in this draft that sinc= e IOAM is deployed in confined administrative domains, it significantly lim= its the scope of all the threats that are described=C2=A0in this section. T= herefore this draft does not define any specific security mechanisms. This = was a basic assumption throughout the process, and therefore the security c= onsiderations does not define any security mechanisms. However, I added som= e text that further clarifies this point.

    The foll= owing pull request includes my suggested changes to the Security Considerat= ions following your comments:

    On Sun, Jan 26, 2020 at 2:30 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
    =
    Hi Tal,
    thank you for your quick response to my comments= . Please find my follow-up notes in-line tagged GIM>>.

    =
    Best regards,
    Greg

    On Wed, Jan 22, 2020 at 12:33 = AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
    Hi Greg,

    Thanks for this comment.

    In the context of &quo= t;confidentiality", since we are talking about OAM information, the co= rrect context here is=C2=A0reconnaissance. Recon and its implications are i= ndeed discussed in the Security Considerations section on the third paragra= ph.
    GIM>> I find the text that you'v= e referring too terse:
    =C2=A0 =C2=A0The data elements of IOAM can= be used for network reconnaissance,
    =C2=A0 =C2=A0allowing attackers to = collect information about network paths,
    =C2=A0 =C2=A0performance, queue= states, buffer occupancy and other information.
    True, you na= me the problem but I don't see any discussion of how to mitigate the ri= sk of an intruder obtaining very sensitive information. What mechanisms can= be used to protect the confidentiality of data?

    A= lso, I've noticed the text that, I think, should not be in the document= in WG Last Call phase:
    =C2=A0 =C2=A0Note that in case IOAM is us= ed in "immediate export" mode (reference
    =C2=A0 =C2=A0to be ad= ded in a future revision) ...
    This is a simple editorial chan= ge but I'd appreciate it being done.

    And as we= discuss confidentiality, I believe that I-D.ietf-sfc-proof-of-transit must= be in the normative list since the security measures and mechanisms discus= sed in that draft are applicable to this specification as well.

    Regarding integrity protection, the first paragraph of the Security C= onsiderations section discusses the consequences of compromising the integr= ity of IOAM.
    GIM>> I am not sure that I = can interpret the first paragraph in the same manner as you. (As a side not= e, since RFC 7276 is used as the source of information, I think it should b= e in the normative list of references). My understanding of the first parag= raph is that it explains that iOAM may be used to produce a false-negative = and/or false-positive view of the network state. But I don't find any d= iscussion on how to protect, how to make it more difficult for an attacker = to manipulate with or alter iOAM data.

    In my opinion the c= urrent Security Considerations section covers the main threats related to I= OAM, and also explains the rationale of not including explicit security mec= hanisms (the last paragraph of the section).
    G= IM>> On this I do agree. Security Considerations section names threat= s. But I believe that it as well should include recommendations, options of= mitigating these risks, risk introduced specifically by iOAM transporting = information in data packets.

    You make a good point that = we did not explicitly use the terms "confidentiality" and "i= ntegrity", and I will suggest new text that explicitly refers to these= terms in the relevant context of the section.

    Che= ers,
    Tal.




    On We= d, Jan 22, 2020 at 8:52 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Dear All,<= div>I'd like to add a note on the scope of the Security Considerations = section. While it discusses the potential use of iOAM as the new DDOS attac= k vector, I didn't find a discussion of the protection of integrity and= confidentiality of collected data. As I understand, please correct me if I= 've missed that in other sections of the=C2=A0document, all data is col= lected and transported in the clear text, no provisions for authentication = or encryption except for Proof-of-Transit. I think that in addition to stre= ssing the importance of protecting the integrity of clock synchronization a= nd of the management plane, possible ways of protecting integrity and, poss= ibly, the confidentiality of collected data must be discussed in the docume= nt.

    Regards,
    Greg

    On Tue, Jan 21, 2= 020 at 3:56 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Dear All,
    please c= onsider my comments to=C2=A0draft-ietf-ippm-ioam-data as part of IPPM WG La= st Call:
    • In Abstract and Section 3, Segment Routing is ch= aracterized, among other networking technologies, as a transport. RFC 8402 = defines Segment Routing as a method to leverage the source routing paradigm= . Where else could the Segment Routing be defined as transport?
    • Als= o, "native IPv6" is mentioned in the Abstract as transport. Could= it be just a reference to IPv6? What is the significance of singling out &= quot;native IPv6"?
    • Introduction section explains the "in-= situ" term as
    =C2=A0 =C2=A0The term "in-situ"= refers to the fact that the OAM
    =C2=A0 =C2=A0data is added to th= e data packets rather than is being sent within
    =C2=A0 =C2=A0pack= ets specifically dedicated to OAM.
    But with the introduct= ion of Loopback and Direct Export as iOAM behaviors, iOAM data are not adde= d to the data packet. And how these new iOAM functions affect the definitio= n of IOAM control points in Section 3?
    • I-D.lapukh= ov-dataplane-probe referenced as describing "recent active probing mec= hanisms". That could have been the case in 2016 when the draft was las= t time updated. But has expired and has not been discussed or worked for 3.= 5 years.
    • In regard to the control over iOAM, text in Section 3 = states "It SHOULD be possible to enable IOAM on a selected set of traf= fic ..." Does that mean that not providing the selective enabling of i= OAM is an acceptable option?
    • Further in Section 3, the requirement = for encapsulation independence is using SHOULD "Data formats for IOAM = SHOULD be defined in a transport-independent manner." What are the exa= mples of exceptions?
    • section 4.4 introduces the notion of an "= iOAM capable node". Which of iOAM objects are expected to be supported= by the iOAM capable node? If a node doesn't support a sub-set of iOAM = data types, would it still be considered as iOAM capable?
    • Section 4= .4.1 I'm having a hard time figuring how the presence of=C2=A0Opaque St= ate Snapshot space can be deduced. The explanation in NodeLen is not clear = to me.
    • The definitions of Bit 0 and Bit 8 of=C2=A0IOAM-Trace-Type d= iffer only in part of the latter specifying that the format is wide. What i= s the length on data identified by Bit 0?
    • Hop_limit in Section 4.4.= 2 is defined as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is copied from the low= er
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer, e.g., TTL value in IPv4 head= er or hop limit field from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 header= of the packet when the packet is ready for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0transmission.
    What is the value of Hop_Limit field if the lower le= vel does not include TTL/Hop Limit field?
    • Four octe= ts are allocated for timestamp subseconds in Section 4.4.2. Both PTP and NT= P have formats that can provide a higher resolution of a timestamp. That li= kely to be useful where a higher resolution of time measurement, e.g. delay= variation is needed (for example, URLLC applications of 5G, TSN or DetNet)= . Can iOAM data be extended in the future to support a different length of = the subsecond field?
    • What was the rationale to choose nanoseconds a= s the unit for transit delay?
    • How future proof is allocating four o= ctets to express the length of an egress queue (queue depth)? What should b= e the value if an iOAM node cannot write the local value in four octets?
    • Similar to the questions above but in regard to the buffer occupancy = field.
    • Checksum Complement may be practical but it raises serious s= ecurity issues. I couldn't find these being identified and discussed in= the document.
    • Section 5 defers the specification of the particular= timestamp format used in the given iOAM Namespace to the management plane.= Does that mean that all nodes in the given iOAM Domain must support the sa= me format? In other words, timestamps collected in the domain required to b= e in the homogeneous format - either all in NTP, all in PTP, or all in POSI= X. That looks like unnecessary complexity and limitation and may cause lowe= r accuracy of time measurement as an iOAM node may be required to transform= from its native time format into the format chosen by the management plane= .
    Regards,
    Greg

    On Tue, Jan 7, 2020 at 8:47 AM= Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
    Hello IPPM,

    Happy New Year! This email starts a working group last call for "Da= ta Fields for In-situ OAM" (https://datatracker.ietf.or= g/doc/draft-ietf-ippm-ioam-data/).

    The last ca= ll will end on Tuesday, January 21. Please reply to ippm@ietf.org with your reviews and = comments. Please indicate whether you think this document is ready for publ= ication.

    Best,
    Tommy (as co-chair)
    =
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000ae057a059d1b3ab7-- From nobody Tue Jan 28 07:55:37 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0760E1209D5 for ; Tue, 28 Jan 2020 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 pr39WKJt9jST for ; Tue, 28 Jan 2020 07:55:33 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 6C2871209B3 for ; Tue, 28 Jan 2020 07:55:33 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00SFWJnr008316 for ; Tue, 28 Jan 2020 07:55:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=T9Q/Ts/lFw6JGnugF3lAKOHj7tBDI7ZXoAFI3hVGd/4=; b=RQHYI55PZc+V3h7xCRyi3os0YS3alt++jJIEJICH7X2ErnXFtN8rerSBaDHVBEsFaYzR iTPayTBNEHYgOWsDJyK3a3A8lH8CEOIvd72BXfqxyQJX/kNb1A7vuDQrCDePZvFlRqa5 iqhobWTumfFNRlUavXV1CUoqXn+olkWbZ25jdmsJW/GV6huWgIlXmsTiKCuVY2HCTGe5 CHxxtPSt5UpXqLdaq1Znzn7mA4HcGAYlMBkkxQis3+zd7Y+vaeydIFSJfudtnTsLhiw3 rXUFsmPNEQl2qPWBAUauDffdF/SEsqj01wZJKE8XoNs8J+fEBW8QOdjFtWQSi7d0IVoN uA== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2xrnj0wgdp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 28 Jan 2020 07:55:32 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4T004BEQWJCM00@mr2-mtap-s02.rno.apple.com> for ippm@ietf.org; Tue, 28 Jan 2020 07:55:31 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4T00700QUHJH00@nwk-mmpp-sz13.apple.com> for ippm@ietf.org; Tue, 28 Jan 2020 07:55:31 -0800 (PST) X-Va-A: X-Va-T-CD: 159681ac17b4bf28eab1955e26a63a9c X-Va-E-CD: 233169c335de2420814a66032983e958 X-Va-R-CD: 73067736ed1cf210d2a5acc4396d0902 X-Va-CD: 0 X-Va-ID: 4deb594e-a3e9-457d-be86-bc8536fb4cee X-V-A: X-V-T-CD: 159681ac17b4bf28eab1955e26a63a9c X-V-E-CD: 233169c335de2420814a66032983e958 X-V-R-CD: 73067736ed1cf210d2a5acc4396d0902 X-V-CD: 0 X-V-ID: 89172537-13ef-4d76-8a24-e37dd9bcc24e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-28_05:,, signatures=0 Received: from [17.234.49.80] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4T006JFQWI8700@nwk-mmpp-sz13.apple.com> for ippm@ietf.org; Tue, 28 Jan 2020 07:55:31 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_F1B7A2B8-D158-4BCC-868F-5FA7268C7276" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Tue, 28 Jan 2020 07:55:25 -0800 References: To: IETF IPPM WG In-reply-to: Message-id: <34A5A6DC-37DA-4DE9-8226-23181C03396A@apple.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-28_05:, , signatures=0 Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 15:55:35 -0000 --Apple-Mail=_F1B7A2B8-D158-4BCC-868F-5FA7268C7276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending as this email is missing from the mail archive] Hi IPPM, Thanks for the feedback on this draft-ietf-ippm-ioam-data! Based on the reviews, we would like to see a new version of the document = posted, so that the group can take a look at those changes and see if we = think we're ready after that. Authors, please post a new version when ready. Best, Tommy > On Jan 7, 2020, at 8:47 AM, Tommy Pauly = > wrote: >=20 > Hello IPPM, >=20 > Happy New Year! This email starts a working group last call for "Data = Fields for In-situ OAM" = (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ = ). >=20 > The last call will end on Tuesday, January 21. Please reply to = ippm@ietf.org with your reviews and comments. = Please indicate whether you think this document is ready for = publication. >=20 > Best, > Tommy (as co-chair) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_F1B7A2B8-D158-4BCC-868F-5FA7268C7276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    [Resending as this = email is missing from the mail archive]

    Hi = IPPM,

    Thanks for the = feedback on this draft-ietf-ippm-ioam-data!

    Based on the reviews, we would like to = see a new version of the document posted, so that the group can take a = look at those changes and see if we think we're ready after = that.

    Authors, = please post a new version when ready.

    Best,
    Tommy

    On Jan 7, 2020, at 8:47 AM, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello IPPM,

    Happy New Year! This = email starts a working group last call for "Data Fields for In-situ OAM" = (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/= ).

    The last = call will end on Tuesday, January 21. Please reply to = ippm@ietf.org with your = reviews and comments. Please indicate whether you think this document is = ready for publication.

    Best,
    Tommy (as = co-chair)
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm

    = --Apple-Mail=_F1B7A2B8-D158-4BCC-868F-5FA7268C7276-- From nobody Tue Jan 28 17:09:16 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D01200B3 for ; Tue, 28 Jan 2020 17:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 L_r4SuiEQWHK for ; Tue, 28 Jan 2020 17:09:10 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 EABAC1200EC for ; Tue, 28 Jan 2020 17:09:09 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id 203so10573374lfa.12 for ; Tue, 28 Jan 2020 17:09:09 -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=79NUIQfTr9JUjQ0qEmQ/r18MYJMtp6Qy+O2ZLqs7O+4=; b=iyVlYtiE7vUE4o/2FzbIck8d3qlsizCgrcEbi1G955scazqKKSBZRWl+/fYxnbpgZI nRhfFrARqGNTJtt7tCy8zsyjPmMh8v3YsIsyGukpwgKsBBclIeHDqK1QrwAgVGnf6fV/ lcoSpA76j1MKlI6X//4+t9muN12hx9UX3C7di6CNSeFzUjvoY/SilKzC8p4QDHjoeBjE IQ/NHcDqoLDEyAlpXpeOc8/abjTwS2lPu2kWkedNRrD5V3M29g/ZQxePDbrXTf+JTTcF LGnigj1zZeIWh093VYIGtJANCan82WGPNvN1CJFl+k+Pr3XmiC9yWLncObolDM4POwc/ 5wog== 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=79NUIQfTr9JUjQ0qEmQ/r18MYJMtp6Qy+O2ZLqs7O+4=; b=IS/CqO2OZbsUhgmlTZ6iv+gJ/of8fwn95rFtWv30AzlsL+r6U1E4yyitGxl0WUxHgo Otb3U9no9Qu6A7n/iK4ykgFR79G5j1+soWGm3qG1RUQsgn2AXVBLTV1piu/jYPZqPAE5 Gsv8bDoU07xL4cm30MXjl5lyrMDKz+aMtcyRBUofCzehnW3S+xnXtbxvGcBvNOe/Nret 1GByN7I8IUP4BbfYs7zYBCoaLyAE2eCZ7EqX6pBG+LlUX4wkpFJ2wD2851iAgZS4qK+Z Yd/90N4qiwq5g7/aKcIixSMBEiuW9smvmMI/neHiw6AyyXXdvuxo4n0EGeug6s80JGUX +a8A== X-Gm-Message-State: APjAAAWLoQ5Gx9NcztArr6fia7A/K1+3TLHZ4Dy0TeK5P5KjDPoDFMUQ SMm1Sd0gLD9e5vkFwMx6hL91O0DI5vv3i6rzcFw= X-Google-Smtp-Source: APXvYqy6rim8DdMWqI/zzRhUzWPzx9DmfMXKufiw3yiyF0IfSgnxlyoKx0A3FDLzJsUhZlHit409xgceJHMJk8+wkP8= X-Received: by 2002:a19:cb95:: with SMTP id b143mr3926668lfg.158.1580260147858; Tue, 28 Jan 2020 17:09:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 28 Jan 2020 17:08:56 -0800 Message-ID: To: Tal Mizrahi Cc: Tommy Pauly , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000c41364059d3cfc1e" Archived-At: Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 01:09:15 -0000 --000000000000c41364059d3cfc1e Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for the clarifying details. I believe it is highly risky to leave outside the document the discussion of what security mechanisms, measures are required from an iOAM domain to be considered as a "confined administrative domain". I strongly encourage adding it to the document as one of the sections. Then, these listed mechanisms and principles can be referenced from the Security Considerations section to explain why iOAM itself does not require the additional measures to protect data integrity and/or confidentiality. Regards, Greg On Mon, Jan 27, 2020 at 12:52 AM Tal Mizrahi wrote: > Hi Greg, > > Many thanks for the comments. > Your point is well taken regarding the term "immediate export", and > regarding clarifying the connection to integrity and confidentiality. > There is a fundamental assumption in this draft that since IOAM is > deployed in confined administrative domains, it significantly limits the > scope of all the threats that are described in this section. Therefore this > draft does not define any specific security mechanisms. This was a basic > assumption throughout the process, and therefore the security > considerations does not define any security mechanisms. However, I added > some text that further clarifies this point. > > The following pull request includes my suggested changes to the Security > Considerations following your comments: > https://github.com/inband-oam/ietf/pull/146 > > Cheers, > Tal. > > > > > On Sun, Jan 26, 2020 at 2:30 AM Greg Mirsky wrote: > >> Hi Tal, >> thank you for your quick response to my comments. Please find my >> follow-up notes in-line tagged GIM>>. >> >> Best regards, >> Greg >> >> On Wed, Jan 22, 2020 at 12:33 AM Tal Mizrahi >> wrote: >> >>> Hi Greg, >>> >>> Thanks for this comment. >>> >>> In the context of "confidentiality", since we are talking about OAM >>> information, the correct context here is reconnaissance. Recon and its >>> implications are indeed discussed in the Security Considerations section on >>> the third paragraph. >>> >> GIM>> I find the text that you've referring too terse: >> The data elements of IOAM can be used for network reconnaissance, >> allowing attackers to collect information about network paths, >> performance, queue states, buffer occupancy and other information. >> True, you name the problem but I don't see any discussion of how to >> mitigate the risk of an intruder obtaining very sensitive information. What >> mechanisms can be used to protect the confidentiality of data? >> >> Also, I've noticed the text that, I think, should not be in the document >> in WG Last Call phase: >> Note that in case IOAM is used in "immediate export" mode (reference >> to be added in a future revision) ... >> This is a simple editorial change but I'd appreciate it being done. >> >> And as we discuss confidentiality, I believe that >> I-D.ietf-sfc-proof-of-transit must be in the normative list since the >> security measures and mechanisms discussed in that draft are applicable to >> this specification as well. >> >>> >>> Regarding integrity protection, the first paragraph of the Security >>> Considerations section discusses the consequences of compromising the >>> integrity of IOAM. >>> >> GIM>> I am not sure that I can interpret the first paragraph in the same >> manner as you. (As a side note, since RFC 7276 is used as the source of >> information, I think it should be in the normative list of references). My >> understanding of the first paragraph is that it explains that iOAM may be >> used to produce a false-negative and/or false-positive view of the network >> state. But I don't find any discussion on how to protect, how to make it >> more difficult for an attacker to manipulate with or alter iOAM data. >> >>> >>> In my opinion the current Security Considerations section covers the >>> main threats related to IOAM, and also explains the rationale of not >>> including explicit security mechanisms (the last paragraph of the section). >>> >> GIM>> On this I do agree. Security Considerations section names threats. >> But I believe that it as well should include recommendations, options of >> mitigating these risks, risk introduced specifically by iOAM transporting >> information in data packets. >> >>> >>> You make a good point that we did not explicitly use the terms >>> "confidentiality" and "integrity", and I will suggest new text that >>> explicitly refers to these terms in the relevant context of the section. >>> >>> Cheers, >>> Tal. >>> >>> >>> >>> >>> On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky >>> wrote: >>> >>>> Dear All, >>>> I'd like to add a note on the scope of the Security Considerations >>>> section. While it discusses the potential use of iOAM as the new DDOS >>>> attack vector, I didn't find a discussion of the protection of integrity >>>> and confidentiality of collected data. As I understand, please correct me >>>> if I've missed that in other sections of the document, all data is >>>> collected and transported in the clear text, no provisions for >>>> authentication or encryption except for Proof-of-Transit. I think that in >>>> addition to stressing the importance of protecting the integrity of clock >>>> synchronization and of the management plane, possible ways of protecting >>>> integrity and, possibly, the confidentiality of collected data must be >>>> discussed in the document. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky >>>> wrote: >>>> >>>>> Dear All, >>>>> please consider my comments to draft-ietf-ippm-ioam-data as part of >>>>> IPPM WG Last Call: >>>>> >>>>> - In Abstract and Section 3, Segment Routing is characterized, >>>>> among other networking technologies, as a transport. RFC 8402 defines >>>>> Segment Routing as a method to leverage the source routing paradigm. Where >>>>> else could the Segment Routing be defined as transport? >>>>> - Also, "native IPv6" is mentioned in the Abstract as transport. >>>>> Could it be just a reference to IPv6? What is the significance of singling >>>>> out "native IPv6"? >>>>> - Introduction section explains the "in-situ" term as >>>>> >>>>> The term "in-situ" refers to the fact that the OAM >>>>> data is added to the data packets rather than is being sent within >>>>> packets specifically dedicated to OAM. >>>>> >>>>> But with the introduction of Loopback and Direct Export as iOAM >>>>> behaviors, iOAM data are not added to the data packet. And how these new >>>>> iOAM functions affect the definition of IOAM control points in Section 3? >>>>> >>>>> >>>>> - I-D.lapukhov-dataplane-probe referenced as describing "recent >>>>> active probing mechanisms". That could have been the case in 2016 when the >>>>> draft was last time updated. But has expired and has not been discussed or >>>>> worked for 3.5 years. >>>>> - In regard to the control over iOAM, text in Section 3 states "It >>>>> SHOULD be possible to enable IOAM on a selected set of traffic ..." Does >>>>> that mean that not providing the selective enabling of iOAM is an >>>>> acceptable option? >>>>> - Further in Section 3, the requirement for encapsulation >>>>> independence is using SHOULD "Data formats for IOAM SHOULD be defined in a >>>>> transport-independent manner." What are the examples of exceptions? >>>>> - section 4.4 introduces the notion of an "iOAM capable node". >>>>> Which of iOAM objects are expected to be supported by the iOAM capable >>>>> node? If a node doesn't support a sub-set of iOAM data types, would it >>>>> still be considered as iOAM capable? >>>>> - Section 4.4.1 I'm having a hard time figuring how the presence >>>>> of Opaque State Snapshot space can be deduced. The explanation in NodeLen >>>>> is not clear to me. >>>>> - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ >>>>> only in part of the latter specifying that the format is wide. What is the >>>>> length on data identified by Bit 0? >>>>> - Hop_limit in Section 4.4.2 is defined as >>>>> >>>>> This is copied from the lower >>>>> layer, e.g., TTL value in IPv4 header or hop limit field from >>>>> IPv6 header of the packet when the packet is ready for >>>>> transmission. >>>>> What is the value of Hop_Limit field if the lower level does not >>>>> include TTL/Hop Limit field? >>>>> >>>>> >>>>> - Four octets are allocated for timestamp subseconds in Section >>>>> 4.4.2. Both PTP and NTP have formats that can provide a higher resolution >>>>> of a timestamp. That likely to be useful where a higher resolution of time >>>>> measurement, e.g. delay variation is needed (for example, URLLC >>>>> applications of 5G, TSN or DetNet). Can iOAM data be extended in the future >>>>> to support a different length of the subsecond field? >>>>> - What was the rationale to choose nanoseconds as the unit for >>>>> transit delay? >>>>> - How future proof is allocating four octets to express the length >>>>> of an egress queue (queue depth)? What should be the value if an iOAM node >>>>> cannot write the local value in four octets? >>>>> - Similar to the questions above but in regard to the buffer >>>>> occupancy field. >>>>> - Checksum Complement may be practical but it raises serious >>>>> security issues. I couldn't find these being identified and discussed in >>>>> the document. >>>>> - Section 5 defers the specification of the particular timestamp >>>>> format used in the given iOAM Namespace to the management plane. Does that >>>>> mean that all nodes in the given iOAM Domain must support the same format? >>>>> In other words, timestamps collected in the domain required to be in the >>>>> homogeneous format - either all in NTP, all in PTP, or all in POSIX. That >>>>> looks like unnecessary complexity and limitation and may cause lower >>>>> accuracy of time measurement as an iOAM node may be required to transform >>>>> from its native time format into the format chosen by the management plane. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly >>>> 40apple.com@dmarc.ietf.org <40apple.com@dmarc..ietf.org>> wrote: >>>>> >>>>>> Hello IPPM, >>>>>> >>>>>> Happy New Year! This email starts a working group last call for "Data >>>>>> Fields for In-situ OAM" ( >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/). >>>>>> >>>>>> The last call will end on *Tuesday, January 21*. Please reply to >>>>>> ippm@ietf.org with your reviews and comments. Please indicate >>>>>> whether you think this document is ready for publication. >>>>>> >>>>>> Best, >>>>>> Tommy (as co-chair) >>>>>> _______________________________________________ >>>>>> ippm mailing list >>>>>> ippm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>>> >>>>> _______________________________________________ >>>> ippm mailing list >>>> ippm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ippm >>>> >>> --000000000000c41364059d3cfc1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tal,
    thank you for the clarifying details. I believ= e it is highly risky to leave outside the document the discussion of what s= ecurity mechanisms, measures are required from an iOAM domain to be conside= red as a "confined administrative domain". I strongly encourage a= dding it to the document as one of the sections. Then, these listed mechani= sms and principles can be referenced from the Security Considerations secti= on to explain why iOAM itself does not require the additional measures to p= rotect data integrity and/or confidentiality.

    Rega= rds,
    Greg

    On Mon, Jan 27, 2020 at 12:52 AM Tal Mizrahi <<= a href=3D"mailto:tal.mizrahi.phd@gmail.com">tal.mizrahi.phd@gmail.com&g= t; wrote:
    Hi Greg,

    Many thanks for the comments.
    <= div>Your point is well taken regarding the term "immediate export"= ;, and regarding clarifying the connection to integrity and confidentiality= .
    There is a fundamental assumption in this draft that since IOAM= is deployed in confined administrative domains, it significantly limits th= e scope of all the threats that are described=C2=A0in this section. Therefo= re this draft does not define any specific security mechanisms. This was a = basic assumption throughout the process, and therefore the security conside= rations does not define any security mechanisms. However, I added some text= that further clarifies this point.

    The following = pull request includes my suggested changes to the Security Considerations f= ollowing your comments:

    Cheers,
    Tal.




    On Sun, Jan 26, 2020 at 2:30 AM Greg Mirsk= y <gregimirsk= y@gmail.com> wrote:
    Hi Tal,
    thank you for your= quick response to my comments. Please find my follow-up notes in-line tagg= ed GIM>>.

    Best regards,
    Greg
    =

    = On Wed, Jan 22, 2020 at 12:33 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrot= e:
    Hi Greg,

    Thanks for this comment.

    In the context of "confidentiality", since we are talking = about OAM information, the correct context here is=C2=A0reconnaissance. Rec= on and its implications are indeed discussed in the Security Considerations= section on the third paragraph.
    GIM>> I= find the text that you've referring too terse:
    =C2=A0 =C2=A0= The data elements of IOAM can be used for network reconnaissance,
    =C2=A0= =C2=A0allowing attackers to collect information about network paths,
    = =C2=A0 =C2=A0performance, queue states, buffer occupancy and other informat= ion.
    True, you name the problem but I don't see any discu= ssion of how to mitigate the risk of an intruder obtaining very sensitive i= nformation. What mechanisms can be used to protect the confidentiality of d= ata?

    Also, I've noticed the text that, I think= , should not be in the document in WG Last Call phase:
    =C2=A0 =C2= =A0Note that in case IOAM is used in "immediate export" mode (ref= erence
    =C2=A0 =C2=A0to be added in a future revision) ...
    = This is a simple editorial change but I'd appreciate it being done.

    And as we discuss confidentiality, I believe that I-D= .ietf-sfc-proof-of-transit must be in the normative list since the security= measures and mechanisms discussed in that draft are applicable to this spe= cification as well.
    =

    Regarding integrity protection, the fi= rst paragraph of the Security Considerations section discusses the conseque= nces of compromising the integrity of IOAM.
    GI= M>> I am not sure that I can interpret the first paragraph in the sam= e manner as you. (As a side note, since RFC 7276 is used as the source of i= nformation, I think it should be in the normative list of references). My u= nderstanding of the first paragraph is that it explains that iOAM may be us= ed to produce a false-negative and/or false-positive view of the network st= ate. But I don't find any discussion on how to protect, how to make it = more difficult for an attacker to manipulate with or alter iOAM data.
    =
    In my opinion the current Security Considerations section cover= s the main threats related to IOAM, and also explains the rationale of not = including explicit security mechanisms (the last paragraph of the section).=
    GIM>> On this I do agree. Security Cons= iderations section names threats. But I believe that it as well should incl= ude recommendations, options of mitigating these risks, risk introduced spe= cifically by iOAM transporting information in data packets.

    You make a good point that we did not explicitly use the terms "conf= identiality" and "integrity", and I will suggest new text th= at explicitly refers to these terms in the relevant context of the section.=

    Cheers,
    Tal.

    <= br>


    On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky <gregimirsky@gmail.c= om> wrote:
    Dear All,
    I'd like to add a note on the scope of= the Security Considerations section. While it discusses the potential use = of iOAM as the new DDOS attack vector, I didn't find a discussion of th= e protection of integrity and confidentiality of collected data. As I under= stand, please correct me if I've missed that in other sections of the= =C2=A0document, all data is collected and transported in the clear text, no= provisions for authentication or encryption except for Proof-of-Transit. I= think that in addition to stressing the importance of protecting the integ= rity of clock synchronization and of the management plane, possible ways of= protecting integrity and, possibly, the confidentiality of collected data = must be discussed in the document.

    Regards,
    <= div>Greg

    On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky <gregimirsky@gmail.com&g= t; wrote:
    Dear All,
    please consider my comments to=C2=A0draft-ietf-ipp= m-ioam-data as part of IPPM WG Last Call:
    • In Abstract and= Section 3, Segment Routing is characterized, among other networking techno= logies, as a transport. RFC 8402 defines Segment Routing as a method to lev= erage the source routing paradigm. Where else could the Segment Routing be = defined as transport?
    • Also, "native IPv6" is mentioned in= the Abstract as transport. Could it be just a reference to IPv6? What is t= he significance of singling out "native IPv6"?
    • Introducti= on section explains the "in-situ" term as
    =C2=A0 = =C2=A0The term "in-situ" refers to the fact that the OAM
    =C2=A0 =C2=A0data is added to the data packets rather than is being sent = within
    =C2=A0 =C2=A0packets specifically dedicated to OAM.
    <= /blockquote>
    But with the introduction of Loopback and Direct Export as iOAM= behaviors, iOAM data are not added to the data packet. And how these new i= OAM functions affect the definition of IOAM control points in Section 3?
    • I-D.lapukhov-dataplane-probe referenced as describi= ng "recent active probing mechanisms". That could have been the c= ase in 2016 when the draft was last time updated. But has expired and has n= ot been discussed or worked for 3.5 years.
    • In regard to the con= trol over iOAM, text in Section 3 states "It SHOULD be possible to ena= ble IOAM on a selected set of traffic ..." Does that mean that not pro= viding the selective enabling of iOAM is an acceptable option?
    • Furt= her in Section 3, the requirement for encapsulation independence is using S= HOULD "Data formats for IOAM SHOULD be defined in a transport-independ= ent manner." What are the examples of exceptions?
    • section 4.4 = introduces the notion of an "iOAM capable node". Which of iOAM ob= jects are expected to be supported by the iOAM capable node? If a node does= n't support a sub-set of iOAM data types, would it still be considered = as iOAM capable?
    • Section 4.4.1 I'm having a hard time figuring = how the presence of=C2=A0Opaque State Snapshot space can be deduced. The ex= planation in NodeLen is not clear to me.
    • The definitions of Bit 0 a= nd Bit 8 of=C2=A0IOAM-Trace-Type differ only in part of the latter specifyi= ng that the format is wide. What is the length on data identified by Bit 0?=
    • Hop_limit in Section 4.4.2 is defined as
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 This is copied from the lower
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0l= ayer, e.g., TTL value in IPv4 header or hop limit field from
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0IPv6 header of the packet when the packet is ready = for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission.
    What is the value= of Hop_Limit field if the lower level does not include TTL/Hop Limit field= ?
    • Four octets are allocated for timestamp subsecond= s in Section 4.4.2. Both PTP and NTP have formats that can provide a higher= resolution of a timestamp. That likely to be useful where a higher resolut= ion of time measurement, e.g. delay variation is needed (for example, URLLC= applications of 5G, TSN or DetNet). Can iOAM data be extended in the futur= e to support a different length of the subsecond field?
    • What was th= e rationale to choose nanoseconds as the unit for transit delay?
    • Ho= w future proof is allocating four octets to express the length of an egress= queue (queue depth)? What should be the value if an iOAM node cannot write= the local value in four octets?
    • Similar to the questions above but= in regard to the buffer occupancy field.
    • Checksum Complement may b= e practical but it raises serious security issues. I couldn't find thes= e being identified and discussed in the document.
    • Section 5 defers = the specification of the particular timestamp format used in the given iOAM= Namespace to the management plane. Does that mean that all nodes in the gi= ven iOAM Domain must support the same format? In other words, timestamps co= llected in the domain required to be in the homogeneous format - either all= in NTP, all in PTP, or all in POSIX. That looks like unnecessary complexit= y and limitation and may cause lower accuracy of time measurement as an iOA= M node may be required to transform from its native time format into the fo= rmat chosen by the management plane.
    Regards,
    Greg<= /div>

    On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.o= rg> wrote:
    https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).

    The last call will end on Tuesday, January 21. Please reply to ippm@= ietf.org with your reviews and comments. Please indicate whether you th= ink this document is ready for publication.

    Best,<= /div>
    Tommy (as co-chair)
    __________________________________= _____________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000c41364059d3cfc1e-- From nobody Wed Jan 29 05:08:58 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1091200F5; Wed, 29 Jan 2020 05:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, 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 tyapGB5juA20; Wed, 29 Jan 2020 05:08:55 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 09739120088; Wed, 29 Jan 2020 05:08:55 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id t14so6361332wmi.5; Wed, 29 Jan 2020 05:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UfVWm9Aydcdqe7U3cVLvnCQuEQV5lAW3lsR/nZs2N54=; b=IyoNOjEcs805uxrXVpZgb2oyzC6eGSUX0I/e/GMzGTDCyzO45jlNEynHyKfwkywjbh k7Hsh/5ZlD7H1/QV/7+cKhMx8z20B1HWGv7PBM3L48qCwKqvysQDjz/Y1g8XUZkN55f6 rXBEiE3dGNK6u+pdSdP2SBzfPUmWof905ct+xx/6hDOcwOnmqXtYYG4RhTKiCh4W13G7 f1rDW+YthxK+D6tzXr/eOY36vUH3ZaJeWthSzFVO/5p9N36ncLhecldHqTUljuNwMmiC czj3y3kC1bRK1p0feAXQHt2BJbi4bpd7g4giISpzP+aoXd5Wd8SeuPEi/wu9nk7/eGjp B3fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UfVWm9Aydcdqe7U3cVLvnCQuEQV5lAW3lsR/nZs2N54=; b=rK6mspDaRzAQnk11Q0xhLMCBBq5bSw2XWjXJp1vNpVp7urb38s/XZCbZvdez4GmIWF XPr+yN4xsJGsETwdRzO8lN/1eKBYrlin+Ez5+HlWZY8tCfAOl12uNISoRJz81k/DyLDc 85UKDyWyzEH3PvT+Mj7kftPc86if5mj0Hs59kUcRkjrbKgvhqwXbxMIg7eR6RImQ3UlK srU33Tjsk9jsWUBK5s35YwpgWqpS8vZa877U3C+M5KlwzKP1W9RX6HBXRu2kXa68sNoy AZIc56OIxQXDICSOKrihHnms7GUocjJADUvnSCDppio2JA9/eHQC6EvfvMULSA5gLDMM GSow== X-Gm-Message-State: APjAAAX0Qyi4EXZSl+lYPMhMzL1L4cIzF9/SnvbFFEk7awWe4r9OLds2 c2CvOULPZicvYbnC99CKSom2cqRZn5PkI6X9MqyK2jjBPoQ= X-Google-Smtp-Source: APXvYqxgB44G8t3v+3HJWVtKmzV4IKYZUj4eAobLq333xdzqVbiHJskbHfMrQuLeKPYMrZ7lfTbYPh0cLoRDs5eyJGY= X-Received: by 2002:a7b:c774:: with SMTP id x20mr11338144wmk.67.1580303333047; Wed, 29 Jan 2020 05:08:53 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Wed, 29 Jan 2020 15:08:40 +0200 Message-ID: To: IETF IPPM WG , IPPM Chairs , draft-ietf-ippm-multipoint-alt-mark@ietf.org Content-Type: multipart/alternative; boundary="000000000000cdc0c4059d470afb" Archived-At: Subject: [ippm] IPR Poll for draft-ietf-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 13:08:57 -0000 --000000000000cdc0c4059d470afb Content-Type: text/plain; charset="UTF-8" Hi, This email begins a one-week poll for any IPRs that may apply to draft-ietf-ippm-multipoint-alt-mark-04. Are you aware of any IPR that applies to draft-ietf-ippm-multipoint-alt-mark-04? Specifically, if you are listed as a document author, please respond to this email (reply-to-all) stating whether or not you are aware of any relevant IPRs beyond the IPRs that have already been reported. Two IPRs have been disclosed for this draft so far: 3035 Telecom Italia SpA's Statement about IPR related to draft-fioccola-ippm-multipoint-alt-mark 3110 Telecom Italia SpA's Statement about IPR related to draft-fioccola-ippm-multipoint-alt-mark (Updates ID#: 3035) These disclosures are available at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ippm-multipoint-alt-mark If you are aware of a relevant IPR, please state whether this IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This poll closes on the 5th of February 2020. Best regards, Tal. [As shepherd of draft-ietf-ippm-multipoint-alt-mark] --000000000000cdc0c4059d470afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    This email begins a one-= week poll for any=C2=A0IPRs=C2=A0that may a= pply to draft-ietf-ippm-multipoint-alt-mark-04.

    Ar= e you aware of any=C2=A0IPR=C2=A0that appli= es to=20 draft-ietf-ippm-multipoint-alt-mark-04?=C2=A0

    Spec= ifically, if you are listed as a document author, please respond to this em= ail (reply-to-all) stating whether or not you are aware of any relevant=C2= =A0IPRs beyond the IPRs that have already been rep= orted.

    Two IPRs have been disclosed for thi= s draft so far:
    3035 Telecom Italia SpA's Statement about IPR= related to draft-fioccola-ippm-multipoint-alt-mark
    3110 Telecom Italia SpA's Statement about IPR related to draft-fiocco= la-ippm-multipoint-alt-mark
    (Updates ID#: 3035)

    =

    If you are a= ware of a relevant=C2=A0IPR, please state w= hether this=C2=A0IPR=C2=A0has been disclose= d in compliance with IETF=C2=A0IPR=C2=A0rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details).

    This poll closes on the 5th of February 2020.

    <= div>Best regards,
    Tal.
    [As shepherd of=C2=A0draft-ietf-= ippm-multipoint-alt-mark]
    --000000000000cdc0c4059d470afb-- From nobody Wed Jan 29 05:50:07 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765551200F5; Wed, 29 Jan 2020 05:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3-ZOKS14fEX; Wed, 29 Jan 2020 05:50:03 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 2C7A612009C; Wed, 29 Jan 2020 05:50:03 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id g17so20250072wro.2; Wed, 29 Jan 2020 05:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wWDSnyjMEARncqxiD2Fs0DtdbZzCxURKbzvthrESDNg=; b=mnfv6k8pDIqC+3qlCz0D1XKZBpuKCwM3bosCFEE7czD6SX2XTWDtv8cBPTuk9xLE7b EeW9N3/mTJ8rOyTEt+EPQRJQRYJps8O84veKiNuQbl8qpfF/lCeLM5M8WATWHSYcdU+4 fnVsyTcBAAVGtw5sE0YwisMtgI3hXqMEXvniPNJIivz+BspZxPJvqxY8uBmuXEJF3qRF e+W8mUoi7x0ebyRVH7MYAq5uDuyDTXvdqR4TlETkPsjEiArIFZwiKivg1FtuEG4ZAvga Ts0HMetNh2cL2tUUervVMsySdlD7TfsvaJlYXVDxPSDVLMTVyCsQVAUA4sO2zMk6EMkn Or2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wWDSnyjMEARncqxiD2Fs0DtdbZzCxURKbzvthrESDNg=; b=mnD6btg4rqGrTK/yYVKTM5VuKEtBRWeb5fiiWn5i0hNR+NnrCWp4mxuej1nzzAsLUf Yw+CqLhMa5iCxHXQfWQ1rMWCivPBabe3SsYT/SQbZ2kHwtvjRUmOqsEPt5fC4BsTiXnR nAXS5q70Cbesq7lJ2gV3bbJvL3HUOKX/n4VRH1fdt7hgAhVsnV4Ps9bmmyZ/aoDUyVKt 3WN/4wKFcC5zGabtBU5UuzijhDol8s1E0oHXsi1Alzfiu4hYnTgdvCiAGQrxyoWoD18Y bunDxUTMGInAUezTF+vpvIxijMJlJVHGq0hmvSP6LMw8BOuV63r4De54iEgcP5oCpOSZ i5EQ== X-Gm-Message-State: APjAAAVnwyG9k61W6MVoLN65BaMUC0p1xE/fUOJLzvDigCbEwlMe2FFq RKXGGZgrP9aWLRio4tGM5rCSz9127jjVpwa9+6wRcj/I/6g= X-Google-Smtp-Source: APXvYqy9SshdZ/YkfrOtge0cEejmyXe83oRdYSn0XgKmtMmH8umdfnbvh8FbNwT2LP1BszTryml5fyfR+ks9rmzNQOc= X-Received: by 2002:a5d:4692:: with SMTP id u18mr35643176wrq.206.1580305801419; Wed, 29 Jan 2020 05:50:01 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Wed, 29 Jan 2020 15:49:50 +0200 Message-ID: To: IETF IPPM WG , draft-ietf-ippm-multipoint-alt-mark@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee2325059d479d3d" Archived-At: Subject: [ippm] Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 13:50:05 -0000 --000000000000ee2325059d479d3d Content-Type: text/plain; charset="UTF-8" Dear authors, I believe this document is ready for publication, with a few minor comments. If the authors can kindly address these comments and post an updated version, we will proceed with the publication process. Comments: Section 5: "The Monitored Network Packet Loss with n input nodes and m output nodes is given by" Please clarify whether the metric PL is measured on a per flow (5-tuple) basis, as defined in Section 4, or measured globally for all the flows. Section 5: "The equation is applied on a per-time-interval basis." Please note that the term time interval has not been defined before this point in the document. This would be a good point to add a sentence that explains that an "interval" is derived from an alternating marking field. Section 6: Please clarify whether a cluster is defined on a per-flow basis, or is it assumed that all flows are monitored at all times. Section 7: "In general the measurement interval for describing the results is the interval of the marking node that is more aligned with the start of the measurement" Please clarify what "more aligned" means. The figure seems to indicate that the measurement interval is determined by the node with the earliest clock, thus starting the measurement interval ahead of the other nodes. Cheers, Tal Mizrahi. [As shepherd of draft-fioccola-ippm-multipoint-alt-mark] --000000000000ee2325059d479d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear authors,

    I believe this document i= s ready for publication, with a few minor comments.
    If the author= s can kindly address these comments and post an updated version, we will pr= oceed with the publication process.

    Comments:

    Section 5:
    "The Monitored Network Packet Loss = with n input nodes and m output nodes is given by"
    Please clarify w= hether the metric PL is measured on a per flow (5-tuple) basis, as defined = in Section 4, or measured globally for all the flows.

    Section 5:
    = "The equation is applied on a per-time-interval basis."
    Please= note that the term time interval has not been defined before this point in= the document. This would be a good point to add a sentence that explains t= hat an "interval" is derived from an alternating marking field.
    Section 6:
    Please clarify whether a cluster is defined on a per-fl= ow basis, or is it assumed that all flows are monitored at all times.
    Section 7:
    "In general the measurement interval for describing th= e results is the interval of the marking node that is more aligned with the= start of the measurement"
    Please clarify what "more aligned&q= uot; means. The figure seems to indicate that the measurement interval is d= etermined by the node with the earliest clock, thus starting the measuremen= t interval ahead of the other nodes.

    Cheers,
    Tal Mizrahi.
    [As shepherd of draft-fioccola-ippm-multipo= int-alt-mark]
    --000000000000ee2325059d479d3d-- From nobody Wed Jan 29 14:32:14 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B297B120045; Wed, 29 Jan 2020 14:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0GcdfbklyFRq; Wed, 29 Jan 2020 14:32:09 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 0D962120044; Wed, 29 Jan 2020 14:32:09 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id 59so1191146otp.12; Wed, 29 Jan 2020 14:32:09 -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=/KdKNkh6Ttmfooek++Fy/cUrYUH7/wYun7dYVqyfFdA=; b=loEYL6XItNoJ9SwYdXujX3odTKCK7yuL0QqFXG+n0FkOcZjV/al8QUZuV3zes7PyW+ 6HHjmKwgs/nT0O4PNTZ6r3zAd3XQ2rTaqe/HsTRsb6wLgSnK33SxBJk04DhVNuKUOc0x 5lprttMSC27p1ERE84GL2GNjrPGKJEjY35OtzQLFgwEAmJehOBs17iW1SgvWyqZiTBx9 1tP7mMW/R3uVOpjF5z8W69nf1glDU8DqFuDAyw3B76CZ/AzwZ+t3Te9YjK6PP5rYZJUs 3w2S/TOpjtzgFrwAsVz9PvdugXMWQgXevAepqVLaWRM+qxsXKEhJxQLypnVAiIwFEq0N nzig== 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=/KdKNkh6Ttmfooek++Fy/cUrYUH7/wYun7dYVqyfFdA=; b=WXtZeIkPS+xKBcCo7JvYuWI7mcLCg8TjPpXtneZVCjtmCE0eGsZIQucvBUxeb/5Cx1 aSS+86QEjF5yn5NSwwONwgudq11xMgcM9H0MN9+cGomE6aU2nV0RSpZJAkDM8ku+Uh0+ 3qnjuI6sM/P0CXq0ShiIlObKW0E86Z+sV6jLqGC979CXwf7Mhwmo8NwrT9KXQotPluUu 6sX055oOQu6dgJ3GLi1RXuCJUpV7n8d8HwLt8uTx+HlpHdH9mJswdNB5Q6KxZAOyBnvQ HeIL7SJIKpKdSftGnAyEvHqRNwAn++zHB3gw+aCy8zHwIKxpkbQRS6yPNiVTEIC4FtGX Myjg== X-Gm-Message-State: APjAAAVKALJX4vOxtw/a8KBcyiXWAToLHZFUUWzOC7CoXT32F8Pi7Qim uK7jJScr4lqLuHK6U699U2baVTDkIqBTU0M9axw= X-Google-Smtp-Source: APXvYqw4CL8SSqY/u+8r3p63u0gTW2F4V1jr28j8Xxbcbg3wQ171UwxEO5RSPQJaW/7sUfV536LWdBiGD+SbXLSC4qQ= X-Received: by 2002:a9d:3ea:: with SMTP id f97mr1211863otf.42.1580337128334; Wed, 29 Jan 2020 14:32:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amedeo Sapio Date: Wed, 29 Jan 2020 14:31:40 -0800 Message-ID: To: Tal Mizrahi Cc: IETF IPPM WG , IPPM Chairs , draft-ietf-ippm-multipoint-alt-mark@ietf.org Content-Type: multipart/alternative; boundary="00000000000028ea80059d4ee99f" Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 22:32:12 -0000 --00000000000028ea80059d4ee99f Content-Type: text/plain; charset="UTF-8" Hi, I am not aware of any additional IPR. Thanks! --- Amedeo On Wed, Jan 29, 2020 at 5:09 AM Tal Mizrahi wrote: > Hi, > > This email begins a one-week poll for any IPRs that may apply to > draft-ietf-ippm-multipoint-alt-mark-04. > > Are you aware of any IPR that applies to > draft-ietf-ippm-multipoint-alt-mark-04? > > Specifically, if you are listed as a document author, please respond to > this email (reply-to-all) stating whether or not you are aware of any > relevant IPRs beyond the IPRs that have already been reported. > > Two IPRs have been disclosed for this draft so far: > 3035 Telecom Italia SpA's Statement about IPR related to > draft-fioccola-ippm-multipoint-alt-mark > 3110 Telecom Italia SpA's Statement about IPR related to > draft-fioccola-ippm-multipoint-alt-mark > (Updates ID#: 3035) > > These disclosures are available at > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ippm-multipoint-alt-mark > > If you are aware of a relevant IPR, please state whether this IPR has > been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, > 3669 and 5378 for more details). > > This poll closes on the 5th of February 2020. > > Best regards, > Tal. > [As shepherd of draft-ietf-ippm-multipoint-alt-mark] > --00000000000028ea80059d4ee99f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0
    I am not = aware of any additional IPR.=C2=A0

    Thanks!
    =
    ---
    Amedeo
    <= /big>
    <= /div>


    On Wed, Jan 29, 2020 at 5:09 AM Tal Mizrah= i <tal.mizrahi.phd@gmail.co= m> wrote:
    Hi,

    This email begins a one= -week poll for any=C2=A0IPRs=C2=A0that may apply to draft-ietf= -ippm-multipoint-alt-mark-04.

    Are you aware of any= =C2=A0IPR=C2=A0that applies to=20 draft-ietf-ippm-multipoint-alt-mark-04?=C2=A0

    Spec= ifically, if you are listed as a document author, please respond to this em= ail (reply-to-all) stating whether or not you are aware of any relevant=C2= =A0IPRs beyond the IPRs that have already been reported.
    =

    Two IPRs have been disclosed for this draft so far:
    3035 Telecom Italia SpA's Statement about IPR related to draft-f= ioccola-ippm-multipoint-alt-mark
    3110 Telecom Ital= ia SpA's Statement about IPR related to draft-fioccola-ippm-multipoint-= alt-mark
    (Updates ID#: 3035)


    If you are aw= are of a relevant=C2=A0IPR, please state whether this=C2=A0IPR=C2=A0has been disclosed in compliance with IETF=C2=A0IP= R=C2=A0rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= /div>

    This poll closes on the 5th of February 2020.

    Best regards,
    Tal.
    [As shepherd of= =C2=A0draft-ietf-ippm-multipoint-alt-mark]
    --00000000000028ea80059d4ee99f-- From nobody Wed Jan 29 16:49:39 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67B12004D; Wed, 29 Jan 2020 16:49:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <158034537714.4849.10709618065227686315@ietfa.amsl.com> Date: Wed, 29 Jan 2020 16:49:37 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 00:49:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Metrics and Methods for IP Capacity Authors : Al Morton Ruediger Geib Len Ciavattone Filename : draft-ietf-ippm-capacity-metric-method-00.txt Pages : 20 Date : 2020-01-29 Abstract: This memo revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-00 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-capacity-metric-method-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 Wed Jan 29 21:56:23 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7FE12006B; Wed, 29 Jan 2020 21:56:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 7DozDltzQ47E; Wed, 29 Jan 2020 21:56:19 -0800 (PST) Received: from fm1nodo5.polito.it (fm1nodo5.polito.it [130.192.180.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44502120059; Wed, 29 Jan 2020 21:56:18 -0800 (PST) Received: from polito.it (frontmail2.polito.it [130.192.180.42]) by fm1nodo5.polito.it with ESMTP id 00U5uEu3026121-00U5uEu5026121 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 30 Jan 2020 06:56:14 +0100 X-ExtScanner: Niversoft's FindAttachments (free) Received: from [94.34.204.186] (account d001943@polito.it HELO Riccardos-MBP.lan) by polito.it (CommuniGate Pro SMTP 6.2.5) with ESMTPSA id 119857674; Thu, 30 Jan 2020 06:56:14 +0100 To: Amedeo Sapio , Tal Mizrahi Cc: IETF IPPM WG , IPPM Chairs , draft-ietf-ippm-multipoint-alt-mark@ietf.org References: From: Riccardo Sisto Message-ID: <11e4da33-b3df-92ca-f2eb-67e94bddf3fd@polito.it> Date: Thu, 30 Jan 2020 06:56:13 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 05:56:22 -0000 Hi All, I am not aware of any additional IPR. Best regards, Riccardo On 29/01/2020 23:31, Amedeo Sapio wrote: > Hi, > I am not aware of any additional IPR. > > Thanks! > --- > Amedeo > > > On Wed, Jan 29, 2020 at 5:09 AM Tal Mizrahi > wrote: > >> Hi, >> >> This email begins a one-week poll for any IPRs that may apply to >> draft-ietf-ippm-multipoint-alt-mark-04. >> >> Are you aware of any IPR that applies to >> draft-ietf-ippm-multipoint-alt-mark-04? >> >> Specifically, if you are listed as a document author, please respond to >> this email (reply-to-all) stating whether or not you are aware of any >> relevant IPRs beyond the IPRs that have already been reported. >> >> Two IPRs have been disclosed for this draft so far: >> 3035 Telecom Italia SpA's Statement about IPR related to >> draft-fioccola-ippm-multipoint-alt-mark >> 3110 Telecom Italia SpA's Statement about IPR related to >> draft-fioccola-ippm-multipoint-alt-mark >> (Updates ID#: 3035) >> >> These disclosures are available at >> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ippm-multipoint-alt-mark >> >> If you are aware of a relevant IPR, please state whether this IPR has >> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >> 3669 and 5378 for more details). >> >> This poll closes on the 5th of February 2020. >> >> Best regards, >> Tal. >> [As shepherd of draft-ietf-ippm-multipoint-alt-mark] >> > From nobody Thu Jan 30 01:49:15 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623CD120116; Thu, 30 Jan 2020 01:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 4jmsiqm-62lZ; Thu, 30 Jan 2020 01:49:12 -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 037E41200B4; Thu, 30 Jan 2020 01:49:12 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AF1A4BBCE1658B3D3777; Thu, 30 Jan 2020 09:49:09 +0000 (GMT) Received: from fraeml716-chm.china.huawei.com (10.206.15.12) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 30 Jan 2020 09:49:09 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml716-chm.china.huawei.com (10.206.15.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 30 Jan 2020 10:49:09 +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.1713.004; Thu, 30 Jan 2020 10:49:09 +0100 From: Giuseppe Fioccola To: Tal Mizrahi , IETF IPPM WG , IPPM Chairs , "draft-ietf-ippm-multipoint-alt-mark@ietf.org" Thread-Topic: IPR Poll for draft-ietf-ippm-multipoint-alt-mark-04 Thread-Index: AQHV1qVLO17ZkI12ok+1+BAktlxf66gC9CPw Date: Thu, 30 Jan 2020 09:49:08 +0000 Message-ID: <946a077dfaa44cfc81c1dd1c03a26b76@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.169.51] Content-Type: multipart/alternative; boundary="_000_946a077dfaa44cfc81c1dd1c03a26b76huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 09:49:14 -0000 --_000_946a077dfaa44cfc81c1dd1c03a26b76huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQpJ4oCZbSBub3QgYXdhcmUgb2Ygb3RoZXIgcmVsZXZhbnQgSVBScyBpbiBhZGRp dGlvbiB0byB0aG9zZSBhbHJlYWR5IGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCg0KR2l1c2VwcGUN Cg0KDQpGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbC5taXpyYWhpLnBoZEBnbWFpbC5jb21d DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgMjowOSBQTQ0KVG86IElFVEYgSVBQ TSBXRyA8aXBwbUBpZXRmLm9yZz47IElQUE0gQ2hhaXJzIDxpcHBtLWNoYWlyc0BpZXRmLm9yZz47 IGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrQGlldGYub3JnDQpTdWJqZWN0OiBJ UFIgUG9sbCBmb3IgZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDQNCg0KSGks DQoNClRoaXMgZW1haWwgYmVnaW5zIGEgb25lLXdlZWsgcG9sbCBmb3IgYW55IElQUnMgdGhhdCBt YXkgYXBwbHkgdG8gZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDQuDQoNCkFy ZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1pcHBtLW11 bHRpcG9pbnQtYWx0LW1hcmstMDQ/DQoNClNwZWNpZmljYWxseSwgaWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3IsIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHJlcGx5 LXRvLWFsbCkgc3RhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFJzIGJleW9uZCB0aGUgSVBScyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIHJlcG9ydGVk Lg0KDQpUd28gSVBScyBoYXZlIGJlZW4gZGlzY2xvc2VkIGZvciB0aGlzIGRyYWZ0IHNvIGZhcjoN CjMwMzUgVGVsZWNvbSBJdGFsaWEgU3BBJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRv IGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyaw0KMzExMCBUZWxlY29tIEl0 YWxpYSBTcEEncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtZmlvY2NvbGEt aXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrDQooVXBkYXRlcyBJRCM6IDMwMzUpDQoNClRoZXNlIGRp c2Nsb3N1cmVzIGFyZSBhdmFpbGFibGUgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvc2VhcmNoLz9zdWJtaXQ9ZHJhZnQmaWQ9ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0 LW1hcmsNCg0KSWYgeW91IGFyZSBhd2FyZSBvZiBhIHJlbGV2YW50IElQUiwgcGxlYXNlIHN0YXRl IHdoZXRoZXIgdGhpcyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKS4NCg0KVGhpcyBwb2xsIGNsb3NlcyBvbiB0aGUgNXRoIG9mIEZlYnJ1YXJ5IDIw MjAuDQoNCkJlc3QgcmVnYXJkcywNClRhbC4NCltBcyBzaGVwaGVyZCBvZiBkcmFmdC1pZXRmLWlw cG0tbXVsdGlwb2ludC1hbHQtbWFya10NCg== --_000_946a077dfaa44cfc81c1dd1c03a26b76huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLWlsDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLWlsO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWFyIEFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SeKAmW0gbm90IGF3YXJlIG9mIG90aGVyIHJlbGV2YW50IElQUnMgaW4gYWRkaXRp b24gdG8gdGhvc2UgYWxyZWFkeSBkaXNjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsLm1penJh aGkucGhkQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkg MjksIDIwMjAgMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBJUFBNIFdHICZsdDtpcHBtQGll dGYub3JnJmd0OzsgSVBQTSBDaGFpcnMgJmx0O2lwcG0tY2hhaXJzQGlldGYub3JnJmd0OzsgZHJh ZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmtAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gSVBSIFBvbGwgZm9yIGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTA0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWls IGJlZ2lucyBhIG9uZS13ZWVrIHBvbGwgZm9yIGFueSZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1p bCI+SVBSczwvc3Bhbj4mbmJzcDt0aGF0IG1heSBhcHBseSB0byBkcmFmdC1pZXRmLWlwcG0tbXVs dGlwb2ludC1hbHQtbWFyay0wNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBhd2FyZSBvZiBhbnkmbmJzcDs8c3BhbiBjbGFzcz0i Z21haWwtaWwiPklQUjwvc3Bhbj4mbmJzcDt0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1pcHBt LW11bHRpcG9pbnQtYWx0LW1hcmstMDQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZmljYWxseSwgaWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IsIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHJl cGx5LXRvLWFsbCkgc3RhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSBy ZWxldmFudCZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1pbCI+SVBScyBiZXlvbmQgdGhlIElQUnMg dGhhdCBoYXZlIGFscmVhZHkgYmVlbiByZXBvcnRlZDwvc3Bhbj4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlR3byBJUFJzIGhhdmUgYmVlbiBk aXNjbG9zZWQgZm9yIHRoaXMgZHJhZnQgc28gZmFyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MzAzNSBUZWxlY29tIEl0YWxpYSBTcEEncyBTdGF0 ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50 LWFsdC1tYXJrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4zMTEwIFRlbGVjb20gSXRhbGlhIFNwQSdzIFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRl ZCB0byBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcms8YnI+DQooVXBkYXRl cyBJRCM6IDMwMzUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXNlIGRpc2Nsb3N1cmVzIGFyZSBhdmFpbGFibGUgYXQmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZh bXA7aWQ9ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0JmFtcDtpZD1kcmFmdC1pZXRm LWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyazwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGFyZSBhd2FyZSBvZiBhIHJlbGV2YW50 Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWlsIj5JUFI8L3NwYW4+LCBwbGVhc2Ugc3RhdGUgd2hl dGhlciB0aGlzJm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLWlsIj5JUFI8L3NwYW4+Jm5ic3A7aGFz IGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGJm5ic3A7PHNwYW4gY2xhc3M9 ImdtYWlsLWlsIj5JUFI8L3NwYW4+Jm5ic3A7cnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2 NjkNCiBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBwb2xsIGNsb3NlcyBvbiB0aGUgNXRo IG9mIEZlYnJ1YXJ5IDIwMjAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltBcyBzaGVwaGVyZCBvZiZuYnNwO2RyYWZ0LWlldGYt aXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_946a077dfaa44cfc81c1dd1c03a26b76huaweicom_-- From nobody Thu Jan 30 02:37:50 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E712011B; Thu, 30 Jan 2020 02:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 AeRHweh7eOZf; Thu, 30 Jan 2020 02:37:46 -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 2F52C12006E; Thu, 30 Jan 2020 02:37:46 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BD5F130A24BFE49ADD3C; Thu, 30 Jan 2020 10:37:42 +0000 (GMT) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 30 Jan 2020 10:37:42 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 30 Jan 2020 11:37:42 +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.1713.004; Thu, 30 Jan 2020 11:37:42 +0100 From: Giuseppe Fioccola To: Tal Mizrahi , IETF IPPM WG , "draft-ietf-ippm-multipoint-alt-mark@ietf.org" Thread-Topic: Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 Thread-Index: AQHV1qsKRjo7Ii7jskm1WJ1UaRyaF6gC+VHQ Date: Thu, 30 Jan 2020 10:37:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.169.51] Content-Type: multipart/alternative; boundary="_000_a61220ad531e46e1bb0d739044160e8ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 10:37:49 -0000 --_000_a61220ad531e46e1bb0d739044160e8ehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBUYWwsDQpQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGlubGluZSB0YWdnZWQgYXMgW0dGXS4N CkxldCBtZSBrbm93IGlmIHRoZXNlIGFkZHJlc3MgeW91ciBjb21tZW50cywgc28gSSBjYW4gdXBk YXRlIGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lvbi4NCg0KUmVnYXJkcywNCg0KR2l1c2VwcGUNCg0K DQpGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbC5taXpyYWhpLnBoZEBnbWFpbC5jb21dDQpT ZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjksIDIwMjAgMjo1MCBQTQ0KVG86IElFVEYgSVBQTSBX RyA8aXBwbUBpZXRmLm9yZz47IGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrQGll dGYub3JnDQpTdWJqZWN0OiBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtZmlvY2NvbGEtaXBwbS1t dWx0aXBvaW50LWFsdC1tYXJrLTA0DQoNCkRlYXIgYXV0aG9ycywNCg0KSSBiZWxpZXZlIHRoaXMg ZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCB3aXRoIGEgZmV3IG1pbm9yIGNvbW1l bnRzLg0KSWYgdGhlIGF1dGhvcnMgY2FuIGtpbmRseSBhZGRyZXNzIHRoZXNlIGNvbW1lbnRzIGFu ZCBwb3N0IGFuIHVwZGF0ZWQgdmVyc2lvbiwgd2Ugd2lsbCBwcm9jZWVkIHdpdGggdGhlIHB1Ymxp Y2F0aW9uIHByb2Nlc3MuDQoNCkNvbW1lbnRzOg0KDQpTZWN0aW9uIDU6DQoiVGhlIE1vbml0b3Jl ZCBOZXR3b3JrIFBhY2tldCBMb3NzIHdpdGggbiBpbnB1dCBub2RlcyBhbmQgbSBvdXRwdXQgbm9k ZXMgaXMgZ2l2ZW4gYnkiDQpQbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoZSBtZXRyaWMgUEwgaXMg bWVhc3VyZWQgb24gYSBwZXIgZmxvdyAoNS10dXBsZSkgYmFzaXMsIGFzIGRlZmluZWQgaW4gU2Vj dGlvbiA0LCBvciBtZWFzdXJlZCBnbG9iYWxseSBmb3IgYWxsIHRoZSBmbG93cy4NCg0KW0dGXTog VGhlIE1vbml0b3JlZCBOZXR3b3JrIFBhY2tldCBMb3NzIGlzIG1lYXN1cmVkIGZvciBvbmUgc2lu Z2xlIGZsb3cgYnV0IHNpbmNlIGl0IGlzIGEgbXVsdGlwb2ludCBmbG93LCB0aGUgaWRlbnRpZmlj YXRpb24gZmllbGRzIG9mIHRoZSA1LXR1cGxlLCBpbiBnZW5lcmFsLCBjYW4gYmUgc2VsZWN0ZWQg d2l0aG91dCBhbnkgY29uc3RyYWludHMuIEkgY2FuIHNwZWNpZnkgYmV0dGVyIHRoaXMgcG9pbnQu DQoNCg0KU2VjdGlvbiA1Og0KIlRoZSBlcXVhdGlvbiBpcyBhcHBsaWVkIG9uIGEgcGVyLXRpbWUt aW50ZXJ2YWwgYmFzaXMuIg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgdGVybSB0aW1lIGludGVydmFs IGhhcyBub3QgYmVlbiBkZWZpbmVkIGJlZm9yZSB0aGlzIHBvaW50IGluIHRoZSBkb2N1bWVudC4g VGhpcyB3b3VsZCBiZSBhIGdvb2QgcG9pbnQgdG8gYWRkIGEgc2VudGVuY2UgdGhhdCBleHBsYWlu cyB0aGF0IGFuICJpbnRlcnZhbCIgaXMgZGVyaXZlZCBmcm9tIGFuIGFsdGVybmF0aW5nIG1hcmtp bmcgZmllbGQuDQoNCltHRl06IFN1cmUuIEkgd2lsbCBhZGQgYSBub3RlIGFib3V0IHRoZSBpbnRl cnZhbCBoZXJlIHJlZmVycmVkLCB0aGF0IGlzIHRoZSBhbHRlcm5hdGUgbWFya2luZyBwZXJpb2Qg YXMgZGVmaW5lZCBpbiBSRkMgODMyMS4NCg0KDQpTZWN0aW9uIDY6DQpQbGVhc2UgY2xhcmlmeSB3 aGV0aGVyIGEgY2x1c3RlciBpcyBkZWZpbmVkIG9uIGEgcGVyLWZsb3cgYmFzaXMsIG9yIGlzIGl0 IGFzc3VtZWQgdGhhdCBhbGwgZmxvd3MgYXJlIG1vbml0b3JlZCBhdCBhbGwgdGltZXMuDQoNCltH Rl06IFllcywgdGhlIENsdXN0ZXIgaXMgZGVmaW5lZCBvbiBhIHBlci1mbG93IGJhc2lzLiBJIGNh biBhZGQgYSBzZW50ZW5jZSB0byBjbGFyaWZ5Lg0KDQoNClNlY3Rpb24gNzoNCiJJbiBnZW5lcmFs IHRoZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBmb3IgZGVzY3JpYmluZyB0aGUgcmVzdWx0cyBpcyB0 aGUgaW50ZXJ2YWwgb2YgdGhlIG1hcmtpbmcgbm9kZSB0aGF0IGlzIG1vcmUgYWxpZ25lZCB3aXRo IHRoZSBzdGFydCBvZiB0aGUgbWVhc3VyZW1lbnQiDQpQbGVhc2UgY2xhcmlmeSB3aGF0ICJtb3Jl IGFsaWduZWQiIG1lYW5zLiBUaGUgZmlndXJlIHNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhlIG1l YXN1cmVtZW50IGludGVydmFsIGlzIGRldGVybWluZWQgYnkgdGhlIG5vZGUgd2l0aCB0aGUgZWFy bGllc3QgY2xvY2ssIHRodXMgc3RhcnRpbmcgdGhlIG1lYXN1cmVtZW50IGludGVydmFsIGFoZWFk IG9mIHRoZSBvdGhlciBub2Rlcy4NCg0KW0dGXTogWWVzLCBpbiB0aGlzIGNhc2Ugd2UgYXNzdW1l IHRoYXQgdGhlIG5vZGUgd2l0aCB0aGUgZWFybGllc3QgY2xvY2sgaWRlbnRpZmllcyB0aGUgcmln aHQgc3RhcnRpbmcgdGltZSBvZiB0aGUgbWVhc3VyZW1lbnQsIGJ1dCBpdCBpcyBqdXN0IGFuIGFz c3VtcHRpb24gYW5kIG90aGVyIHBvc3NpYmlsaXRpZXMgY2FuIGhhcHBlbi4gVGhpcyBpcyB0byBp bnRyb2R1Y2UgdGhlIG5ldyBjb25zdHJhaW50IHRoYXQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCBm b3IgdGhlIHByb3BlciBmdW5jdGlvbiBvZiB0aGUgbWV0aG9kLiBJIHdpbGwgY2xhcmlmeSB0aGlz IHBvaW50IGFzIHdlbGwuDQoNCg0KQ2hlZXJzLA0KVGFsIE1penJhaGkuDQpbQXMgc2hlcGhlcmQg b2YgZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrXQ0K --_000_a61220ad531e46e1bb0d739044160e8ehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5EZWFyIFRhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGZpbmQgbXkgYW5zd2VycyBpbmxp bmUgdGFnZ2VkIGFzIFtHRl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBrbm93IGlmIHRoZXNl IGFkZHJlc3MgeW91ciBjb21tZW50cywgc28gSSBjYW4gdXBkYXRlIGFuZCBzdWJtaXQgYSBuZXcg dmVyc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5HaXVzZXBwZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gVGFsIE1penJhaGkgW21haWx0bzp0YWwubWl6cmFoaS5waGRAZ21haWwuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAyMCAyOjUwIFBNPGJyPg0K PGI+VG86PC9iPiBJRVRGIElQUE0gV0cgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRm LWlwcG0tbXVsdGlwb2ludC1hbHQtbWFya0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBT aGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJr LTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhdXRob3JzLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRo aXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCB3aXRoIGEgZmV3IG1pbm9yIGNv bW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgdGhlIGF1dGhvcnMgY2FuIGtpbmRseSBhZGRyZXNzIHRoZXNlIGNvbW1lbnRzIGFuZCBw b3N0IGFuIHVwZGF0ZWQgdmVyc2lvbiwgd2Ugd2lsbCBwcm9jZWVkIHdpdGggdGhlIHB1YmxpY2F0 aW9uIHByb2Nlc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDU6PGJyPg0KJnF1b3Q7VGhlIE1vbml0b3JlZCBOZXR3 b3JrIFBhY2tldCBMb3NzIHdpdGggbiBpbnB1dCBub2RlcyBhbmQgbSBvdXRwdXQgbm9kZXMgaXMg Z2l2ZW4gYnkmcXVvdDs8YnI+DQpQbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoZSBtZXRyaWMgUEwg aXMgbWVhc3VyZWQgb24gYSBwZXIgZmxvdyAoNS10dXBsZSkgYmFzaXMsIGFzIGRlZmluZWQgaW4g U2VjdGlvbiA0LCBvciBtZWFzdXJlZCBnbG9iYWxseSBmb3IgYWxsIHRoZSBmbG93cy48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5bR0ZdOiBUaGUgTW9uaXRvcmVkIE5ldHdvcmsgUGFja2V0IExvc3MgaXMgbWVhc3Vy ZWQgZm9yIG9uZSBzaW5nbGUgZmxvdyBidXQgc2luY2UgaXQgaXMgYSBtdWx0aXBvaW50IGZsb3cs IHRoZSBpZGVudGlmaWNhdGlvbiBmaWVsZHMgb2YgdGhlIDUtdHVwbGUsIGluIGdlbmVyYWwsDQog Y2FuIGJlIHNlbGVjdGVkIHdpdGhvdXQgYW55IGNvbnN0cmFpbnRzLiBJIGNhbiBzcGVjaWZ5IGJl dHRlciB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NClNlY3Rpb24gNTo8YnI+DQomcXVvdDtUaGUgZXF1YXRpb24gaXMgYXBw bGllZCBvbiBhIHBlci10aW1lLWludGVydmFsIGJhc2lzLiZxdW90Ozxicj4NClBsZWFzZSBub3Rl IHRoYXQgdGhlIHRlcm0gdGltZSBpbnRlcnZhbCBoYXMgbm90IGJlZW4gZGVmaW5lZCBiZWZvcmUg dGhpcyBwb2ludCBpbiB0aGUgZG9jdW1lbnQuIFRoaXMgd291bGQgYmUgYSBnb29kIHBvaW50IHRv IGFkZCBhIHNlbnRlbmNlIHRoYXQgZXhwbGFpbnMgdGhhdCBhbiAmcXVvdDtpbnRlcnZhbCZxdW90 OyBpcyBkZXJpdmVkIGZyb20gYW4gYWx0ZXJuYXRpbmcgbWFya2luZyBmaWVsZC48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bR0ZdOiBTdXJlLiBJIHdpbGwgYWRkIGEgbm90ZSBhYm91dCB0aGUgaW50ZXJ2YWwgaGVy ZSByZWZlcnJlZCwgdGhhdCBpcyB0aGUgYWx0ZXJuYXRlIG1hcmtpbmcgcGVyaW9kIGFzIGRlZmlu ZWQgaW4gUkZDIDgzMjEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KU2VjdGlvbiA2Ojxicj4NClBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgYSBj bHVzdGVyIGlzIGRlZmluZWQgb24gYSBwZXItZmxvdyBiYXNpcywgb3IgaXMgaXQgYXNzdW1lZCB0 aGF0IGFsbCBmbG93cyBhcmUgbW9uaXRvcmVkIGF0IGFsbCB0aW1lcy48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b R0ZdOiBZZXMsIHRoZSBDbHVzdGVyIGlzIGRlZmluZWQgb24gYSBwZXItZmxvdyBiYXNpcy4gSSBj YW4gYWRkIGEgc2VudGVuY2UgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpTZWN0aW9uIDc6PGJyPg0KJnF1b3Q7SW4gZ2Vu ZXJhbCB0aGUgbWVhc3VyZW1lbnQgaW50ZXJ2YWwgZm9yIGRlc2NyaWJpbmcgdGhlIHJlc3VsdHMg aXMgdGhlIGludGVydmFsIG9mIHRoZSBtYXJraW5nIG5vZGUgdGhhdCBpcyBtb3JlIGFsaWduZWQg d2l0aCB0aGUgc3RhcnQgb2YgdGhlIG1lYXN1cmVtZW50JnF1b3Q7PGJyPg0KUGxlYXNlIGNsYXJp Znkgd2hhdCAmcXVvdDttb3JlIGFsaWduZWQmcXVvdDsgbWVhbnMuIFRoZSBmaWd1cmUgc2VlbXMg dG8gaW5kaWNhdGUgdGhhdCB0aGUgbWVhc3VyZW1lbnQgaW50ZXJ2YWwgaXMgZGV0ZXJtaW5lZCBi eSB0aGUgbm9kZSB3aXRoIHRoZSBlYXJsaWVzdCBjbG9jaywgdGh1cyBzdGFydGluZyB0aGUgbWVh c3VyZW1lbnQgaW50ZXJ2YWwgYWhlYWQgb2YgdGhlIG90aGVyIG5vZGVzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bR0ZdOiBZZXMsIGluIHRoaXMgY2FzZSB3ZSBhc3N1bWUg dGhhdCB0aGUgbm9kZSB3aXRoIHRoZSBlYXJsaWVzdCBjbG9jayBpZGVudGlmaWVzIHRoZSByaWdo dCBzdGFydGluZyB0aW1lIG9mIHRoZSBtZWFzdXJlbWVudCwgYnV0IGl0IGlzIGp1c3QgYW4gYXNz dW1wdGlvbiBhbmQNCiBvdGhlciBwb3NzaWJpbGl0aWVzIGNhbiBoYXBwZW4uIFRoaXMgaXMgdG8g aW50cm9kdWNlIHRoZSBuZXcgY29uc3RyYWludCB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQg Zm9yIHRoZSBwcm9wZXIgZnVuY3Rpb24gb2YgdGhlIG1ldGhvZC4gSSB3aWxsIGNsYXJpZnkgdGhp cyBwb2ludCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRhbCBNaXpy YWhpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W0FzIHNoZXBoZXJkIG9mIGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFya108 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_a61220ad531e46e1bb0d739044160e8ehuaweicom_-- From nobody Thu Jan 30 03:17:23 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7067A120104; Thu, 30 Jan 2020 03:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZMZoktVCYtm; Thu, 30 Jan 2020 03:17:19 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 86D0F120125; Thu, 30 Jan 2020 03:17:19 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id k11so3524142wrd.9; Thu, 30 Jan 2020 03:17: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=hWhid2vUe16kefy2heISD/r4KjyhGG1KKQJrihgBAts=; b=c5hq9a8xn4YFkgJM6udl0244kH5VdCLhF/8KsK/8SAGf7M1kqQG2mcB/J+BwFbz5Zq G/aVtKuMn4z8v2jrWOlGOvuDycNssfPt/EAFVTuZU1qlMqEOMwtVmKVp97BKK9izw+Ka j29E+uO1f4hZ1S2n2k/31xDLBh/GlE5kw2KZDiu2B8bsQiIOOpBSd+q7pYBtR8LMsQXk TI/HDlbMVKdF/L370GArhEp0mGGBqkWFhXuSUg6Qs1s+wU0LMvBrDDPKPGRULrjhBZkk Ma6PdchRIcxiII5N2xKpjBMaA90gQeizwxTm0/Vz1u244IIuzloYyHwYHBjR9a8OXVbm PImQ== 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=hWhid2vUe16kefy2heISD/r4KjyhGG1KKQJrihgBAts=; b=fBe3o5amfeh1LAz84kFfJ+CSW9JcqmpIWi7iXx+LGDndvVK7KdSFaMrQHi/0HEgfyD LRPh0KI637MIgF4csE1VdVTV6bJj4zRz5SWFoj+E+jDkuYhV3S2dJ4kQWLZCrupXtytw oLghjZw6svn2B/8++yKxQnKQr/Yy/D7urwpxNHcJB+KlbI1TwSOL+aIWN9ernGCink8U Wnm14uh9vXvicdVICarMwBPu4/kaW+kAH8wC5E7FmUuuoizhtps7OkmooujoR2a5HQIq 7V/YivWibKR/IYQYBLn/N5Hi6fd1rNvKVMMCAxU7BIHJovRP1xj3oP1nBRS4yHGOA/N4 9b7w== X-Gm-Message-State: APjAAAWf3qw9QNA/L0lp/5tx+03B4UZ2HSZDdx8Q8vn5fVpzkdNWx2oc 80hJByJo79wfSNpWiQv58tVDcZrBr6W+R/pS5j4= X-Google-Smtp-Source: APXvYqyiRq1g3JHM0et+G5/tGZip6/gCNu+O4Z3Mstfolm9vD+6Qi5haD/uN1OCeKYoHA/fBd+Y4FvRJiiadUrg7RYo= X-Received: by 2002:a5d:4ed0:: with SMTP id s16mr5082923wrv.144.1580383037997; Thu, 30 Jan 2020 03:17:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Thu, 30 Jan 2020 13:17:06 +0200 Message-ID: To: Giuseppe Fioccola Cc: IETF IPPM WG , "draft-ietf-ippm-multipoint-alt-mark@ietf.org" Content-Type: multipart/alternative; boundary="00000000000096c5b5059d59999e" Archived-At: Subject: Re: [ippm] Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 11:17:21 -0000 --00000000000096c5b5059d59999e Content-Type: text/plain; charset="UTF-8" Hi Giuseppe, Sounds good to me. If you can update the draft based on these responses that would be great. Cheers, Tal. On Thu, Jan 30, 2020 at 12:37 PM Giuseppe Fioccola < giuseppe.fioccola@huawei.com> wrote: > Dear Tal, > > Please find my answers inline tagged as [GF]. > > Let me know if these address your comments, so I can update and submit a > new version. > > > > Regards, > > > > Giuseppe > > > > > > *From:* Tal Mizrahi [mailto:tal.mizrahi.phd@gmail.com] > *Sent:* Wednesday, January 29, 2020 2:50 PM > *To:* IETF IPPM WG ; > draft-ietf-ippm-multipoint-alt-mark@ietf.org > *Subject:* Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 > > > > Dear authors, > > > > I believe this document is ready for publication, with a few minor > comments. > > If the authors can kindly address these comments and post an updated > version, we will proceed with the publication process. > > > > Comments: > > > > Section 5: > "The Monitored Network Packet Loss with n input nodes and m output nodes > is given by" > Please clarify whether the metric PL is measured on a per flow (5-tuple) > basis, as defined in Section 4, or measured globally for all the flows. > > > > [GF]: The Monitored Network Packet Loss is measured for one single flow > but since it is a multipoint flow, the identification fields of the > 5-tuple, in general, can be selected without any constraints. I can specify > better this point. > > > > Section 5: > "The equation is applied on a per-time-interval basis." > Please note that the term time interval has not been defined before this > point in the document. This would be a good point to add a sentence that > explains that an "interval" is derived from an alternating marking field. > > > > [GF]: Sure. I will add a note about the interval here referred, that is > the alternate marking period as defined in RFC 8321. > > > > Section 6: > Please clarify whether a cluster is defined on a per-flow basis, or is it > assumed that all flows are monitored at all times. > > > > [GF]: Yes, the Cluster is defined on a per-flow basis. I can add a > sentence to clarify. > > > > Section 7: > "In general the measurement interval for describing the results is the > interval of the marking node that is more aligned with the start of the > measurement" > Please clarify what "more aligned" means. The figure seems to indicate > that the measurement interval is determined by the node with the earliest > clock, thus starting the measurement interval ahead of the other nodes. > > > > [GF]: Yes, in this case we assume that the node with the earliest clock > identifies the right starting time of the measurement, but it is just an > assumption and other possibilities can happen. This is to introduce the new > constraint that needs to be considered for the proper function of the > method. I will clarify this point as well. > > > > > > Cheers, > > Tal Mizrahi. > > [As shepherd of draft-fioccola-ippm-multipoint-alt-mark] > --00000000000096c5b5059d59999e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Giuseppe,

    Sounds good to me.
    If you can update the draft based on these responses that would be great= .

    Cheers,
    Tal.

    On Thu, Jan 30, 2020= at 12:37 PM Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:

    Dear Tal,

    Please find my answers inline tagged as [GF]= .

    Let me know if these address your comments, = so I can update and submit a new version.

    =C2=A0

    Regards,

    =C2=A0

    Giuseppe

    =C2=A0

    <= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">=C2=A0

    From: Tal Mizrahi [mailto:tal.mizrahi.phd@gmail.com]
    Sent: Wednesday, January 29, 2020 2:50 PM
    To: IETF IPPM WG <ippm@ietf.org>; draft-ietf-ippm-multipoint-alt-mark@ietf.= org
    Subject: Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-= 04

    =C2=A0

    Dear authors,

    =C2=A0

    I believe this document is ready for publication, wi= th a few minor comments.

    If the authors can kindly address these comments and= post an updated version, we will proceed with the publication process.<= /u>

    =C2=A0

    Comments:

    =C2=A0

    Section 5:
    "The Monitored Network Packet Loss with n input nodes and m output nod= es is given by"
    Please clarify whether the metric PL is measured on a per flow (5-tuple) ba= sis, as defined in Section 4, or measured globally for all the flows.

    =C2=A0

    [GF]: The Monitored Network Packet Loss is m= easured for one single flow but since it is a multipoint flow, the identifi= cation fields of the 5-tuple, in general, can be selected without any constraints. I can specify better this point.<= u>



    Section 5:
    "The equation is applied on a per-time-interval basis."
    Please note that the term time interval has not been defined before this po= int in the document. This would be a good point to add a sentence that expl= ains that an "interval" is derived from an alternating marking fi= eld.

    =C2=A0

    [GF]: Sure. I will add a note about the inte= rval here referred, that is the alternate marking period as defined in RFC = 8321.



    Section 6:
    Please clarify whether a cluster is defined on a per-flow basis, or is it a= ssumed that all flows are monitored at all times.

    =C2=A0

    [GF]: Yes, the Cluster is defined on a per-f= low basis. I can add a sentence to clarify.



    Section 7:
    "In general the measurement interval for describing the results is the= interval of the marking node that is more aligned with the start of the me= asurement"
    Please clarify what "more aligned" means. The figure seems to ind= icate that the measurement interval is determined by the node with the earl= iest clock, thus starting the measurement interval ahead of the other nodes= .

    =C2=A0

    [GF]: Yes, in this case we assume that the n= ode with the earliest clock identifies the right starting time of the measu= rement, but it is just an assumption and other possibilities can happen. This is to introduce the new constraint th= at needs to be considered for the proper function of the method. I will cla= rify this point as well.

    =C2=A0

    =C2=A0

    Cheers,

    Tal Mizrahi.

    [As shepherd of draft-fioccola-ippm-multipoint-alt-m= ark]

    --00000000000096c5b5059d59999e-- From nobody Thu Jan 30 07:14:30 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DBE120145 for ; Thu, 30 Jan 2020 07:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rVnjsb2ZXGSs for ; Thu, 30 Jan 2020 07:14:25 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E3C120168 for ; Thu, 30 Jan 2020 07:14:25 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00UF7E5u020250 for ; Thu, 30 Jan 2020 10:14:24 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2xuh9ts0js-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 30 Jan 2020 10:14:24 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 00UFENwO005188 for ; Thu, 30 Jan 2020 09:14:24 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 00UFEGJl004891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Jan 2020 09:14:16 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 1D717400073A for ; Thu, 30 Jan 2020 15:14:16 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id EFAC7400072D for ; Thu, 30 Jan 2020 15:14:15 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 00UFEFIl008044 for ; Thu, 30 Jan 2020 09:14:15 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 00UFEDkM007879 for ; Thu, 30 Jan 2020 09:14:13 -0600 Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-blue.research.att.com (Postfix) with ESMTP id 8A3F7F17A2 for ; Thu, 30 Jan 2020 10:14:12 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0468.000; Thu, 30 Jan 2020 10:14:12 -0500 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-00.txt Thread-Index: AQHV1wctFS6Rip/D9EmrzcoJkKGwaKgCYJrQ Date: Thu, 30 Jan 2020 15:14:11 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F1DDD3@njmtexg5.research.att.com> References: <158034537714.4849.10709618065227686315@ietfa.amsl.com> In-Reply-To: <158034537714.4849.10709618065227686315@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.42.43.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-30_04:2020-01-28, 2020-01-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 adultscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001300109 Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:14:28 -0000 Hi IPPM, Thanks to everyone who supported adoption of our draft. This version simply changes the filename. At the IETF-106 Hackathon, we encountered some new conditions in our testing with the prototype implementation: https://github.com/IETF-Hackathon/ietf106-project-presentations/blob/master= /106-acm-Hackathon-Measurements.pdf Load Adjustment:=20 Search Algorithm uses Loss and delay variation feedback Observed: Random loss throughout some tests, with insignificant delay variation Possible revisions to Search Algorithm, etc. under these conditions: Add a variable Loss threshold for conditions encountered Continue "large" rate increases when loss-only is encountered May need longer test durations under Loss-only Conditions We'd like to discuss these findings further with the WG, and run=20 some more tests to answer questions and investigate further. regards, Al, for the co-authors > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, January 29, 2020 7:50 PM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Performance Measurement WG of the > IETF. >=20 > Title : Metrics and Methods for IP Capacity > Authors : Al Morton > Ruediger Geib > Len Ciavattone > Filename : draft-ietf-ippm-capacity-metric-method-00.txt > Pages : 20 > Date : 2020-01-29 >=20 > Abstract: > This memo revisits the problem of Network Capacity metrics first > examined in RFC 5136. The memo specifies a more practical Maximum > IP-layer Capacity metric definition catering for measurement > purposes, and outlines the corresponding methods of measurement. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric- > 2Dmethod_&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dwr9y6v7T2pw1NXocsCDBLyhp= 1XSfR > aMle2rSbJ4MYZ8&s=3DPKuptmwoRT6LU0XzA5aP5ALP1V886WdfH5ZX22BoJ98&e=3D >=20 > There are also htmlized versions available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod- > 2D00&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dwr9y6v7T2pw1NXocsCDBLyhp= 1XSfR > aMle2rSbJ4MYZ8&s=3DraoeB7QOHSj15ytpNw58k9mRSEH4ORlmgztBDL8JH-8&e=3D > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric= - > 2Dmethod-2D00&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dwr9y6v7T2pw1NXocsCDBLyhp= 1XSfR > aMle2rSbJ4MYZ8&s=3DjRWhzLsfl0BvlwGBPXzAFPIDCSlGTqGLu367v1fmXL8&e=3D >=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 > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t- > 2Ddrafts_&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dwr9y6v7T2pw1NXocsCDBLyhp= 1XSfR > aMle2rSbJ4MYZ8&s=3DlBIhRtdqdEhzyeJ2ZjT-tONnwcxIsLe0VHDtL4k9Rrc&e=3D >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3Dwr9y6v7T2pw1NXocsCDBLyhp= 1XSfR > aMle2rSbJ4MYZ8&s=3DY8MyKFxZhcXaex8xmJn8G3hrATiH7vegAuYDd8ZF_zg&e=3D From nobody Fri Jan 31 01:51:44 2020 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7FD120026; Fri, 31 Jan 2020 01:51:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <158046429994.21150.14643427264263782276@ietfa.amsl.com> Date: Fri, 31 Jan 2020 01:51:40 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-multipoint-alt-mark-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 09:51:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Multipoint Alternate Marking method for passive and hybrid performance monitoring Authors : Giuseppe Fioccola Mauro Cociglio Amedeo Sapio Riccardo Sisto Filename : draft-ietf-ippm-multipoint-alt-mark-05.txt Pages : 22 Date : 2020-01-31 Abstract: The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-multipoint-alt-mark-05 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-multipoint-alt-mark-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-multipoint-alt-mark-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 31 02:02:54 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B801200F8; Fri, 31 Jan 2020 02:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 4GBVv9YUZHyS; Fri, 31 Jan 2020 02: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 7D32212089B; Fri, 31 Jan 2020 02:02:49 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DD22FFB133229EA9A3AA; Fri, 31 Jan 2020 10:02:43 +0000 (GMT) Received: from fraeml718-chm.china.huawei.com (10.206.15.14) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 31 Jan 2020 10:02:44 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml718-chm.china.huawei.com (10.206.15.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 31 Jan 2020 11:02:43 +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.1713.004; Fri, 31 Jan 2020 11:02:43 +0100 From: Giuseppe Fioccola To: Tal Mizrahi CC: IETF IPPM WG , "draft-ietf-ippm-multipoint-alt-mark@ietf.org" Thread-Topic: Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 Thread-Index: AQHV1qsKRjo7Ii7jskm1WJ1UaRyaF6gC+VHQgAAGMQCAAYt1sA== Date: Fri, 31 Jan 2020 10:02:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.169.218] Content-Type: multipart/alternative; boundary="_000_ab8fa52e659248adbe6db6dee2a847a2huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Shepherd review of draft-fioccola-ippm-multipoint-alt-mark-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 10:02:53 -0000 --_000_ab8fa52e659248adbe6db6dee2a847a2huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGFsLA0KSSBoYXZlIGp1c3Qgc3VibWl0dGVkIHRoZSBuZXcgLTA1IHZlcnNpb24uDQpQbGVh c2UgbGV0IG1lIGtub3cgaWYgdGhpcyBhZGRyZXNzZXMgeW91ciByZW1hcmtzLg0KDQpSZWdhcmRz LA0KDQpHaXVzZXBwZQ0KDQoNCkZyb206IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsLm1penJhaGku cGhkQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDMwLCAyMDIwIDEyOjE3IFBN DQpUbzogR2l1c2VwcGUgRmlvY2NvbGEgPGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20+DQpD YzogSUVURiBJUFBNIFdHIDxpcHBtQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9p bnQtYWx0LW1hcmtAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTaGVwaGVyZCByZXZpZXcgb2YgZHJh ZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTA0DQoNCkhpIEdpdXNlcHBlLA0K DQpTb3VuZHMgZ29vZCB0byBtZS4NCklmIHlvdSBjYW4gdXBkYXRlIHRoZSBkcmFmdCBiYXNlZCBv biB0aGVzZSByZXNwb25zZXMgdGhhdCB3b3VsZCBiZSBncmVhdC4NCg0KQ2hlZXJzLA0KVGFsLg0K DQpPbiBUaHUsIEphbiAzMCwgMjAyMCBhdCAxMjozNyBQTSBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1 c2VwcGUuZmlvY2NvbGFAaHVhd2VpLmNvbTxtYWlsdG86Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KRGVhciBUYWwsDQpQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGlubGluZSB0 YWdnZWQgYXMgW0dGXS4NCkxldCBtZSBrbm93IGlmIHRoZXNlIGFkZHJlc3MgeW91ciBjb21tZW50 cywgc28gSSBjYW4gdXBkYXRlIGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lvbi4NCg0KUmVnYXJkcywN Cg0KR2l1c2VwcGUNCg0KDQpGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbC5taXpyYWhpLnBo ZEBnbWFpbC5jb208bWFpbHRvOnRhbC5taXpyYWhpLnBoZEBnbWFpbC5jb20+XQ0KU2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDI5LCAyMDIwIDI6NTAgUE0NClRvOiBJRVRGIElQUE0gV0cgPGlwcG1A aWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+PjsgZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9p bnQtYWx0LW1hcmtAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFs dC1tYXJrQGlldGYub3JnPg0KU3ViamVjdDogU2hlcGhlcmQgcmV2aWV3IG9mIGRyYWZ0LWZpb2Nj b2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyay0wNA0KDQpEZWFyIGF1dGhvcnMsDQoNCkkgYmVs aWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgd2l0aCBhIGZldyBt aW5vciBjb21tZW50cy4NCklmIHRoZSBhdXRob3JzIGNhbiBraW5kbHkgYWRkcmVzcyB0aGVzZSBj b21tZW50cyBhbmQgcG9zdCBhbiB1cGRhdGVkIHZlcnNpb24sIHdlIHdpbGwgcHJvY2VlZCB3aXRo IHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzLg0KDQpDb21tZW50czoNCg0KU2VjdGlvbiA1Og0KIlRo ZSBNb25pdG9yZWQgTmV0d29yayBQYWNrZXQgTG9zcyB3aXRoIG4gaW5wdXQgbm9kZXMgYW5kIG0g b3V0cHV0IG5vZGVzIGlzIGdpdmVuIGJ5Ig0KUGxlYXNlIGNsYXJpZnkgd2hldGhlciB0aGUgbWV0 cmljIFBMIGlzIG1lYXN1cmVkIG9uIGEgcGVyIGZsb3cgKDUtdHVwbGUpIGJhc2lzLCBhcyBkZWZp bmVkIGluIFNlY3Rpb24gNCwgb3IgbWVhc3VyZWQgZ2xvYmFsbHkgZm9yIGFsbCB0aGUgZmxvd3Mu DQoNCltHRl06IFRoZSBNb25pdG9yZWQgTmV0d29yayBQYWNrZXQgTG9zcyBpcyBtZWFzdXJlZCBm b3Igb25lIHNpbmdsZSBmbG93IGJ1dCBzaW5jZSBpdCBpcyBhIG11bHRpcG9pbnQgZmxvdywgdGhl IGlkZW50aWZpY2F0aW9uIGZpZWxkcyBvZiB0aGUgNS10dXBsZSwgaW4gZ2VuZXJhbCwgY2FuIGJl IHNlbGVjdGVkIHdpdGhvdXQgYW55IGNvbnN0cmFpbnRzLiBJIGNhbiBzcGVjaWZ5IGJldHRlciB0 aGlzIHBvaW50Lg0KDQoNClNlY3Rpb24gNToNCiJUaGUgZXF1YXRpb24gaXMgYXBwbGllZCBvbiBh IHBlci10aW1lLWludGVydmFsIGJhc2lzLiINClBsZWFzZSBub3RlIHRoYXQgdGhlIHRlcm0gdGlt ZSBpbnRlcnZhbCBoYXMgbm90IGJlZW4gZGVmaW5lZCBiZWZvcmUgdGhpcyBwb2ludCBpbiB0aGUg ZG9jdW1lbnQuIFRoaXMgd291bGQgYmUgYSBnb29kIHBvaW50IHRvIGFkZCBhIHNlbnRlbmNlIHRo YXQgZXhwbGFpbnMgdGhhdCBhbiAiaW50ZXJ2YWwiIGlzIGRlcml2ZWQgZnJvbSBhbiBhbHRlcm5h dGluZyBtYXJraW5nIGZpZWxkLg0KDQpbR0ZdOiBTdXJlLiBJIHdpbGwgYWRkIGEgbm90ZSBhYm91 dCB0aGUgaW50ZXJ2YWwgaGVyZSByZWZlcnJlZCwgdGhhdCBpcyB0aGUgYWx0ZXJuYXRlIG1hcmtp bmcgcGVyaW9kIGFzIGRlZmluZWQgaW4gUkZDIDgzMjEuDQoNCg0KU2VjdGlvbiA2Og0KUGxlYXNl IGNsYXJpZnkgd2hldGhlciBhIGNsdXN0ZXIgaXMgZGVmaW5lZCBvbiBhIHBlci1mbG93IGJhc2lz LCBvciBpcyBpdCBhc3N1bWVkIHRoYXQgYWxsIGZsb3dzIGFyZSBtb25pdG9yZWQgYXQgYWxsIHRp bWVzLg0KDQpbR0ZdOiBZZXMsIHRoZSBDbHVzdGVyIGlzIGRlZmluZWQgb24gYSBwZXItZmxvdyBi YXNpcy4gSSBjYW4gYWRkIGEgc2VudGVuY2UgdG8gY2xhcmlmeS4NCg0KDQpTZWN0aW9uIDc6DQoi SW4gZ2VuZXJhbCB0aGUgbWVhc3VyZW1lbnQgaW50ZXJ2YWwgZm9yIGRlc2NyaWJpbmcgdGhlIHJl c3VsdHMgaXMgdGhlIGludGVydmFsIG9mIHRoZSBtYXJraW5nIG5vZGUgdGhhdCBpcyBtb3JlIGFs aWduZWQgd2l0aCB0aGUgc3RhcnQgb2YgdGhlIG1lYXN1cmVtZW50Ig0KUGxlYXNlIGNsYXJpZnkg d2hhdCAibW9yZSBhbGlnbmVkIiBtZWFucy4gVGhlIGZpZ3VyZSBzZWVtcyB0byBpbmRpY2F0ZSB0 aGF0IHRoZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBub2RlIHdp dGggdGhlIGVhcmxpZXN0IGNsb2NrLCB0aHVzIHN0YXJ0aW5nIHRoZSBtZWFzdXJlbWVudCBpbnRl cnZhbCBhaGVhZCBvZiB0aGUgb3RoZXIgbm9kZXMuDQoNCltHRl06IFllcywgaW4gdGhpcyBjYXNl IHdlIGFzc3VtZSB0aGF0IHRoZSBub2RlIHdpdGggdGhlIGVhcmxpZXN0IGNsb2NrIGlkZW50aWZp ZXMgdGhlIHJpZ2h0IHN0YXJ0aW5nIHRpbWUgb2YgdGhlIG1lYXN1cmVtZW50LCBidXQgaXQgaXMg anVzdCBhbiBhc3N1bXB0aW9uIGFuZCBvdGhlciBwb3NzaWJpbGl0aWVzIGNhbiBoYXBwZW4uIFRo aXMgaXMgdG8gaW50cm9kdWNlIHRoZSBuZXcgY29uc3RyYWludCB0aGF0IG5lZWRzIHRvIGJlIGNv bnNpZGVyZWQgZm9yIHRoZSBwcm9wZXIgZnVuY3Rpb24gb2YgdGhlIG1ldGhvZC4gSSB3aWxsIGNs YXJpZnkgdGhpcyBwb2ludCBhcyB3ZWxsLg0KDQoNCkNoZWVycywNClRhbCBNaXpyYWhpLg0KW0Fz IHNoZXBoZXJkIG9mIGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFya10NCg== --_000_ab8fa52e659248adbe6db6dee2a847a2huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGFs LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhhdmUganVzdCBzdWJtaXR0ZWQgdGhlIG5ldyAtMDUgdmVy c2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgYWRkcmVz c2VzIHlvdXIgcmVtYXJrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5H aXVzZXBwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gVGFsIE1penJhaGkgW21haWx0bzp0YWwubWl6cmFoaS5waGRAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDMwLCAyMDIwIDEyOjE3 IFBNPGJyPg0KPGI+VG86PC9iPiBHaXVzZXBwZSBGaW9jY29sYSAmbHQ7Z2l1c2VwcGUuZmlvY2Nv bGFAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgSVBQTSBXRyAmbHQ7aXBwbUBp ZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtZmlvY2Nv bGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgR2l1c2VwcGUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Tb3VuZHMgZ29vZCB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBjYW4gdXBkYXRlIHRoZSBkcmFmdCBi YXNlZCBvbiB0aGVzZSByZXNwb25zZXMgdGhhdCB3b3VsZCBiZSBncmVhdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEph biAzMCwgMjAyMCBhdCAxMjozNyBQTSBHaXVzZXBwZSBGaW9jY29sYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20iPmdpdXNlcHBlLmZpb2Njb2xhQGh1YXdl aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlYXIgVGFs LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBmaW5kIG15IGFuc3dlcnMgaW5saW5lIHRhZ2dl ZCBhcyBbR0ZdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBrbm93IGlmIHRoZXNlIGFkZHJl c3MgeW91ciBjb21tZW50cywgc28gSSBjYW4gdXBkYXRlIGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdpdXNlcHBl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXy01NDMzMjg0OTk5MDIyMTMyNjgyX19NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRhbCBNaXpyYWhpIFttYWlsdG86 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0YWwubWl6cmFoaS5waGRAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj50YWwubWl6cmFoaS5waGRAZ21haWwuY29tPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEph bnVhcnkgMjksIDIwMjAgMjo1MCBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBJUFBNIFdHICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPmlwcG1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pcHBtLW11bHRpcG9pbnQtYWx0 LW1hcmtAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmRyYWZ0LWll dGYtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtZmlv Y2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTA0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgYXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24sIHdpdGggYSBmZXcgbWlub3IgY29tbWVudHMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHRoZSBhdXRob3Jz IGNhbiBraW5kbHkgYWRkcmVzcyB0aGVzZSBjb21tZW50cyBhbmQgcG9zdCBhbiB1cGRhdGVkIHZl cnNpb24sIHdlIHdpbGwgcHJvY2VlZCB3aXRoIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29t bWVudHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TZWN0aW9uIDU6PGJyPg0KJnF1b3Q7VGhlIE1vbml0b3JlZCBOZXR3b3JrIFBhY2tl dCBMb3NzIHdpdGggbiBpbnB1dCBub2RlcyBhbmQgbSBvdXRwdXQgbm9kZXMgaXMgZ2l2ZW4gYnkm cXVvdDs8YnI+DQpQbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoZSBtZXRyaWMgUEwgaXMgbWVhc3Vy ZWQgb24gYSBwZXIgZmxvdyAoNS10dXBsZSkgYmFzaXMsIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0 LCBvciBtZWFzdXJlZCBnbG9iYWxseSBmb3IgYWxsIHRoZSBmbG93cy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltHRl06IFRoZSBNb25pdG9yZWQgTmV0d29yayBQYWNr ZXQgTG9zcyBpcyBtZWFzdXJlZCBmb3Igb25lIHNpbmdsZSBmbG93IGJ1dCBzaW5jZSBpdCBpcyBh IG11bHRpcG9pbnQNCiBmbG93LCB0aGUgaWRlbnRpZmljYXRpb24gZmllbGRzIG9mIHRoZSA1LXR1 cGxlLCBpbiBnZW5lcmFsLCBjYW4gYmUgc2VsZWN0ZWQgd2l0aG91dCBhbnkgY29uc3RyYWludHMu IEkgY2FuIHNwZWNpZnkgYmV0dGVyIHRoaXMgcG9pbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnI+DQpTZWN0aW9uIDU6PGJyPg0KJnF1b3Q7 VGhlIGVxdWF0aW9uIGlzIGFwcGxpZWQgb24gYSBwZXItdGltZS1pbnRlcnZhbCBiYXNpcy4mcXVv dDs8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSB0ZXJtIHRpbWUgaW50ZXJ2YWwgaGFzIG5vdCBi ZWVuIGRlZmluZWQgYmVmb3JlIHRoaXMgcG9pbnQgaW4gdGhlIGRvY3VtZW50LiBUaGlzIHdvdWxk IGJlIGEgZ29vZCBwb2ludCB0byBhZGQgYSBzZW50ZW5jZSB0aGF0IGV4cGxhaW5zIHRoYXQgYW4g JnF1b3Q7aW50ZXJ2YWwmcXVvdDsgaXMgZGVyaXZlZCBmcm9tIGFuIGFsdGVybmF0aW5nIG1hcmtp bmcgZmllbGQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bR0ZdOiBT dXJlLiBJIHdpbGwgYWRkIGEgbm90ZSBhYm91dCB0aGUgaW50ZXJ2YWwgaGVyZSByZWZlcnJlZCwg dGhhdCBpcyB0aGUgYWx0ZXJuYXRlIG1hcmtpbmcgcGVyaW9kDQogYXMgZGVmaW5lZCBpbiBSRkMg ODMyMS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N Cjxicj4NClNlY3Rpb24gNjo8YnI+DQpQbGVhc2UgY2xhcmlmeSB3aGV0aGVyIGEgY2x1c3RlciBp cyBkZWZpbmVkIG9uIGEgcGVyLWZsb3cgYmFzaXMsIG9yIGlzIGl0IGFzc3VtZWQgdGhhdCBhbGwg Zmxvd3MgYXJlIG1vbml0b3JlZCBhdCBhbGwgdGltZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5bR0ZdOiBZZXMsIHRoZSBDbHVzdGVyIGlzIGRlZmluZWQgb24gYSBw ZXItZmxvdyBiYXNpcy4gSSBjYW4gYWRkIGEgc2VudGVuY2UgdG8gY2xhcmlmeS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NClNlY3Rpb24g Nzo8YnI+DQomcXVvdDtJbiBnZW5lcmFsIHRoZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBmb3IgZGVz Y3JpYmluZyB0aGUgcmVzdWx0cyBpcyB0aGUgaW50ZXJ2YWwgb2YgdGhlIG1hcmtpbmcgbm9kZSB0 aGF0IGlzIG1vcmUgYWxpZ25lZCB3aXRoIHRoZSBzdGFydCBvZiB0aGUgbWVhc3VyZW1lbnQmcXVv dDs8YnI+DQpQbGVhc2UgY2xhcmlmeSB3aGF0ICZxdW90O21vcmUgYWxpZ25lZCZxdW90OyBtZWFu cy4gVGhlIGZpZ3VyZSBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBtZWFzdXJlbWVudCBpbnRl cnZhbCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBub2RlIHdpdGggdGhlIGVhcmxpZXN0IGNsb2NrLCB0 aHVzIHN0YXJ0aW5nIHRoZSBtZWFzdXJlbWVudCBpbnRlcnZhbCBhaGVhZCBvZiB0aGUgb3RoZXIg bm9kZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bR0ZdOiBZZXMs IGluIHRoaXMgY2FzZSB3ZSBhc3N1bWUgdGhhdCB0aGUgbm9kZSB3aXRoIHRoZSBlYXJsaWVzdCBj bG9jayBpZGVudGlmaWVzIHRoZSByaWdodCBzdGFydGluZw0KIHRpbWUgb2YgdGhlIG1lYXN1cmVt ZW50LCBidXQgaXQgaXMganVzdCBhbiBhc3N1bXB0aW9uIGFuZCBvdGhlciBwb3NzaWJpbGl0aWVz IGNhbiBoYXBwZW4uIFRoaXMgaXMgdG8gaW50cm9kdWNlIHRoZSBuZXcgY29uc3RyYWludCB0aGF0 IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgZm9yIHRoZSBwcm9wZXIgZnVuY3Rpb24gb2YgdGhlIG1l dGhvZC4gSSB3aWxsIGNsYXJpZnkgdGhpcyBwb2ludCBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGFsIE1penJhaGkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltBcyBzaGVwaGVyZCBvZiBkcmFmdC1m aW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmtdPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_ab8fa52e659248adbe6db6dee2a847a2huaweicom_-- From nobody Fri Jan 31 07:55:52 2020 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57B3120123 for ; Fri, 31 Jan 2020 07:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jdO9rmKeAHOb for ; Fri, 31 Jan 2020 07:55:48 -0800 (PST) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3AF1200FD for ; Fri, 31 Jan 2020 07:55:48 -0800 (PST) Received: from web3.cs.jhu.edu (web3.cs.jhu.edu [128.220.13.76]) (user=soudeh mech=LOGIN bits=0) by blaze.cs.jhu.edu (8.14.4/8.14.4) with ESMTP id 00VFtkDW030506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 31 Jan 2020 10:55:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 31 Jan 2020 10:55:47 -0500 From: Soudeh Ghorbani To: ippm@ietf.org Reply-To: soudeh@cs.jhu.edu Mail-Reply-To: soudeh@cs.jhu.edu Message-ID: <4160189b9b0ed33f9e8e4aa6e729835f@cs.jhu.edu> X-Sender: soudeh@cs.jhu.edu User-Agent: Roundcube Webmail/1.0.12 Archived-At: Subject: [ippm] ACM SOSR'20: Call for Participation / Registration X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 15:55:50 -0000 ACM SOSR'20: Call for Participation / Registration The organizing committee is delighted to invite you to the ACM SIGCOMM Symposium on SDN Research (SOSR), to be held on March 3, 2020 in San Jose, CA. SOSR is the premiere venue for research publications on SDN, building on past years' successful SOSR and HotSDN (Hot Topics in Software Defined Networking) workshops. New this year, SOSR will be co-­located with the Open Compute Project (OCP) Global Summit to foster interaction between academic and industrial attendees. We are also pleased to announce that we will again be giving out the SOSR Software Systems Award at this year's SOSR, which recognizes software that has significantly impacted SDN. Registration details: https://conferences.sigcomm.org/sosr/2020/register.html