From nobody Fri Oct 1 10:04:01 2021 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 5B6D93A0E26 for ; Fri, 1 Oct 2021 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Wt49KPkPsm_I for ; Fri, 1 Oct 2021 10:03:54 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 2150C3A0E1C for ; Fri, 1 Oct 2021 10:03:39 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id h30so12143240vsq.3 for ; Fri, 01 Oct 2021 10:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=jiSHUIIbS65azLOAmZO7y9x5GVH7Zs1AfdWX0Sr4WUE=; b=K3kajQX9q7h00IIGoKfS8t1zBDGUL/z1kXAopMNCtjKXne5iMg/OPvZJZtQuhcBZu1 0sG9mMctjzstgvjtsLrDLerSEHYef6zGaFUq1awAOcTw/Nk6Uz1zhradW40VJZMqk7X/ 9KErTi4tkSTNZdQIl8RsPxufVYx7agkOiS99ZEAiF5PqZbcYcs+E6LPXCa/JDWgDM9ex rm/30YcmGEVBmtmlEfL+92JmnyvJRtNWz8MHEX3ATOavojz8Ll+GBrcA7wt69ZpRsdL9 nuYNHtnFKf/UDa6DKf7xwIQguHKOFrteLZCmpaO9FBCriVjkairooR//mb/P15cNM8oV H2fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=jiSHUIIbS65azLOAmZO7y9x5GVH7Zs1AfdWX0Sr4WUE=; b=dj5kr3gPgJzMkkYAiVFs0+HP7MZI6amRjbLqd0K5hTW5cb/pUOGQbnI+XYF7T7yQnu 76h2ppyUlEIVYXtqKh++OHJv64A5QpAQ4UbrQkBn+EQFo+wRT7XI9/sj37qzaCA8z83t gn26WA4XmHqttUVltHJ6pKOg/zi+1hWQkM99x4YUa1nhfDWYb86nb0A8YA4eoccBRhXD pKoTjhkgRg/8/TeIfxr539Y8WiHuYJJXqPta+4yVw9Sgeh0UO7zDUXAsgPviNxzUO33+ sqM1LsqTSN3uVEy7O89IcEPiG9tRHDcqUUngVCbpJ2DYSlzq4HXLYaxqjjUlqxTbT0h5 a2Tw== X-Gm-Message-State: AOAM533vcFCApXnpvXxGcie7l4fHhJml27GJqSqzACQiZHuYDh9z1LRo hcyg3seH/6uL81uIThoGqQjA7K0iIys/hUz4w/OC4f9C X-Google-Smtp-Source: ABdhPJwBt92BnJSvQ/VqOIOrj0ku1yQ+P69mtvRxGhZ7l0v+vSXtCozxM7ZJBtzDk8qlfuXL/wLCapcLAyZaHTjcXDA= X-Received: by 2002:a67:f74f:: with SMTP id w15mr5236957vso.61.1633107816650; Fri, 01 Oct 2021 10:03:36 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Fri, 1 Oct 2021 10:03:25 -0700 Message-ID: To: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000004a99b205cd4d8be4" Archived-At: Subject: [ippm] New chair! 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, 01 Oct 2021 17:03:58 -0000 --0000000000004a99b205cd4d8be4 Content-Type: text/plain; charset="UTF-8" Greetings IPPM! I'm pleased to announce that Marcus Ihlar is joining IPPM as our newest chair. Ian Swett is stepping down for various reasons, I'd like to thank him for his efforts to move the WG forward over the past year and a half. We will run with three chairs at IETF 112, after which Ian will formally depart. Welcome Marcus! Martin --0000000000004a99b205cd4d8be4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings IPPM!

I'm plea= sed to announce that Marcus Ihlar is joining IPPM as our newest chair. Ian = Swett is stepping down for various reasons, I'd like to thank him for h= is efforts to move the WG forward over the past year and a half.
=
We will run with three chairs at IETF 112, after which Ian w= ill formally depart.

Welcome Marcus!
Mar= tin
--0000000000004a99b205cd4d8be4-- From nobody Fri Oct 1 10:16:41 2021 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 D51843A0E4D for ; Fri, 1 Oct 2021 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RJbIqL5Ga6Gf for ; Fri, 1 Oct 2021 10:16:36 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 9E5243A0E4C for ; Fri, 1 Oct 2021 10:16:36 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id u32so21966460ybd.9 for ; Fri, 01 Oct 2021 10:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nuLQwnT9BCl50nhpLS4D5Mk4poR1l7d6GWWYY2ChLqY=; b=QpgVHZvrqLSvfVUwslntKGrm9e1Gu6rfdrHwhZzqZVmaFX3f422V49ecwOspZqJBuS z0bf7lTRshzU7u/Uv5gvvfQ2BiZuTF+fbrN0GLinMAB17gl4SrAZNTC6GKvUbGKB2wrT XKYFcFFxVYtBfHQgitk8NGbwcbA0dTGZL1rz+SH0IT4eE7SPtef8wk1eWQbCOv+vD5X8 9e+vBbAHm3jCWNNnOL1kEk/ePsi3xX07QX8/0smZAswVDkbBHMxMMOEbK56NYJ72GodE BQyiEoP+mmz+yAUCKKZtrGoWP8WXc4a6qp+/I04wSAf9wfTkBkEnHTmWIg1r9KbatWv1 EAOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nuLQwnT9BCl50nhpLS4D5Mk4poR1l7d6GWWYY2ChLqY=; b=ELVeYSs8LRolriOJkGe6GWumfRYd+8TSyMax9jkf53yxwzR0shvaN+76JCFg4ktMJd AhbLjOYMKynmWLgyaTRGMEHaLd/ZuF4NFB7HWw3q8IscWZ4e7azjBMyhZ7a0OjbsGIjL UGTeqX3/BCWrdHdmaI6z6rw9N4dPF1MtvRWite6F3D/OSRDon9Efh1csYG10LnXPjD/0 aoRfdv6sPtLa3aUmsFVOEtdWylU4CUkWN8WanTQsb6f+sYUt7e30wb1oxb6zBiim9EAc IlYh9XyJl1Rlb9sCFWCGAgtgkuaMPyj23BFsWOv1MmRr9L2u8FJWtsay62QMJGxy2Mu0 AU+A== X-Gm-Message-State: AOAM531MVB2uo8Iz7/ORv1Q8Pf9/aTY8BVpMUXtbe9MUIDhxtBpSPOEo gPpl/3cEVB29XID5uPDImuIT8oS7mEx6tLuSA/glX2B8+Pk= X-Google-Smtp-Source: ABdhPJxrLaRmPcArwHXdFwsSORYpFlOVJK5aYY29KLF2VJt2k5MiJwEPWyNcsITN/+XUyn/d2WDWLGDCOtoQwxyemx8= X-Received: by 2002:a25:2286:: with SMTP id i128mr7019009ybi.76.1633108595023; Fri, 01 Oct 2021 10:16:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 1 Oct 2021 13:16:24 -0400 Message-ID: To: Martin Duke Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000b02f8b05cd4db95d" Archived-At: Subject: Re: [ippm] New chair! 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, 01 Oct 2021 17:16:39 -0000 --000000000000b02f8b05cd4db95d Content-Type: text/plain; charset="UTF-8" Thanks Martin, It's been a great experience to chair IPPM, but I have confidence Marcus will do an awesome job. Ian On Fri, Oct 1, 2021 at 1:04 PM Martin Duke wrote: > Greetings IPPM! > > I'm pleased to announce that Marcus Ihlar is joining IPPM as our newest > chair. Ian Swett is stepping down for various reasons, I'd like to thank > him for his efforts to move the WG forward over the past year and a half. > > We will run with three chairs at IETF 112, after which Ian will formally > depart. > > Welcome Marcus! > Martin > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000b02f8b05cd4db95d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Martin,

It's been a great ex= perience to chair IPPM, but I have=C2=A0confidence Marcus will=C2=A0do an a= wesome job.

Ian

On Fri, Oct 1, 2021 at 1:04 P= M Martin Duke <martin.h.duke@= gmail.com> wrote:
Greetings IPPM!

I= 'm pleased to announce that Marcus Ihlar is joining IPPM as our newest = chair. Ian Swett is stepping down for various reasons, I'd like to than= k him for his efforts to move the WG forward over the past year and a half.=

We will run with three chairs at IETF 112, after = which Ian will formally depart.

Welcome Marcus!
Martin
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000b02f8b05cd4db95d-- From nobody Sat Oct 2 08:39:41 2021 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 B748B3A1002 for ; Sat, 2 Oct 2021 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDHHvAHw6UYc for ; Sat, 2 Oct 2021 08:39:33 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 94FCF3A0C04 for ; Sat, 2 Oct 2021 08:39:33 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id v10so46561615edj.10 for ; Sat, 02 Oct 2021 08:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JUo5bZ5Aa/fBkHcz5fjWsGUPp1+EoRaFLhvtWzK3PPc=; b=LXujYhy4SFrblRqWDbh5pBfN3shq3etW2KGwn84gnRlIwlJ/g7Ni1k98cBzTrHB5El MuZ9kWK/EqhZtAxAya7T2TjZfr7I0Rc3HSNxE5huehvY9+FOXoqKEr6/dnI5NtLcsKSb Ff+WwJo806RZhRiR0/Xxi9iqq7N4T/rJW2j4hdh9hESkpZ6olFeGVAKPF3P4dvrTijFd y1AR2fwsbST9nVskEZFsF78e5FjtGq0c42LTtL0vGEu5B6ZSAs9T/jX+SCSSAweYl1gd nDk14Z4LsE7W8h/vxFAa8VOKsgz4I92DffmYvOf00MSOvfXAhErpS6wk5rddikVIi/xw ZK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JUo5bZ5Aa/fBkHcz5fjWsGUPp1+EoRaFLhvtWzK3PPc=; b=2uVKYqcgLDoT3Xhp4/Jsm2sxw4UruYGTt/tHPkH1kgtC3squ2XyJzvffefIZaw8Iq6 dyYpR4OV8Xxc0xRx+X6K796e32ley57aXaiDOaYxnPVwm5BMiOlGanVO8M6UQGNjz6oN Clma+gX4JQeWtdTH/eHDZGyCCekIQoZ5ad1PwF1dp8gT8cRadm5s2eVPmhEVLhxFBRh1 u3TmMmwOR69vFJk7eKo4nPKgIQp+TH6pT0B/beCe++TbIWNGhJG31FER1U7ydIzQqVTD lp33PaCC620dDrqEdKzoxeP8mPQjcYcmcdRq52xV31IgEx+hRZ2ic1n2RStMR5wJ19gd iJdQ== X-Gm-Message-State: AOAM532mfa0QxBOTKQKSjUZ00x+xCSJuE6XadNT5W31ahmT/r8IAb5IE g5kr4w94km5ZqHGfFFmp3Hfrxm6p99HT3l+R/jthuyx4MYc= X-Google-Smtp-Source: ABdhPJydWSBAnvza23HjK/uUXjwjDx4zeV83xUWxJUyNKQZuuaBUTZJqEM9XJuwniUgxqiDrdc5NOs2jsqliYA2s2us= X-Received: by 2002:a05:6402:1207:: with SMTP id c7mr2434618edw.342.1633189171697; Sat, 02 Oct 2021 08:39:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sat, 2 Oct 2021 08:39:20 -0700 Message-ID: To: Martin Duke Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000006e19f205cd607c0e" Archived-At: Subject: Re: [ippm] New chair! 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: Sat, 02 Oct 2021 15:39:39 -0000 --0000000000006e19f205cd607c0e Content-Type: text/plain; charset="UTF-8" Thank you, Ian, for your guidance and work in the IPPM WG. It was a pleasure and privilege working with you. Welcome, Marcus! Regards, Greg On Fri, Oct 1, 2021 at 10:04 AM Martin Duke wrote: > Greetings IPPM! > > I'm pleased to announce that Marcus Ihlar is joining IPPM as our newest > chair. Ian Swett is stepping down for various reasons, I'd like to thank > him for his efforts to move the WG forward over the past year and a half. > > We will run with three chairs at IETF 112, after which Ian will formally > depart. > > Welcome Marcus! > Martin > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --0000000000006e19f205cd607c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Ian, for your guidance and work in the IPPM WG.= It was a pleasure=C2=A0and privilege working with you.

= Welcome, Marcus!

Regards,
Greg
<= br>


On Fri, Oct 1, 2021 at 10:04 AM Martin Duke &= lt;martin.h.duke@gmail.com&g= t; wrote:
Greetings IPPM!

I'm pleased to= announce that Marcus Ihlar is joining IPPM as our newest chair. Ian Swett = is stepping down for various reasons, I'd like to thank him for his eff= orts to move the WG forward over the past year and a half.

We will run with three chairs at IETF 112, after which Ian will fo= rmally depart.

Welcome Marcus!
Martin
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--0000000000006e19f205cd607c0e-- From nobody Sun Oct 3 03:55:43 2021 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 3B78B3A06E7 for ; Sun, 3 Oct 2021 03:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 aLGvMd_pms-8 for ; Sun, 3 Oct 2021 03:55:32 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 9D9363A0749 for ; Sun, 3 Oct 2021 03:55:31 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id n65so1102735ybb.7 for ; Sun, 03 Oct 2021 03:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJcbkrStzy5Aarrq1x88zqAfwKXatoVg3GxyruSHMLI=; b=cTJV8fY/CANBazOJ0urEIHb9MxFML8fXlT4EgM3+deaWIpmX9pcJq822bYYholojIL 6okCeXinvUYO+ex/pp50WfY+UbRvFYpTMOI0n/JMVOCfVso3wrXydCAQEaL6qI6ITNXn we48SeTiW/llqKp3ufYJGHex3kkI8iQfi2yWyu/+I626dfibRlp5Zz374myU9wexMf5M Dwj+2ypxulURWF5d5ummsRh17iLVcsdpR8eX79fjDokowSKR0u2A77tcXxQiUSMjgDmo cKLYH1IbNoEXsCiT2mOlgpXVw15qKPHphueBXVe5jt7F5B+fjY9pOnovUeQ++CCWwmk0 BBfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rJcbkrStzy5Aarrq1x88zqAfwKXatoVg3GxyruSHMLI=; b=44og/uu6RzEg+qZvJfXn1MyjNuV2SM4XFmJnUZAkmtVp6fDt3xLah5agZgGqRpxtga E1yZmuVj1pzyD1VrTu96p+vjnMjLkVsiq2Cwco3tj0q/uLYae8mfpVypB/LhHXP7tcXG b7XTLFEj1BtwEX8zn5A/W4AnR9xWNXzzv0BesQ/sVR90PmT1GVLs9XUeOccyS2F0qmVh v6gb3ZeAF1VlFRW5HEvAv6ooDYudpQ7W2QGLqAjdvUKqS6lr9IArrpOqhSgjw3FmRKdu yST99K2yJboo5KjnL/FMPrAL9+f5cwWYWFod12sH9bEJSHsEwKInpgUdx95j65fwFniv 5ERg== X-Gm-Message-State: AOAM53104PxKavpl1qloYR559Z/lMRFEPHdQKW1D0AfVVO98nMx8PMuu 6pIwKvVR1eBffumTjnXo6WVf2ZFf3BNA0LU7/62asSJvCCk= X-Google-Smtp-Source: ABdhPJz1D1B6P8LqVHr74JstTKz8GKfAkXNYse01ZIE9Lbt4C047w/GfC4+yX/BOACiGGuxxZZIdghnHJn5pFKNTDBo= X-Received: by 2002:a25:348b:: with SMTP id b133mr8199236yba.264.1633258529959; Sun, 03 Oct 2021 03:55:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Sun, 3 Oct 2021 06:55:18 -0400 Message-ID: To: Greg Mirsky Cc: Martin Duke , IETF IPPM WG Content-Type: multipart/alternative; boundary="00000000000081caf905cd70a27f" Archived-At: Subject: Re: [ippm] New chair! 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, 03 Oct 2021 10:55:39 -0000 --00000000000081caf905cd70a27f Content-Type: text/plain; charset="UTF-8" Thank you very much for your kind words. I greatly value your opinion and your contributions to the group. Ian On Sat, Oct 2, 2021 at 11:39 AM Greg Mirsky wrote: > Thank you, Ian, for your guidance and work in the IPPM WG. It was a > pleasure and privilege working with you. > > Welcome, Marcus! > > Regards, > Greg > > > > On Fri, Oct 1, 2021 at 10:04 AM Martin Duke > wrote: > >> Greetings IPPM! >> >> I'm pleased to announce that Marcus Ihlar is joining IPPM as our newest >> chair. Ian Swett is stepping down for various reasons, I'd like to thank >> him for his efforts to move the WG forward over the past year and a half. >> >> We will run with three chairs at IETF 112, after which Ian will formally >> depart. >> >> Welcome Marcus! >> Martin >> _______________________________________________ >> 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 > --00000000000081caf905cd70a27f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much for your kind words.=C2=A0 I greatly v= alue your opinion and your contributions to the group.

I= an

On Sat, Oct 2, 2021 at 11:39 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Thank you, Ian,= for your guidance and work in the IPPM WG. It was a pleasure=C2=A0and priv= ilege working with you.

Welcome, Marcus!

<= /div>
Regards,
Greg



On= Fri, Oct 1, 2021 at 10:04 AM Martin Duke <martin.h.duke@gmail.com> wrote:
<= /div>
Greetings IPPM!

I'm pleased to announce that= Marcus Ihlar is joining IPPM as our newest chair. Ian Swett is stepping do= wn for various reasons, I'd like to thank him for his efforts to move t= he WG forward over the past year and a half.

We wi= ll run with three chairs at IETF 112, after which Ian will formally depart.=

Welcome Marcus!
Martin
_______________________________________________
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
--00000000000081caf905cd70a27f-- From nobody Sun Oct 3 04:43:57 2021 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 E7BD53A083C; Sun, 3 Oct 2021 04:43:15 -0700 (PDT) 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: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163326139586.4733.17378783495922173599@ietfa.amsl.com> Date: Sun, 03 Oct 2021 04:43:15 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-data-15.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: Sun, 03 Oct 2021 11:43:17 -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 : Data Fields for In-situ OAM Authors : Frank Brockners Shwetha Bhandari Tal Mizrahi Filename : draft-ietf-ippm-ioam-data-15.txt Pages : 48 Date : 2021-10-03 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. This document discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be encapsulated into a variety of protocols such as NSH, Segment Routing, Geneve, or IPv6. In-situ OAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-data-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 3 05:40:55 2021 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 A19F03A0896; Sun, 3 Oct 2021 05:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPt4dogPArj5; Sun, 3 Oct 2021 05:40:44 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA353A089B; Sun, 3 Oct 2021 05:40:43 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id b136-20020a1c808e000000b0030d60716239so2767701wmd.4; Sun, 03 Oct 2021 05:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8FG572exjC6WzqFxfPMwrJEE21BQBNNrrzp9WQmPCA=; b=a+Pz02nV3WrNMqzGj2dGGkvl0tufzUI4PS6ihp195H66CxjL99guDkV5Au2ft9yvZy /BHL/t3za3NUb2IbJ/8LTYA2O0TrFpURj5LKY259+gbJXk/pwI8n9951xiUIbSdcfMXM HjLxWAw0S1FbTqd5gFVNxeRXsblQN7YLsR8VTw5C8o/7oSs1GafycEKf5WMGhXyHArJZ KMRneb5WzKsA1eM5FpCeh8w7K7sLCX2k+Rf+OYC9DC6J6CjqkdacXX16pCuP3kw9ONFN ezgutbt/VM9qQvA8T4YbscZLsGVyGtlPVEhu2AP+0/PeBHnMhMA3R406qRTtTgPJh8v5 DaUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y8FG572exjC6WzqFxfPMwrJEE21BQBNNrrzp9WQmPCA=; b=TWfWR24HBl6Ysv+Oq76+m+dfuRpn5svMVA6F6s74LSeJJ9VCCHez0/fiiJLYcnJvO4 OjqrZygDJR3NPCkwUAQNphhqL1qBFfLLRsQHQ2ZRukiE9o9VmdozEYhnjkh8M6seMyhV xXNTj2U0DzjAztwZTz10i9mNi8CqxCts0ePy2C9r/RlHzoXCykzZpc3JfMdzlr8mH8N7 I76BFlicLag5ujGco2qe+6dLrNGBMCkThUAyPPho8pU+ldPGBqJGOq49/KS4gY+dhDyB rdtR/4R9TwiTWkA+6kXsvsFwYwZ05xZ0ba7ozLBC+CB7oJuGwsgzjWnAR7FvxreJauFy gP+A== X-Gm-Message-State: AOAM531/aMBmqTJXza62XtfxYbjYSlkKbbJfXPRVFNP1s6zuqpwZWQT9 UWUCr+OgjscZZvlmEEE265+cTK88sfph7x9IIGFL1s7eC3XJpNNc X-Google-Smtp-Source: ABdhPJyUISgGgM4a86f+3lZ3aZVMgmpmWWFwls8FHb189T2RwWK9Fnpxj+eH53ho2YSFX4+j/X0kXFMc2K/okYFgvXs= X-Received: by 2002:a7b:cc18:: with SMTP id f24mr13877128wmh.8.1633264841669; Sun, 03 Oct 2021 05:40:41 -0700 (PDT) MIME-Version: 1.0 References: <163063564823.15336.14662092029682255691@ietfa.amsl.com> In-Reply-To: <163063564823.15336.14662092029682255691@ietfa.amsl.com> From: Tal Mizrahi Date: Sun, 3 Oct 2021 15:40:29 +0300 Message-ID: To: Bernard Aboba , IPPM Chairs Cc: tsv-art@ietf.org, draft-ietf-ippm-ioam-flags.all@ietf.org, IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [ippm] Tsvart early review of draft-ietf-ippm-ioam-flags-06 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, 03 Oct 2021 12:40:51 -0000 Dear Bernard, Many thanks for the thorough review. Please see the responses and text update suggestions below, marked with [TM]. Please let us know if there are any further comments. On Fri, Sep 3, 2021 at 5:20 AM Bernard Aboba via Datatracker wrote: > > Reviewer: Bernard Aboba > Review result: Ready with Issues > > Transport Area Review Team (TSV-ART) > Document: draft-ietf-ppm-ioam-flags-06 > Reviewer: Bernard Aboba > Verdict: Ready with Issues > > Overall comment > > The review request indicated: > "Please review this document, specifically for security considerations around > amplification attacks or similar concerns." > > Indeed, the amplification attacks do appear to be an important potential issue > with the document. > > In Section 8 it is stated: > > " IOAM is assumed to be deployed in a restricted administrative domain, > thus limiting the scope of the threats above and their affect. This > is a fundamental assumtion with respect to the security aspects of" > > While this is a common argument, it does not impress me, particularly now that > security breaches have become so common. So I'd prefer to start from the > assumption that the administrative domain will eventually be breached. > > For example, one might start from the assumption that: > > 1. An attacker can find a way to inject packets with one or more of the flags > defined in the document set to a value of their choosing. 2. An attacker can > compromise the firmware load of an IOAM encapsulating node so as to affect > execution of > the algorithms defined in the document. > > Then based on these assumptions, see what mitigations can be added to minimize > the damage. > > For example, one might minimize the damage by adding a mandatory-to-implement > "circuit breaker". > [TM] You make a valid point regarding the basic assumption and how it is described. The following text edit is proposed: OLD: An attacker may attempt to overload network devices by injecting synthetic packets that include an IOAM Trace Option with one or more of the flags defined in this document. Similarly, an on-path attacker may maliciously set one or more of the flags of transit packets. ... IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the threats above and their affect. This is a fundamental assumtion with respect to the security aspects of IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. NEW: IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the threats above and their effect. This is a fundamental assumption with respect to the security aspects of IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. However, despite this assumption, security threats should still be considered and mitigated. Specifically, an attacker may attempt to overload network devices by injecting synthetic packets that include an IOAM Trace Option with one or more of the flags defined in this document. Similarly, an on-path attacker may maliciously set one or more of the flags of transit packets. ... END Then, the rest of this section (marked by "..." above), as currently structured, provides more details about the threats and mitigations. The "circuit breaker" sounds like it may create a DoS threat. The currently proposed mitigation methods are intended to limit the impact of a potential attack, but not to "break" anything. > Overall, it seems like the aspect of most concern is the Loopback Flag, which > seems like it offers significant magnification potential. > > Comments on individual sections > > Section 4.1 > > The reason for allowing a > single data field per hop is to minimize the impact of amplification > attacks. > > [BA] This will be effective if we can assume that nodes are running compliant > firmware. But what if an attacker can run firmware of their choosing? What are > the mitigations that can be applied by a node if it detects that another node > is adding more than one data field per hop? > [TM] Right. Suggested text: OLD: An IOAM trace option that has the Loopback flag set MUST have the value '1' in the most significant bit of IOAM-Trace-Type, and '0' in the rest of the bits of IOAM-Trace-Type. Thus, every transit node that processes this trace option only adds a single data field, which is the Hop_Lim and node_id data field. The reason for allowing a single data field per hop is to minimize the impact of amplification attacks. NEW: An IOAM trace option that has the Loopback flag set MUST have the value '1' in the most significant bit of IOAM-Trace-Type, and '0' in the rest of the bits of IOAM-Trace-Type. Thus, every transit node that processes this trace option only adds a single data field, which is the Hop_Lim and node_id data field. A transit node that receives a packet with an IOAM trace option that has the Loopback flag set and the IOAM-Trace-Type is not equal to '1' in the most significant bit and '0' in the rest of the bits, MUST NOT loop back a copy of the packet. The reason for allowing a single data field per hop is to minimize the impact of amplification attacks. > Section 4.1.1 > > If an IOAM encapsulating node incorporates the Loopback flag into all > the traffic it forwards it may lead to an excessive amount of looped > back packets, which may overload the network and the encapsulating > node. Therefore, an IOAM encapsulating node that supports the > Loopback flag MUST support the ability to incorporate the Loopback > flag selectively into a subset of the packets that are forwarded by > it. > > [BA] This MUST is a fairly basic capability (e.g. a lot of damage can be > done even by nodes obeying this requirement). It seems like more should > be required. [TM] Right, and the rest of Section 4.1.1. indeed specifies more functionality that mitigates these amplification attacks. > > Various methods of packet selection and sampling have been previously > defined, such as [RFC7014] and [RFC5475]. Similar techniques can be > applied by an IOAM encapsulating node to apply Loopback to a subset > of the forwarded traffic. > > The subset of traffic that is forwarded or transmitted with a > Loopback flag SHOULD NOT exceed 1/N of the interface capacity on any > of the IOAM encapsulating node's interfaces. It is noted that this > requirement applies to the total traffic that incorporates a Loopback > flag, including traffic that is forwarded by the IOAM encapsulating > node and probe packets that are generated by the IOAM encapsulating > node. In this context N is a parameter that can be configurable by > network operators. If there is an upper bound, M, on the number of > IOAM transit nodes in any path in the network, then it is recommended > to use an N such that N >> M. The rationale is that a packet that > includes the Loopback flag triggers a looped back packet from each > IOAM transit node along the path for a total of M looped back > packets. Thus, if N >> M then the number of looped back packets is > significantly lower than the number of data packets forwarded by the > IOAM encapsulating node. If there is no prior knowledge about the > network topology or size, it is recommended to use N>100. > > [BA] This is OK as far as it goes. But what happens if a node detects that > amplification is occurring somewhere (e.g. another node isn't obeying the > SHOULD NOT) Is a circuit breaker triggered? > [TM] In order for a node to detect that another node is malfunctioning some stateful monitoring functionality is required. We currently do not require this functionality, although an operator may choose to use various counters with threshold-based notifications to the management plane in specific locations in the network in order to detect such functionality. Not sure it would be useful to describe this in the document, as it seems like common practice. > Section 4.2 > > An IOAM node that supports the reception and processing of the > Loopback flag MUST support the ability to limit the rate of the > looped back packets. The rate of looped back packets SHOULD be > limited so that the number of looped back packets is significantly > lower than the number of packets that are forwarded by the device. > The looped back data rate SHOULD NOT exceed 1/N of the interface > capacity on any of the IOAM node's interfaces. It is recommended to > use N>100. Depending on the IOAM node's architecture considerations, > the loopback response rate may be limited to a lower number in order > to avoid loading the IOAM node. > > [BA] Here the SHOULD does not seem strong enough to me. If for example, > another node is forwarding more than 1/N, and this is detected, shouldn't > some mandatory circuit breaker be triggered? > > Section 5 > > If the volume of traffic that incorporates the Active flag is large, > it may overload the network and the IOAM node(s) that process the > active measurement packet. Thus, the rate of the traffic that > includes the Active flag rate SHOULD NOT exceed 1/N of the interface > capacity on any of the IOAM node's interfaces. It is recommended to > use N>100. Depending on the IOAM node's architecture considerations, > the rate of Active-enabled IOAM packets may be limited to a lower > number in order to avoid loading the IOAM node. > > [BA] Again, the SHOULD NOT does not seem strong enough to me. I'd suggest > that some kind of mandatory circuit breaker should be required. [TM] Regarding the last two comments, as mentioned above, we do not require an IOAM transit node to be able to detect when another IOAM node does not limit its rate. The assumption is that given that there *is* an attacker, the current node limits its rate in order to limit the impact of the attack and avoid amplifying the attack. However, the current node does not necessarily implement any monitoring or intrusion detection that reports potential attacks. > > NITs > > Abstract > > a path between two points in the network. This document defines two > new flags in the IOAM Trace Option headers, specifically the the > > s/the the/the/ [TM] Will be fixed. > > Section 8 > > IOAM is assumed to be deployed in a restricted administrative domain, > thus limiting the scope of the threats above and their affect. This > is a fundamental assumtion with respect to the security aspects of > > s/assumtion/assumption/ [TM] Will be fixed. > > IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. > > > Thanks, Tal. From nobody Mon Oct 4 00:14:48 2021 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 9E3C63A120D; Mon, 4 Oct 2021 00:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPAv2wS30khS; Mon, 4 Oct 2021 00:14:01 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4DACE3A078A; Mon, 4 Oct 2021 00:13:56 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id s21so28903348wra.7; Mon, 04 Oct 2021 00:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wCd+DAdKl8l2LJyO54oA2E1vNiUiQpC7Bzz1oVvc7hU=; b=YIiRwIKy4KTA00Iy4HgXgVH0Yu4/y5JF9fkNZcseJEfBJkMMNHO8KQ3e8juM6woDML QKxH0ovHJyAQYlIUOzNEA2AEsx0Fk81NUr2yPMjJrLIFIjiXKx1id8eoi9iUqu8e6J8B RSbrrNXIzEaCnltKXP5BWR1NG8jI5VV1GaQxpDfj8sGVzZQUlwIQESy5UKowz01EXGLk H0HwI8v5naqWyFNCHCBQufL7Piu6IGz/YdOM8JE/PRZI0sg5siUqXtN+mrWzNS1Wr62/ k6eNpQRI3oh63hm2PsZqiqSMTIYCuoawm9mI3+jWph+6jwu3pDRAcFiT23a9mH5TzZrb ZoXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wCd+DAdKl8l2LJyO54oA2E1vNiUiQpC7Bzz1oVvc7hU=; b=FNAZX44BoS70yX+uv1mxj+jWZ3zJRnmjI2WRtyueKpTxs98Qn2SUnGKVRFyBDDMpc/ R79QQ+0ZaorHAE8IcokMEKS5VdyfH2YyEieYvGmelnVkO03CYgBU3UpPmA0zAVSfpQGx P7CaqMyASMdzBDhzk0147Adqk0sNGt07JEjfsctttNNcmxgFnzFw5iBoF3cbWoAjN/5l U/9Lf1wOoQLQKY62KgBT5iVYEjoPAW0CCbq3jDBXGNxrfZ5n9RsyJxCY35BjhIcySaiq G3DjNcZsS7cB4GWcs8MlJO6WYzWbjE1oLMEEerLOd4P2OciS+KoZDFexaQK4ocl1GpKI ydFg== X-Gm-Message-State: AOAM533j2XRSt9+EuoJzmL+7EhyGZPO7zPj7+/dECpCZ+ZqrA1k/SMLn w8246BPYeYINLVjPjTuA1eZdtJLXO2P760MstLmXtThMJqtgWTFJ X-Google-Smtp-Source: ABdhPJz1JlN3sMGGVlGcMHwWpjWReI4KxS4AXKhDa1/2bAAjmFjel3wQqAvmqQoisZlXRq9VmW/HaElWqPUq3pBKgDg= X-Received: by 2002:a5d:6d8e:: with SMTP id l14mr11951099wrs.26.1633331634569; Mon, 04 Oct 2021 00:13:54 -0700 (PDT) MIME-Version: 1.0 References: <163068085282.8497.2281892161766368778@ietfa.amsl.com> In-Reply-To: <163068085282.8497.2281892161766368778@ietfa.amsl.com> From: Tal Mizrahi Date: Mon, 4 Oct 2021 10:13:43 +0300 Message-ID: To: Colin Perkins , IPPM Chairs Cc: tsv-art@ietf.org, draft-ietf-ippm-ioam-direct-export.all@ietf.org, IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [ippm] Tsvart early review of draft-ietf-ippm-ioam-direct-export-06 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, 04 Oct 2021 07:14:30 -0000 Dear Colin, Thanks for the feedback. Please see below a comment and a question regarding your feedback. On Fri, Sep 3, 2021 at 5:54 PM Colin Perkins via Datatracker wrote: [snip] > It may be worth considering to require the exporting mechanism to perform an > authenticated handshake with the destination to which it will export data, to > gain explicit consent to export the data to that destination, before starting > to send exported data. [TM] The point is well-taken. The following text edit is proposed, borrowing some of the text from your comment: OLD: Although the exporting method is not within the scope of this document, any exporting method MUST secure the exported data from the IOAM node to the receiving entity. Specifically, an IOAM node that performs DEX exporting MUST send the exported data to a pre- configured trusted receiving entity. NEW: Although the exporting method is not within the scope of this document, any exporting method MUST secure the exported data from the IOAM node to the receiving entity. Specifically, an IOAM node that performs DEX exporting MUST send the exported data to a pre- configured trusted receiving entity. Furthermore, an IOAM node MUST gain explicit consent to export data to a receiving entity before starting to send exported data. > It may also be worth considering to add authentication > of IOAM DEX triggers, to ensure they come from a known and trusted source, > before acting on export requests. > [TM] Can you please clarify what you mean by "add authentication of IOAM DEX triggers"? What is the threat that you have in mind? Thanks, Tal. From nobody Wed Oct 6 16:30:40 2021 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 265A63A0A60; Wed, 6 Oct 2021 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2vI09ZodSoo; Wed, 6 Oct 2021 16:30:28 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74F53A0A64; Wed, 6 Oct 2021 16:30:27 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id g10so15463413edj.1; Wed, 06 Oct 2021 16:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DyWtm6VQ1DeQEMATbLmGyzyKAmUd18yvpwnh0SqFlaw=; b=J/6EB5G6u35yl8F15Cua4QgkSk7GzZl3SjA6fPptKDr8/1DEdo47C95Bv4PtUuyKXz B+geCP7rPAkis4fy1IIAKMelGq200s+JHClScyClONwyVIDYyljsxmas+mnaBKQ/erzX A3wh20wNG6Thn8Ykr2kaCKrEgSgGbqhGtmft7OpeUKFtBG2Y2RW6rZuQiC2Z7QV+VFC2 8aYQthCmra2nLUfF/56ifjyFzzR8LDnZQkz8fruDphLOAGu0Pd2tDmC/q5ezaTTKWUIL FFHb8HTXbtit8j0rREGxW+XyOxuZToRk4vpFe02DAb+IzI2GyeaiphMqx2sMx/jPXD/v 4D4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DyWtm6VQ1DeQEMATbLmGyzyKAmUd18yvpwnh0SqFlaw=; b=o+agJD58PySlMdM+XIFHwPqiATYXKm7vFnlCThMj2horKioakvVw6FEfsFhofvCMJu 5uqFainqAHLRNKBj/eLOQHJCfWbKPCQBDp9qeq6lZGhOkVj0+VXu6GEu67ZpKen9ifew oozW7+erTLTI4Cp/GjBe9A4QmLfeDiZkmQGTmIusDpRHg/v+OBUI1SIqBIMkAsoaHhld YtBeWN66UAEvZf7ATPoxsAjhwJZccxTIfTXEM+5OYdd34RFfvhCIAmv1W83PKa5tzwHa 7pWu7Nxb7E0trZPEQmZwfWDiZ646MTh9YyV5ZQ1JxHml+/w/dCIOvZ66d+FRt1CAi+Kg KK+A== X-Gm-Message-State: AOAM533DYFVAHrkugbskTKt0ChihJTxwlO7VVP0lxIUFvw+S1KZX9NuD I4jYQIZo/ipi+LOfR3t6BGSHVLK9DF1x3aoFrPmjOb5/t/M= X-Google-Smtp-Source: ABdhPJzvxAhsVSw8rZS5W8VNDGV4zkRtukP3bterxmYOmppllu/O2RRQXpSVH6mA9EOmEoNMtAIoanQtMv4PBhNeJWw= X-Received: by 2002:a17:906:369a:: with SMTP id a26mr1302204ejc.539.1633563025613; Wed, 06 Oct 2021 16:30:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 6 Oct 2021 16:30:15 -0700 Message-ID: To: Tal Mizrahi Cc: Tommy Pauly , IPPM Chairs , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000dc276d05cdb7878e" Archived-At: Subject: Re: [ippm] WGLC for IOAM Direct Exports 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, 06 Oct 2021 23:30:34 -0000 --000000000000dc276d05cdb7878e Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for your kind consideration of my comments and constructive proposals. Please find my notes in-lined below under the GIM>> tag. Regards, Greg On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi wrote: > Hi Greg, > > Many thanks for the thorough review. > Below you can find responses to your comments, and in some cases > proposed text edits. > > If there are no further comments we will update the document accordingly. > > Thanks, > The authors. > > > On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky wrote: > > > > Dear Authors, WG Chairs, and All, > > I've read the latest version of the draft and have several comments and > questions to share with you. None of these are blocking, I support > progressing this draft to publication. Please consider the notes below as > an invitation to a discussion: > > > > It seems that the characterization of the Direct Export IOAM option in > the following is not entirely accurate: > > > > The DEX option is used as a trigger to collect and/or export IOAM data. > > > > I propose re-wording: > > The DEX option is used as a trigger to collect and export or only > collect locally the IOAM data. > > > > Using "exporting and/or collecting" reflects the use of the Direct > Export option type technically accurate but the order of actions is > backward. What are your thoughts? > > > > [TM] Right. The following text edit is proposed in the introduction. > > OLD: > This option is used as > a trigger for IOAM nodes to locally aggregate and process IOAM data, > and/or to export it to a receiving entity (or entities). > NEW: > This option is used as > a trigger for IOAM nodes to locally aggregate and process IOAM data, > and/or to export it to a receiving entity (or entities). Throughout > the document this functionality is referred to as collection and/or > exporting. > GIM>> Thank you, the new text is very helpful. > > > > I find references to RFC 5475 and 7014 very appropriate and helpful. But > I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data. I > think that excessive use of not only the Direct Export IAOM option but the > IOAM method, in general, may adversely affect a network and the > recommendations listed in RFC 5475 and 7014 are equally applicable. > > Similarly, the good and helpful discussion of how to practically control > the use of the Direct Export option is, in my opinion, equally applicable > to other IOAM trace options and should be in the Security Considerations > section of draft-ietf-ippm-ioam-data. > > > [TM] The last two comments are about draft-ietf-ippm-ioam-data, which > is currently in IESG review. I will take this feedback with the other > authors to see how we can address this input at this point. > GIM>> Thank you. > > > > The second paragraph in Section 3.1.2 is re-phrasing if not repeating > what is already expressed in the last paragraph of the previous sub-section > (though the limit is applied to exporting telemetry information). I think > that it can be removed without any loss to the document. > > [TM] The second par of 3.1.2 refers to *exporting*, while the last par > of 3.1.1 refers to *encapsulating*, so these are two complementary > requirements. > GIM>> Thank you for clarifying that to me. > > > > I think that it will be helpful to provide some recommendations, i.e., > SHOULD do this, how an implementation handles the excess of packets to > export. Drop silently, drop and log notification, or try to shape that flow? > > [TM] Assuming an amplification scenario, a large number of packets may > be dropped, so logging each drop may defeat the purpose. A drop > counter may be a good idea here, but this document does not really > define counter requirements in general, so it seems like more of an > implementation-specific aspect, or possibly can be considered as part > of the YANG model. > GIM>> I think that logging a warning with the throttling control is a good option. What is your opinion? A counter of throttled DEX packets is helpful. Perhaps both mechanisms can be recommended. > > > I was really puzzled by this requirement in Section 3.1.2 > > > > Exported packets SHOULD NOT be exported over a path or a tunnel that > > > > is subject to IOAM direct exporting. > > > > I hope you can clarify it for me. > > > [TM] As explained later in that paragraph: "This requirement is > intended to prevent nested exporting and/or exporting loops." > This was thoroughly discussed in the working group, and came out of > the security-related review. > GIM>> As I understand IOAM DEX, packets with telemetry information are out-of-band relative to the monitored data flow and encapsulated to avoid being taken for an IOAM packet. I imagine that exported telemetry data can be collected via, for example, Kafka or gRPC. Am I missing something? > > > > > This requirement > > > > Furthermore, IOAM encapsulating > > nodes that can identify a packet as an IOAM exported packet MUST NOT > > push a DEX option into such a packet. > > brings up questions: > > > > How can a node identify a packet as the IOAM exported packet? > > [TM] The requirement means that if an encapsulating node's ACL can > detect exported packets, then DEX should not be applied. > GIM>> Please consider my previous note. I understand that that gets very close to an implementation choice but it seems that the document should be clear in its normative statements. > > > What should be done if the IOAM exported packet contains the IOAM header > with the DEX option? > > [TM] The current document does not require an IOAM transit node to > parse beyond the (external) IOAM encapsulation if there are nested > IOAM encapsulations. > GIM>> I have to admit that I'm lost with the reference to an "external IOAM encapsulation". What is the purpose of using IOAM in the exported packet? > > > > > What is special about the decapsulating node that is not DEX-capable? > > > > A decapsulating node that does not support the DEX option > > MUST remove it, along with any other IOAM options carried in the > > packet if such exist. > > Shouldn't that be a general behavior of a decapsulating IOAM node? > > [TM] Right. The following text edit is proposed: > > OLD: > A transit IOAM node that does not support the DEX option SHOULD > ignore it. A decapsulating node that does not support the DEX option > MUST remove it, along with any other IOAM options carried in the > packet if such exist. > NEW: > A transit or decapsulating IOAM node that does not support the DEX > option SHOULD > ignore it. Note that as per a > decapsulating node removes the IOAM encapsulation and all its IOAM > options, > and specifically in the case where one of these options is a > (possibly unknown) > DEX option. > GIM>> What could be an alternative to ignoring IOAM DEX option? I feel that MUST is what is required here. Would you agree? > > > > > > The format of the first four-octet word in Figure 2 is different from > the format defined in draft-ietf-ippm-ioam-data: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Namespace-ID |NodeLen | Flags | RemainingLen| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IOAM-Trace-Type | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Is this intentional? If it is, how does an implementation know which > format to use? > > [TM] Each IOAM Option-Type has a different header format. The current > document defines a new Option-Type, which was not defined in > draft-ietf-ippm-ioam-data. > The IOAM-Type field in the lower layer header determines which > Option-Type is used and how its header should be parsed. > GIM>> How does an IOAM node differentiate between different Option-Types? Is that expected to be communicated to an IOAM node over the management or control plane and not part of the IOAM encapsulation? If that is the case, then, I imagine, changing between IOAM tracing modes will require reconfiguration of all IOAM nodes. Doesn't seem operationally friendly. > > > > > > It is stated in the draft that: > > > > The length of the DEX option is at least 8 octets. > > > > But the figure 2 in the draft does not include any field that reflects > the length of the IOAM option. Is that because the figure is out of sync? > If not, how can an implementation verify the length? Also, what is the > behavior if the length is less than 8 octets? > > > > [TM] Quoting the draft: > > The existence of the optional fields is > indicated by the corresponding flags in the Extension-Flags field. > ... > Thus, the Extension-Flags field explicitly indicates > the length of the DEX option. > > > > RE: PerformanceConsiderations > > > > I agree with you that a DEX-encapsulating node and DEX-transit nodes > must have rate-limiting controls (as noted earlier, the behavior of the > transit node needs more detailed specification). But I think that the > document should also note that exported packets could be sent over the > network out-of-band, relative to the monitored flow. As a result, the > impact of packets carrying telemetry information might be not direct and > harmful to the data flow. I see that as one of the important benefits of > the Direct Export method transporting on-path telemetry information. > > > > [TM] Right. The following new text is proposed: > > It should be noted that in some networks DEX data may be exported over > an out-of-band network, in which a large volume of exported traffic > does not compromise user traffic. In this case an operator may choose > to disable the exporting rate limiting. > GIM>> Thank you for the proposed update. I thought that the main advantage of the IOAM DEX mode is the ability to export the telemetry information out-of-band. And, as I've noted above, the mechanism to collect and transport the telemetry is outside the scope of this specification. I think that would significantly simplify the document without any adverse impact on the value it provides. > > > > > Regards, > > Greg > > > > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> > >> Hello IPPM, > >> > >> This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags and > draft-ietf-ippm-ioam-direct-export. > >> > >> In-situ OAM Loopback and Active Flags > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > >> > >> In-situ OAM Direct Exporting > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 > >> > >> Please provide feedback by replying to this email with your reviews and > if you think these documents are ready to progress, by Wednesday, September > 15. > >> > >> Best, > >> Tommy & Ian > >> > >> _______________________________________________ > >> 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 > --000000000000dc276d05cdb7878e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal,
thank you for your kind consi= deration of my comments and constructive proposals. Please find my notes in= -lined below under the GIM>> tag.

Regards,
Greg

On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wro= te:
Hi Greg,

Many thanks for the thorough review.
Below you can find responses to your comments, and in some cases
proposed text edits.

If there are no further comments we will update the document accordingly.
Thanks,
The authors.


On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Authors, WG Chairs, and All,
> I've read the latest version of the draft and have several comment= s and questions to share with you. None of these are blocking, I support pr= ogressing this draft to publication. Please consider the notes below as an = invitation to a discussion:
>
> It seems that the characterization of the Direct Export IOAM option in= the following is not entirely accurate:
>
> The DEX option is used as a trigger to collect and/or export IOAM data= .
>
> I propose re-wording:
> The DEX option is used as a trigger to collect and export or only coll= ect locally the IOAM data.
>
> Using "exporting and/or collecting" reflects the use of the = Direct Export option type technically accurate but the order of actions is = backward. What are your thoughts?
>

[TM] Right. The following text edit is proposed in the introduction.

OLD:
=C2=A0 =C2=A0This option is used as
=C2=A0 =C2=A0a trigger for IOAM nodes to locally aggregate and process IOAM= data,
=C2=A0 =C2=A0and/or to export it to a receiving entity (or entities).
NEW:
=C2=A0 =C2=A0This option is used as
=C2=A0 =C2=A0a trigger for IOAM nodes to locally aggregate and process IOAM= data,
=C2=A0 =C2=A0and/or to export it to a receiving entity (or entities). Throu= ghout
=C2=A0 =C2=A0the document this functionality is referred to as collection a= nd/or
exporting.
GIM>> Thank you, the new text is very= helpful.=C2=A0


> I find references to RFC 5475 and 7014 very appropriate and helpful. B= ut I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data= . I think that excessive use of not only the Direct Export IAOM option but = the IOAM method, in general, may adversely affect a network and the recomme= ndations listed in RFC 5475 and 7014 are equally applicable.
> Similarly, the good and helpful discussion of how to practically contr= ol the use of the Direct Export option is, in my opinion, equally applicabl= e to other IOAM trace options and should be in the Security Considerations = section of draft-ietf-ippm-ioam-data.


[TM] The last two comments are about draft-ietf-ippm-ioam-data, which
is currently in IESG review. I will take this feedback with the other
authors to see how we can address this input at this point.
GIM>> Thank you.=C2=A0


> The second paragraph in Section 3.1.2 is re-phrasing if not repeating = what is already expressed in the last paragraph of the previous sub-section= (though the limit is applied to exporting telemetry information). I think = that it can be removed without any loss to the document.

[TM] The second par of 3.1.2 refers to *exporting*, while the last par
of 3.1.1 refers to *encapsulating*, so these are two complementary
requirements.
GIM>> Thank you for clarifying tha= t to me.=C2=A0


> I think that it will be helpful to provide some recommendations, i.e.,= SHOULD do this, how an implementation handles the excess of packets to exp= ort. Drop silently, drop and log notification, or try to shape that flow?
[TM] Assuming an amplification scenario, a large number of packets may
be dropped, so logging each drop may defeat the purpose. A drop
counter may be a good idea here, but this document does not really
define counter requirements in general, so it seems like more of an
implementation-specific aspect, or possibly can be considered as part
of the YANG model.
GIM>> I think that logging a = warning with the throttling control is a good option. What is your opinion?= A counter of throttled DEX packets is helpful. Perhaps=C2=A0both mechanism= s can be recommended.

>
> This requirement
>
>=C2=A0 =C2=A0 Furthermore, IOAM encapsulating
>=C2=A0 =C2=A0 nodes that can identify a packet as an IOAM exported pack= et MUST NOT
>=C2=A0 =C2=A0 push a DEX option into such a packet.
> brings up questions:
>
> How can a node identify a packet as the IOAM exported packet?

[TM] The requirement means that if an encapsulating node's ACL can
detect exported packets, then DEX should not be applied.
GIM>> Please consider my previous note. I understand that that get= s very close to an implementation choice but it seems that the document sho= uld be clear in its normative statements.=C2=A0

> What should be done if the IOAM exported packet contains the IOAM head= er with the DEX option?

[TM] The current document does not require an IOAM transit node to
parse beyond the (external) IOAM encapsulation if there are nested
IOAM encapsulations.
GIM>> I have to admit that = I'm lost with the reference to an "external IOAM encapsulation&quo= t;. What is the purpose of using IOAM in the exported packet?

>
> What is special about the decapsulating node that is not DEX-capable?<= br> >
>=C2=A0 =C2=A0 A decapsulating node that does not support the DEX option=
>=C2=A0 =C2=A0 MUST remove it, along with any other IOAM options carried= in the
>=C2=A0 =C2=A0 packet if such exist.
> Shouldn't that be a general behavior of a decapsulating IOAM node?=

[TM] Right. The following text edit is proposed:

OLD:
=C2=A0 =C2=A0A transit IOAM node that does not support the DEX option SHOUL= D
=C2=A0 =C2=A0ignore it.=C2=A0 A decapsulating node that does not support th= e DEX option
=C2=A0 =C2=A0MUST remove it, along with any other IOAM options carried in t= he
=C2=A0 =C2=A0packet if such exist.
NEW:
=C2=A0 =C2=A0A transit or decapsulating IOAM node that does not support the= DEX
option SHOULD
=C2=A0 =C2=A0ignore it.=C2=A0 Note that as per <xref target=3D"I-D.= ietf-ippm-ioam-data"/> a
=C2=A0 =C2=A0decapsulating node removes the IOAM encapsulation and all its = IOAM options,
=C2=A0 =C2=A0and specifically in the case where one of these options is a (possibly unknown)
=C2=A0 =C2=A0DEX option.
GIM>> What could be an = alternative to ignoring IOAM DEX option? I feel that MUST is what is requir= ed here. Would you agree?


>
> The format of the first four-octet word in Figure 2 is different from = the format defined in draft-ietf-ippm-ioam-data:
>
>=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A03
>=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5= 6 7 8 9 0 1
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 Namespace-ID=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|NodeLen=C2=A0 | Flags | RemainingLen|
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= OAM-Trace-Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
> Is this intentional? If it is, how does an implementation know which f= ormat to use?

[TM] Each IOAM Option-Type has a different header format. The current
document defines a new Option-Type, which was not defined in
draft-ietf-ippm-ioam-data.
The IOAM-Type field in the lower layer header determines which
Option-Type is used and how its header should be parsed.
GIM>> How does an IOAM node differentiate between different Option= -Types? Is that expected to be communicated to an IOAM node over the manage= ment or control plane and not part of the IOAM encapsulation? If that is th= e case, then, I imagine, changing between IOAM tracing modes will require r= econfiguration of all IOAM nodes. Doesn't seem operationally friendly.<= /div>


>
> It is stated in the draft that:
>
> The length of the DEX option is at least 8 octets.
>
> But the figure 2 in the draft does not include any field that reflects= the length of the IOAM option. Is that because the figure is out of sync? = If not, how can an implementation verify the length? Also, what is the beha= vior if the length is less than 8 octets?
>

[TM] Quoting the draft:

=C2=A0 =C2=A0The existence of the optional fields is
=C2=A0 =C2=A0indicated by the corresponding flags in the Extension-Flags fi= eld.
=C2=A0 =C2=A0...
=C2=A0 =C2=A0Thus, the Extension-Flags field explicitly indicates
=C2=A0 =C2=A0the length of the DEX option.


> RE: PerformanceConsiderations
>
> I agree with you that a DEX-encapsulating node and DEX-transit nodes m= ust have rate-limiting controls (as noted earlier, the behavior of the tran= sit node needs more detailed specification). But I think that the document = should also note that exported packets could be sent over the network out-o= f-band, relative to the monitored flow. As a result, the impact of packets = carrying telemetry information might be not direct and harmful to the data = flow. I see that as one of the important benefits of the Direct Export meth= od transporting on-path telemetry information.
>

[TM] Right. The following new text is proposed:

It should be noted that in some networks DEX data may be exported over
an out-of-band network, in which a large volume of exported traffic
does not compromise user traffic. In this case an operator may choose
to disable the exporting rate limiting.
GIM>> Th= ank you for the proposed update. I thought that the main advantage of the I= OAM DEX mode is the ability to export the telemetry information out-of-band= . And, as I've noted above, the mechanism to collect and transport the = telemetry is outside the scope of this specification. I think that would si= gnificantly simplify the document without any adverse impact on the value i= t provides.=C2=A0

>
> Regards,
> Greg
>
> On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.o= rg> wrote:
>>
>> Hello IPPM,
>>
>> This email starts a Working Group Last Call on two related IOAM do= cuments, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export.=
>>
>> In-situ OAM Loopback and Active Flags
>> https://datatracker.ietf.org/do= c/draft-ietf-ippm-ioam-flags/
>> https://datatracker.ietf= .org/doc/html/draft-ietf-ippm-ioam-flags-06
>>
>> In-situ OAM Direct Exporting
>> https://datatracker.iet= f.org/doc/draft-ietf-ippm-ioam-direct-export/
>> https://datatrac= ker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06
>>
>> Please provide feedback by replying to this email with your review= s and if you think these documents are ready to progress, by Wednesday, Sep= tember 15.
>>
>> Best,
>> Tommy & Ian
>>
>> _______________________________________________
>> 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
--000000000000dc276d05cdb7878e-- From nobody Wed Oct 6 19:59:45 2021 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 59ED33A0A3B for ; Wed, 6 Oct 2021 19:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhXU2pXwwcoP for ; Wed, 6 Oct 2021 19:59:38 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 EA8DE3A0A34 for ; Wed, 6 Oct 2021 19:59:37 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id m21so4237234pgu.13 for ; Wed, 06 Oct 2021 19:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YdedtSPcUimTa+GCTTcoNh4r8iPvIRKzRr9BvLPBah4=; b=k0gaPamkqEZk5ALFxdc/3mv3e7aPB/yrRwm0As3MwRbCIBGpgLVrO/0uTddXbG1FZ7 t964kriNpKRydt26HQ1usZjuPPKCWI+h/sMw2zAsGGte8AaJNFxdkeu/MdUBdufnaKi/ rdbA3VEy20yOCh1jHxPiqvjU5CRynV72+KhnecrcJDW4q07UyprczVhlsnJNZsZFjCxZ DcJK7o4Xo/z2sAmy+pMzRzYY8okg6Ni7+O1YcAYORzuPXvOZCdPb9+2k5xljNPZfRtqk 8TUVFIEhdsutnOVK7Cv1PzWNw1ylfPJexQbw96xCSbKo6CDHNbSBQpp0KqzOyRR8gVDf EPrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YdedtSPcUimTa+GCTTcoNh4r8iPvIRKzRr9BvLPBah4=; b=8GyakFD8MQZvomCGC+mOUXkTnqkRx3mMbR6m6zKfKeXG2qYR1u1si7Tyy4izDFT3LG DE1DwI1hzsjaVREmuICFUHyu2tyE80ZBNTJhiBsfnDSmKv/y3DgLyvChETLWIxEiJfT1 njy3auX84zE4whH8kt/hrX409L7h0sN3E4GvMgsjc3qLhggogBec8NZ1sBGtIUU9mde0 GzibLqWapJNqyLL1rPtRwNHmKfvx4JrWsnN4JJ6rrps8Gg+3zvG1SG1uc65oa+hGi3C0 OpkrXKgocvfjzsRJG0Z1ATO3DoXdzp6URMOrPdXUDH59BGerx7IfDsL1k99gY4g3LGUX o0/Q== X-Gm-Message-State: AOAM531bBqfytnBaWSFqGiN01YQT5AwYf2zbnl3EWWwCh1Ns3v7Api3g dOH4OrnZcQig+pPbX4Wvkvxv+25Wx24= X-Google-Smtp-Source: ABdhPJxQCdcetD8eGg9QchlHBa5v3sTOVj2N7z31NxXA9wDote691aJCNoZxJ7uZx3MnjfEFbuFolg== X-Received: by 2002:a05:6a00:1a01:b0:44c:1ec3:364f with SMTP id g1-20020a056a001a0100b0044c1ec3364fmr1918356pfv.86.1633575577255; Wed, 06 Oct 2021 19:59:37 -0700 (PDT) Received: from smtpclient.apple ([2601:640:104:80fe:bce3:3077:1f77:8bcf]) by smtp.gmail.com with ESMTPSA id e12sm6712213pfl.67.2021.10.06.19.59.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 19:59:36 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5C193AD2-FE96-4215-A6BB-2E34AB2316D3 Content-Transfer-Encoding: 7bit From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Wed, 6 Oct 2021 19:59:35 -0700 Message-Id: References: Cc: "IETF IPPM WG (ippm@ietf.org)" In-Reply-To: To: Tommy Pauly X-Mailer: iPhone Mail (19A348) Archived-At: Subject: Re: [ippm] WGLC for IOAM Flags and Direct Exports 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, 07 Oct 2021 02:59:44 -0000 --Apple-Mail-5C193AD2-FE96-4215-A6BB-2E34AB2316D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes/support=20 Cheers, Jeff > =20 >=20 > On Mon, Aug 30, 2021 at 11:58 PM Tommy Pauly wrote: >=20 > Hello IPPM, >=20 > =20 >=20 > This email starts a Working Group Last Call on two related IOAM documents,= draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export. >=20 > =20 >=20 > In-situ OAM Loopback and Active Flags >=20 > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 >=20 > =20 >=20 > In-situ OAM Direct Exporting >=20 > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-0= 6 >=20 > =20 >=20 > Please provide feedback by replying to this email with your reviews and if= you think these documents are ready to progress, by Wednesday, September 15= . >=20 > =20 >=20 > Best, >=20 > Tommy & Ian >=20 > =20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail-5C193AD2-FE96-4215-A6BB-2E34AB2316D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Yes/support 

Cheers,
Jeff

 

On Mon, Aug 30, 2021 at 11:58 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:

Hello IPPM,

 

This email starts a Working Group Last Call on two related IOAM documents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export.

 

In-situ OAM Loopback and Active Flags

https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/

 

In-situ OAM Direct Exporting

 

Please provide feedback by replying to this email with your reviews and if you think these documents are ready to progress, by Wednesday, September 15.

 

Best,

Tommy & Ian

 

_______________________________________________
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
--Apple-Mail-5C193AD2-FE96-4215-A6BB-2E34AB2316D3-- From nobody Wed Oct 6 22:22:49 2021 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 6A0903A09D6; Wed, 6 Oct 2021 22:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 tZ1Fa5nUD9Uz; Wed, 6 Oct 2021 22:22:31 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 19B8E3A09E5; Wed, 6 Oct 2021 22:22:31 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id u18so15183285wrg.5; Wed, 06 Oct 2021 22:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2fTxSC64C3R6q3sxQy8LTN0DGSMFAU2UCjrT+boKPXw=; b=fiDVymnSVPUekoOBeizBwZ6EclAzq2rZVI83TsZZcogiB9j7YWMZESP0rr3pWapbOf xCOOqDFpat1cDTf30ORBQHQowLmqaDsmQ50DrZzV6KZfTBrMukfLFIFWtG7HjWJ76+xG SgNrq8CEf3agiOEzWJZa5lOqX4cp7tGG3cpTgqkeB6kk0ZtzwI7vF6qSvI8HTcBZvNaP Oy8YbpyGxMnj7fZyuD+cYTBGZoBJ9xtg7r6T1HePwcXf3FE/es5D11KWNBpzawH+mE5j L1lEwF+RhthZSLgHHUCCN6rTtmnGe8ilRULOAFwYSjZNfiTaBAfScg9PB94pwn9ALdui mJWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2fTxSC64C3R6q3sxQy8LTN0DGSMFAU2UCjrT+boKPXw=; b=EAUih+Z8bgMqagnFHNh3Duki9qMkNNvbfsepv7g2mNV0xW/duOQZ+kWaoQUzQU00UO BuF+BX4kDV0aqSh55k5ydYzMw+HuHnoEaqsWLRklvcZqPlg9qOlNCCnQm5nbavGPai7g G66QFJ8ln7dlm1HYVGqv8dxWicAcx0w5xYLlZqgfcdfr4FnBFnBbWJRk/e/1+SO4f3qQ daeNUha91Bo+fVWwJqUC1La4pvr7QWRxnt+HlNj93PHNtCuzu991eQMHV6TvYFpnYapI sXLyfPRzuxVCfTGh27dt8tGMgHHcXrWUMjey1pDei14qj3/It/4uMRtna4WiTKK06KjM 1Jyg== X-Gm-Message-State: AOAM533jxcUOQQj9T9ToHXknPST2sIcl6oH1loyUe7luUV7LtXPhs4tZ OSmkf6BuSu4M+Bqc65SJE9YR3GX0wTfqJVD2NeQ= X-Google-Smtp-Source: ABdhPJztzRgWGN5EuZu7KfpoPoXGirOdWW8LClLtmK09Z6MUeA5T53aZApTeyHLoUGT/mIETwKEQn5tPerFbwmSOMjo= X-Received: by 2002:a5d:6c65:: with SMTP id r5mr2744686wrz.26.1633584147404; Wed, 06 Oct 2021 22:22:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Thu, 7 Oct 2021 08:22:17 +0300 Message-ID: To: Greg Mirsky , IPPM Chairs Cc: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] WGLC for IOAM Direct Exports 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, 07 Oct 2021 05:22:47 -0000 Hi Greg, Thanks for the responses. Please see additional responses below marked with [[TM]]. If there are no further comments we will post an updated version. Cheers, Tal. On Thu, Oct 7, 2021 at 2:30 AM Greg Mirsky wrote: > > Hi Tal, > thank you for your kind consideration of my comments and constructive pro= posals. Please find my notes in-lined below under the GIM>> tag. > > Regards, > Greg > > On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi = wrote: >> >> Hi Greg, >> >> Many thanks for the thorough review. >> Below you can find responses to your comments, and in some cases >> proposed text edits. >> >> If there are no further comments we will update the document accordingly= . >> >> Thanks, >> The authors. >> >> >> On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky wrote= : >> > >> > Dear Authors, WG Chairs, and All, >> > I've read the latest version of the draft and have several comments an= d questions to share with you. None of these are blocking, I support progre= ssing this draft to publication. Please consider the notes below as an invi= tation to a discussion: >> > >> > It seems that the characterization of the Direct Export IOAM option in= the following is not entirely accurate: >> > >> > The DEX option is used as a trigger to collect and/or export IOAM data= . >> > >> > I propose re-wording: >> > The DEX option is used as a trigger to collect and export or only coll= ect locally the IOAM data. >> > >> > Using "exporting and/or collecting" reflects the use of the Direct Exp= ort option type technically accurate but the order of actions is backward. = What are your thoughts? >> > >> >> [TM] Right. The following text edit is proposed in the introduction. >> >> OLD: >> This option is used as >> a trigger for IOAM nodes to locally aggregate and process IOAM data, >> and/or to export it to a receiving entity (or entities). >> NEW: >> This option is used as >> a trigger for IOAM nodes to locally aggregate and process IOAM data, >> and/or to export it to a receiving entity (or entities). Throughout >> the document this functionality is referred to as collection and/or >> exporting. > > GIM>> Thank you, the new text is very helpful. >> >> >> >> > I find references to RFC 5475 and 7014 very appropriate and helpful. B= ut I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data. I = think that excessive use of not only the Direct Export IAOM option but the = IOAM method, in general, may adversely affect a network and the recommendat= ions listed in RFC 5475 and 7014 are equally applicable. >> > Similarly, the good and helpful discussion of how to practically contr= ol the use of the Direct Export option is, in my opinion, equally applicabl= e to other IOAM trace options and should be in the Security Considerations = section of draft-ietf-ippm-ioam-data. >> >> >> [TM] The last two comments are about draft-ietf-ippm-ioam-data, which >> is currently in IESG review. I will take this feedback with the other >> authors to see how we can address this input at this point. > > GIM>> Thank you. >> >> >> >> > The second paragraph in Section 3.1.2 is re-phrasing if not repeating = what is already expressed in the last paragraph of the previous sub-section= (though the limit is applied to exporting telemetry information). I think = that it can be removed without any loss to the document. >> >> [TM] The second par of 3.1.2 refers to *exporting*, while the last par >> of 3.1.1 refers to *encapsulating*, so these are two complementary >> requirements. > > GIM>> Thank you for clarifying that to me. >> >> >> >> > I think that it will be helpful to provide some recommendations, i.e.,= SHOULD do this, how an implementation handles the excess of packets to exp= ort. Drop silently, drop and log notification, or try to shape that flow? >> >> [TM] Assuming an amplification scenario, a large number of packets may >> be dropped, so logging each drop may defeat the purpose. A drop >> counter may be a good idea here, but this document does not really >> define counter requirements in general, so it seems like more of an >> implementation-specific aspect, or possibly can be considered as part >> of the YANG model. > > GIM>> I think that logging a warning with the throttling control is a goo= d option. What is your opinion? A counter of throttled DEX packets is helpf= ul. Perhaps both mechanisms can be recommended. [[TM]] The following new sentence is proposed to be added to Section 3.1.2: NEW: An IOAM node MAY maintain a counter or a set of counters that count the events in which the IOAM node receives a packet with the DEX option type and does not collect and/or export data due to the rate limits. >> >> >> > I was really puzzled by this requirement in Section 3.1.2 >> > >> > Exported packets SHOULD NOT be exported over a path or a tunnel tha= t >> > >> > is subject to IOAM direct exporting. >> > >> > I hope you can clarify it for me. >> >> >> [TM] As explained later in that paragraph: "This requirement is >> intended to prevent nested exporting and/or exporting loops." >> This was thoroughly discussed in the working group, and came out of >> the security-related review. > > GIM>> As I understand IOAM DEX, packets with telemetry information are ou= t-of-band relative to the monitored data flow and encapsulated to avoid bei= ng taken for an IOAM packet. I imagine that exported telemetry data can be = collected via, for example, Kafka or gRPC. Am I missing something? [[TM]] Right, the export encapsulation may be any of the methods you mentioned. However, if the export path runs through another IOAM domain it creates a nested IOAM scenario. This scenario was raised by Martin Duke in his security-related review, and we added this text in order to address this scenario. This also relates to the next comment (about pushing the DEX option onto exported packets). >> >> >> > >> > This requirement >> > >> > Furthermore, IOAM encapsulating >> > nodes that can identify a packet as an IOAM exported packet MUST NO= T >> > push a DEX option into such a packet. >> > brings up questions: >> > >> > How can a node identify a packet as the IOAM exported packet? >> >> [TM] The requirement means that if an encapsulating node's ACL can >> detect exported packets, then DEX should not be applied. > > GIM>> Please consider my previous note. I understand that that gets very = close to an implementation choice but it seems that the document should be = clear in its normative statements. >> >> >> > What should be done if the IOAM exported packet contains the IOAM head= er with the DEX option? >> >> [TM] The current document does not require an IOAM transit node to >> parse beyond the (external) IOAM encapsulation if there are nested >> IOAM encapsulations. > > GIM>> I have to admit that I'm lost with the reference to an "external IO= AM encapsulation". What is the purpose of using IOAM in the exported packet= ? [[TM]] My point was that in the scenario in which an exported packet is forwarded through an IOAM domain we do not expect IOAM transit nodes to detect this. We expect IOAM transit nodes to parse the outer encapsulation, but not beyond that. >> >> >> > >> > What is special about the decapsulating node that is not DEX-capable? >> > >> > A decapsulating node that does not support the DEX option >> > MUST remove it, along with any other IOAM options carried in the >> > packet if such exist. >> > Shouldn't that be a general behavior of a decapsulating IOAM node? >> >> [TM] Right. The following text edit is proposed: >> >> OLD: >> A transit IOAM node that does not support the DEX option SHOULD >> ignore it. A decapsulating node that does not support the DEX option >> MUST remove it, along with any other IOAM options carried in the >> packet if such exist. >> NEW: >> A transit or decapsulating IOAM node that does not support the DEX >> option SHOULD >> ignore it. Note that as per a >> decapsulating node removes the IOAM encapsulation and all its IOAM op= tions, >> and specifically in the case where one of these options is a >> (possibly unknown) >> DEX option. > > GIM>> What could be an alternative to ignoring IOAM DEX option? I feel th= at MUST is what is required here. Would you agree? [[TM]] Interesting point, because a node that does not support the DEX option does not comply to this document, and so the sentence we suggested would be pointless. I suggest the following text instead: NEW: A transit or decapsulating IOAM node that receives an unknown IOAM option type ignores it (as defined in ),= and specifically nodes that do not support the DEX option ignore it. Note that as per a decapsulating node removes the IOAM encapsulation and all its IOAM options, and specifically in the case where one of these options is a (possibly unknown) DEX option. >> >> >> >> > >> > The format of the first four-octet word in Figure 2 is different from = the format defined in draft-ietf-ippm-ioam-data: >> > >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Namespace-ID |NodeLen | Flags | RemainingLen| >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | IOAM-Trace-Type | Reserved | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > Is this intentional? If it is, how does an implementation know which f= ormat to use? >> >> [TM] Each IOAM Option-Type has a different header format. The current >> document defines a new Option-Type, which was not defined in >> draft-ietf-ippm-ioam-data. >> The IOAM-Type field in the lower layer header determines which >> Option-Type is used and how its header should be parsed. > > GIM>> How does an IOAM node differentiate between different Option-Types?= Is that expected to be communicated to an IOAM node over the management or= control plane and not part of the IOAM encapsulation? If that is the case,= then, I imagine, changing between IOAM tracing modes will require reconfig= uration of all IOAM nodes. Doesn't seem operationally friendly. [[TM]] This question is not strictly related to the current draft, but anyway an IOAM node differentiates between different option types according to the IOAM Type field which resides in the lower layer header. For example, in the IPv6 option (draft-ietf-ippm-ioam-ipv6-options-06), the IPv6 Hop-by-Hop Option header includes the IOAM-Type field: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Reserved | IOAM Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> > >> > It is stated in the draft that: >> > >> > The length of the DEX option is at least 8 octets. >> > >> > But the figure 2 in the draft does not include any field that reflects= the length of the IOAM option. Is that because the figure is out of sync? = If not, how can an implementation verify the length? Also, what is the beha= vior if the length is less than 8 octets? >> > >> >> [TM] Quoting the draft: >> >> The existence of the optional fields is >> indicated by the corresponding flags in the Extension-Flags field. >> ... >> Thus, the Extension-Flags field explicitly indicates >> the length of the DEX option. >> >> >> > RE: PerformanceConsiderations >> > >> > I agree with you that a DEX-encapsulating node and DEX-transit nodes m= ust have rate-limiting controls (as noted earlier, the behavior of the tran= sit node needs more detailed specification). But I think that the document = should also note that exported packets could be sent over the network out-o= f-band, relative to the monitored flow. As a result, the impact of packets = carrying telemetry information might be not direct and harmful to the data = flow. I see that as one of the important benefits of the Direct Export meth= od transporting on-path telemetry information. >> > >> >> [TM] Right. The following new text is proposed: >> >> It should be noted that in some networks DEX data may be exported over >> an out-of-band network, in which a large volume of exported traffic >> does not compromise user traffic. In this case an operator may choose >> to disable the exporting rate limiting. > > GIM>> Thank you for the proposed update. I thought that the main advantag= e of the IOAM DEX mode is the ability to export the telemetry information o= ut-of-band. And, as I've noted above, the mechanism to collect and transpor= t the telemetry is outside the scope of this specification. I think that wo= uld significantly simplify the document without any adverse impact on the v= alue it provides. >> >> >> > >> > Regards, >> > Greg >> > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly wrote: >> >> >> >> Hello IPPM, >> >> >> >> This email starts a Working Group Last Call on two related IOAM docum= ents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export. >> >> >> >> In-situ OAM Loopback and Active Flags >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 >> >> >> >> In-situ OAM Direct Exporting >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-exp= ort-06 >> >> >> >> Please provide feedback by replying to this email with your reviews a= nd if you think these documents are ready to progress, by Wednesday, Septem= ber 15. >> >> >> >> Best, >> >> Tommy & Ian >> >> >> >> _______________________________________________ >> >> 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 From nobody Thu Oct 7 19:09:20 2021 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 EFB893A08BD for ; Thu, 7 Oct 2021 19:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHvCWQk0KROF for ; Thu, 7 Oct 2021 19:09:13 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F723A08B8 for ; Thu, 7 Oct 2021 19:09:12 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 39211604BEE5AA0AC387; Fri, 8 Oct 2021 10:09:11 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 1DA02FA9636269EFB1B6; Fri, 8 Oct 2021 10:09:11 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 19828tcr006849; Fri, 8 Oct 2021 10:08:55 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Fri, 8 Oct 2021 10:08:55 +0800 (CST) Date: Fri, 8 Oct 2021 10:08:55 +0800 (CST) X-Zmail-TransId: 2afa615fa8372a4ab163 X-Mailer: Zmail v1.0 Message-ID: <202110081008554007720@zte.com.cn> In-Reply-To: References: CAM4esxSG5Jpya0DtVx5mjj4iS1Cb-z_MViHjBQ-S=3yxrw5QQQ@mail.gmail.com Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 19828tcr006849 Archived-At: Subject: Re: [ippm] =?utf-8?q?New_chair!?= 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, 08 Oct 2021 02:09:18 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWFueSB0aGFua3MgdG8gSWFuIGZvciB5b3VyIGd1aWRhbmNlIGFuZCBleGNlbGxlbnQgd29yay4N Cg0KDQpDb25ncmF0cyB0byBNYXJjdXMsIFdlbGNvbWUhDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMsDQoNCg0KDQpYaWFvIE1pbg0KDQoNCg0KDQoNCg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0K DQrlj5Hku7bkurrvvJpNYXJ0aW5EdWtlDQrmlLbku7bkurrvvJpJRVRGIElQUE0gV0c7DQrml6Ug 5pyfIO+8mjIwMjHlubQxMOaciDAy5pelIDAxOjA0DQrkuLsg6aKYIO+8mltpcHBtXSBOZXcgY2hh aXIhDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg0KR3JlZXRpbmdzIElQUE0hDQoNCg0KSSdtIHBs ZWFzZWQgdG8gYW5ub3VuY2UgdGhhdCBNYXJjdXMgSWhsYXIgaXMgam9pbmluZyBJUFBNIGFzIG91 ciBuZXdlc3QgY2hhaXIuIElhbiBTd2V0dCBpcyBzdGVwcGluZyBkb3duIGZvciB2YXJpb3VzIHJl YXNvbnMsIEknZCBsaWtlIHRvIHRoYW5rIGhpbSBmb3IgaGlzIGVmZm9ydHMgdG8gbW92ZSB0aGUg V0cgZm9yd2FyZCBvdmVyIHRoZSBwYXN0IHllYXIgYW5kIGEgaGFsZi4NCg0KDQpXZSB3aWxsIHJ1 biB3aXRoIHRocmVlIGNoYWlycyBhdCBJRVRGIDExMiwgYWZ0ZXIgd2hpY2ggSWFuIHdpbGwgZm9y bWFsbHkgZGVwYXJ0Lg0KDQoNCldlbGNvbWUgTWFyY3VzIQ0KTWFydGlu --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+TWFueSB0aGFua3MgdG8gSWFuIGZv ciB5b3VyIGd1aWRhbmNlIGFuZCBleGNlbGxlbnQgd29yay48L3A+PHAgc3R5bGU9ImZvbnQtc2l6 ZToxNHB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij5Db25ncmF0 cyB0byBNYXJjdXMsIFdlbGNvbWUhPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE0cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkJl c3QgUmVnYXJkcyw8YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTrl vq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+WGlhbyBNaW48L3A+PGRpdiBjbGFzcz0iek1h aWxTaWduIiB1bm9uYW1lY2g9IuiCluaVjzEwMDkzNTcwIiB1bm9uYW1lZW49InhpYW9taW4xMDA5 MzU3MCI+PGRpdiBjbGFzcz0iek1haWxTaWduQ29udGVudCI+PC9kaXY+PC9kaXY+PGRpdiBjbGFz cz0iek1haWxGcm9tIj48L2Rpdj48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHlsZT0i ZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDogMTAw JTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Uw RTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRhdGE9 Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlD b250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBj bGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29s b3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4 dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPk1hcnRp bkR1a2U8bWFydGluLmguZHVrZUBnbWFpbC5jb20+PC9tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT48 L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlUT1R4dCI+5pS2 5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7Ij5JRVRGIElQUE0gV0c8aXBwbUBpZXRmLm9yZz47PC9pcHBtQGlldGYub3Jn Pjwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeURhdGVUeHQi PuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+MjAyMeW5tDEw5pyIMDLml6UgMDE6 MDQ8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0 VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25n PltpcHBtXSBOZXcgY2hhaXIhPC9zdHJvbmc+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgem1haWxi dXNpbmVzcz0iYnVzaW5lc3NFeHRlcm5hbCI+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250 ZW50Ij48ZGl2Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPmlwcG0mbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxicj5pcHBtQGlldGYub3JnPGJyPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTxicj48YnI+PGRpdiBkaXI9Imx0 ciI+PGRpdj5HcmVldGluZ3MgSVBQTSE8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkknbSBwbGVh c2VkIHRvIGFubm91bmNlIHRoYXQgTWFyY3VzIElobGFyIGlzIGpvaW5pbmcgSVBQTSBhcyBvdXIg bmV3ZXN0IGNoYWlyLiBJYW4gU3dldHQgaXMgc3RlcHBpbmcgZG93biBmb3IgdmFyaW91cyByZWFz b25zLCBJJ2QgbGlrZSB0byB0aGFuayBoaW0gZm9yIGhpcyBlZmZvcnRzIHRvIG1vdmUgdGhlIFdH IGZvcndhcmQgb3ZlciB0aGUgcGFzdCB5ZWFyIGFuZCBhIGhhbGYuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5XZSB3aWxsIHJ1biB3aXRoIHRocmVlIGNoYWlycyBhdCBJRVRGIDExMiwgYWZ0ZXIg d2hpY2ggSWFuIHdpbGwgZm9ybWFsbHkgZGVwYXJ0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ V2VsY29tZSBNYXJjdXMhPC9kaXY+PGRpdj5NYXJ0aW48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Fri Oct 8 02:36:54 2021 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 6D7863A15F6 for ; Fri, 8 Oct 2021 02:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8OCjJuTJPMBs for ; Fri, 8 Oct 2021 02:36:46 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50061.outbound.protection.outlook.com [40.107.5.61]) (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 2D11B3A15F7 for ; Fri, 8 Oct 2021 02:36:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XfOQo27SUWFZNV4Gg+ViHNjgby+cG/wDT67sJ7s3Jbuf92UQNvxZKtxSKkv6rtPMXMIXvzmdnkqvmbPgB7s/MsX2/zAW//xd1issk5c7nu2llwqJR0oR+IRDtvmyhCAgIuFjPDWYr6iR36EQ1HmbkGu+gHbzZCft1GaVT6YBQqasfhsmaeBK/dZ+PdtsDCV+uam/kxapIarv/amU6ZlgQPjEk3vEbR00L/QNayB5wAoqvRi8/YL6rUDaeH/4041zoZioIdMb+V+i0uRsfGpGWhyJPohJY7hypLlXVS64R80fvPT6eyfvsox7n8dVd+dTHzHk70SjxpF3DDPPYtbJkg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vnl0md7UKILhinrCxp06fPWqyKjKNN8Nw1MQEcIlabI=; b=BxSxfI52qUmXoXyRdWy+50N9n33TfnnRID7iRIlLCRXnypNNM/Zc7I7v6pPWQ9dN7IdWLCsDQ4KI2/4qKqEO699dpXi5DYGiFdqzG0GXSPSbaatAHH084iRN5YQGVb0h2tSnlGX8v6us+DXXmch8Cki9Tumv/K0ugnn4uaZLV6WuFbL1V+b8uUxmoqO4x3CCOHDrYS1RAu1Oqaatl5v+gHAxQJkSSNf0JIapJsnoRsLZSSrOYkfgp+6Ni+xRE6MsEPkNnChg9iLNLS1Nif7b8DvWbpWln+xE7X6UO/LBkm8xBcSCv2Uo1cst6x1cuWnEcCJO58ZjycOngMBL+SusWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vnl0md7UKILhinrCxp06fPWqyKjKNN8Nw1MQEcIlabI=; b=LtuTylkD6XJ54ayUcX/M7ytW4jUoCQBYQ0CD9eu7uJh5kM5KVFfZeIOnp61xafTKbE11bx/d/qi3m1zCP1PV9QyRCtz8+4xOEx7maHRYAQkZnjJOifUYMPlV0c3PX4KHc75gRs7O0X3hOpPHtW1wFsEJBnHPHLueYaHI3aRFKEQ= Received: from HE1PR07MB4426.eurprd07.prod.outlook.com (2603:10a6:7:a1::15) by HE1PR0701MB2092.eurprd07.prod.outlook.com (2603:10a6:3:20::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Fri, 8 Oct 2021 09:36:22 +0000 Received: from HE1PR07MB4426.eurprd07.prod.outlook.com ([fe80::2d97:ee65:39e9:6698]) by HE1PR07MB4426.eurprd07.prod.outlook.com ([fe80::2d97:ee65:39e9:6698%5]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 09:36:22 +0000 From: Marcus Ihlar To: "xiao.min2@zte.com.cn" CC: "ippm@ietf.org" Thread-Topic: [ippm] New chair! Thread-Index: AQHXtuZJVrRnvkL+806TNLNqCjpR46vIZRiAgAB8qWA= Date: Fri, 8 Oct 2021 09:36:22 +0000 Message-ID: References: CAM4esxSG5Jpya0DtVx5mjj4iS1Cb-z_MViHjBQ-S=3yxrw5QQQ@mail.gmail.com <202110081008554007720@zte.com.cn> In-Reply-To: <202110081008554007720@zte.com.cn> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: zte.com.cn; dkim=none (message not signed) header.d=none;zte.com.cn; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08a479c7-1ac9-4201-7480-08d98a3f1737 x-ms-traffictypediagnostic: HE1PR0701MB2092: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B9pNXodey5Kt7E6ujqsQmhlbRNHAaVm4iPEnUqY4cA/33cdTlR7HctZJArVyRLBAKEXolGu3ur90qJFba0XKSYCKEIsbjKUtzm8t4byhORl87c3FSmrYe6YlwI3szdru1DPg29W9fLr0oOlkmrlVIXcEMcAjRkBRqeoZUQT0iXfSq2SrIVBrKY1xWUQvxkZUZTBNoGV6MVPez7tn9ZRT8vi3o4W7V0bsg5Y44lN4n1MOh0odI5aSX9bF3hNXwMbG0V58n7Yp/tm7f0YURuHFzhiCIJsWta1JypDJFkiKgmgWmboMbNbD2yPkie0o8WDLU812QQoOXA6TufDkEnq4oGEYyKO3ROIH+Unc4wyTCKxSAkhl6Q8mXXzIyJZUA0tWdtG3wEOK/FvLBts03AkDz6MLZa97BMVhbsNFnh6DulbgLjCgq9/1TFn6OydPJlD0M5Y/PuXA08aio8KKNE0tDc7R6wcOmjUYul0aYj2rd6FYH6XHdkeaXB83IliNnVrCFzwK5vlLGVFnYHB1Bs+k/Y2rgqhsiA0JX+x3M8aGkpMPq6twx010nh6gzUZP10mrpP4MX/vGH6/kOUvmG9rNJcXXziW6dH6KiE1gPs4gOvKJKxoB/TV65eWdIX56xllZ6SAtkXy6hRKgO+o8Ty03F22l+tSrW2mChY853ZZk6y7NIns3ClhHPR4rpfjI1399bNiK/h2mnpsbfHpnUfwEI6Am/kS3zUdRAkPY+/ifU/G7wVRBdz9JPAZKp4iDp4ZhX6Q7ry0VBNWtyfWF1ac23rH5U3J+w2yHDV4n5899+O4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4426.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66476007)(66946007)(76116006)(71200400001)(44832011)(4326008)(8936002)(86362001)(316002)(508600001)(52536014)(8676002)(33656002)(66556008)(38100700002)(64756008)(966005)(66446008)(83380400001)(38070700005)(9686003)(5660300002)(55016002)(4744005)(7696005)(186003)(122000001)(2906002)(53546011)(6506007)(6916009)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bXEzc1ArTDNTNnFSWUFyR0RiVFFNY2ZYZTdRTnlJS282b2RtMXBYRUQweDlz?= =?utf-8?B?bThoQjdjYWtldFY4ajFaSW9jSjhJUksyU2pZMlZqREg0VWtLUTZXa2xVOFpz?= =?utf-8?B?SmU1VU1xeEZRSmhtb0grTkJSWVd3YSsrTXNlRkttclB5VUNxK2hUYThsUXMx?= =?utf-8?B?WEFyQ2RyanpUWHRJSDQ2Mm9tZWRKSjhxWndobUg4ZE5OOVBxKzlEdCtRYnA0?= =?utf-8?B?MmRBK0hvbXpxOWdQbVZUZDYrWkdzaFBvbTIrVVRrTCt6aDZBS05DQSs2bEE3?= =?utf-8?B?Q0FLOHJmODNMMVU4QWFHWFlPb3ZNMnRjWmdPWjlwRGg4QXdKYUZsVU9xUlh0?= =?utf-8?B?dU4wbGZSUGVaOGRSdVFHMEgyRlZLVnFEYitBSEpJUFRvWW1HeFBrcDJKY0hP?= =?utf-8?B?QldadzgreWFtTC9WVTBCbDV5R2J6YVd4eEZ3cTJtVmFieDZnVVF0ejc4VGYz?= =?utf-8?B?eldpVEU1NENRVzhTQThIZG9HVm12Z1N0N1hjZFhJS0Z2cXJSNlhmOXozdlpi?= =?utf-8?B?ZnJDeGlPa2FGTzd0Wm5uT2lZZC9GanpyY1FtK3o0dzlPb0hwcy94TURpdng4?= =?utf-8?B?d3JWeFBMb1U4d1dIZU1VdkFRd0pHbmhxcjkzVTR0eURBYmFHbWV5UENlOFlG?= =?utf-8?B?ajg1VENCZVZPME5EbzN4dGs3cmRGZ1hydisxUXFpUEdjWEtIY0hDWUNDZ0Fu?= =?utf-8?B?M3QwajZSMCs0dFhvbWNrOXB0NU9FM0tGQ0czRjFib2UvMGluV3hGdHpwSnZF?= =?utf-8?B?cHR4cURHemdUMTB1dmdXanE3OVgxazJHNTNRVXVHUkIvWDErd1ExbUZHWlBM?= =?utf-8?B?akw1UCsyOTUxRDdGanY5aXhwdElOelVHUWdYL3JyOXZXUEo0SjJzV1NLTldE?= =?utf-8?B?dDNXM05HbnVZV3dlWWFpMDhlQ3kvUFNURmNSM0dMRUNmam5TUnEvL1dTRmgr?= =?utf-8?B?WTdWSTNDWVU0SUtuZHVma3dlUnFsdTBaWExzMkp5b0dOTjdPVjdEYkFqVHpO?= =?utf-8?B?VnRvcFFNVE1IYm05MTBiQTNGL3N4dmdBemNNWncwSlUwUEhyaXZJSU05OW5T?= =?utf-8?B?eEpPZWVydkVNMDgzb3JGUk5DQlArZHAwbUNiWVN5QXNJR1lMSkJiZXQ4QWdv?= =?utf-8?B?NmF6NFl3emYycWlOV2xCNXQ3OUxOQmxSU0wzcjVFVmdLd0xjZGlEMFBwd0c4?= =?utf-8?B?ODB2US8vQ2lIK3pyUFZLWFNhbXh6NFZOTG9HTXZ0K2hEM0ZmbDhqbG8rVUtQ?= =?utf-8?B?a0pGaFduL01OUjN2TThOY2VBS05PVnQrUnR6QkxUQnFCS2Y1SUZpWktJblpK?= =?utf-8?B?eVpQMDJYN08yNlNmSENQbVNFdFpmV2FFK1FaT3hJZDFsSmNZSjlTSWtBSWxt?= =?utf-8?B?WWNVbkc4RmorYjZ3bjhKR2JQK1BJSXlCRzhDTFkveDZaRXcyZWlkMVlmbk9V?= =?utf-8?B?Q3B1NGRPSlpySVUxZkRuS2h2dkdKMXlNTHB2MnBrS1F4c1pVamFDZWZKQk45?= =?utf-8?B?QWVNWjNlalFBZk5qekVjSkFmblFaMVl6Ri81SXNoTlk0eGV0RVFDdGxUZHNy?= =?utf-8?B?TStzU25aRHVMOVdJbUdaRXZibllIcm51bm54b1dSY2NRM3JaaDdkTkduK0k5?= =?utf-8?B?V0RzZjhnY3lSdjE2OVNvck5vUDJIaU01U2NnTXhlZkhoM0p1RGJxUGZqZCtO?= =?utf-8?B?LzQ0NDdDQlNpdEllU09SY2ZLS0MrT1k4TUM1ZmVXbmxEWklmZThDdDl3RXEr?= =?utf-8?B?ZFZnZG1LQUROS0JSWlpodlhjSHRTdDk5OGg2cE1KVis5TmJDNDlrUGcxSlN3?= =?utf-8?B?UlpqZ0VVbE1FdjBWY1NpcmhlTUtldFMwclIrWUU3S0VNNUVXY1lJdThsT2tF?= =?utf-8?Q?A+KYQlx/O5jyB?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB442693244064B5BAF5E6FFF3E2B29HE1PR07MB4426eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4426.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08a479c7-1ac9-4201-7480-08d98a3f1737 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 09:36:22.5539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YY3sFhq7qCQdGQjNjmX0pF6DtcQkIEyUTnApZYZ5AR3e5s/cz97Wngtav2F1nXrzg6FyXC2Mo8BNpFwbhvEQl3eKDIYN/7LD3J+ZmoMQgaM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2092 Archived-At: Subject: Re: [ippm] New chair! 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, 08 Oct 2021 09:36:52 -0000 --_000_HE1PR07MB442693244064B5BAF5E6FFF3E2B29HE1PR07MB4426eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIQ0KDQpJ4oCZbSB2ZXJ5IG11Y2ggbG9va2luZyBmb3J3YXJkIHRvIHdvcmtpbmcgd2l0 aCB5b3UgYWxsLg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpNYXJjdXMgSWhsYXINCg0KDQoNCkZy b206IGlwcG0gPGlwcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIHhpYW8ubWluMkB6 dGUuY29tLmNuDQpTZW50OiBkZW4gOCBva3RvYmVyIDIwMjEgMDQ6MDkNClRvOiBtYXJ0aW4uaC5k dWtlQGdtYWlsLmNvbQ0KQ2M6IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbaXBwbV0gTmV3 IGNoYWlyIQ0KDQoNCg0KTWFueSB0aGFua3MgdG8gSWFuIGZvciB5b3VyIGd1aWRhbmNlIGFuZCBl eGNlbGxlbnQgd29yay4NCg0KQ29uZ3JhdHMgdG8gTWFyY3VzLCBXZWxjb21lIQ0KDQoNCg0KQmVz dCBSZWdhcmRzLA0KDQpYaWFvIE1pbg0KDQrljp/lp4vpgq7ku7YNCg0K5Y+R5Lu25Lq677yaTWFy dGluRHVrZQ0KDQrmlLbku7bkurrvvJpJRVRGIElQUE0gV0c7DQoNCuaXpSDmnJ8g77yaMjAyMeW5 tDEw5pyIMDLml6UgMDE6MDQNCg0K5Li7IOmimCDvvJpbaXBwbV0gTmV3IGNoYWlyIQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5n IGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KR3JlZXRpbmdzIElQUE0hDQoNCg0KDQpJ J20gcGxlYXNlZCB0byBhbm5vdW5jZSB0aGF0IE1hcmN1cyBJaGxhciBpcyBqb2luaW5nIElQUE0g YXMgb3VyIG5ld2VzdCBjaGFpci4gSWFuIFN3ZXR0IGlzIHN0ZXBwaW5nIGRvd24gZm9yIHZhcmlv dXMgcmVhc29ucywgSSdkIGxpa2UgdG8gdGhhbmsgaGltIGZvciBoaXMgZWZmb3J0cyB0byBtb3Zl IHRoZSBXRyBmb3J3YXJkIG92ZXIgdGhlIHBhc3QgeWVhciBhbmQgYSBoYWxmLg0KDQoNCg0KV2Ug d2lsbCBydW4gd2l0aCB0aHJlZSBjaGFpcnMgYXQgSUVURiAxMTIsIGFmdGVyIHdoaWNoIElhbiB3 aWxsIGZvcm1hbGx5IGRlcGFydC4NCg0KDQoNCldlbGNvbWUgTWFyY3VzIQ0KDQpNYXJ0aW4NCg0K DQoNCg== --_000_HE1PR07MB442693244064B5BAF5E6FFF3E2B29HE1PR07MB4426eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3Nv ZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IEpoZW5nSGVpIjt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0 IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IFlhSGVpIjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnpyZWFkdXNlcm5hbWUNCgl7bXNv LXN0eWxlLW5hbWU6enJlYWR1c2VybmFtZTt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyEgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSB2ZXJ5IG11Y2ggbG9va2luZyBmb3J3YXJkIHRv IHdvcmtpbmcgd2l0aCB5b3UgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJjdXMgSWhsYXI8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IGlwcG0gJmx0O2lwcG0tYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwv Yj4NCnhpYW8ubWluMkB6dGUuY29tLmNuPGJyPg0KPGI+U2VudDo8L2I+IGRlbiA4IG9rdG9iZXIg MjAyMSAwNDowOTxicj4NCjxiPlRvOjwvYj4gbWFydGluLmguZHVrZUBnbWFpbC5jb208YnI+DQo8 Yj5DYzo8L2I+IGlwcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtpcHBtXSBO ZXcgY2hhaXIhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmIj5N YW55IHRoYW5rcyB0byBJYW4gZm9yIHlvdXIgZ3VpZGFuY2UgYW5kIGV4Y2VsbGVudCB3b3JrLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmIj5Db25ncmF0 cyB0byBNYXJjdXMsIFdlbGNvbWUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OyxzYW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPlhpYW8gTWluPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MjEuMHB0O2JhY2tncm91bmQ6I0UwRTVFOSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMx Mzg4RkYiPuWOn+Wnizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IEpoZW5nSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzEzODhGRiI+6YKu5Lu2PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMTM4OEZGIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNUY2RjgiPjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj7lj5Hku7bkurrvvJo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9 InpyZWFkdXNlcm5hbWUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFydGluRHVrZTwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGNkY4Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuaUtuS7tuS6uu+8mjwv c3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWR1c2VybmFtZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5JRVRGIElQUE0gV0c7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNUY2 RjgiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 Oztjb2xvcjpibGFjayI+5pelPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8 L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMg R290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7mnJ88L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4NCjwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPu+8mjwvc3Bhbj48L3N0cm9uZz48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIwMjE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+MDI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90Oztjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ DQogMDE6MDQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGNkY4Ij48c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuS4uzwvc3Bh bj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7popg8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4NCjwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPu+8mjwvc3Bhbj48L3N0cm9uZz48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPltpcHBtXSBOZXcgY2hhaXIhPC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0mbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVldGluZ3MgSVBQTSE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHBs ZWFzZWQgdG8gYW5ub3VuY2UgdGhhdCBNYXJjdXMgSWhsYXIgaXMgam9pbmluZyBJUFBNIGFzIG91 ciBuZXdlc3QgY2hhaXIuIElhbiBTd2V0dCBpcyBzdGVwcGluZyBkb3duIGZvciB2YXJpb3VzIHJl YXNvbnMsIEknZCBsaWtlIHRvIHRoYW5rIGhpbSBmb3IgaGlzIGVmZm9ydHMgdG8gbW92ZSB0aGUg V0cgZm9yd2FyZCBvdmVyIHRoZSBwYXN0IHllYXIgYW5kIGEgaGFsZi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBydW4gd2l0aCB0 aHJlZSBjaGFpcnMgYXQgSUVURiAxMTIsIGFmdGVyIHdoaWNoIElhbiB3aWxsIGZvcm1hbGx5IGRl cGFydC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2VsY29tZSBNYXJjdXMhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXJ0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR07MB442693244064B5BAF5E6FFF3E2B29HE1PR07MB4426eurp_-- From nobody Fri Oct 8 08:59:27 2021 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 ACA293A04BC for ; Fri, 8 Oct 2021 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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=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 yg1D5IvP-X_s for ; Fri, 8 Oct 2021 08:59:17 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (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 C306B3A053E for ; Fri, 8 Oct 2021 08:59:17 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 198FqFWN029290 for ; Fri, 8 Oct 2021 08:59:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=vy9ayj6sbPtXTY7duzxAECUC4WsXCabbPLtV7pRWv9k=; b=AaYVkfDvZfp/P6yQ5BoO5aTJSY0dDIltlGvQy4kmH7JLlQkbHmKpU9759JbZC9fCbsvo SEjw/xP0h7S5LIanWMN4sFe1MbvWWK8/upFzDU8B5TG1hqvb78+reMwMSU8gwu2QD6T/ 7DmUDOg+H3qVVlad0aA0y3xkhDI5vW2FW0kKUBcy7Lx/vbLbjLdOhGXxEGhlxKPydNU0 /GrzcyMO1Uys7tLpUF23Yz9vobP9mGGZs8z5C17A+3bhNMcKe49pRnFdBvOdI8V5GzQQ cHqztYsSntjUAb2HkjLvfm5Q1XeI9I9hcKyfyFIrnFIEPY/hbY+KeObZS89OSrSkLaFn Aw== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3bjcy8hnkh-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 08 Oct 2021 08:59:17 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R0O00TWY1QSCGG0@rn-mailsvcp-mta-lapp01.rno.apple.com> for ippm@ietf.org; Fri, 08 Oct 2021 08:59:16 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R0O000001AHLF00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for ippm@ietf.org; Fri, 08 Oct 2021 08:59:16 -0700 (PDT) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: be988628c0ecf739cc96acbe4c048c2f X-Va-R-CD: 5db31cc9099d5e5d012fbc60621eb621 X-Va-CD: 0 X-Va-ID: fdb2e252-fa20-4ef5-b722-ba6dde90b7c6 X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: be988628c0ecf739cc96acbe4c048c2f X-V-R-CD: 5db31cc9099d5e5d012fbc60621eb621 X-V-CD: 0 X-V-ID: 56147811-6d2f-4141-a8c1-c3cf7069430a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-08_04:2021-10-07, 2021-10-08 signatures=0 Received: from smtpclient.apple (unknown [17.234.5.13]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R0O00N3G1QPB400@rn-mailsvcp-mmp-lapp04.rno.apple.com> for ippm@ietf.org; Fri, 08 Oct 2021 08:59:16 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_AB9A0C94-FA44-4F21-90A2-241D83BE3E3F" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Message-id: Date: Fri, 08 Oct 2021 08:59:12 -0700 To: "IETF IPPM WG (ippm@ietf.org)" X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-08_04:2021-10-07, 2021-10-08 signatures=0 Archived-At: Subject: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 08 Oct 2021 15:59:24 -0000 --Apple-Mail=_AB9A0C94-FA44-4F21-90A2-241D83BE3E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello IPPM, This email starts an adoption call for = draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements = Techniques=E2=80=9D. This document is proposed as an Informational = document that describes techniques that go beyond single bit markings = like the QUIC spin bit. = https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements= / = = https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measure= ments-02 = This adoption call will last until Friday, October 22. Please review the = document, and reply to this email thread to indicate if you think IPPM = should adopt this document. Best, Tommy= --Apple-Mail=_AB9A0C94-FA44-4F21-90A2-241D83BE3E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello IPPM,

This email starts an adoption call for = draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements = Techniques=E2=80=9D. This document is proposed as an Informational = document that describes techniques that go beyond single bit markings = like the QUIC spin bit.

https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-m= easurements/
https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-f= low-measurements-02

This adoption call will last until Friday, = October 22. Please review the document, and reply to this email = thread to indicate if you think IPPM should adopt this = document.

Best,
Tommy
= --Apple-Mail=_AB9A0C94-FA44-4F21-90A2-241D83BE3E3F-- From nobody Fri Oct 8 08:59:41 2021 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 6CBF23A0818; Fri, 8 Oct 2021 08:59:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163370877342.6810.16760852945965257183@ietfa.amsl.com> Date: Fri, 08 Oct 2021 08:59:33 -0700 Archived-At: Subject: [ippm] The IPPM WG has placed draft-mdt-ippm-explicit-flow-measurements in state "Call For Adoption By WG Issued" 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, 08 Oct 2021 15:59:39 -0000 The IPPM WG has placed draft-mdt-ippm-explicit-flow-measurements in state Call For Adoption By WG Issued (entered by Tommy Pauly) The document is available at https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/ From nobody Fri Oct 8 09:04:19 2021 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 42B163A0553; Fri, 8 Oct 2021 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETHUk2uk3z92; Fri, 8 Oct 2021 09:04:13 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 9AD4D3A058F; Fri, 8 Oct 2021 09:04:12 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id d3so10749436edp.3; Fri, 08 Oct 2021 09:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ja3DgGevHSkbXsk0hM71Gw7aR1fjFEhETlm1U3iYDg=; b=SzDVuUnIv/K/rzL1wdwOxRlwidlnTbMsgLj9AOBzG5injEDWawycFRYex6cXAcuFOD tkwfWEOeO1RvQUo2CCn9ZSEzQNywGmB+Tpi2geTYUugTlKkfLmWkLGEGcNT9LBX1IfR2 1sPfY3o4Xr/fT3m684d4Vfbajk1resl3GbaRTFJd0tjXCCuKDSkgzmjBrZh/vaoxNanC 6bUBWediQXnquWmgl0vH0L9WwHt7H6N/byG6JNoe1I07Dfj4oA5UtrZ4BreotsRn1h2E cjb6K61sJFSiZJQqqVeIzBY6LfA6u1qX0KWMdU8Kgcr2+l8Wbw3xMr+paxYt1xFmHxux TjiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ja3DgGevHSkbXsk0hM71Gw7aR1fjFEhETlm1U3iYDg=; b=YFlfjpXSnPIOK5mmI6QyljvuqI9IsWgVd9cCegsSA96shmhXa8gBLAvVSqrD1ASeNT aSyCwLCfrkl+N88IDovrVppSbI0PXi/xm+QWil3Py7IBy8j3wVXL1C3m/ccCWtMc9px4 T906mYNBSYMhP9XtBpxRLAlQlvsLmpbbJz5eEKW66dS4R3ICZCJvDD3PjEUnv4vpeIAo ZPg6khd/o6vaf8SHsmvu9l7o6x+4/2etG7rwfM0uVrI3ixNSKsnrM56u6EDyeZf4RHbG F+kYPimAr3a11Q4qNfBsEcez4rwitjDnZ3pprzZi87OHrPZvlwNlV4aIkbZ2g3MdhF7n itMg== X-Gm-Message-State: AOAM530eCTk5HWbPtlSJRkdLpDMKC3a8GEByFprmJRHGG1UVw4vQ29hQ v/7TpHi0vGvrUCkrCJ/BRMMqPTx+/71hAuMn7iE= X-Google-Smtp-Source: ABdhPJz+hcwe6Gq6/vNg0baYA8v/Bt5x8QUtRE3JirmPmjlxfesA6Mt5qYd5oMx6azYIGDQcnwbL2f0UE5IHA6O9KcQ= X-Received: by 2002:a17:906:60c3:: with SMTP id f3mr4977770ejk.561.1633709049118; Fri, 08 Oct 2021 09:04:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 8 Oct 2021 09:03:57 -0700 Message-ID: To: Tal Mizrahi Cc: Tommy Pauly , IPPM Chairs , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000008a03b605cdd987b9" Archived-At: Subject: Re: [ippm] WGLC for IOAM Flags 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, 08 Oct 2021 16:04:18 -0000 --0000000000008a03b605cdd987b9 Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for your responses to my comments and questions. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi wrote: > Hi Greg, > > Many thanks for the detailed comments. > Please see the responses below, as well as suggested text edits in some > cases. > > Cheers, > The authors. > > On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky wrote: > > > > Dear Authors, WG Chairs, and All, > > I've read the latest version of the draft and have several comments and > questions to share with you. I would much appreciate the opportunity to > discuss these before I can state my support for progressing this draft to > publication. > > > > The Abstract states that: > > > > In-situ Operations, Administration, and Maintenance (IOAM) records > > operational and telemetry information in packets while they traverse > > a path between two points in the network. > > > > I think that is not a complete description of IOAM options as it > excludes the Direct Export option. It might be easier to improve by > s/records/collects/. Also, what, in your opinion, is the distinction > between operational and telemetry information? I think that operational > information collected from remote nodes is one example of telemetry > information. What do you think? > > [TM] Agreed. Your proposal makes sense: s/records/collects/ > Regarding the difference between operational and telemetry > information, the way I see it "telemetry" refers to measurements that > are being exported to an external/remote entity, whereas operational > information is not measurement-based, such as the Node ID or Interface > ID. > GIM>> I think that there's no standardized definition of "telemetry" and "telemetry information". I share the idea expressed in the following: Telemetry is automated communication that processes from multiple data sources. Telemetry data improves customer experiences, monitors security, application health, quality, and performance. For different cases, the set of information referred to as telemetry data variates. For example, CPU and buffer utilization are valuable for virtualized environments. In other words, I understand telemetry data as information extracted from a remote system that characterizes the system's state. In any case, providing a definition would be helpful to a reader of the document. > > > > > > nit s/the the/the/ > > [TM] Agreed. > > > I think that Abstract and Introduction can be improved by explaining the > purpose of defining the Loopback and Active flags. What each of them is > intended to achieve and improve? > > [TM] The point is well-taken, and the following text will be added to > the introduction. In order to avoid text repetition, I believe it > would be best not to add it to the abstract as well. > > OLD: > - > NEW: > The Loopback flag is used to request that each transit device along > the path loops back a copy of the data packet to the sender. The > Active flag indicates that a packet is used for active measurement. > GIM>> Thank you for the proposed text. I have several notes to the new text: - As I understand the behavior required from a node processing the Loopback flag, the returned packet is not the complete but truncated data packet. - Is "active measurement" used in the context of RFC 7799? If "yes", does that mean that the packet is a specifically generated test packet? > > > It is stated in the Introduction that: > > > > This document defines > > two new flags in the Pre-allocated and Incremental Trace options: the > > Loopback and Active flags. > > Does that mean that neither of the two flags is applicable in the Direct > Export option? Should draft-ietf-ippm-ioam-direct-export have an explicit > statement regarding the applicability of the Loopback and Active flags? And > if any is applicable, describe the behavior of an IOAM node receiving it. > > [TM] Right. > The direct exporting draft explicitly states the behavior of each > field in the DEX option header including the flags, so there seems to > be no need to specify flags that are supported in other options. > GIM>> I'm a bit confused. Can you help me with the text from the DEX draft that specifies the use of the Loopback and Active flags in combination with the DEX trace option? > > > > > In Section 4 the purpose of using the Loopback flag is explained as: > > > > Loopback allows an IOAM encapsulating node to trace the path to a > > given destination, and to receive per-hop data about both the forward > > and the return path. > > In my previous comments, I've pointed out that the Loopback mode is just > a special case of the Direct Export option. In addition to that, I would > appreciate your explanation of how the IOAM encapsulating node receives > per-hop data about the return path. How does that work, for example, in an > MPLS or SFC NSH environment? > > [TM] It is slightly similar to direct exporting, but is not a special > case of direct exporting. In direct exporting telemetry/operational > data is not pushed into the data packet, but the data packet with the > DEX option triggers the data collection and optionally also exporting, > but exporting is not mandatory and may be performed later, for example > by the management plane. On the other hand, a trace option with the > loopback flag causes all IOAM transit nodes to push IOAM data onto the > trace option, and also loop a copy of the packet back to the sender. > GIM>> Thank you for providing that comparison between the result of processing DEX and the Loopback. As I understand it, the result of DEX, i.e., immediate export or local processing with exporting a batch of telemetry data, is determined by the local policy. If that is the case, the local policy can produce the same result as for the Loopback flag, which could be the default behavior for the DEX. > > > > > > Further it Section 4, it is stated that: > > > > The two IOAM looped back copies are > > terminated by the encapsulating node. > > But I don't see any technical explanation that could sustain that > assumption. As I understand the diagram in figure 1, a transit node doesn't > know the identity of the IOAM encapsulating node. Correct? If that is the > case, where does the transit node direct the looped packet? > > [TM] As described in the draft, the loopback flag is not necessarily > applicable to all possible encapsulations. The way the return path is > defined is encapsulation-specific. The draft currently states: > > Loopback can be used only if a return path from transit nodes and > destination nodes towards the source (encapsulating node) exists. > Specifically, loopback is only applicable in encapsulations in which > the identity of the encapsulating node is available in the > encapsulation header. If an encapsulating node receives a looped > back packet that was not originated from the current encapsulating > node, the packet is dropped. > GIM>> Please help me understand, the looped back packet is transmitted using the same encapsulation as the data packet with the Loopback flag? What is the rationale? If we use MPLS LSP Ping as an example, the response can be sent in several ways, but the default is in IP/UDP encapsulation as the commonly available transport. Why not use that and send the looped packet over IP/UDP? I believe that the applicability of this mechanism will be much broader. > > > > It seems that the text in the last paragraph attempts to walk around my > questions. But I don't find that paragraph sufficient. It lacks the > normative language to guide a developer to produce resilient > implementation. For example, how to interpret: > > Loopback can be used only if a return path from transit nodes and > > destination nodes towards the source (encapsulating node) exists. > > That reads like a recommendation, not a requirement. As a result, an > implementation may transmit an IOAM packet with the Loopback fag set > regardless of whether there's a return path or not. Then, how must a > transit node process such an IOAM packet? > > > > [TM] Right, the last response and quoted text is relevant here as > well. Please also note the following text from the draft: > > it is assumed that the > source address is available in the encapsulation header. Thus, the > source address of the original packet is used as the destination > address in the copied packet. > > I propose to add the following sentence: > The loopback flag MUST NOT be set if it is not guaranteed that there > is a return path from each of the IOAM transit and IOAM decapsulating > nodes, or if the encapsulating node's address is not available in the > encapsulation header. > GIM>> Thank you for the proposed text. I'd note that referring to the "encapsulating node's address" and "source address" might be interpreted as applying only to IP. In some networks, for example, BIER, the identity of the IOAM encapsulating node, BFIR, is known from its identifier that, in turn, can be mapped to the IP address. > > > > A very concerning statement I've found in Section 4.1 > > > > The encapsulating node either generates synthetic packets with an > > IOAM trace option that has the Loopback flag set ... > > IOAM has been defined as a hybrid measurement protocol. This statement > implies that it is to be used as an active OAM protocol (all per RFC 7799 > definitions). The requirements for active OAM protocols in terms of their > applicability and, most of, security are very different from those set for > a hybrid measurement protocol. I believe that extending IOAM into an active > mode of measurement requires more discussion and the audience from other > IETF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG. > > [TM] This draft does not define an active measurement protocol. The > point in the draft is that the loopback flag can be used in active > measurement packets. > GIM>> I have to disagree. Per RFC 7799, the use of specially constructed test packets is the primary characteristic of an active measurement method. By introducing the Active flag, this drat makes the IOAM into an active measurement protocol with all the requirements to an active measurement protocol to be applied. > The following text edit is proposed: > > OLD: > The encapsulating node either generates synthetic packets with an > IOAM trace option that has the Loopback flag set, or sets the loopack > flag in a subset of the in-transit data packets. Loopback is used > either proactively or on-demand, i.e., when a failure is detected. > NEW: > The loopback flag can be set in the IOAM trace option either in a > subset of the in-transit data packets, or in synthetic packets that > are generated by the encapsulating node. Loopback can be used > either proactively or on-demand, i.e., when a failure is detected. > > > > > The next statement explains the use case for the Loopback flag: > > > > Loopback is used > > either proactively or on-demand, i.e., when a failure is detected. > > That is the same use of ICMP and LSP Ping. What is the benefit of using > the Loopback flag instead of readily available ICMP? Does it work as L2 > Linktrace? I don't see that as a sufficient benefit considering the > complexity, exclusions, and risks associated and identified in the draft. > It is clear that there are tools like ICMP and LSP Ping that adequately > address scenarios listed in the draft. Don't see any technical reason for > the introduction of another mechanism that does not have any significant > benefit compared to the existing OAM tools. Especially, considering the > limited information that is allowed to be collected using the Loopback IOAM > flag ("every transit node that processes this trace option only adds a > single data field, which is the Hop_Lim and node_id data field"). With the > abundance of information and additional verification achieved using ICMP > and LSP Ping, there's even less rationale in the introduction of this > over-complex and unnatural mechanism. > > [TM] Right, as the draft says, the loopback flag is an "...alternative > to Traceroute, that allows the encapsulating node to receive responses > from multiple transit nodes along the path". Indeed, it slightly > resembles ETH-LT (Ethernet Linktrace) in the sense that a single > packet from the encapsulating node allows to quickly trace the entire > path, but as with IOAM in general, using the loopback flag does not > mandate a specific encapsulation. > GIM>> Also, I must note that "pro-active" use of the Loopback is possible only as part of the active measurement protocol. > > > > > The last paragraph states the requirement: > > > > IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with the > > Loopback flag onto data packets that already include an IOAM > > encapsulation. > > I couldn't find any guidance on how an IOAM node that receives such > invalid combination processes the packet. > > > > [TM] The current draft only specifies the flags. Specifically in the > scenario described above, the encapsulating node does not set the > loopback flag. This is intended to reduce the impact of potential > amplification attacks. > GIM>> I am still not clear about "MUST NOT push an IOAM encapsulation with the Loopback flag" in the draft and your explanation "the encapsulating node does not set the Loopback flag". As I understand it, in the given network for the monitored data flow, only one IOAM encapsulating node can exist. If that is correct, where does the existing IOAM encapsulation come from? > > > > > It is assumed that the identity of the IOAM encapsulating node is known > to the node that is expected to sent a copy of the received packet back. > But what if that is not the case? How must that node act? > > [TM] Agreed. The following new text is proposed to be added to Section 4.1: > If the address of the encapsulating node is not available in the > encapsulation header, then the transit/decapsulating node does not > loop back a copy of the original packet. > GIM>> I think that points to the significant limitation of the proposed mechanism. Comparing with MPLS LSP Ping, we see that it allows tracing the LSP even though MPLS encapsulation does not identify the ingress LER while the proposed Loopback would not work at all. > > > I believe that there's inconsistency between Figure 1 and the following > text in Section 4.2 > > > > Thus, the > > source address of the original packet is used as the destination > > address in the copied packet. > > It seems that the text assumes that the IOAM encapsulating node adds > also a network layer encapsulation. But how would it work, for example, in > SFC NSH data plane? Or MPLS? > > [TM] Right, the paragraph beginning with "Loopback can be used > only..." (discussed in response to one of the previous comments) makes > that restriction. > > > > > Section 4.4 states that > > > > If the Node ID matches the current > > IOAM node, it indicates that this is a looped back packet that was > > initiated by the current IOAM node, and processed accordingly. > > But according to the definition of node_id in Section 5.4.2.1 of > draft-ietf-ippm-ioam-data, "Node identifier field to uniquely identify a > node within the IOAM-Namespace and associated IOAM-Domain." It appears that > simply comparing Node IDs is not sufficient to verify that the node > received its looped back packet. What is your opinion? > > [TM] Agreed. The following update is proposed: > OLD: > If the Node ID matches > NEW: > If the Node ID and IOAM-Namespace match > > > > > > If, as stated in Section 5, > > > > It [Active flag] is not intended as a replacement for existing > > active OAM protocols, which may run in higher layers and make use of > > the Active flag. > > Then the question, What is the purpose of the Active flag? Existing > active protocols, Fault Management and Performance Monitoring, are > identified by, for example, use of a well-known destination port number or, > in case of MPLS, Generic Associated Channel type. There's no apparent need > of using IOAM option header to identify the payload as a control message of > an active OAM protocol. On the contrary, that would likely cause more > confusion and challenges to interoperation among different implementations. > > > > Three cases analyzed in Section 5 require special consideration, as > these likely present the motivation for the introduction of the Active flag: > > > > the first use case is not really using the Active flag at all and thus > the text doesn't seem adding any value to the draft; > > it is not clear what is viewed as the benefit of using the Active flag > compared with using any of the existing active OAM protocols in the second > use case. I would appreciate it if you can clarify that for me. Since an > SFC NSH network is used as an example, is it required that a Service > Function (SF) or an SF Proxy process the IOAM header with Active flag set? > Or would a Service Function Forwarder (SFF) avoid sending a packet with the > IOAM header that has an Active flag set? And can you compare that with the > procedures defined in the Active OAM for SFC draft? > > My questions for the third use case described in Section 5 are the same > as above because I don't see the benefit of using a replicated data packet > (less benefits if it is truncated) compared to a special test packet. > > > > In my conclusion on the Active flag, I don't see any clear benefit of > introducing it and using whether in place or in addition to the existing > active OAM protocols. > > [TM] General response to all the Active flag comments: this was > extensively discussed on the mailing list and in previous IETF > meetings, and your comments about the previous versions of the > document have contributed to greatly improving Section 5, which > describes the main use cases of the Active flag. > GIM>> I have to disagree with you here. I don't find the explanation in the document sufficient to justify the introduction of another mechanism to achieve what has already been satisfactorily addressed in IETF. Without a more detailed specification of the problem solved by the Active flag and how that is achieved, this mechanism appears like the answer is looking for a question, like a loaded gun without safety. > > > > > > I am looking forward to your feedback and the continued discussion. > > > > Regards, > > Greg > > > > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> > >> Hello IPPM, > >> > >> This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags and > draft-ietf-ippm-ioam-direct-export. > >> > >> In-situ OAM Loopback and Active Flags > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > >> > >> In-situ OAM Direct Exporting > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 > >> > >> Please provide feedback by replying to this email with your reviews and > if you think these documents are ready to progress, by Wednesday, September > 15. > >> > >> Best, > >> Tommy & Ian > >> > >> _______________________________________________ > >> 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 > --0000000000008a03b605cdd987b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal,
thank you for your responses = to my comments=C2=A0and questions. Please find my follow-up notes in-lined = below under the GIM>> tag.

Regards,
Greg

On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com<= /a>> wrote:
H= i Greg,

Many thanks for the detailed comments.
Please see the responses below, as well as suggested text edits in some cas= es.

Cheers,
The authors.

On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Authors, WG Chairs, and All,
> I've read the latest version of the draft and have several comment= s and questions to share with you. I would much appreciate the opportunity = to discuss these before I can state my support for progressing this draft t= o publication.
>
> The Abstract states that:
>
>=C2=A0 =C2=A0 In-situ Operations, Administration, and Maintenance (IOAM= ) records
>=C2=A0 =C2=A0 operational and telemetry information in packets while th= ey traverse
>=C2=A0 =C2=A0 a path between two points in the network.
>
> I think that is not a complete description of IOAM options as it exclu= des the Direct Export option. It might be easier to improve by s/records/co= llects/. Also, what, in your opinion, is the distinction between operationa= l and telemetry information? I think that operational information collected= from remote nodes is one example of telemetry information. What do you thi= nk?

[TM] Agreed. Your proposal makes sense: s/records/collects/
Regarding the difference between operational and telemetry
information, the way I see it "telemetry" refers to measurements = that
are being exported to an external/remote entity, whereas operational
information is not measurement-based, such as the Node ID or Interface
ID.
GIM>> I think that there's no standardiz= ed definition of "telemetry" and "telemetry information"= ;. I share the idea expressed in the following:
=
Telemetry is automated communication that processes from multiple data= sources. Telemetry data improves customer experiences, monitors security, = application health, quality, and performance.
For d= ifferent cases, the set of information referred to as telemetry data variat= es. For example, CPU and buffer utilization are valuable for virtualized en= vironments. In other words, I understand telemetry data as information extr= acted from a remote system that characterizes the system's state. In an= y case, providing a definition would be helpful to a reader of the document= .


>
> nit s/the the/the/

[TM] Agreed.

> I think that Abstract and Introduction can be improved by explaining t= he purpose of defining the Loopback and Active flags. What each of them is = intended to achieve and improve?

[TM] The point is well-taken, and the following text will be added to
the introduction. In order to avoid text repetition, I believe it
would be best not to add it to the abstract as well.

OLD:
-
NEW:
The Loopback flag is used to request that each transit device along
the path loops back a copy of the data packet to the sender. The
Active flag indicates that a packet is used for active measurement.
GIM>> Thank you for the proposed text. I have several n= otes to the new text:
  • As I understand the behavior requir= ed from a node processing the Loopback flag, the returned packet is not the= complete but truncated data packet.
  • Is "active measurement&qu= ot; used in the context of RFC 7799? If "yes", does that mean tha= t the packet is a specifically generated test packet?


> It is stated in the Introduction that:
>
>=C2=A0 =C2=A0 This document defines
>=C2=A0 =C2=A0 two new flags in the Pre-allocated and Incremental Trace = options: the
>=C2=A0 =C2=A0 Loopback and Active flags.
> Does that mean that neither of the two flags is applicable in the Dire= ct Export option? Should draft-ietf-ippm-ioam-direct-export have an explici= t statement regarding the applicability of the Loopback and Active flags? A= nd if any is applicable, describe the behavior of an IOAM node receiving it= .

[TM] Right.
The direct exporting draft explicitly states the behavior of each
field in the DEX option header including the flags, so there seems to
be no need to specify flags that are supported in other options.
GIM>> I'm a bit confused. Can you help me with the tex= t from the DEX draft that specifies the use of the Loopback and Active flag= s in combination with the DEX trace option?

>
> In Section 4 the purpose of using the Loopback flag is explained as: >
>=C2=A0 =C2=A0 Loopback allows an IOAM encapsulating node to trace the p= ath to a
>=C2=A0 =C2=A0 given destination, and to receive per-hop data about both= the forward
>=C2=A0 =C2=A0 and the return path.
> In my previous comments, I've pointed out that the Loopback mode i= s just a special case of the Direct Export option. In addition to that, I w= ould appreciate your explanation of how the IOAM encapsulating node receive= s per-hop data about the return path. How does that work, for example, in a= n MPLS or SFC NSH environment?

[TM] It is slightly similar to direct exporting, but is not a special
case of direct exporting. In direct exporting telemetry/operational
data is not pushed into the data packet, but the data packet with the
DEX option triggers the data collection and optionally also exporting,
but exporting is not mandatory and may be performed later, for example
by the management plane. On the other hand, a trace option with the
loopback flag causes all IOAM transit nodes to push IOAM data onto the
trace option, and also loop a copy of the packet back to the sender.
GIM>> Thank you for providing that comparison between = the result of processing DEX and the Loopback. As I understand it, the resu= lt of DEX, i.e., immediate=C2=A0export or local processing with exporting a= batch of telemetry data, is determined by the local policy. If that is the= case, the local policy can produce the same result as for the Loopback fla= g, which could be the default behavior for the DEX.


>
> Further it Section 4, it is stated that:
>
>=C2=A0 =C2=A0 The two IOAM looped back copies are
>=C2=A0 =C2=A0 terminated by the encapsulating node.
> But I don't see any technical explanation that could sustain that = assumption. As I understand the diagram in figure 1, a transit node doesn&#= 39;t know the identity of the IOAM encapsulating node. Correct? If that is = the case, where does the transit node direct the looped packet?

[TM] As described in the draft, the loopback flag is not necessarily
applicable to all possible encapsulations. The way the return path is
defined is encapsulation-specific. The draft currently states:

=C2=A0 =C2=A0Loopback can be used only if a return path from transit nodes = and
=C2=A0 =C2=A0destination nodes towards the source (encapsulating node) exis= ts.
=C2=A0 =C2=A0Specifically, loopback is only applicable in encapsulations in= which
=C2=A0 =C2=A0the identity of the encapsulating node is available in the
=C2=A0 =C2=A0encapsulation header.=C2=A0 If an encapsulating node receives = a looped
=C2=A0 =C2=A0back packet that was not originated from the current encapsula= ting
=C2=A0 =C2=A0node, the packet is dropped.
GIM>> = Please help me understand, the looped back packet is transmitted using the = same encapsulation as the data packet with the Loopback flag? What is the r= ationale? If we use MPLS LSP Ping as an example, the response can be sent i= n several ways, but the default is in IP/UDP encapsulation as the commonly = available transport. Why not use that and send the looped packet over IP/UD= P? I believe that the applicability of this mechanism will be much broader.=


> It seems that the text in the last paragraph attempts to walk around m= y questions. But I don't find that paragraph sufficient. It lacks the n= ormative language to guide a developer to produce resilient implementation.= For example, how to interpret:
>=C2=A0 =C2=A0 Loopback can be used only if a return path from transit n= odes and
>=C2=A0 =C2=A0 destination nodes towards the source (encapsulating node)= exists.
> That reads like a recommendation, not a requirement. As a result, an i= mplementation may transmit an IOAM packet with the Loopback fag set regardl= ess of whether there's a return path or not. Then, how must a transit n= ode process such an IOAM packet?
>

[TM] Right, the last response and quoted text is relevant here as
well. Please also note the following text from the draft:

it is assumed that the
=C2=A0 =C2=A0source address is available in the encapsulation header.=C2=A0= Thus, the
=C2=A0 =C2=A0source address of the original packet is used as the destinati= on
=C2=A0 =C2=A0address in the copied packet.

I propose to add the following sentence:
The loopback flag MUST NOT be set if it is not guaranteed that there
is a return path from each of the IOAM transit and IOAM decapsulating
nodes, or if the encapsulating node's address is not available in the encapsulation header.
GIM>> Thank you for the pr= oposed text. I'd note that referring to the "encapsulating node= 9;s address" and "source address" might be interpreted=C2=A0= as applying only to IP. In some networks, for example, BIER, the identity o= f the IOAM encapsulating node, BFIR, is known from its identifier that, in = turn, can be mapped to the IP address.


> A very concerning statement I've found in Section 4.1
>
>=C2=A0 =C2=A0 The encapsulating node either generates synthetic packets= with an
>=C2=A0 =C2=A0 IOAM trace option that has the Loopback flag set ...
> IOAM has been defined as a hybrid measurement protocol. This statement= implies that it is to be used as an active OAM protocol (all per RFC 7799 = definitions). The requirements for active OAM protocols in terms of their a= pplicability and, most of, security are very different from those set for a= hybrid measurement protocol. I believe that extending IOAM into an active = mode of measurement requires more discussion and the audience from other IE= TF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG.

[TM] This draft does not define an active measurement protocol. The
point in the draft is that the loopback flag can be used in active
measurement packets.
GIM>> I have to disagree. P= er RFC 7799, the use of specially constructed=C2=A0test packets is the prim= ary characteristic of an active measurement method. By introducing the Acti= ve flag, this drat makes the IOAM into an active measurement protocol with = all the requirements to an active measurement protocol to be applied.
=
The following text edit is proposed:

OLD:
=C2=A0 =C2=A0The encapsulating node either generates synthetic packets with= an
=C2=A0 =C2=A0IOAM trace option that has the Loopback flag set, or sets the = loopack
=C2=A0 =C2=A0flag in a subset of the in-transit data packets.=C2=A0 Loopbac= k is used
=C2=A0 =C2=A0either proactively or on-demand, i.e., when a failure is detec= ted.
NEW:
=C2=A0 =C2=A0The loopback flag can be set in the IOAM trace option either i= n a
=C2=A0 =C2=A0subset of the in-transit data packets, or in synthetic packets= that
=C2=A0 =C2=A0are generated by the encapsulating node. Loopback can be used<= br> =C2=A0 =C2=A0either proactively or on-demand, i.e., when a failure is detec= ted.

>
> The next statement explains the use case for the Loopback flag:
>
>=C2=A0 =C2=A0 Loopback is used
>=C2=A0 =C2=A0 either proactively or on-demand, i.e., when a failure is = detected.
> That is the same use of ICMP and LSP Ping. What is the benefit of usin= g the Loopback flag instead of readily available ICMP? Does it work as L2 L= inktrace? I don't see that as a sufficient benefit considering the comp= lexity, exclusions, and risks associated and identified in the draft. It is= clear that there are tools like ICMP and LSP Ping that adequately address = scenarios listed in the draft. Don't see any technical reason for the i= ntroduction of another mechanism that does not have any significant benefit= compared to the existing OAM tools. Especially, considering the limited in= formation that is allowed to be collected using the Loopback IOAM flag (&qu= ot;every transit node that processes this trace option only adds a single d= ata field, which is the Hop_Lim and node_id data field"). With the abu= ndance of information and additional verification achieved using ICMP and L= SP Ping, there's even less rationale in the introduction of this over-c= omplex and unnatural mechanism.

[TM] Right, as the draft says, the loopback flag is an "...alternative=
to Traceroute, that allows the encapsulating node to receive responses
from multiple transit nodes along the path". Indeed, it slightly
resembles ETH-LT (Ethernet Linktrace) in the sense that a single
packet from the encapsulating node allows to quickly trace the entire
path, but as with IOAM in general, using the loopback flag does not
mandate a specific encapsulation.
GIM>> Also, I = must note that "pro-active" use of the Loopback is possible only = as part of the active measurement protocol.=C2=A0

>
> The last paragraph states the requirement:
>
>=C2=A0 =C2=A0 IOAM encapsulating nodes MUST NOT push an IOAM encapsulat= ion with the
>=C2=A0 =C2=A0 Loopback flag onto data packets that already include an I= OAM
>=C2=A0 =C2=A0 encapsulation.
> I couldn't find any guidance on how an IOAM node that receives suc= h invalid combination processes the packet.
>

[TM] The current draft only specifies the flags. Specifically in the
scenario described above, the encapsulating node does not set the
loopback flag. This is intended to reduce the impact of potential
amplification attacks.
GIM>> I am still not clea= r about "MUST NOT push an IOAM encapsulation=C2=A0with the Loopback fl= ag" in the draft and your explanation "the encapsulating node doe= s not set the Loopback flag". As I understand it, in the given network= for the monitored data flow, only one IOAM encapsulating=C2=A0node can exi= st. If that is correct, where does the existing IOAM encapsulation come=C2= =A0from?

>
> It is assumed that the identity of the IOAM encapsulating node is know= n to the node that is expected to sent a copy of the received packet back. = But what if that is not the case? How must that node act?

[TM] Agreed. The following new text is proposed to be added to Section 4.1:=
If the address of the encapsulating node is not available in the
encapsulation header, then the transit/decapsulating node does not
loop back a copy of the original packet.
GIM>> I= think that points to the significant limitation of the proposed mechanism.= Comparing with MPLS LSP Ping, we see that it allows tracing the LSP even t= hough MPLS encapsulation does not identify the ingress LER while the propos= ed Loopback would not work at all.=C2=A0

> I believe that there's inconsistency between Figure 1 and the foll= owing text in Section 4.2
>
>=C2=A0 =C2=A0 Thus, the
>=C2=A0 =C2=A0 source address of the original packet is used as the dest= ination
>=C2=A0 =C2=A0 address in the copied packet.
> It seems that the text assumes that the IOAM encapsulating node adds a= lso a network layer encapsulation. But how would it work, for example, in S= FC NSH data plane? Or MPLS?

[TM] Right, the paragraph beginning with "Loopback can be used
only..." (discussed in response to one of the previous comments) makes=
that restriction.

>
> Section 4.4 states that
>
>=C2=A0 =C2=A0 If the Node ID matches the current
>=C2=A0 =C2=A0 IOAM node, it indicates that this is a looped back packet= that was
>=C2=A0 =C2=A0 initiated by the current IOAM node, and processed accordi= ngly.
> But according to the definition of node_id in Section 5.4.2.1 of draft= -ietf-ippm-ioam-data, "Node identifier field to uniquely identify a no= de within the IOAM-Namespace and associated IOAM-Domain." It appears t= hat simply comparing Node IDs is not sufficient to verify that the node rec= eived its looped back packet. What is your opinion?

[TM] Agreed. The following update is proposed:
OLD:
If the Node ID matches
NEW:
If the Node ID and IOAM-Namespace match


>
> If, as stated in Section 5,
>
>=C2=A0 =C2=A0 It [Active flag] is not intended as a replacement for exi= sting
>=C2=A0 =C2=A0 active OAM protocols, which may run in higher layers and = make use of
>=C2=A0 =C2=A0 the Active flag.
> Then the question, What is the purpose of the Active flag? Existing ac= tive protocols, Fault Management and Performance Monitoring, are identified= by, for example, use of a well-known destination port number or, in case o= f MPLS, Generic Associated Channel type. There's no apparent need of us= ing IOAM option header to identify the payload as a control message of an a= ctive OAM protocol. On the contrary, that would likely cause more confusion= and challenges to interoperation among different implementations.
>
> Three cases analyzed in Section 5 require special consideration, as th= ese likely present the motivation for the introduction of the Active flag:<= br> >
> the first use case is not really using the Active flag at all and thus= the text doesn't seem adding any value to the draft;
> it is not clear what is viewed as the benefit of using the Active flag= compared with using any of the existing active OAM protocols in the second= use case. I would appreciate it if you can clarify that for me. Since an S= FC NSH network is used as an example, is it required that a Service Functio= n (SF) or an SF Proxy process the IOAM header with Active flag set? Or woul= d a Service Function Forwarder (SFF) avoid sending a packet with the IOAM h= eader that has an Active flag set? And can you compare that with the proced= ures defined in the Active OAM for SFC draft?
> My questions for the third use case described in Section 5 are the sam= e as above because I don't see the benefit of using a replicated data p= acket (less benefits if it is truncated) compared to a special test packet.=
>
> In my conclusion on the Active flag, I don't see any clear benefit= of introducing it and using whether in place or in addition to the existin= g active OAM protocols.

[TM] General response to all the Active flag comments: this was
extensively discussed on the mailing list and in previous IETF
meetings, and your comments about the previous versions of the
document have contributed to greatly improving Section 5, which
describes the main use cases of the Active flag.
GIM&g= t;> I have to disagree with you here. I don't find the explanation= =C2=A0in the document sufficient to justify the introduction of another mec= hanism to achieve what has already been satisfactorily addressed in IETF. W= ithout a more detailed specification of the problem solved by the Active fl= ag and how that is achieved, this mechanism appears like the answer is look= ing for a question, like a loaded gun without safety.


>
> I am looking forward to your feedback and the continued discussion. >
> Regards,
> Greg
>
> On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.o= rg> wrote:
>>
>> Hello IPPM,
>>
>> This email starts a Working Group Last Call on two related IOAM do= cuments, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export.=
>>
>> In-situ OAM Loopback and Active Flags
>> https://datatracker.ietf.org/do= c/draft-ietf-ippm-ioam-flags/
>> https://datatracker.ietf= .org/doc/html/draft-ietf-ippm-ioam-flags-06
>>
>> In-situ OAM Direct Exporting
>> https://datatracker.iet= f.org/doc/draft-ietf-ippm-ioam-direct-export/
>> https://datatrac= ker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06
>>
>> Please provide feedback by replying to this email with your review= s and if you think these documents are ready to progress, by Wednesday, Sep= tember 15.
>>
>> Best,
>> Tommy & Ian
>>
>> _______________________________________________
>> 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
--0000000000008a03b605cdd987b9-- From nobody Sun Oct 10 10:23:42 2021 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 D01403A0A8D; Sun, 10 Oct 2021 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8HwYdUhh1pe; Sun, 10 Oct 2021 10:23:36 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597C43A0A90; Sun, 10 Oct 2021 10:23:36 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id y12so44895093eda.4; Sun, 10 Oct 2021 10:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oVc4ELEPEeyJfs3PWPUOfNixJJcw4BxVXN+3V5OpdBg=; b=TUfemlDRi34+Dty+LcCJHyq3530FZBMQdbgQvZ15BzrobKwDKoJKr2dYKbRmYTrwOb euLyTF72END3hKsFCTkK31srZgLsylwV2K7RkSLDKuCkLCbjROjEMGTt8GnohBgWslwl 2rSwvfCvKDHeTtPyhAyYqV15hm8uHGKHgwCPMnkxs2tqrCmK5xtlkKFIqd9QZw3D2RhY S/ROmmJr7/Opoy7h8rxFc/ma+rU7HDgwcBim8NoC2J9eeBDDXGJl6H5M4ClUGsOOU6HQ WqmWATSpVCefzQ5rYsjcxR31wQExjQuDlmPuvB2W0zTNSp/NxTsJgiP1jdWIwBrG3R2b YWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oVc4ELEPEeyJfs3PWPUOfNixJJcw4BxVXN+3V5OpdBg=; b=7952280GuTWaCcFVrkitsQdMQPqFYz7HIFt3r0D4ccY/hXPFGqfa9iPbGq58X3tpni hIUSWhCXq5kMpP5FnH+dG+OqylC+uCX3V1yNN5kAiKk/qQTl+0Iq9Dx82wCKC4xXJLB8 WmxvzCGIEcWnHiePauDTrqUCm9qlkVmXt2Ogs8U1msc7Guqd8lUIrvXoMDWxjavPWY/j RA71LBDCt4u+n4epMVKTTcrPB7Hyu8R0ctVshHalHc+tQ+U5VPua/QoWAA4IoVIshjee ZSYNISw5xPhTCVq8Vv+NBVWkhEHfMHuqEFW4Dy/X6aiPvDdy+QiMI7gJ7ZYbJLjbGmbK XuoA== X-Gm-Message-State: AOAM530taxEVlKbu5bVyI5oVV9o5SdZdaGS9OlylaaTGmk4RBQDBw5pF T3++pZfozvlN7H0mDOkYPOGebD9PwWIQhrra2NI= X-Google-Smtp-Source: ABdhPJwTiobo1wGiWx2dkGJvZBFXymclfjqNyhN6C3EcCGx7h3ldRrZTnun+OXuULw+S/P28bbGv8Vcl8ewEk3zq6G8= X-Received: by 2002:a50:e106:: with SMTP id h6mr34706697edl.295.1633886612108; Sun, 10 Oct 2021 10:23:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 10 Oct 2021 10:23:22 -0700 Message-ID: To: Tal Mizrahi Cc: Tommy Pauly , IPPM Chairs , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000001e396005ce02dfe6" Archived-At: Subject: Re: [ippm] WGLC for IOAM Direct Exports 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, 10 Oct 2021 17:23:41 -0000 --0000000000001e396005ce02dfe6 Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for carefully considering my comments and suggestions. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi wrote: > Hi Greg, > > Many thanks for the thorough review. > Below you can find responses to your comments, and in some cases > proposed text edits. > > If there are no further comments we will update the document accordingly. > > Thanks, > The authors. > > > On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky wrote: > > > > Dear Authors, WG Chairs, and All, > > I've read the latest version of the draft and have several comments and > questions to share with you. None of these are blocking, I support > progressing this draft to publication. Please consider the notes below as > an invitation to a discussion: > > > > It seems that the characterization of the Direct Export IOAM option in > the following is not entirely accurate: > > > > The DEX option is used as a trigger to collect and/or export IOAM data. > > > > I propose re-wording: > > The DEX option is used as a trigger to collect and export or only > collect locally the IOAM data. > > > > Using "exporting and/or collecting" reflects the use of the Direct > Export option type technically accurate but the order of actions is > backward. What are your thoughts? > > > > [TM] Right. The following text edit is proposed in the introduction. > > OLD: > This option is used as > a trigger for IOAM nodes to locally aggregate and process IOAM data, > and/or to export it to a receiving entity (or entities). > NEW: > This option is used as > a trigger for IOAM nodes to locally aggregate and process IOAM data, > and/or to export it to a receiving entity (or entities). Throughout > the document this functionality is referred to as collection and/or > exporting. > GIM>> As I understand it, it is the local policy that controls the behavior of the node receiving the IOAM DEX indicator. Similar to IPFIX, the information can be aggregated and exported as a calculated metric, e.g., percentile or mean value, or exported as soon as possible as recorded. The new text is certainly better but it seems it does not express the role of the local policy in defining the processing behavior, the transport to be used, and the identity of the Collector. One of possible ways could be to state that the definition of all these controls is outside the scope of the document. > > > > I find references to RFC 5475 and 7014 very appropriate and helpful. But > I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data. I > think that excessive use of not only the Direct Export IAOM option but the > IOAM method, in general, may adversely affect a network and the > recommendations listed in RFC 5475 and 7014 are equally applicable. > > Similarly, the good and helpful discussion of how to practically control > the use of the Direct Export option is, in my opinion, equally applicable > to other IOAM trace options and should be in the Security Considerations > section of draft-ietf-ippm-ioam-data. > > > [TM] The last two comments are about draft-ietf-ippm-ioam-data, which > is currently in IESG review. I will take this feedback with the other > authors to see how we can address this input at this point. > GIM>> Thanks. > > > > The second paragraph in Section 3.1.2 is re-phrasing if not repeating > what is already expressed in the last paragraph of the previous sub-section > (though the limit is applied to exporting telemetry information). I think > that it can be removed without any loss to the document. > > [TM] The second par of 3.1.2 refers to *exporting*, while the last par > of 3.1.1 refers to *encapsulating*, so these are two complementary > requirements. > GIM>> Is it the intention of this draft to define the encapsulation of exported information? What if the local policy mandates the node calculating p95 and p99 of packet delay and inter-packet delay variation? Can you help me by describing how these metrics are encapsulated? > > > > I think that it will be helpful to provide some recommendations, i.e., > SHOULD do this, how an implementation handles the excess of packets to > export. Drop silently, drop and log notification, or try to shape that flow? > > [TM] Assuming an amplification scenario, a large number of packets may > be dropped, so logging each drop may defeat the purpose. A drop > counter may be a good idea here, but this document does not really > define counter requirements in general, so it seems like more of an > implementation-specific aspect, or possibly can be considered as part > of the YANG model. > GIM>> I am still struggling to understand how IOAM DEX triggers amplification. Can you add more details, steps to help me understand it? > > > I was really puzzled by this requirement in Section 3.1.2 > > > > Exported packets SHOULD NOT be exported over a path or a tunnel that > > > > is subject to IOAM direct exporting. > > > > I hope you can clarify it for me. > > > [TM] As explained later in that paragraph: "This requirement is > intended to prevent nested exporting and/or exporting loops." > This was thoroughly discussed in the working group, and came out of > the security-related review. > GIM>> If the definition of exporting, including the encapsulation, choice of transport, and the Collector is outside the scope, then this statement, in my opinion, should be removed. If all these issues are in the scope, then there is more, much more information that is missing. > > > > > This requirement > > > > Furthermore, IOAM encapsulating > > nodes that can identify a packet as an IOAM exported packet MUST NOT > > push a DEX option into such a packet. > > brings up questions: > > > > How can a node identify a packet as the IOAM exported packet? > > [TM] The requirement means that if an encapsulating node's ACL can > detect exported packets, then DEX should not be applied. > GIM>> I think that whether this belongs in the document depends on the answer to my question above - what is in the scope of this document. > > > What should be done if the IOAM exported packet contains the IOAM header > with the DEX option? > > [TM] The current document does not require an IOAM transit node to > parse beyond the (external) IOAM encapsulation if there are nested > IOAM encapsulations. > GIM>> Same, as above - need to clarify the scope of the document first. > > > > > What is special about the decapsulating node that is not DEX-capable? > > > > A decapsulating node that does not support the DEX option > > MUST remove it, along with any other IOAM options carried in the > > packet if such exist. > > Shouldn't that be a general behavior of a decapsulating IOAM node? > > [TM] Right. The following text edit is proposed: > > OLD: > A transit IOAM node that does not support the DEX option SHOULD > ignore it. A decapsulating node that does not support the DEX option > MUST remove it, along with any other IOAM options carried in the > packet if such exist. > NEW: > A transit or decapsulating IOAM node that does not support the DEX > option SHOULD > ignore it. Note that as per a > decapsulating node removes the IOAM encapsulation and all its IOAM > options, > and specifically in the case where one of these options is a > (possibly unknown) > DEX option. > GIM>> Why is it SHOULD? In what situation a node MAY act on the DEX? > > > > > > The format of the first four-octet word in Figure 2 is different from > the format defined in draft-ietf-ippm-ioam-data: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Namespace-ID |NodeLen | Flags | RemainingLen| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IOAM-Trace-Type | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Is this intentional? If it is, how does an implementation know which > format to use? > > [TM] Each IOAM Option-Type has a different header format. The current > document defines a new Option-Type, which was not defined in > draft-ietf-ippm-ioam-data. > The IOAM-Type field in the lower layer header determines which > Option-Type is used and how its header should be parsed. > GIM>> Thank you for the clarification. Is that the intention to start new drafts to define the DEX IOAM Option-Type separately? > > > > > > It is stated in the draft that: > > > > The length of the DEX option is at least 8 octets. > > > > But the figure 2 in the draft does not include any field that reflects > the length of the IOAM option. Is that because the figure is out of sync? > If not, how can an implementation verify the length? Also, what is the > behavior if the length is less than 8 octets? > > > > [TM] Quoting the draft: > > The existence of the optional fields is > indicated by the corresponding flags in the Extension-Flags field. > ... > Thus, the Extension-Flags field explicitly indicates > the length of the DEX option. > > > > RE: PerformanceConsiderations > > > > I agree with you that a DEX-encapsulating node and DEX-transit nodes > must have rate-limiting controls (as noted earlier, the behavior of the > transit node needs more detailed specification). But I think that the > document should also note that exported packets could be sent over the > network out-of-band, relative to the monitored flow. As a result, the > impact of packets carrying telemetry information might be not direct and > harmful to the data flow. I see that as one of the important benefits of > the Direct Export method transporting on-path telemetry information. > > > > [TM] Right. The following new text is proposed: > > It should be noted that in some networks DEX data may be exported over > an out-of-band network, in which a large volume of exported traffic > does not compromise user traffic. In this case an operator may choose > to disable the exporting rate limiting. > GIM>> I think that the text can be stronger, recommending that information is exported out-of-band and explaining the interpretation of out-of-band in the case of IOAM. > > > > > Regards, > > Greg > > > > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> > >> Hello IPPM, > >> > >> This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags and > draft-ietf-ippm-ioam-direct-export. > >> > >> In-situ OAM Loopback and Active Flags > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > >> > >> In-situ OAM Direct Exporting > >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 > >> > >> Please provide feedback by replying to this email with your reviews and > if you think these documents are ready to progress, by Wednesday, September > 15. > >> > >> Best, > >> Tommy & Ian > >> > >> _______________________________________________ > >> 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 > --0000000000001e396005ce02dfe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Tal,
thank you for carefully = considering my comments and=C2=A0suggestions. Please find my follow-up note= s in-lined below=C2=A0under the GIM>> tag.

R= egards,
Greg

On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi = <tal.mizrahi.phd@gmail.com<= /a>> wrote:
H= i Greg,

Many thanks for the thorough review.
Below you can find responses to your comments, and in some cases
proposed text edits.

If there are no further comments we will update the document accordingly.
Thanks,
The authors.


On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Authors, WG Chairs, and All,
> I've read the latest version of the draft and have several comment= s and questions to share with you. None of these are blocking, I support pr= ogressing this draft to publication. Please consider the notes below as an = invitation to a discussion:
>
> It seems that the characterization of the Direct Export IOAM option in= the following is not entirely accurate:
>
> The DEX option is used as a trigger to collect and/or export IOAM data= .
>
> I propose re-wording:
> The DEX option is used as a trigger to collect and export or only coll= ect locally the IOAM data.
>
> Using "exporting and/or collecting" reflects the use of the = Direct Export option type technically accurate but the order of actions is = backward. What are your thoughts?
>

[TM] Right. The following text edit is proposed in the introduction.

OLD:
=C2=A0 =C2=A0This option is used as
=C2=A0 =C2=A0a trigger for IOAM nodes to locally aggregate and process IOAM= data,
=C2=A0 =C2=A0and/or to export it to a receiving entity (or entities).
NEW:
=C2=A0 =C2=A0This option is used as
=C2=A0 =C2=A0a trigger for IOAM nodes to locally aggregate and process IOAM= data,
=C2=A0 =C2=A0and/or to export it to a receiving entity (or entities). Throu= ghout
=C2=A0 =C2=A0the document this functionality is referred to as collection a= nd/or
exporting.
GIM>> As I understand it, it is the l= ocal policy that controls the behavior of the node receiving the IOAM DEX i= ndicator. Similar to IPFIX, the information can be aggregated and exported = as a calculated metric, e.g., percentile or mean value, or exported as soon= as possible as recorded. The new text is certainly better but it seems it = does not express the role of the local policy in defining the processing be= havior, the transport to be used, and the identity of the Collector. One of= possible ways could be to state that the definition of all these controls = is outside the scope of the document.


> I find references to RFC 5475 and 7014 very appropriate and helpful. B= ut I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data= . I think that excessive use of not only the Direct Export IAOM option but = the IOAM method, in general, may adversely affect a network and the recomme= ndations listed in RFC 5475 and 7014 are equally applicable.
> Similarly, the good and helpful discussion of how to practically contr= ol the use of the Direct Export option is, in my opinion, equally applicabl= e to other IOAM trace options and should be in the Security Considerations = section of draft-ietf-ippm-ioam-data.


[TM] The last two comments are about draft-ietf-ippm-ioam-data, which
is currently in IESG review. I will take this feedback with the other
authors to see how we can address this input at this point.
GIM>> Thanks.=C2=A0


> The second paragraph in Section 3.1.2 is re-phrasing if not repeating = what is already expressed in the last paragraph of the previous sub-section= (though the limit is applied to exporting telemetry information). I think = that it can be removed without any loss to the document.

[TM] The second par of 3.1.2 refers to *exporting*, while the last par
of 3.1.1 refers to *encapsulating*, so these are two complementary
requirements.
GIM>> Is it the intention of this = draft to define the encapsulation of exported information? What if the loca= l policy mandates the node calculating p95 and p99 of packet delay and inte= r-packet delay variation? Can you help me by describing how these metrics a= re encapsulated?


> I think that it will be helpful to provide some recommendations, i.e.,= SHOULD do this, how an implementation handles the excess of packets to exp= ort. Drop silently, drop and log notification, or try to shape that flow?
[TM] Assuming an amplification scenario, a large number of packets may
be dropped, so logging each drop may defeat the purpose. A drop
counter may be a good idea here, but this document does not really
define counter requirements in general, so it seems like more of an
implementation-specific aspect, or possibly can be considered as part
of the YANG model.
GIM>> I am still struggling t= o understand how IOAM DEX triggers amplification. Can you add more details,= steps to help me understand it?=C2=A0

> I was really puzzled by this requirement in Section 3.1.2
>
>=C2=A0 =C2=A0 Exported packets SHOULD NOT be exported over a path or a = tunnel that
>
>=C2=A0 =C2=A0 is subject to IOAM direct exporting.
>
> I hope you can clarify it for me.


[TM] As explained later in that paragraph: "This requirement is
intended to prevent nested exporting and/or exporting loops."
This was thoroughly discussed in the working group, and came out of
the security-related review.
GIM>> If the defini= tion of exporting, including the encapsulation, choice of transport, and th= e Collector is outside the scope, then this statement, in my opinion, shoul= d be removed. If all these issues are in the scope, then=C2=A0 there is mor= e, much more information that is missing.

>
> This requirement
>
>=C2=A0 =C2=A0 Furthermore, IOAM encapsulating
>=C2=A0 =C2=A0 nodes that can identify a packet as an IOAM exported pack= et MUST NOT
>=C2=A0 =C2=A0 push a DEX option into such a packet.
> brings up questions:
>
> How can a node identify a packet as the IOAM exported packet?

[TM] The requirement means that if an encapsulating node's ACL can
detect exported packets, then DEX should not be applied.
GIM>> I think that whether this belongs in the document depends on= the answer to my question above - what is in the scope of this document.= =C2=A0

> What should be done if the IOAM exported packet contains the IOAM head= er with the DEX option?

[TM] The current document does not require an IOAM transit node to
parse beyond the (external) IOAM encapsulation if there are nested
IOAM encapsulations.
GIM>> Same, as above - need= to clarify the scope of the document first.=C2=A0

>
> What is special about the decapsulating node that is not DEX-capable?<= br> >
>=C2=A0 =C2=A0 A decapsulating node that does not support the DEX option=
>=C2=A0 =C2=A0 MUST remove it, along with any other IOAM options carried= in the
>=C2=A0 =C2=A0 packet if such exist.
> Shouldn't that be a general behavior of a decapsulating IOAM node?=

[TM] Right. The following text edit is proposed:

OLD:
=C2=A0 =C2=A0A transit IOAM node that does not support the DEX option SHOUL= D
=C2=A0 =C2=A0ignore it.=C2=A0 A decapsulating node that does not support th= e DEX option
=C2=A0 =C2=A0MUST remove it, along with any other IOAM options carried in t= he
=C2=A0 =C2=A0packet if such exist.
NEW:
=C2=A0 =C2=A0A transit or decapsulating IOAM node that does not support the= DEX
option SHOULD
=C2=A0 =C2=A0ignore it.=C2=A0 Note that as per <xref target=3D"I-D.= ietf-ippm-ioam-data"/> a
=C2=A0 =C2=A0decapsulating node removes the IOAM encapsulation and all its = IOAM options,
=C2=A0 =C2=A0and specifically in the case where one of these options is a (possibly unknown)
=C2=A0 =C2=A0DEX option.
GIM>> Why is it SHOULD?= In what situation a node MAY act on the DEX?


>
> The format of the first four-octet word in Figure 2 is different from = the format defined in draft-ietf-ippm-ioam-data:
>
>=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A03
>=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5= 6 7 8 9 0 1
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 Namespace-ID=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|NodeLen=C2=A0 | Flags | RemainingLen|
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= OAM-Trace-Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
> Is this intentional? If it is, how does an implementation know which f= ormat to use?

[TM] Each IOAM Option-Type has a different header format. The current
document defines a new Option-Type, which was not defined in
draft-ietf-ippm-ioam-data.
The IOAM-Type field in the lower layer header determines which
Option-Type is used and how its header should be parsed.
GIM>> Thank you for the clarification. Is that the intention to st= art new drafts to define the DEX IOAM Option-Type separately?=C2=A0


>
> It is stated in the draft that:
>
> The length of the DEX option is at least 8 octets.
>
> But the figure 2 in the draft does not include any field that reflects= the length of the IOAM option. Is that because the figure is out of sync? = If not, how can an implementation verify the length? Also, what is the beha= vior if the length is less than 8 octets?
>

[TM] Quoting the draft:

=C2=A0 =C2=A0The existence of the optional fields is
=C2=A0 =C2=A0indicated by the corresponding flags in the Extension-Flags fi= eld.
=C2=A0 =C2=A0...
=C2=A0 =C2=A0Thus, the Extension-Flags field explicitly indicates
=C2=A0 =C2=A0the length of the DEX option.


> RE: PerformanceConsiderations
>
> I agree with you that a DEX-encapsulating node and DEX-transit nodes m= ust have rate-limiting controls (as noted earlier, the behavior of the tran= sit node needs more detailed specification). But I think that the document = should also note that exported packets could be sent over the network out-o= f-band, relative to the monitored flow. As a result, the impact of packets = carrying telemetry information might be not direct and harmful to the data = flow. I see that as one of the important benefits of the Direct Export meth= od transporting on-path telemetry information.
>

[TM] Right. The following new text is proposed:

It should be noted that in some networks DEX data may be exported over
an out-of-band network, in which a large volume of exported traffic
does not compromise user traffic. In this case an operator may choose
to disable the exporting rate limiting.
GIM>> I = think that the text can be stronger, recommending that information=C2=A0is = exported out-of-band and explaining the interpretation of out-of-band in th= e case of IOAM.

>
> Regards,
> Greg
>
> On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.o= rg> wrote:
>>
>> Hello IPPM,
>>
>> This email starts a Working Group Last Call on two related IOAM do= cuments, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export.=
>>
>> In-situ OAM Loopback and Active Flags
>> https://datatracker.ietf.org/do= c/draft-ietf-ippm-ioam-flags/
>> https://datatracker.ietf= .org/doc/html/draft-ietf-ippm-ioam-flags-06
>>
>> In-situ OAM Direct Exporting
>> https://datatracker.iet= f.org/doc/draft-ietf-ippm-ioam-direct-export/
>> https://datatrac= ker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06
>>
>> Please provide feedback by replying to this email with your review= s and if you think these documents are ready to progress, by Wednesday, Sep= tember 15.
>>
>> Best,
>> Tommy & Ian
>>
>> _______________________________________________
>> 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
--0000000000001e396005ce02dfe6-- From nobody Mon Oct 11 06:57:46 2021 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 DEFFE3A0C36 for ; Mon, 11 Oct 2021 06:57:43 -0700 (PDT) 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, 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=guest.telecomitalia.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1vX9VXQbA2p for ; Mon, 11 Oct 2021 06:57:37 -0700 (PDT) Received: from mx05.telecomitalia.it (mx05.telecomitalia.it [156.54.232.21]) (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 9C3263A0C3B for ; Mon, 11 Oct 2021 06:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=guest.telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@guest.telecomitalia.it; t=1633960652; x=2497874252; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=aH8jLe7K2WlB+V7a5xPhiUr27SLHD473qaDpS85LpZk=; b=XdsF6mNjEAxg3PBRsTXBX78Y4xESWCeB6Cq4Ew3drCkea0jqQzKjJwYHX2cn1SDJ qFVxctbOY6X0TWkOMpAJueMLMWBxUtVpC03aiZnZm9EgdKBvdIV7seJDPJffUBZf PUgcMX8bI+MfbsU5tNZA4Ar7sAngkzvwsHXkPo8fyZ7TDT9dCfhZBa23N+57Bt7D vUd5fWhzRjBa9VLUPeg2adziDCL4oPte2KKGOAbH6t8KzmreGTM+LUbVJzS+wKEe v5Rq6B569REiNDNElq3Bvaa8XIFdrErndsiUxuJ53dXCxHGcl3yWECGAPauprFWP ZweyqGtLk6R5kOQ7m/+/nQ==; X-AuditID: 0a5a2d15-996f870000008b41-d2-616442cc1547 Received: from TELMBXD12BA020.telecomitalia.local ( [10.90.43.47]) by mx05.telecomitalia.it () with SMTP id 6C.2A.35649.CC244616; Mon, 11 Oct 2021 15:57:32 +0200 (CEST) From: "Bulgarella Fabio (Guest)" To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [EXT] [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF5T6L90iKV9KkKwvRhZQBRPkKvN0b4X Date: Mon, 11 Oct 2021 13:57:32 +0000 Message-ID: <1633960651877.28757@guest.telecomitalia.it> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [5.8.125.37] Content-Type: multipart/alternative; boundary="_000_163396065187728757guesttelecomitaliait_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsXCFaWtr3vGKSXR4NRGTYueB++YLXomvWJ2 YPI4sewKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIub8ooOK9YMeF1VgPjBtkuRk4OCQETiblN P5i7GLk4hARWMUpMe3GavYuRg4NNwEti9h1lkBoRgVSJnuP3mUBsYYFgiTUNc1gh4iESv/63 s0HYRhInt1wFi7MIqEpsODkJrJ5XwEJizfxVYHEhARuJ/+f3gcU5BWwl1vTuYgexGQVkJSbs XsQIYjMLiEu8mH6CHeI2AYkle84zQ9iiEi8f/2OFsA0kti7dxwJhy0ms2d8BdjKzQJzE7OZK iLWCEidnPmGZwCg8C8nUWQhVs5BUQZToSdyYOoUNwtaWWLbwNTOErSsx498hFmTxBYzsqxhF cysMTPVKUnNSk/NzM0sSczIT9TJLNjGCo0ZXdAfjthVv9A4xMnEwHmKU4GBWEuF9y5GSKMSb klhZlVqUH19UmpNafIhRmoNFSZw3HxiPQgLpiSWp2ampBalFMFkmDk6pBqb92VYhubLOli+n HqyuLHjZ5Niiei4tWG6R4qEntXssZ//XK5jnutXyzoXcgH1eR/UsmvI/W67ky/HYF7Phieed ncLiDZl39DqX/t27KbjItn3TkwCp68pcU756XvYXNpbpZj+j9jcnUmCZj9dSjqD8JM+82emH mC4/jwphiWq7uE3rsMWv7y0Hpz0QdeR03bJdyfPkYof/qQ+2lz/3aPRQljedMPfAL/53Xp+S HZ9bhO5V+be47VE+s4N5c/2vpb+qLh048WBegI/0mljul29VPq5cYmH1s0xTnKswPeiHN7/E fYGPRWt3lSwR1TKeY/m6kz1QVjNN5ktq2fWEuVHMv258i2i/+NB3wam51kosxRmJhlrMRcWJ ANuaRCoJAwAA Archived-At: Subject: Re: [ippm] [EXT] Adoption call for Explicit Flow Measurements Techniques 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, 11 Oct 2021 13:57:44 -0000 --_000_163396065187728757guesttelecomitaliait_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi WG, Chairs, I support the adoption of this document as author. These passive e2e methodologies for perfomance measurement are quite import= ant for TELCOs as they contribute to evaluate the quality of service delive= red to the customer?. Best Regards, Fabio B. ________________________________ Da: ippm per conto di Tommy Pauly Inviato: venerd=EC 8 ottobre 2021 17:59 A: IETF IPPM WG (ippm@ietf.org) Oggetto: [EXT] [ippm] Adoption call for Explicit Flow Measurements Techniqu= es Hello IPPM, This email starts an adoption call for draft-mdt-ippm-explicit-flow-measure= ments, "Explicit Flow Measurements Techniques". This document is proposed a= s an Informational document that describes techniques that go beyond single= bit markings like the QUIC spin bit. https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/ https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurem= ents-02 This adoption call will last until Friday, October 22. Please review the do= cument, and reply to this email thread to indicate if you think IPPM should= adopt this document. Best, Tommy --_000_163396065187728757guesttelecomitaliait_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi WG, Chairs,


I support the adoption of this document as author.

These passive e2e methodologies for perfomance measurement&nbs= p;are quite important for TELCOs as t= hey contribute to evaluate the quality of service delivered = to the customer​.


Best Regards,

Fabio B.



Da: ippm <ippm-bounces@i= etf.org> per conto di Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.or= g>
Inviato: venerd=EC 8 ottobre 2021 17:59
A: IETF IPPM WG (ippm@ietf.org)
Oggetto: [EXT] [ippm] Adoption call for Explicit Flow Measurements T= echniques
 
Hello IPPM,

This email starts an adoption call for draft-mdt-ippm-expli= cit-flow-measurements, "Explicit Flow Measurements Techniques”. = This document is proposed as an Informational document that describes techn= iques that go beyond single bit markings like the QUIC spin bit.

https://datatracker.ietf.org/doc/dr= aft-mdt-ippm-explicit-flow-measurements/
https://datatracker.ietf.org= /doc/html/draft-mdt-ippm-explicit-flow-measurements-02

This adoption call will last until Friday, Oc= tober 22. Please review the document, and reply to this email thread to= indicate if you think IPPM should adopt this document.

Best,
Tommy
--_000_163396065187728757guesttelecomitaliait_-- From nobody Mon Oct 11 15:29:55 2021 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 648DE3A0E9E; Mon, 11 Oct 2021 15:29:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-ippm-ioam-data@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, Al Morton , acm@research.att.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163399139337.5936.5073810021440741362@ietfa.amsl.com> Date: Mon, 11 Oct 2021 15:29:53 -0700 Archived-At: Subject: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-ioam-data-15: (with DISCUSS and 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: Mon, 11 Oct 2021 22:29:54 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ippm-ioam-data-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the many updates and email discussion about the relationship between limited (network) domains, IOAM domains, IOAM namespaces, and the like -- I think I do now have a pretty clear picture of how they're expected to interact! However, I think there may still be a couple places in the document that need to get updated in order to match that vision. One point here, and some (more minor) instances in the COMMENT section... Section 5.2 has: The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating node is always performed within a specific IOAM-Namespace. This [...] described above, that is added in a future revision. An IOAM decapsulating node situated at the edge of an IOAM domain MUST remove all IOAM-Option-Types and associated encapsulation headers for all IOAM-Namespaces from the packet. The "MUST remove [...] for all IOAM-Namespaces" at the end seems to conflict with the notion of the role of IOAM-decapsulating node being performed within a specific IOAM-Namespace. Indeed, later on in Section 5.3 we see that namespace identifiers "allow devices which are IOAM capable to determine: [...] o whether IOAM-Option-Type(s) have to be removed from the packet, e.g., at a domain edge or domain boundary." If a decapsulating node always had to remove IOAM options from all namespaces, then the namespace identifier is irrelevant to whether option type(s) are removed from the packet. [the following paragraph is retained unchanged from my ballot position on the -12, since the topic seems to still be open.] As foreshadowed in https://mailarchive.ietf.org/arch/msg/last-call/Ak2NAIKQ7p4Rij9jfv123xeTXQY/ I think we need to have a discussion about the expectations and provisions for cryptographic (e.g., integrity) protection of IOAM data. >From my perspective, IOAM is a new (class of) protocols that is seeking publication on the IETF stream as Proposed Standard. While we do make exceptions for modifications to protocols that were developed before we realized how important integrated security mechanisms are, it's generally the case that new protocols are held to the current IETF expectations for what security properties are provided; the default expectation is that a protocol is expected to provide secure operation in the internet threat model of RFC 3552. This draft currently only provides a brief note in the security considerations that there exists an individual draft (draft-brockners-ippm-ioam-data-integrity) that might provide ways to protect the integrity of IOAM data fields. Shouldn't the security mechanisms be getting developed side-by-side by the protocol mechanisms, to ensure that they are properly integrated and fit for purpose? (This does not necessarily have to be in the same document and could be part of a cluster of related documents, but I don't think that an informative reference to a non-WG draft really qualifies.) [new disucssion on this topic as of the -15] The discussion on this topic was over a rather protracted timescale, for which I share much of the blame. I think that the latest message is https://mailarchive.ietf.org/arch/msg/ippm/POycw2NpSl5cIruqSimTa_4WrwI/ where I make a proposal to have some text about how actual use of these data fields in a protocol or encapsulation needs to provide some (possibly optional) mechanism for cryptographic integrity protection, which could be draft-brockners-ippm-ioam-data-integrity but could also be native to the encapsulation format. I think that such a construction would allow this document to proceed to RFC without waiting for the other one to be complete. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All-new (okay, almost all) comments as of the -15. Mentioning here for lack of a better place, I happened to follow the reference to draft-brokners-opsawg-ioam-deployment, which seems to still be using the old definition of transit node and should get updated to match this document's definition. Section 5.2 IOAM is expected to be deployed in a specific domain. The part of the network which employs IOAM is referred to as the "IOAM-Domain". In light of the (new) text up in §5, we might consider rewording this part as well, mostly to avoid mentioning "network" that risks confusion about "network domain" (pre previous discussion). An "IOAM transit node" read and/or write and/or process one or more of the IOAM-Data-Fields. If both the Pre-allocated and the Incremental Trace Option-Types are present in the packet, each IOAM transit node based on configuration and available implementation of IOAM populates IOAM trace data in either Pre-allocated or Incremental Trace Option-Type but not both. [...] Since we redefined transit nodes to include only reading, in addition to modifying, it doesn't seem 100% accurate to say that "each transit node populates [one or the other but not both]" -- it seems valid for a transit node to populate zero of the trace option types. Section 5.3 An IOAM-Namespace can be associated to a subset or all of the the IOAM-Option-Types and their corresponding IOAM-Data-Fields. IOAM- This sentence seems confusing to me. It talks about namespaces as if they contain options, but if we go on to examine the actual data structures each option has a field to indicate the associated namespace. We even go on to say that the IOAM-Namespace field "MUST be included in all future IOAM-Option-Types" (side note: might be worth calling that out in the guidance in the IANA considerations, and also to specifically say that it's the first field of the option). So it's really not clear to me what this sentence is adding -- would it be safe to just remove it? o IOAM-Namespaces can be used by an operator to distinguish different operational domains. Devices at domain edges can filter on Namespace-IDs to provide for proper IOAM-Domain isolation. I suggest tweaking the wording to clarify that the "different operational domains" in the first sentence are precisely the "IOAM-Domain"s of the second sentence. * Assigning different IOAM Namespace-IDs to different sets of [...] There are two instances of a bullet point that talks about assembling a full trace from partial traces, but the text has substantial differences. I suspect that one is just an editing artifact and should be removed, but am less sure which one has the intended text (I would guess the latter, for what it's worth). Section 5.4 "IOAM tracing data" is expected to be collected at every IOAM transit node that a packet traverses to ensure visibility into the entire path a packet takes within an IOAM-Domain. [...] Since we redefined transit nodes to include only reading, this "is expected to be collected" doesn't seem entirely representative anymore. [...]. If not all nodes within a domain support IOAM functionality as defined in this document, IOAM tracing information (i.e., node data, see below) will only be collected on those nodes which support IOAM functionality as defined in this document. [...] Similarly, I might s/will only/can only/ here for the same reason. Section 5.4.2 Some IOAM-Data-Fields defined below, such as interface identifiers or IOAM-Namespace specific data, are defined in both "short format" as well as "wide format". "Short format" refers to an IOAM-Data-Field which comprises 4 octets. "Wide format" refers to an IOAM-Data-Field which comprises 8 octets. [...] We have definition entries for short/wide format in Section 3, so these clarification sentences may not be needed. Section 5.5 draft-ietf-sfc-proof-of-transit might be undergoing significant changes prompted by the results of its secdir review thread. I don't object to leaving this discusison in place but it may be prudent to think about paring down what we say here. In particular, there seems to be some (admittely, small) chance that the SFC doc will not have exactly two POT types. Section 6.3 It seems that in going from the -12 to -15 we lost the paragraph about leap seconds here. My understanding is that posix timestamps *are* affected by leap seconds, and so it is correct to include such a statement. My ballot comment on the -12 was conditioned on the use of TAI for the epoch, and thus my comment on the -12 is irrelevant. Section 10 We should probably say that the opaque snapshot, namespace specific data, etc., will have security considerations corresponding to their defined data contents that should be described where those formats are defined. [ed. this remains unchanged from my comment on the -12; I'm not sure if the intent to add some text just got overlooked, but don't intend to rehash any discussions that were already made.] Since we clarified the definition of transit nodes to include read-only transit nodes, we might want to say something about how transit nodes that only implement support for one or the other trace option types (as is clearly permitted) will have an incomplete picture of the trace in cases where both trace option types are used for the same packet. In many cases that is innocuous, of course, but it does not seem guaranteed to always be so. allowing attackers to collect information about network paths, performance, queue states, buffer occupancy and other information. One possible application of such reconiassance is to gauge the effectiveness of an ongoing attack (e.g., if buffers and queues are overflowing). I don't know whether it's particularly useful to mention that scenario here or not, though, and the lack of response the previous time I made the comment suggests that it's not actually useful to mention it. Indeed, in order to limit the scope of threats mentioned above to within the current network domain the network operator is expected to enforce policies that prevent IOAM traffic from leaking outside of the IOAM domain, and prevent IOAM data from outside the domain to be processed and used within the domain. On the -12, I said "it would be great if we could provide a bit more detail on the scope of consequences if the operator fails to do so." Some of the follow-up discussion suggested that draft-brockners-opsawg-ioam-deployment would be a better home, which I don't object to; I'm retaining this comment just in case there was actual desire to put such content in this document. No specific reply is expected or required, either way. NITS Section 5.3 controllers. For example, the node identifier field (node_id, see below) does not need to be unique in a deployment (e.g., if an operator wishes to use different node identifiers for different IOAM layers, even within the same device; or node identifiers might not be unique for other organizational reasons, such as after a merger of two formerly separated organizations), the Namespace-ID can be used as a context identifier, such that the combination of node_id and Namespace-ID will always be unique. This looks like a comma splice (maybe put a sentence break after the long parenthetical?). * Assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using the Namespace-ID as a selector at the IOAM encapsulating node, a full trace for a flow could be collected and constructed via partial traces in different packets of the same flow. Example: An operator could I think s/Assigning/By assigning/ (note the comment that indicates there are "two copies" of this text). Section 5.4 o Time of day when the packet was processed by the node as well as the transit delay. Different definitions of processing time are feasible and expected, though it is important that all devices of an in-situ OAM domain follow the same definition. I think we've been standardizing on the "IOAM domain" spelling. From nobody Tue Oct 12 05:09:19 2021 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 D44A13A0A3D for ; Tue, 12 Oct 2021 05:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecomitalia.it header.b=Coezmwxp; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=telecomitalia.onmicrosoft.com header.b=zAgXHUGA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLXN51pH1T1X for ; Tue, 12 Oct 2021 05:09:05 -0700 (PDT) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982823A0A41 for ; Tue, 12 Oct 2021 05:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@telecomitalia.it; t=1634040539; x=2497954139; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=lGyfdJjgqISwR4/OgL6QrGyruVCYXPTjzSVyNB5tWMg=; b=Coezmwxpc8hdZx9IqFEQ1A0vqJfd/xOzOj3iyQjuWg0ziD1s+JVd35gyKwPkZZl0 JVavhuseL/SNjNtCcxcuzu6XercjBPYItds04P7FfmLQaVJaCJGbYuJ1OYvOdhRc z+0BB0EX86nCD9D0gCVeOo0NIctnhXV1dcXjlCWzNHCPYgjHQfCigR6HDDFUl4u6 rYnTWExebVjrLE39XZqP//yP1ssFZLHMQe3M0A5JJit0v2ikIt9V+UIXPe61A7zw iFGIy3JBVqcyKIBh84Z/xTFL6+Q9tmAT3TQ6mXWHA8SHRbKPYh0BEATyTwpQ6eRv BuMp78FmWmTsnr9/7qK/PA==; X-AuditID: d9a97918-059ca70000000a23-9b-61657adbf435 Received: from TELMBXA15RM001.telecomitalia.local ( [10.14.252.92]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 47.1D.02595.BDA75616; Tue, 12 Oct 2021 14:08:59 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nRzSwNZhYLPOu7/TQ30VG9u2/EGJNBS6GwPQqVz9vjPM1pRN6B3/qAH6352+SvXr7DoNsVRajg3gzB+KTBFt5y+2StS43eTdUezSp6m8k3Ck3n3BNWn9M1XXn2HEGhtRN/s8zys7uxslHqOkf4bEZXAU3vsZrGfc1Qx09VhyTwudUyhQg2oN5f3kx0HOT9Ut+4xmHyik1uzh6Vtdo2kYgEGlZKn9LZ40pNex36ZHSmmj2Qq8K9fVVQ9YMVU2tXmDUFAhvboxVSCUd4dINc0I3nG84ywtzbfQNRkItmWH3suRJo+GWUBPNDOytaSn11Jwe1mnNgfY7QjCRw8+dYAKKQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+eF9gayjhVEiwlM5AEZ7DCnsdTNowS1dQcFgBJgYe6o=; b=Nda/DmspqBBLuTQPG6jLCM6FMezQG2gVLVExgwEuQK01FIXumsRT3GGA78oMaQLaWsp/sHM7nF5oHQAYDLTie4guMdrwgORTr5j9d11D7/lvHsD9BzsCiss9RM5U3zK3/B8PkOFMbanude1K7sHTNP/4SpFS+ibv5eQiI83zyQ0AjkYgXQ+3zU95KxuQBOXzqA4K2Se2dGDz/5SczA499g2FvEYz4EBhP0QpfOEkMxqK0FS7ZIXae6+1rj5qmPp/bX4vqXfPuM/rJGwnhZ98CuSOGuFn/zZOPIg4dltT1Vat+vpH6/kKOTwwCrcV+jixBuoILPujEbwPI8X0c4MfOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telecomitalia.it; dmarc=pass action=none header.from=telecomitalia.it; dkim=pass header.d=telecomitalia.it; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecomitalia.onmicrosoft.com; s=selector1-telecomitalia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eF9gayjhVEiwlM5AEZ7DCnsdTNowS1dQcFgBJgYe6o=; b=zAgXHUGArq+qYY/qnvsVYMxm+IL2ykSVOgnx3RiO+6K1VoYSGZMM4/2Tdkg10PM5dpSKFTpFfukxCOZzHN04l4e02JXdfq8qBLbPG1CGKihKJX4+4QFXieLC+tp/PPLXUYYfYSIxMjvjNOZrV4uv/W0weOvrPg2qi7erIOEWGuY= From: Cociglio Mauro To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [EXT] [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF5Xl+BNkhj35UuJ9LT7tAU846vPMasg Date: Tue, 12 Oct 2021 12:08:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Enabled=true; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_SetDate=2021-10-12T12:00:12Z; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Method=Privileged; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Name=PUBBLICO; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_SiteId=6815f468-021c-48f2-a6b2-d65c8e979dfb; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_ActionId=ceb2fe6c-a941-4798-9710-4a38da0b2434; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_ContentBits=0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=telecomitalia.it; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afe91d18-bf18-4625-8dd6-08d98d79119f x-ms-traffictypediagnostic: DB9PR07MB7242: x-microsoft-antispam-prvs: x-ti-disclaimer: ADBanner x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ca1OrpVwIguyupLucJh78sPa75oh1GOp/zMmHqf4jft7b2pO5n0dGb37ABQ+XXM8a59uE0z9+JBQPnWjoXH/xk8pctEIS2qt297ZdZEMw5JQ/wpCArVlYf74tdufM0bN6VKaNloEA29yvqsurP0DEvtTtiuBxzU4cbvnjAyG9VDI65HRr7QkqpjIHdJZrz2Ews6WSXcXt0TLpEUtq/n3aJmZGUMrsxmGpjyTnPisSOALtNpkRvc75mD9HUHBZpyT9I3B7j2gxKbSPCUTUrJ25l7cWubpbtFO9FJMY01ibw40UXlsHdkcP9gK8kEoUZO33ggzh1dRtud5Bj99mZ5oVSJaOeMgDxDMGqQbQ9/87ZD6nD3ogcWPQkvPDilG4jzwKmWWRp2AXQCGBBjWJLjk0J1PF4oDVoW5l6iIL1xFkOARNbbY/ZjJ8auDPJd6E76S13as/gnBUooe0NtM9BAZ2DIlpb6D/QzUhGtb+U735aAMndDChYjgCLgcI8V7ODhhBY1r3+kGBKLSLDYGi5HNxbcYNexZ9n3iojhNB6sFPAF2/1yIjrjuRhQ5/gxgHPwaEOpqoUqqWtgoPQcAOK+aQFGpdUKLWx3OSg/xEgcRltiqs8iy9HBSIz0+c1syC2sxA0PQwDR1MWLENkcpCcuv8mJka5NsLIZ161oXpQX7zQC3IFOOBoz764BmTpRA3oFBwO79Tuhgg6bWLlL8DapFKYMMCijGa0PSfpsV9ci/Bho/AOuC4tHykMGh9HZyyuw+vRl61tkcB+b5Ht7+drtmjyhWi7acZsKhobQ21BnvuaM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR07MB6775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(38100700002)(66446008)(66476007)(33656002)(2906002)(38070700005)(166002)(52536014)(5660300002)(64756008)(508600001)(8676002)(7696005)(6506007)(8936002)(66946007)(86362001)(76116006)(966005)(71200400001)(186003)(26005)(316002)(55016002)(122000001)(110136005)(19627235002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TVo4WlpKR1VDZGd3ZXlDRTVqL2J2N1Vsam85L1RHb2luaXE2VHJpMkFPNitE?= =?utf-8?B?UFlsdk85SnIyeVpqdUhHRzdyNTZRZHhQbWZETVYvRHFSMkxhNERWL1NrdGhq?= =?utf-8?B?TjBOa1U4dFN1Q0hVK1B0WXdiTndWWEJFVUNXUVh5MDJvVS9ySGVYMzlkTWdC?= =?utf-8?B?bWE4NXpSSXBFOFBQS040S3V5d1NRR0RsT3F6K205VGIwOVo2SSsvU20yTTk3?= =?utf-8?B?QlR5R0pHU2dpWUx5cklxdm5hZkFITG4ycU5QRzFKb1Y4L3IwRzUxVTNCMjlY?= =?utf-8?B?RlJXL1lkVDZnbnJJMndEaXhBZ1ZxWjRHUVlpZitSeHpGaEZPODd6M2JmN2tL?= =?utf-8?B?V2dEMHZLUzl2TXNsNm1PQmI0Y1BLSFVFNVY5dTJYODd3eGUxaWVOVXZtb2RB?= =?utf-8?B?am1tblNZY0tGbllSbUpwYVBoSXNsaUZrdStTNnJYRkxDekRIeTNpd3E2TExT?= =?utf-8?B?azZNc1phUXRTUmp6U0V5bFN5T3Q0SXFNc0xoRjIzSWUrdGZrU250ajQvOCtk?= =?utf-8?B?VTkrNURoV1NoYTJ6NnVvWjZMVFZMV0h1aTZadmM3NjIxR3RrejVwVkNLTGZ3?= =?utf-8?B?VklSRGh6aWJuWWxCSnRRN1ZuSmc2RlRxN1JUcmV4Q3NEczdFRDUwc0YydkM2?= =?utf-8?B?WklzeFA0eDA5YW9KSEd4dklqc0FsNnZNTk51bFJTTHpWMHVsZmZuMEFxTlZq?= =?utf-8?B?dmtjRDJ4L1o4MGp4R3c4am0zSDJMbGI4SVNpejZCWGdKejFHTUR3Z3dITUFO?= =?utf-8?B?dndUOWp3MWtEeTRSMmFSVlVtL2RUc0pLb1hPYTRiTVNaNEIzZTM1c2kyUGd1?= =?utf-8?B?WVI2WkYxdXFhYlBMYVVGKy9MVi9tZFRqTnF4YmxPS2s1cnZXbTBJdnRkZjEw?= =?utf-8?B?NU9EWHo1NjY1K0o4MGpWM3NZdDNNYWdhTktEZmFPSGE1a3YvZUZZYkRlMlFn?= =?utf-8?B?ZHFXTnd3bDVzMlFzQWd4T3J0Z0JVTjYxdTBCNk9JQ3dreGRENUl6bmRnT2hi?= =?utf-8?B?d1BDS09qM2RVOSt2bm9XTHprS3YweitaS29mVWdURnl4b3E3WlFrNDRUelRP?= =?utf-8?B?amZ0UFQ5ZE90MTgzTzhwOWRIbWdsMFR6R3dyd0xGNE1lWUxKOVZEdkhlZWFH?= =?utf-8?B?VXRKRjNRdG95bHNUZ3dKejl2UmdRUVo2TTFtOEZNK3BYMVhQR3NTdkxXL3JW?= =?utf-8?B?MjFpdHM3Nm9TcmdJNVZMRG1mc2d4UHZTNUFOT0dEWVRLT3FGMVE1dzJxT0N4?= =?utf-8?B?OFBvY0hUYmRMUXpDTnBMSGVsNUpuRzVDYVpSOU9jbVpCck1WdHRxdU5vQjVC?= =?utf-8?B?dldicXJIRkNteGNCSGM4MG8yUUxheTNRK3hkRUM4ZG93dGpLZWUySEtOWGtR?= =?utf-8?B?dGJPVWhEbFdCTFM5VUUxV05qUGtFeGRiZW9TWFozV3VQZ252ZTZ4aE12TVI3?= =?utf-8?B?K0RzMVJZcGFWNGxTdVRySnM3WkZGajhNZ1FySmlqbUc1MHdmR2RzTnhVdk9W?= =?utf-8?B?VFdEUHVIdk1SQVR4OVhsRkc4Q1h6ZVFjK3Izd1paMHFsQm5TTExYUnRXM2Zw?= =?utf-8?B?VlV6VTFrblkzRWFoQXFlV1R0cjRubjIxSlhEcy81dDFmYXBVRENHMUlKRDY4?= =?utf-8?B?clRvVkNXbzUyVGNPWGlPUENzSWRzcXB1ZVJWWXZiREU3QTdNaHRWNmdKbGh6?= =?utf-8?B?ZFErN2RPbWlqWHRPeUlRWEdaclFXaDhQbk5qWGdKbmh4U1RRalo2QWs1TGpu?= =?utf-8?Q?PqDOYBFPlE2lZ7ERlM=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBAPR07MB67751EBDE930EE67E7F82B80E9B69DBAPR07MB6775eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBAPR07MB6775.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: afe91d18-bf18-4625-8dd6-08d98d79119f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 12:08:57.5017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6815f468-021c-48f2-a6b2-d65c8e979dfb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P6C6XUnZk29Vwxi8BLTIe79UHO+uW4jq4u6TuWgXLFb0799U03Fq73/ZhEuZIM0P+3WuRSfBPdcqryNFCaFIDyoJc8gKE1SwD0PnwZm/+R4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7242 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMJsWRmVeSWpSXmKPExsXCxfcnRvd2VWqiwa/pKhY9D94xW/RMesXs wORxYtkVVo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFik4ujgBJVOLlBQy U2yVzJQUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZJdYGlqcUm+Qm5qcXFienpmvkLCNNGM1lPTWQp2hVTcvCXUwDghqIuRk0NCwERi0rsr7F2M XBxCAlOZJP7cm8YC4jAKLGOWuLpyGSOUwyrRdeoCK4RzhFFiafMBJhCHRWA/s8SxF1vYQIax CZhJnNnyDMwWEUiV6Dl+nwnEFhYIkji47z4rRDxE4tf/dqAaDiDbSKJ9twBImEVAVeLYmglg 5bwCMRKn1x8Es4UEbCT+n98HZnMK2Eqs6d3FDmIzCshKzGhYA2YzC4hLvJh+gh3iHwGJJXvO M0PYohIvH/8DO5pXYAGLxJXfs9khPpjLKLGuow2qSlbi0vxuRgjbV+LN4VlQcS2JOzcnMIIc KiGQLXH2oQZEWFLi8OFNbBC2msSNNx1Q5XISq3ofskDY8hLTFr2HOkhG4sGN7VD159kk9j/J BblBQuAOs8TtY89ZJjDqz0LyBISdL3H8YifzLHBgCEqcnPmEZRbQGcwCmhLrd0GVK0pM6X4I Va4h0TpnLjuy+AJG9lWMorkVBiZ6Jak5qcn5uZkliTmZiXqZJZsYgcn25spKiR2MF7a90TvE yMTBeIhRgoNZSYTXMCM1UYg3JbGyKrUoP76oNCe1+BCjDzB2JjJLiSbnA9N9Xkm8oamZqbmx kZmpgamZJQ5hJXHepWZAswTSgUk+OzW1ILUIZhwTB6dUA5PVU6lmA6b1E61/3PpYLPLlTr7r 09oTJxLCo/Z+ujVZ2ihfb6nRg+cRH6UtVs7UVOb8WZVx8fvGiOaOf0nXYsVOPVd6/7lr08n7 mQL9z2o3y0r8ZHyYdsNLdM7jf+8UhQWuBH5KMH3msCx2S4LnypX12bs7Hn96UXf3Dm+qQkYX 94dpLwTnbarazKov67Z80c57hl6PcnXubw+ovhQgVr2iuzzajEeX7dLqpumCAns0XmV/+5Fr 1f/ZfFbThpOqtou3f6n64dz2wN3o84TC9ur5btoLjzXUWYboJrD8v/RlnyrDaou7NbEzTt/e +DoiTojhe5HbJLO3K+dcMfCZwqXMztSiIXd2mqX655j+SlslluKMREMt5qLiRABb4LsVVgQA AA== Archived-At: Subject: [ippm] R: [EXT] Adoption call for Explicit Flow Measurements Techniques 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, 12 Oct 2021 12:09:17 -0000 --_000_DBAPR07MB67751EBDE930EE67E7F82B80E9B69DBAPR07MB6775eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGF1 dGhvci4NClRlbGVjb20gSXRhbGlhIGhhcyBkZXZlbG9wZWQgc29tZSBtb2JpbGUgYXBwbGlj YXRpb25zIHRoYXQgaW1wbGVtZW50IHRoZSBtZXRyaWNzIGRlc2NyaWJlZCBpbiB0aGUgZHJh ZnQgb24gc21hcnRwaG9uZXMuDQpUaGUgdGVzdHMgaGF2ZSBhbHJlYWR5IGJlZW4gc3VjY2Vz c2Z1bGx5IGNvbXBsZXRlZCBhbmQgd2UgYXJlIG9yZ2FuaXppbmcgYSBmaWVsZCB0cmlhbCBm b3IgbW9yZSBpbi1kZXB0aCB2YWxpZGF0aW9uLg0KVGhlIGlkZWEgaXMgdG8gaGF2ZSBhcHBz IHRoYXQgZ2VuZXJhdGUgUVVJQyB0cmFmZmljIG1hcmtlZCAgYWNjb3JkaW5nIHRvIHRoZSBz cGVjaWZpY2F0aW9ucyBvZiB0aGUgZHJhZnQgYW5kIGFuIGFwcCB0aGF0IGFuYWx5emVzIHRo ZSB0cmFmZmljIGJ5IGFjdGluZyBhcyBhbiBvYnNlcnZlci4NCkJlc3QgcmVnYXJkcy4NCk1h dXJvDQpfX19fX19fX19fX19fX19fX19fX18NCk1hdXJvIENvY2lnbGlvDQpUSU0g4oCTIFRl bGVjb20gSXRhbGlhDQpWaWEgRy4gUmVpc3MgUm9tb2xpLCAyNzQNCjEwMTQ4IC0gVG9yaW5v IChJdGFseSkNClRlbC46ICszOTAxMTIyODUwMjgNCk1vYmlsZTogKzM5MzM1NzY2OTc1MQ0K X19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQoNCg0KRGE6IGlwcG0gPGlwcG0tYm91bmNl c0BpZXRmLm9yZz4gUGVyIGNvbnRvIGRpIFRvbW15IFBhdWx5DQpJbnZpYXRvOiB2ZW5lcmTD rCA4IG90dG9icmUgMjAyMSAxNzo1OQ0KQTogSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3Jn KSA8aXBwbUBpZXRmLm9yZz4NCk9nZ2V0dG86IFtFWFRdIFtpcHBtXSBBZG9wdGlvbiBjYWxs IGZvciBFeHBsaWNpdCBGbG93IE1lYXN1cmVtZW50cyBUZWNobmlxdWVzDQoNCkhlbGxvIElQ UE0sDQoNClRoaXMgZW1haWwgc3RhcnRzIGFuIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1k dC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzLCAiRXhwbGljaXQgRmxvdyBNZWFz dXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBkb2N1bWVudCBpcyBwcm9wb3NlZCBhcyBh biBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRlY2huaXF1ZXMgdGhh dCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5ncyBsaWtlIHRoZSBRVUlDIHNwaW4gYml0 Lg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZHQtaXBwbS1l eHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMt MDINCg0KVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCB1bnRpbCBGcmlkYXksIE9jdG9i ZXIgMjIuIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50LCBhbmQgcmVwbHkgdG8gdGhpcyBl bWFpbCB0aHJlYWQgdG8gaW5kaWNhdGUgaWYgeW91IHRoaW5rIElQUE0gc2hvdWxkIGFkb3B0 IHRoaXMgZG9jdW1lbnQuDQoNCkJlc3QsDQpUb21teQ0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUg aSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2 dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRp IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFp biBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMp IG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0K DQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9u IMOoIG5lY2Vzc2FyaW8uDQo= --_000_DBAPR07MB67751EBDE930EE67E7F82B80E9B69DBAPR07MB6775eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSAy LjBjbSAyLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+SGkmbmJzcDthbGwuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1l bnQgYXMgYXV0aG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPlRlbGVjb20gSXRhbGlhIGhhcyBkZXZlbG9wZWQgc29tZSBtb2JpbGUgYXBwbGljYXRp b25zIHRoYXQgaW1wbGVtZW50IHRoZSBtZXRyaWNzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQg b24gc21hcnRwaG9uZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQiI+VGhlIHRlc3RzIGhhdmUgYWxyZWFkeSBiZWVuIHN1Y2Nlc3NmdWxseSBjb21wbGV0 ZWQgYW5kIHdlIGFyZSBvcmdhbml6aW5nIGEgZmllbGQgdHJpYWwgZm9yIG1vcmUgaW4tZGVw dGggdmFsaWRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj5UaGUgaWRlYSBpcyB0byBoYXZlIGFwcHMgdGhhdCBnZW5lcmF0ZSBRVUlDIHRyYWZm aWMgbWFya2VkJm5ic3A7IGFjY29yZGluZyB0byB0aGUgc3BlY2lmaWNhdGlvbnMgb2YgdGhl IGRyYWZ0IGFuZCBhbiBhcHAgdGhhdCBhbmFseXplcyB0aGUgdHJhZmZpYyBieSBhY3Rpbmcg YXMgYW4gb2JzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5CZXN0IHJl Z2FyZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5NYXVybzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPl9fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+TWF1cm8gQ29jaWdsaW88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPlRJTSDigJM8L3NwYW4+IDxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+DQpUZWxlY29tIEl0YWxpYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+VmlhIEcuIFJlaXNzIFJvbW9saSwgMjc0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj4xMDE0OCAtIFRvcmlubyAoSXRhbHkpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj5UZWwuOiArMzkwMTEyMjg1MDI4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj5Nb2JpbGU6ICszOTMzNTc2Njk3NTE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPl9fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RGE6 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGlwcG0gJmx0O2lwcG0tYm91bmNlc0Bp ZXRmLm9yZyZndDsNCjxiPlBlciBjb250byBkaSA8L2I+VG9tbXkgUGF1bHk8YnI+DQo8Yj5J bnZpYXRvOjwvYj4gdmVuZXJkw6wgOCBvdHRvYnJlIDIwMjEgMTc6NTk8YnI+DQo8Yj5BOjwv Yj4gSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSAmbHQ7aXBwbUBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5PZ2dldHRvOjwvYj4gW0VYVF0gW2lwcG1dIEFkb3B0aW9uIGNhbGwgZm9yIEV4 cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gSVBQTSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgZW1haWwg c3RhcnRzIGFuIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZs b3ctbWVhc3VyZW1lbnRzLCAmcXVvdDtFeHBsaWNpdCBGbG93IE1lYXN1cmVtZW50cyBUZWNo bmlxdWVz4oCdLiBUaGlzIGRvY3VtZW50IGlzIHByb3Bvc2VkIGFzIGFuIEluZm9ybWF0aW9u YWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgdGVjaG5pcXVlcyB0aGF0IGdvIGJleW9uZA0K IHNpbmdsZSBiaXQgbWFya2luZ3MgbGlrZSB0aGUgUVVJQyBzcGluIGJpdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVu dHMvIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMvPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1 cmVtZW50cy0wMiI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVu dHMtMDI8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgYWRvcHRpb24gY2Fs bCB3aWxsIGxhc3QgdW50aWwgPGI+RnJpZGF5LCBPY3RvYmVyIDIyPC9iPi4gUGxlYXNlIHJl dmlldyB0aGUgZG9jdW1lbnQsIGFuZCByZXBseSB0byB0aGlzIGVtYWlsIHRocmVhZCB0byBp bmRpY2F0ZSBpZiB5b3UgdGhpbmsgSVBQTSBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbW15PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPCEtLSAtLT48aHRtbD4NCgk8Ym9keT4NCjxicj4N Cjxocj4NCgkJPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KCQk8dHI+DQoJCQk8dGQg c3R5bGU9IndpZHRoOjYwMHB4OyI+DQoNCjxhIGhyZWY9Imh0dHBzOi8vb24udGltLml0L2Jh bm5lci1tYWlsLWRpcCI+IDxpbWcgc3JjPSJodHRwczovL2Nkbi50aW0udGljZG4uaXQvY29u dGVudC9kYW0vZmx5dG9jby1hcmVhcHViYmxpY2EtYWVtZmUvdGltX2l0L2RlbS1hc3NldHMv ZW1haWxfZm9vdGVyL0Jhbm5lcl9NYWlsX1RWJTIwR29sZC5qcGciIHRpdGxlPSJUSU0iIHN0 eWxlPSJ3aWR0aDogMTAwJTsgaGVpZ2h0OiBhdXRvOyBtYXJnaW4tdG9wOiAyMHB4O21hcmdp bi1ib3R0b206IDIwcHg7Ij48L2E+DQoJCQk8L3RkPg0KCQk8L3RyPg0KCQk8dHI+DQoJCQk8 dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXpl OjcuNXB0OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0iMzk1Ij4N CgkJCQlRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenph dGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25l LCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0 ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9y ZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5p Y2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlv bmUsIEdyYXppZS4NCgkJCQk8YnI+PGJyPg0KCQkJCTxpPg0KCQkJCQlUaGlzIGUtbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5ICBjb250YWluIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25s eS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkg ZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiAgZS1tYWlsLCBUaGFua3MuDQoJCQkJ PC9pPg0KCQkJCTxicj48YnI+DQoJCQkJPGI+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0 YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiAmZWdyYXZlOyBuZWNlc3NhcmlvLjwvYj4NCgkJ CTwvdGQ+DQoJCTwvdHI+DQoJCTwvdGFibGU+CQ0KCTwvYm9keT4NCjwvaHRtbD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DBAPR07MB67751EBDE930EE67E7F82B80E9B69DBAPR07MB6775eurp_-- From nobody Tue Oct 12 08:03:32 2021 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 A6C8A3A09B8 for ; Tue, 12 Oct 2021 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6q_ZJx_o4Nc for ; Tue, 12 Oct 2021 08:03:26 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2A43A0D01 for ; Tue, 12 Oct 2021 08:03:25 -0700 (PDT) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HTJjJ2s9Rz6H7Lk for ; Tue, 12 Oct 2021 22:59:32 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 12 Oct 2021 17:03:20 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 12 Oct 2021 23:03:19 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.008; Tue, 12 Oct 2021 23:03:19 +0800 From: Tianran Zhou To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: Ade/ejHUl3K4VIEkR6K5evaCgCeaXg== Date: Tue, 12 Oct 2021 15:03:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.195.208] Content-Type: multipart/alternative; boundary="_000_c42fbe9c20b54e87b300e6dbce6771f8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 12 Oct 2021 15:03:31 -0000 --_000_c42fbe9c20b54e87b300e6dbce6771f8huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0cgYW5kIENoYWlycywNCg0KSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQpJ IHRoaW5rIGl04oCZcyB1c2VmdWwgdG8gcHJvdmlkZSBhIHBtIHRvb2wgc2V0IGluIHRyYW5zcG9y dCBsYXllci4NCg0KQ2hlZXJzLA0KVGlhbnJhbg0KDQrlj5Hku7bkuro6IGlwcG0gW21haWx0bzpp cHBtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBUb21teSBQYXVseQ0K5Y+R6YCB5pe26Ze0OiAy MDIx5bm0MTDmnIg45pelIDIzOjU5DQrmlLbku7bkuro6IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRm Lm9yZykgPGlwcG1AaWV0Zi5vcmc+DQrkuLvpopg6IFtpcHBtXSBBZG9wdGlvbiBjYWxsIGZvciBF eHBsaWNpdCBGbG93IE1lYXN1cmVtZW50cyBUZWNobmlxdWVzDQoNCkhlbGxvIElQUE0sDQoNClRo aXMgZW1haWwgc3RhcnRzIGFuIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1kdC1pcHBtLWV4cGxp Y2l0LWZsb3ctbWVhc3VyZW1lbnRzLCAiRXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5p cXVlc+KAnS4gVGhpcyBkb2N1bWVudCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRv Y3VtZW50IHRoYXQgZGVzY3JpYmVzIHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJp dCBtYXJraW5ncyBsaWtlIHRoZSBRVUlDIHNwaW4gYml0Lg0KDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy8N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWR0LWlwcG0tZXhw bGljaXQtZmxvdy1tZWFzdXJlbWVudHMtMDINCg0KVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFz dCB1bnRpbCBGcmlkYXksIE9jdG9iZXIgMjIuIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50LCBh bmQgcmVwbHkgdG8gdGhpcyBlbWFpbCB0aHJlYWQgdG8gaW5kaWNhdGUgaWYgeW91IHRoaW5rIElQ UE0gc2hvdWxkIGFkb3B0IHRoaXMgZG9jdW1lbnQuDQoNCkJlc3QsDQpUb21teQ0K --_000_c42fbe9c20b54e87b300e6dbce6771f8huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgV0cgYW5kIENoYWlycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgdGhpbmsgaXTigJlzIHVzZWZ1bCB0byBwcm92aWRlIGEgcG0gdG9vbCBzZXQg aW4gdHJhbnNwb3J0IGxheWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaWFucmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6 ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj4gaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbW15IFBhdWx5PGJyPg0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjE8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj7m nIg8c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjM6 NTk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSAmbHQ7aXBw bUBpZXRmLm9yZyZndDs8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gW2lwcG1dIEFkb3B0aW9uIGNhbGwgZm9yIEV4 cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlbGxvIElQUE0sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGVtYWlsIHN0YXJ0cyBhbiBhZG9w dGlvbiBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cywg JnF1b3Q7RXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBkb2N1 bWVudCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3Jp YmVzIHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQNCiBzaW5nbGUgYml0IG1hcmtpbmdzIGxpa2Ug dGhlIFFVSUMgc3BpbiBiaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRz LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50 cy0wMiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBw bS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGxhc3Qg dW50aWwgPGI+RnJpZGF5LCBPY3RvYmVyIDIyPC9iPi4gUGxlYXNlIHJldmlldyB0aGUgZG9jdW1l bnQsIGFuZCByZXBseSB0byB0aGlzIGVtYWlsIHRocmVhZCB0byBpbmRpY2F0ZSBpZiB5b3UgdGhp bmsgSVBQTSBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRv bW15PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_c42fbe9c20b54e87b300e6dbce6771f8huaweicom_-- From nobody Tue Oct 12 09:40:41 2021 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 0B4F83A1677 for ; Tue, 12 Oct 2021 09:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIzfVtj_yQHx for ; Tue, 12 Oct 2021 09:40:26 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0287C3A0B19 for ; Tue, 12 Oct 2021 09:40:25 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id r18so1730218edv.12 for ; Tue, 12 Oct 2021 09:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gypV5AynYi2bLebwbAoDuVloNwEn5aLnqbTOz2or6ME=; b=gpbJ4sg0wmILGdx3hRIHy3dgvqgPgc9XL3Gq0584vuMqtgSIcIR4vt8I7RcXrsSd6X n3jnks6oy9xYh9VVNOJ3AGI7DrpjwNR2CwAMuUR1XXLlMcxUJa3IoyjfT9ozShw6r3As WFSeU8dBmM4M5SRTDVXN8BFLJps/Q9TUug9NVYu0I50PW4WnSSoGZ1iwlyXP2hkcRhwR /PCLsngrXgcD3mjWDuwjng+IZ3l1TwEXJMoUieCokHxwRBwS5FaAMyt8G4lMNkFAbpgr rnk3ZTUSu0L8khNPLGB1OCO3wl2lCL/dvj6tMBlyOavSPBd6Jw37ReHU6xAkJptiSHwJ Rt+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gypV5AynYi2bLebwbAoDuVloNwEn5aLnqbTOz2or6ME=; b=UZTeDelNu8Pi31qRyQ5VVzxLgLs3w1X503BdqLvhA/K2DJ9WTv6MUEpt69w+zSj8Uh fDnhYUrbwyexAYGF2GQX9IM/ROOX8WWkdzY0s62o7u9o8JwwUtNtlgmvIQjZ63GzjyOb w76IX7fwZ0ociEINXzzr5AKtZdChnSBvsfYlovrc2m1WIO47uTWxHvinkbZIghaaB8VU pbQoQKqYcXmunnQYuyLThnPjZJgchWB1VPhoVTYFAi7T0iFpfd7Q6C2C4Z6DsomCHYkf /Eoi87zHedNM3aTrGtrAPl++0Dimk7CbHYN93iM612fgz3Ffs3QpIKDoNy9OUCkkkaZU /Edw== X-Gm-Message-State: AOAM530kU5l5nzTejAq8ju30nMQr5d51I53ze+vCY2NDSLwn//jRF2/U nO73+xeCqkMcVn6fOu2gIh7b/U6SOlM62GOFr8bZ/he5 X-Google-Smtp-Source: ABdhPJwYB716eV8qc8v4usPkB8XM8yH2kk0fNtlMR79ko1wm2mVVm3PgnhngS6ga1MyJrxNxV+acQ1BxlOYhYxH3GRI= X-Received: by 2002:a17:906:912:: with SMTP id i18mr33557398ejd.131.1634056823818; Tue, 12 Oct 2021 09:40:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 12 Oct 2021 09:40:09 -0700 Message-ID: To: Tommy Pauly Cc: "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="00000000000086cd3605ce2a80b6" Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 12 Oct 2021 16:40:38 -0000 --00000000000086cd3605ce2a80b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I support adoption of this draft. On-path telemetry is an essential OAM tool. Regards, Greg On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly wrote: > Hello IPPM, > > This email starts an adoption call for > draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements > Techniques=E2=80=9D. This document is proposed as an Informational docume= nt that > describes techniques that go beyond single bit markings like the QUIC spi= n > bit. > > https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurement= s/ > > https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measur= ements-02 > > This adoption call will last until *Friday, October 22*. Please review > the document, and reply to this email thread to indicate if you think IPP= M > should adopt this document. > > Best, > Tommy > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00000000000086cd3605ce2a80b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I support adoption of this draft. On-path te= lemetry is an essential OAM tool.

Regards,
Greg

On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> = wrote:
Hello IPPM,

= This email starts an adoption call for draft-mdt-ippm-explicit-flow-measure= ments, "Explicit Flow Measurements Techniques=E2=80=9D. This document = is proposed as an Informational document that describes techniques that go = beyond single bit markings like the QUIC spin bit.

https://datatracker.ietf.org/doc/draft-mdt-= ippm-explicit-flow-measurements/

This adoption call will la= st until Friday, October 22. Please review the document, and reply t= o this email thread to indicate if you think IPPM should adopt this documen= t.

Best,
Tommy
______________= _________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--00000000000086cd3605ce2a80b6-- From nobody Tue Oct 12 22:06:40 2021 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 0C90D3A120C for ; Tue, 12 Oct 2021 22:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAOGNPxyU03d for ; Tue, 12 Oct 2021 22:06:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 4C17E3A120D for ; Tue, 12 Oct 2021 22:06:33 -0700 (PDT) Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MDiSu-1mWeap2TWQ-00H97a for ; Wed, 13 Oct 2021 07:06:29 +0200 Content-Type: multipart/alternative; boundary="------------t8q3Q0CjUDJAP0rBm4F1gflD" Message-ID: <3240de1f-2fe5-f290-78d0-44c51dd809f9@clemm.org> Date: Tue, 12 Oct 2021 22:06:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: ippm@ietf.org References: From: Alexander L Clemm In-Reply-To: X-Provags-ID: V03:K1:KocaZpDeBW6Fpl/Gmysw7C5b+p+vC/tVGWGPDbga5SY/O/kFLIc nHs3wMQsCAFbLKKej/JQ8eNf8jfiwtGx9l2V07cRFmNPQcNdZy8OAgsFITT1PiVZLHMjah4 GqVa04tDXeW+0htxCNclQejK8sVDhQwKSUwtFjlPwysycISnTLTcrgXzzCML53eGBFbqM4o i0rm55Nc9qsMg/5GG8ilA== X-UI-Out-Filterresults: notjunk:1;V03:K0:N2h5FbD37pY=:qXJTBQE2vtm5VfB/ecJxJL eT4kwdEukX31rSWUv9kzBIkFEMQOkcoFAvMSL3lOJE9DTAIHEQufycXXJFoEqUqDCjhTbbMbN XXeG+BWRfA1xvdUknhxWHLfFNq8JS0C7NZxNvo6w9m6LxKB6gNEPDAUtR19fyYbqk+GdmH+bR uy56xDyH3LrOb8Ho5pthtZAh59BDQUH1puocjdBzRQk228JUM+flfYrSAKT9oeM0394o85Hmc o4zALj5liEFPhhUN5xZK2wj/eU2y024K5D83ie7Amk+E3mg+nmCW9/R5MkAC8VfGRFX/MJiG0 Hd9L1L0l6kz5KNYyJl7YRZqMyaFvJD1k6WNC1htFqHeJuHYNlwXW7CbPJx2f+evQE0zUShrr0 HgCPbXXyJLTs+xmQD1wRxE7P9Pvjekxu4R9efr4jpu6K2l5XsBo9Dciyc7amw9NH9IqhfA/PY x+EHrouXNC3Of1/Q/Fj+0zLkxGwUuarUhD3MPpBMjGIJ827LkNs1sP54vmHkZODGfSOSaUTRO Wnw768ZBdtsFzvOvsJr79svDrv3mRk+iykKJfVOc99awVs0Oysoh1F74FpFAE941SJF14WyBE NBxiKifiXCerBUOL+1/dosxNkCss/Nk5hDw/ehEDsASa5WvwWPZgdAwHpEMxxiWc9xXsWmpg8 qWX2qY4RZZR0IV43n2WwyoH36bMmhhyqiTSnChoz9DaQ38SHlq9YPRU4Z3fprTXwHT6UFF2+t BlZLXuI+eIs22eZqABEnGfV7rdiTUD1AK72/zg== Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 13 Oct 2021 05:06:38 -0000 This is a multi-part message in MIME format. --------------t8q3Q0CjUDJAP0rBm4F1gflD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I think that a description of various flow measurement techniques using various types of marking bits will make for a useful informational document with substance.   I support adoption as well. --- Alex On 10/12/2021 9:40 AM, Greg Mirsky wrote: > Dear All, > I support adoption of this draft. On-path telemetry is an essential > OAM tool. > > Regards, > Greg > > On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly > wrote: > > Hello IPPM, > > This email starts an adoption call for > draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow > Measurements Techniques”. This document is proposed as an > Informational document that describes techniques that go beyond > single bit markings like the QUIC spin bit. > > https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/ > https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurements-02 > > This adoption call will last until *Friday, October 22*. Please > review the document, and reply to this email thread to indicate if > you think IPPM should adopt this document. > > Best, > Tommy > _______________________________________________ > 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 --------------t8q3Q0CjUDJAP0rBm4F1gflD Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear all,

I think that a description of various flow measurement techniques using various types of marking bits will make for a useful informational document with substance.   I support adoption as well.

--- Alex

On 10/12/2021 9:40 AM, Greg Mirsky wrote:
Dear All,
I support adoption of this draft. On-path telemetry is an essential OAM tool.

Regards,
Greg

On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
Hello IPPM,

This email starts an adoption call for draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements Techniques”. This document is proposed as an Informational document that describes techniques that go beyond single bit markings like the QUIC spin bit.


This adoption call will last until Friday, October 22. Please review the document, and reply to this email thread to indicate if you think IPPM should adopt this document.

Best,
Tommy
_______________________________________________
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
--------------t8q3Q0CjUDJAP0rBm4F1gflD-- From nobody Wed Oct 13 05:06:51 2021 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 9DD853A088A; Wed, 13 Oct 2021 05:05:44 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163412674453.6511.7174229943801604189@ietfa.amsl.com> Date: Wed, 13 Oct 2021 05:05:44 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-direct-export-07.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: Wed, 13 Oct 2021 12:05:45 -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 Direct Exporting Authors : Haoyu Song Barak Gafni Tianran Zhou Zhenbin Li Frank Brockners Shwetha Bhandari Ramesh Sivakolundu Tal Mizrahi Filename : draft-ietf-ippm-ioam-direct-export-07.txt Pages : 14 Date : 2021-10-13 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type called the Direct Export (DEX) option, which is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-direct-export-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 13 05:07:56 2021 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 44D823A0890; Wed, 13 Oct 2021 05:07:16 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163412683620.8504.10595577955241242138@ietfa.amsl.com> Date: Wed, 13 Oct 2021 05:07:16 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-flags-07.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: Wed, 13 Oct 2021 12:07:17 -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 Loopback and Active 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-07.txt Pages : 14 Date : 2021-10-13 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-flags-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 13 05:12:13 2021 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 7F1EA3A08AA; Wed, 13 Oct 2021 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 wMnydZ_QVlQy; Wed, 13 Oct 2021 05:12:05 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 7C49B3A089C; Wed, 13 Oct 2021 05:12:05 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t2so7604698wrb.8; Wed, 13 Oct 2021 05:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a7I9uykP89YBcmpLV5oxjgUaQmlCJxEZ7+nMAdRrPoo=; b=LxEQfIvzGVsVVSlcw9UlIdpqmTLUIrJLdlp9OS203If0uhNH0hr6ApjJVXsBq+HrG4 1Hjl5/bqKAK2u3+LaD2QVrNCLzGxBcAon5eNJb9Y2t9JcPC083g7lMKBNtJR7f8S/wSl ubsVJlTXhiL8rvriIos6r9EWFZQN2ZHz+G+/m6/vtKy0pGdUS9R2k6EYtPK8VdyeiHpI YAG/ZfDz09KL6cAXoIUOkO3IIEq8G9oSHdpYm8q4dvSQxOwZy6oanhvmcvM/cLLRK/aD IP87BdUSCEKUGQ3Y6cwOijpFUZUqpVDikgrf/UfABJ/bmkX7pj7t0SywmAkIDHkhlRYG 0ltg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a7I9uykP89YBcmpLV5oxjgUaQmlCJxEZ7+nMAdRrPoo=; b=5diRxoB84y+aPWmCtdLJ1+h61ICc2IKodYGVUUzVHZMphVrYA5XLYCeNlxXoiMsFVF LsiadFcSUTTfHTcx9W7u7SXyzoPd5pKOTfAvi5WgT5mYyd/tBVMVwcmQ8No9B2rFO1s0 tfXXCTZGAUpH8tTOaC/rVogr2TahKGK6/K/BINFqxfZ1+ZkqwxdTGvReU3L0IoWKKeer WHRY4+ikve889FGD9v0fCquFDhMqmlNhX2j95JWYzN4OGiW1Fb+r4nr5yy/hx6pVag2G 6u2C/MV853HM4VN7dk6M9ovwyPyBvKEKIyTZviOVhOz6sZz/667ssfa3i6mI71/zLgR5 WRAw== X-Gm-Message-State: AOAM531VUynIBg3+teP7kTt9HAbmMpPcLhj7Yy3NuiuNWEBNTT5tgidq EWSdBHrTLFGe6GCjvxws9ZeIzyG8DF6KTcOoOVYOAUKD4S5Yvw== X-Google-Smtp-Source: ABdhPJwYMGgjEXFSK431UyZONn3UgYneTPoULtw5PqYpBlgULLRk6hPzM17az+Kjq3NEiNnRUt+ctVW6cDLH18/esBY= X-Received: by 2002:a05:600c:21cc:: with SMTP id x12mr4041399wmj.8.1634127122950; Wed, 13 Oct 2021 05:12:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 13 Oct 2021 15:11:49 +0300 Message-ID: To: IPPM Chairs , Tommy Pauly Cc: "IETF IPPM WG (ippm@ietf.org)" , Greg Mirsky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] WGLC for IOAM Direct Exports 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, 13 Oct 2021 12:12:11 -0000 Dear Chairs, We want to thank Greg for his thorough review and useful comments. Although these comments were defined by Greg as non-blocking we made an effort to address them either by updating the draft or by responding to Greg's comments. Some further responses can be found below, marked [[TM]]. We have posted an updated version (07) that seems to address these comments, as well as comments received from Bernard Aboba (TSV-ART reviewer). https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ We believe the draft is ready to be submitted to the IESG. Thanks, Authors. On Sun, Oct 10, 2021 at 8:23 PM Greg Mirsky wrote: > > Hi Tal, > thank you for carefully considering my comments and suggestions. Please f= ind my follow-up notes in-lined below under the GIM>> tag. > > Regards, > Greg > > On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi = wrote: >> >> Hi Greg, >> >> Many thanks for the thorough review. >> Below you can find responses to your comments, and in some cases >> proposed text edits. >> >> If there are no further comments we will update the document accordingly= . >> >> Thanks, >> The authors. >> >> >> On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky wrote= : >> > >> > Dear Authors, WG Chairs, and All, >> > I've read the latest version of the draft and have several comments an= d questions to share with you. None of these are blocking, I support progre= ssing this draft to publication. Please consider the notes below as an invi= tation to a discussion: >> > >> > It seems that the characterization of the Direct Export IOAM option in= the following is not entirely accurate: >> > >> > The DEX option is used as a trigger to collect and/or export IOAM data= . >> > >> > I propose re-wording: >> > The DEX option is used as a trigger to collect and export or only coll= ect locally the IOAM data. >> > >> > Using "exporting and/or collecting" reflects the use of the Direct Exp= ort option type technically accurate but the order of actions is backward. = What are your thoughts? >> > >> >> [TM] Right. The following text edit is proposed in the introduction. >> >> OLD: >> This option is used as >> a trigger for IOAM nodes to locally aggregate and process IOAM data, >> and/or to export it to a receiving entity (or entities). >> NEW: >> This option is used as >> a trigger for IOAM nodes to locally aggregate and process IOAM data, >> and/or to export it to a receiving entity (or entities). Throughout >> the document this functionality is referred to as collection and/or >> exporting. > > GIM>> As I understand it, it is the local policy that controls the behavi= or of the node receiving the IOAM DEX indicator. Similar to IPFIX, the info= rmation can be aggregated and exported as a calculated metric, e.g., percen= tile or mean value, or exported as soon as possible as recorded. The new te= xt is certainly better but it seems it does not express the role of the loc= al policy in defining the processing behavior, the transport to be used, an= d the identity of the Collector. One of possible ways could be to state tha= t the definition of all these controls is outside the scope of the document= . [[TM]] Right. The following text edit is proposed. OLD: Note that even though the IOAM Option-Type is called "Direct Export", it depends on the deployment whether the receipt of a packet with DEX option type leads to the creation of another packet. Some deployments might simply use the packet with the DEX option type to trigger local processing of OAM data. NEW: Note that even though the IOAM Option-Type is called "Direct Export", it depends on the deployment whether the receipt of a packet with DEX option type leads to the creation of another packet. Some deployments might simply use the packet with the DEX option type to trigger local processing of OAM data. The functionality of this local processing is= not within the scope of this document. >> >> >> >> > I find references to RFC 5475 and 7014 very appropriate and helpful. B= ut I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data. I = think that excessive use of not only the Direct Export IAOM option but the = IOAM method, in general, may adversely affect a network and the recommendat= ions listed in RFC 5475 and 7014 are equally applicable. >> > Similarly, the good and helpful discussion of how to practically contr= ol the use of the Direct Export option is, in my opinion, equally applicabl= e to other IOAM trace options and should be in the Security Considerations = section of draft-ietf-ippm-ioam-data. >> >> >> [TM] The last two comments are about draft-ietf-ippm-ioam-data, which >> is currently in IESG review. I will take this feedback with the other >> authors to see how we can address this input at this point. > > GIM>> Thanks. >> >> >> >> > The second paragraph in Section 3.1.2 is re-phrasing if not repeating = what is already expressed in the last paragraph of the previous sub-section= (though the limit is applied to exporting telemetry information). I think = that it can be removed without any loss to the document. >> >> [TM] The second par of 3.1.2 refers to *exporting*, while the last par >> of 3.1.1 refers to *encapsulating*, so these are two complementary >> requirements. > > GIM>> Is it the intention of this draft to define the encapsulation of ex= ported information? What if the local policy mandates the node calculating = p95 and p99 of packet delay and inter-packet delay variation? Can you help = me by describing how these metrics are encapsulated? [[TM]] As emphasized in the document: "The exporting method and format are outside the scope of this document." Section 3.1.2 actually refers (as its name suggests) to "Responding to the DEX Trigger". >> >> >> >> > I think that it will be helpful to provide some recommendations, i.e.,= SHOULD do this, how an implementation handles the excess of packets to exp= ort. Drop silently, drop and log notification, or try to shape that flow? >> >> [TM] Assuming an amplification scenario, a large number of packets may >> be dropped, so logging each drop may defeat the purpose. A drop >> counter may be a good idea here, but this document does not really >> define counter requirements in general, so it seems like more of an >> implementation-specific aspect, or possibly can be considered as part >> of the YANG model. > > GIM>> I am still struggling to understand how IOAM DEX triggers amplifica= tion. Can you add more details, steps to help me understand it? [[TM]] This is explained in the document: The amplification effect of DEX may be worse in wide area networks in which there are multiple IOAM domains. For example, if DEX is used in IOAM domain 1 for exporting IOAM data to a receiving entity, then the exported packets of domain 1 can be forwarded through IOAM domain 2, in which they are subject to DEX. The exported packets of domain 2 may in turn be forwarded through another IOAM domain (or through domain 1), and theoretically this recursive amplification may continue infinitely. >> >> >> > I was really puzzled by this requirement in Section 3.1.2 >> > >> > Exported packets SHOULD NOT be exported over a path or a tunnel tha= t >> > >> > is subject to IOAM direct exporting. >> > >> > I hope you can clarify it for me. >> >> >> [TM] As explained later in that paragraph: "This requirement is >> intended to prevent nested exporting and/or exporting loops." >> This was thoroughly discussed in the working group, and came out of >> the security-related review. > > GIM>> If the definition of exporting, including the encapsulation, choice= of transport, and the Collector is outside the scope, then this statement,= in my opinion, should be removed. If all these issues are in the scope, th= en there is more, much more information that is missing. [[TM]] As explained in the abstract, "The exporting method and format are outside the scope of this document." However, the current document has a paragraph that defines security requirements for the export method. These requirements came out of the very detailed security discussions we had with Martin Duke and Mirja K=C3=BChlewind. >> >> >> > >> > This requirement >> > >> > Furthermore, IOAM encapsulating >> > nodes that can identify a packet as an IOAM exported packet MUST NO= T >> > push a DEX option into such a packet. >> > brings up questions: >> > >> > How can a node identify a packet as the IOAM exported packet? >> >> [TM] The requirement means that if an encapsulating node's ACL can >> detect exported packets, then DEX should not be applied. > > GIM>> I think that whether this belongs in the document depends on the an= swer to my question above - what is in the scope of this document. [[TM]] See the response above. >> >> >> > What should be done if the IOAM exported packet contains the IOAM head= er with the DEX option? >> >> [TM] The current document does not require an IOAM transit node to >> parse beyond the (external) IOAM encapsulation if there are nested >> IOAM encapsulations. > > GIM>> Same, as above - need to clarify the scope of the document first. >> >> >> > >> > What is special about the decapsulating node that is not DEX-capable? >> > >> > A decapsulating node that does not support the DEX option >> > MUST remove it, along with any other IOAM options carried in the >> > packet if such exist. >> > Shouldn't that be a general behavior of a decapsulating IOAM node? >> >> [TM] Right. The following text edit is proposed: >> >> OLD: >> A transit IOAM node that does not support the DEX option SHOULD >> ignore it. A decapsulating node that does not support the DEX option >> MUST remove it, along with any other IOAM options carried in the >> packet if such exist. >> NEW: >> A transit or decapsulating IOAM node that does not support the DEX >> option SHOULD >> ignore it. Note that as per a >> decapsulating node removes the IOAM encapsulation and all its IOAM op= tions, >> and specifically in the case where one of these options is a >> (possibly unknown) >> DEX option. > > GIM>> Why is it SHOULD? In what situation a node MAY act on the DEX? Right. Proposed text: A transit or decapsulating IOAM node that receives an unknown IOAM option type ignores it (as defined in ), and specifically nodes that do not support the DEX option ignore it. Note that as per a decapsulating node removes the IOAM encapsulation and all its IOAM options, and specifically in the case where one of these options is a (possibly unknown) DEX option. >> >> >> >> > >> > The format of the first four-octet word in Figure 2 is different from = the format defined in draft-ietf-ippm-ioam-data: >> > >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Namespace-ID |NodeLen | Flags | RemainingLen| >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | IOAM-Trace-Type | Reserved | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > Is this intentional? If it is, how does an implementation know which f= ormat to use? >> >> [TM] Each IOAM Option-Type has a different header format. The current >> document defines a new Option-Type, which was not defined in >> draft-ietf-ippm-ioam-data. >> The IOAM-Type field in the lower layer header determines which >> Option-Type is used and how its header should be parsed. > > GIM>> Thank you for the clarification. Is that the intention to start new= drafts to define the DEX IOAM Option-Type separately? [[TM]] Right. IOAM-Type values are defined in per encapsulation drafts, such as draft-ietf-ippm-ioam-ipv6-options. >> >> >> >> > >> > It is stated in the draft that: >> > >> > The length of the DEX option is at least 8 octets. >> > >> > But the figure 2 in the draft does not include any field that reflects= the length of the IOAM option. Is that because the figure is out of sync? = If not, how can an implementation verify the length? Also, what is the beha= vior if the length is less than 8 octets? >> > >> >> [TM] Quoting the draft: >> >> The existence of the optional fields is >> indicated by the corresponding flags in the Extension-Flags field. >> ... >> Thus, the Extension-Flags field explicitly indicates >> the length of the DEX option. >> >> >> > RE: PerformanceConsiderations >> > >> > I agree with you that a DEX-encapsulating node and DEX-transit nodes m= ust have rate-limiting controls (as noted earlier, the behavior of the tran= sit node needs more detailed specification). But I think that the document = should also note that exported packets could be sent over the network out-o= f-band, relative to the monitored flow. As a result, the impact of packets = carrying telemetry information might be not direct and harmful to the data = flow. I see that as one of the important benefits of the Direct Export meth= od transporting on-path telemetry information. >> > >> >> [TM] Right. The following new text is proposed: >> >> It should be noted that in some networks DEX data may be exported over >> an out-of-band network, in which a large volume of exported traffic >> does not compromise user traffic. In this case an operator may choose >> to disable the exporting rate limiting. > > GIM>> I think that the text can be stronger, recommending that informatio= n is exported out-of-band and explaining the interpretation of out-of-band = in the case of IOAM. >> >> >> > >> > Regards, >> > Greg >> > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly wrote: >> >> >> >> Hello IPPM, >> >> >> >> This email starts a Working Group Last Call on two related IOAM docum= ents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export. >> >> >> >> In-situ OAM Loopback and Active Flags >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 >> >> >> >> In-situ OAM Direct Exporting >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-exp= ort-06 >> >> >> >> Please provide feedback by replying to this email with your reviews a= nd if you think these documents are ready to progress, by Wednesday, Septem= ber 15. >> >> >> >> Best, >> >> Tommy & Ian >> >> >> >> _______________________________________________ >> >> 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 From nobody Wed Oct 13 05:19:12 2021 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 1899F3A08E5; Wed, 13 Oct 2021 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 WOjd7MCWutWm; Wed, 13 Oct 2021 05:19:06 -0700 (PDT) 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 B4B663A08E2; Wed, 13 Oct 2021 05:19:05 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id u18so7751707wrg.5; Wed, 13 Oct 2021 05:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rxHQnP8aEsXUmdCZe5Vu8OZuPcgMJIQL7gH1BOqXkLU=; b=k9XkSUkDBlP08rxeokSydhNazgcXVZ9kPaN/rmoLqvtBFrL4YBNNrWL86OJF7KsgxV BPM90RsS4hkzZV03pcRMtBY3QWAVK9e2x/9yBZ68DLXD+5djg0GeDNLhLBdihIVfJjLj 1LZdlQHr55CrsQW/FEknklql+/PEax1ZUqFou128sBH9R2uN02kbpGyIWl/5JnK3EHcw rLEusJocp+gSj5/7VLemPy/28lQTJy5Yyu0TSnacus3SUSyDT9EwxSezcMULtX0zQbyQ rvWChPQ2fEfKpc9Rq7RstrlnHwh6y0b5HCckEBkYlUfzIzK8KvuWSd4mIgrngheV8LZi AIAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rxHQnP8aEsXUmdCZe5Vu8OZuPcgMJIQL7gH1BOqXkLU=; b=28HYqc3BUZfWSFzulApyeWDIwaYO9SZR/xo+wDWq2NBcU0ZDWqWkRENync16nYwTBM 5nPqlmNHd70TrS/7XXq7P7Vp56kqSth/O4601935geJk15WHrfGRubX2wyuRuzLCSp2i WREipxjwmeWvz4Oay0dq+lY0OZ5FdopwDOXRjrSlsxE3440F20JCCnSWcWTtKa3ehq/p JO9xdECHQaWmy0TW0OzM4TVbWn0ImRNm2E5eaMJZYr6jXhOJsGtyzqw025g9zGayccD6 UFJIxTydBrb7dgfj99r8a7tFYiG060fWStVoVF5aBmVEOk4kwxOXxijjNGnd1pd/eoSL vRrw== X-Gm-Message-State: AOAM533xzrtBo7bCqiKR1oO5t3kT361g6Ldgv42xOBHGpbseocMPtAa8 pOlbfLoq/FOYWQERfzwU+SA1Be9yFIHHdJu90HhaSCniqjpIKg== X-Google-Smtp-Source: ABdhPJzzAzL2I3fPxaHYMbrN6iM9cqKV8Vn0detn2mhuU6MM2Z6DQ+gSqpgzfMcXQn9Zorf+mQ8H5kJ5FrX5vqfAgWY= X-Received: by 2002:a05:600c:1d03:: with SMTP id l3mr12458751wms.119.1634127543364; Wed, 13 Oct 2021 05:19:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 13 Oct 2021 15:18:50 +0300 Message-ID: To: IPPM Chairs , Tommy Pauly Cc: "IETF IPPM WG (ippm@ietf.org)" , Greg Mirsky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] WGLC for IOAM Flags 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, 13 Oct 2021 12:19:11 -0000 Dear Chairs, Thanks again to Greg for a very thorough review that helped us improve the quality and clarity of the draft. We believe we addressed most of the comments, either by updating the text, or by responding to the comments. Some further responses can be found below, marked [[[TM]]]. Note (1): it looks like some of the comments are basically about the purpose of the document. Addressing these documents would probably require a complete rewriting of the document with a different purpose. At this point we do not think it would make sense to align to these comments. These comments can be easily found by searching for "(1)" through this email. We have posted an updated version of this draft (07): https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ We believe the draft is ready to be submitted to the IESG. Thanks, Authors. On Fri, Oct 8, 2021 at 7:04 PM Greg Mirsky wrote: > > Hi Tal, > thank you for your responses to my comments and questions. Please find my= follow-up notes in-lined below under the GIM>> tag. > > Regards, > Greg > > On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi = wrote: >> >> Hi Greg, >> >> Many thanks for the detailed comments. >> Please see the responses below, as well as suggested text edits in some = cases. >> >> Cheers, >> The authors. >> >> On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky wrote= : >> > >> > Dear Authors, WG Chairs, and All, >> > I've read the latest version of the draft and have several comments an= d questions to share with you. I would much appreciate the opportunity to d= iscuss these before I can state my support for progressing this draft to pu= blication. >> > >> > The Abstract states that: >> > >> > In-situ Operations, Administration, and Maintenance (IOAM) records >> > operational and telemetry information in packets while they travers= e >> > a path between two points in the network. >> > >> > I think that is not a complete description of IOAM options as it exclu= des the Direct Export option. It might be easier to improve by s/records/co= llects/. Also, what, in your opinion, is the distinction between operationa= l and telemetry information? I think that operational information collected= from remote nodes is one example of telemetry information. What do you thi= nk? >> >> [TM] Agreed. Your proposal makes sense: s/records/collects/ >> Regarding the difference between operational and telemetry >> information, the way I see it "telemetry" refers to measurements that >> are being exported to an external/remote entity, whereas operational >> information is not measurement-based, such as the Node ID or Interface >> ID. > > GIM>> I think that there's no standardized definition of "telemetry" and = "telemetry information". I share the idea expressed in the following: > > Telemetry is automated communication that processes from multiple data so= urces. Telemetry data improves customer experiences, monitors security, app= lication health, quality, and performance. > > For different cases, the set of information referred to as telemetry data= variates. For example, CPU and buffer utilization are valuable for virtual= ized environments. In other words, I understand telemetry data as informati= on extracted from a remote system that characterizes the system's state. In= any case, providing a definition would be helpful to a reader of the docum= ent. [[[TM]]] This word is mentioned only once in the document (in the abstract), and not sure adding a definition for this particular word would change the readability of the document. >> >> >> >> > >> > nit s/the the/the/ >> >> [TM] Agreed. >> >> > I think that Abstract and Introduction can be improved by explaining t= he purpose of defining the Loopback and Active flags. What each of them is = intended to achieve and improve? >> >> [TM] The point is well-taken, and the following text will be added to >> the introduction. In order to avoid text repetition, I believe it >> would be best not to add it to the abstract as well. >> >> OLD: >> - >> NEW: >> The Loopback flag is used to request that each transit device along >> the path loops back a copy of the data packet to the sender. The >> Active flag indicates that a packet is used for active measurement. > > GIM>> Thank you for the proposed text. I have several notes to the new te= xt: > > As I understand the behavior required from a node processing the Loopback= flag, the returned packet is not the complete but truncated data packet. > Is "active measurement" used in the context of RFC 7799? If "yes", does t= hat mean that the packet is a specifically generated test packet? [[[TM]]] These are two good points. Based on these comments the following text is proposed instead. NEW: The Loopback flag is used to request that each transit device along the path loops back a truncated copy of the data packet to the sender. The Active flag indicates that a packet is used for active measurement. The term active measurement in the context of this document is as defined in [RFC7799]. >> >> >> >> > It is stated in the Introduction that: >> > >> > This document defines >> > two new flags in the Pre-allocated and Incremental Trace options: t= he >> > Loopback and Active flags. >> > Does that mean that neither of the two flags is applicable in the Dire= ct Export option? Should draft-ietf-ippm-ioam-direct-export have an explici= t statement regarding the applicability of the Loopback and Active flags? A= nd if any is applicable, describe the behavior of an IOAM node receiving it= . >> >> [TM] Right. >> The direct exporting draft explicitly states the behavior of each >> field in the DEX option header including the flags, so there seems to >> be no need to specify flags that are supported in other options. > > GIM>> I'm a bit confused. Can you help me with the text from the DEX draf= t that specifies the use of the Loopback and Active flags in combination wi= th the DEX trace option? [[[TM]]] The DEX option does not support the loopback and active flags. That is why the DEX document does not discuss these flags. The DEX document defines the DEX option header including all the flags that are relevant to the DEX option (loopback and active are not included). >> >> >> > >> > In Section 4 the purpose of using the Loopback flag is explained as: >> > >> > Loopback allows an IOAM encapsulating node to trace the path to a >> > given destination, and to receive per-hop data about both the forwa= rd >> > and the return path. >> > In my previous comments, I've pointed out that the Loopback mode is ju= st a special case of the Direct Export option. In addition to that, I would= appreciate your explanation of how the IOAM encapsulating node receives pe= r-hop data about the return path. How does that work, for example, in an MP= LS or SFC NSH environment? >> >> [TM] It is slightly similar to direct exporting, but is not a special >> case of direct exporting. In direct exporting telemetry/operational >> data is not pushed into the data packet, but the data packet with the >> DEX option triggers the data collection and optionally also exporting, >> but exporting is not mandatory and may be performed later, for example >> by the management plane. On the other hand, a trace option with the >> loopback flag causes all IOAM transit nodes to push IOAM data onto the >> trace option, and also loop a copy of the packet back to the sender. > > GIM>> Thank you for providing that comparison between the result of proce= ssing DEX and the Loopback. As I understand it, the result of DEX, i.e., im= mediate export or local processing with exporting a batch of telemetry data= , is determined by the local policy. If that is the case, the local policy = can produce the same result as for the Loopback flag, which could be the de= fault behavior for the DEX. [[[TM]]] Not exactly, because when using DEX in node X, the policy in node X enables immediate exporting of the IOAM data of node X, but does not enable exporting of the IOAM data of all the transit nodes between the encapsulating node and node X. The former is possible with DEX, but the latter is only possible with Loopback. This is just one example of why Loopback is not a special case of DEX. >> >> >> >> > >> > Further it Section 4, it is stated that: >> > >> > The two IOAM looped back copies are >> > terminated by the encapsulating node. >> > But I don't see any technical explanation that could sustain that assu= mption. As I understand the diagram in figure 1, a transit node doesn't kno= w the identity of the IOAM encapsulating node. Correct? If that is the case= , where does the transit node direct the looped packet? >> >> [TM] As described in the draft, the loopback flag is not necessarily >> applicable to all possible encapsulations. The way the return path is >> defined is encapsulation-specific. The draft currently states: >> >> Loopback can be used only if a return path from transit nodes and >> destination nodes towards the source (encapsulating node) exists. >> Specifically, loopback is only applicable in encapsulations in which >> the identity of the encapsulating node is available in the >> encapsulation header. If an encapsulating node receives a looped >> back packet that was not originated from the current encapsulating >> node, the packet is dropped. > > GIM>> Please help me understand, the looped back packet is transmitted us= ing the same encapsulation as the data packet with the Loopback flag? What = is the rationale? If we use MPLS LSP Ping as an example, the response can b= e sent in several ways, but the default is in IP/UDP encapsulation as the c= ommonly available transport. Why not use that and send the looped packet ov= er IP/UDP? I believe that the applicability of this mechanism will be much = broader. [[[TM]]] The rationale is to define very simple Loopback functionality. Simplicity is an advantage as it enables hardware implementations. >> >> >> >> > It seems that the text in the last paragraph attempts to walk around m= y questions. But I don't find that paragraph sufficient. It lacks the norma= tive language to guide a developer to produce resilient implementation. For= example, how to interpret: >> > Loopback can be used only if a return path from transit nodes and >> > destination nodes towards the source (encapsulating node) exists. >> > That reads like a recommendation, not a requirement. As a result, an i= mplementation may transmit an IOAM packet with the Loopback fag set regardl= ess of whether there's a return path or not. Then, how must a transit node = process such an IOAM packet? >> > >> >> [TM] Right, the last response and quoted text is relevant here as >> well. Please also note the following text from the draft: >> >> it is assumed that the >> source address is available in the encapsulation header. Thus, the >> source address of the original packet is used as the destination >> address in the copied packet. >> >> I propose to add the following sentence: >> The loopback flag MUST NOT be set if it is not guaranteed that there >> is a return path from each of the IOAM transit and IOAM decapsulating >> nodes, or if the encapsulating node's address is not available in the >> encapsulation header. > > GIM>> Thank you for the proposed text. I'd note that referring to the "en= capsulating node's address" and "source address" might be interpreted as ap= plying only to IP. In some networks, for example, BIER, the identity of the= IOAM encapsulating node, BFIR, is known from its identifier that, in turn,= can be mapped to the IP address. [[[TM]]] Right. Proposed text: The loopback flag MUST NOT be set if it is not guaranteed that there is a return path from each of the IOAM transit and IOAM decapsulating nodes, or if the encapsulating node's identity is not available in the encapsulation header. >> >> >> >> > A very concerning statement I've found in Section 4.1 >> > >> > The encapsulating node either generates synthetic packets with an >> > IOAM trace option that has the Loopback flag set ... >> > IOAM has been defined as a hybrid measurement protocol. This statement= implies that it is to be used as an active OAM protocol (all per RFC 7799 = definitions). The requirements for active OAM protocols in terms of their a= pplicability and, most of, security are very different from those set for a= hybrid measurement protocol. I believe that extending IOAM into an active = mode of measurement requires more discussion and the audience from other IE= TF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG. >> >> [TM] This draft does not define an active measurement protocol. The >> point in the draft is that the loopback flag can be used in active >> measurement packets. > > GIM>> I have to disagree. Per RFC 7799, the use of specially constructed = test packets is the primary characteristic of an active measurement method.= By introducing the Active flag, this drat makes the IOAM into an active me= asurement protocol with all the requirements to an active measurement proto= col to be applied. [[[TM]]] See note (1). >> >> The following text edit is proposed: >> >> OLD: >> The encapsulating node either generates synthetic packets with an >> IOAM trace option that has the Loopback flag set, or sets the loopack >> flag in a subset of the in-transit data packets. Loopback is used >> either proactively or on-demand, i.e., when a failure is detected. >> NEW: >> The loopback flag can be set in the IOAM trace option either in a >> subset of the in-transit data packets, or in synthetic packets that >> are generated by the encapsulating node. Loopback can be used >> either proactively or on-demand, i.e., when a failure is detected. >> >> > >> > The next statement explains the use case for the Loopback flag: >> > >> > Loopback is used >> > either proactively or on-demand, i.e., when a failure is detected. >> > That is the same use of ICMP and LSP Ping. What is the benefit of usin= g the Loopback flag instead of readily available ICMP? Does it work as L2 L= inktrace? I don't see that as a sufficient benefit considering the complexi= ty, exclusions, and risks associated and identified in the draft. It is cle= ar that there are tools like ICMP and LSP Ping that adequately address scen= arios listed in the draft. Don't see any technical reason for the introduct= ion of another mechanism that does not have any significant benefit compare= d to the existing OAM tools. Especially, considering the limited informatio= n that is allowed to be collected using the Loopback IOAM flag ("every tran= sit node that processes this trace option only adds a single data field, wh= ich is the Hop_Lim and node_id data field"). With the abundance of informat= ion and additional verification achieved using ICMP and LSP Ping, there's e= ven less rationale in the introduction of this over-complex and unnatural m= echanism. >> >> [TM] Right, as the draft says, the loopback flag is an "...alternative >> to Traceroute, that allows the encapsulating node to receive responses >> from multiple transit nodes along the path". Indeed, it slightly >> resembles ETH-LT (Ethernet Linktrace) in the sense that a single >> packet from the encapsulating node allows to quickly trace the entire >> path, but as with IOAM in general, using the loopback flag does not >> mandate a specific encapsulation. > > GIM>> Also, I must note that "pro-active" use of the Loopback is possible= only as part of the active measurement protocol. [[[TM]]] See note (1). >> >> >> > >> > The last paragraph states the requirement: >> > >> > IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with t= he >> > Loopback flag onto data packets that already include an IOAM >> > encapsulation. >> > I couldn't find any guidance on how an IOAM node that receives such in= valid combination processes the packet. >> > >> >> [TM] The current draft only specifies the flags. Specifically in the >> scenario described above, the encapsulating node does not set the >> loopback flag. This is intended to reduce the impact of potential >> amplification attacks. > > GIM>> I am still not clear about "MUST NOT push an IOAM encapsulation wit= h the Loopback flag" in the draft and your explanation "the encapsulating n= ode does not set the Loopback flag". As I understand it, in the given netwo= rk for the monitored data flow, only one IOAM encapsulating node can exist.= If that is correct, where does the existing IOAM encapsulation come from? [[[TM]]] The scenario that was raised by Martin Duke in his security review is a nested IOAM scenario, where traffic in an IOAM domain is forwarded through another domain/tunnel, which is also IOAM-enabled. This is explained in the draft: This requirement is intended to prevent IOAM Loopback nesting, where looped back packets may be subject to loopback in a nested IOAM domain. >> >> >> > >> > It is assumed that the identity of the IOAM encapsulating node is know= n to the node that is expected to sent a copy of the received packet back. = But what if that is not the case? How must that node act? >> >> [TM] Agreed. The following new text is proposed to be added to Section 4= .1: >> If the address of the encapsulating node is not available in the >> encapsulation header, then the transit/decapsulating node does not >> loop back a copy of the original packet. > > GIM>> I think that points to the significant limitation of the proposed m= echanism. Comparing with MPLS LSP Ping, we see that it allows tracing the L= SP even though MPLS encapsulation does not identify the ingress LER while t= he proposed Loopback would not work at all. [[[TM]]] See note (1). >> >> >> > I believe that there's inconsistency between Figure 1 and the followin= g text in Section 4.2 >> > >> > Thus, the >> > source address of the original packet is used as the destination >> > address in the copied packet. >> > It seems that the text assumes that the IOAM encapsulating node adds a= lso a network layer encapsulation. But how would it work, for example, in S= FC NSH data plane? Or MPLS? >> >> [TM] Right, the paragraph beginning with "Loopback can be used >> only..." (discussed in response to one of the previous comments) makes >> that restriction. >> >> > >> > Section 4.4 states that >> > >> > If the Node ID matches the current >> > IOAM node, it indicates that this is a looped back packet that was >> > initiated by the current IOAM node, and processed accordingly. >> > But according to the definition of node_id in Section 5.4.2.1 of draft= -ietf-ippm-ioam-data, "Node identifier field to uniquely identify a node wi= thin the IOAM-Namespace and associated IOAM-Domain." It appears that simply= comparing Node IDs is not sufficient to verify that the node received its = looped back packet. What is your opinion? >> >> [TM] Agreed. The following update is proposed: >> OLD: >> If the Node ID matches >> NEW: >> If the Node ID and IOAM-Namespace match >> >> >> > >> > If, as stated in Section 5, >> > >> > It [Active flag] is not intended as a replacement for existing >> > active OAM protocols, which may run in higher layers and make use o= f >> > the Active flag. >> > Then the question, What is the purpose of the Active flag? Existing ac= tive protocols, Fault Management and Performance Monitoring, are identified= by, for example, use of a well-known destination port number or, in case o= f MPLS, Generic Associated Channel type. There's no apparent need of using = IOAM option header to identify the payload as a control message of an activ= e OAM protocol. On the contrary, that would likely cause more confusion and= challenges to interoperation among different implementations. >> > >> > Three cases analyzed in Section 5 require special consideration, as th= ese likely present the motivation for the introduction of the Active flag: >> > >> > the first use case is not really using the Active flag at all and thus= the text doesn't seem adding any value to the draft; >> > it is not clear what is viewed as the benefit of using the Active flag= compared with using any of the existing active OAM protocols in the second= use case. I would appreciate it if you can clarify that for me. Since an S= FC NSH network is used as an example, is it required that a Service Functio= n (SF) or an SF Proxy process the IOAM header with Active flag set? Or woul= d a Service Function Forwarder (SFF) avoid sending a packet with the IOAM h= eader that has an Active flag set? And can you compare that with the proced= ures defined in the Active OAM for SFC draft? >> > My questions for the third use case described in Section 5 are the sam= e as above because I don't see the benefit of using a replicated data packe= t (less benefits if it is truncated) compared to a special test packet. >> > >> > In my conclusion on the Active flag, I don't see any clear benefit of = introducing it and using whether in place or in addition to the existing ac= tive OAM protocols. >> >> [TM] General response to all the Active flag comments: this was >> extensively discussed on the mailing list and in previous IETF >> meetings, and your comments about the previous versions of the >> document have contributed to greatly improving Section 5, which >> describes the main use cases of the Active flag. > > GIM>> I have to disagree with you here. I don't find the explanation in t= he document sufficient to justify the introduction of another mechanism to = achieve what has already been satisfactorily addressed in IETF. Without a m= ore detailed specification of the problem solved by the Active flag and how= that is achieved, this mechanism appears like the answer is looking for a = question, like a loaded gun without safety. [[[TM]]] See note (1). >> >> >> >> > >> > I am looking forward to your feedback and the continued discussion. >> > >> > Regards, >> > Greg >> > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly wrote: >> >> >> >> Hello IPPM, >> >> >> >> This email starts a Working Group Last Call on two related IOAM docum= ents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export. >> >> >> >> In-situ OAM Loopback and Active Flags >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 >> >> >> >> In-situ OAM Direct Exporting >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-exp= ort-06 >> >> >> >> Please provide feedback by replying to this email with your reviews a= nd if you think these documents are ready to progress, by Wednesday, Septem= ber 15. >> >> >> >> Best, >> >> Tommy & Ian >> >> >> >> _______________________________________________ >> >> 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 From nobody Wed Oct 13 05:24:42 2021 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 7A29C3A08C1; Wed, 13 Oct 2021 05:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 ACKiaYtlMOqO; Wed, 13 Oct 2021 05:24:36 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 EB0AC3A08F8; Wed, 13 Oct 2021 05:24:35 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id k7so7641671wrd.13; Wed, 13 Oct 2021 05:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t9IoELArEIuQ7h9uPrpOCcaL6x1GuH7CeZNajAfq/eI=; b=jFn3VBDgm5vj8mnwldEwWeLGFNn+AzMbyQggXyA6scpkcHf8H6ETDuNmJntavExvCZ jQI0AwUixY+TBCxg5SpewuJ7v4ZXZmfkDD3UGPuxE80AyTu0OXDj3A90F8GbFOoL+WQH Ulf2L5g/apTBwHGpPK4g/e8GGDTE6/E8j9IN7d+h/mI21pxWGlrlVUzR5daGE6T1/GDa fEa7zYE7FEjq8gSWARiDbZInLDnCd/vlqWZnGMAIN4s23NSGYcXN/RxAfSOCqfRki9gx Ro4JRB4wnrGOCBkur5rke8UPqmVNUvnJgWQfoNU/zNdhsxq7AtgbmFuam4o2g+br9gqE YP5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t9IoELArEIuQ7h9uPrpOCcaL6x1GuH7CeZNajAfq/eI=; b=J5blusqBQ7bO3JA5RnvcsRjl8ZbJ8CsgB+DuarqNRkfWMC4EYOizjD+N58AfYwkLoF AM2NJF9ie3A8jhhDuxFhjQl8O+obw2bVdg6bYhd3w0KTyvQrEE8V2xuu7reul3c6G/j/ +x85TEcrLNyrPMEuhBKezXyYyhh2NPraIfl6514q4oTe7+j9u/1WZ+s5gf0eLqm9fPdQ GWiGgLtWCviGu4Z0xSLHc8NbhCuDjb5G9Zno7CnYS96lj4HzO8efZZWvc1Kis8ZdNDT/ YieM0dn5LHKxyBb54P+ATtkkmaM3AlkYq5iqbfPTEobZZACP+1SmgQPCyRqZadeMNzDx 1pfw== X-Gm-Message-State: AOAM53344TQ7gkyx5S4RIP5NPL0NtfJhCZ7pgRO+v3wJv8QkywM7a4yZ jaZZTgdKPijLSCgowRviAAro9vgtajWrBQJwOaMkqOkIdUA= X-Google-Smtp-Source: ABdhPJxzt+T7jUvezOEwWgzc2aRj+AI2EB7VHNqtyJPQqTsD7+yHGUx9+kyP7BO4A9NBym2IebXFRGTwwFJ8F0A+8oM= X-Received: by 2002:a05:600c:1d03:: with SMTP id l3mr12490260wms.119.1634127872103; Wed, 13 Oct 2021 05:24:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 13 Oct 2021 15:24:19 +0300 Message-ID: To: IPPM Chairs , Tommy Pauly Cc: "IETF IPPM WG (ippm@ietf.org)" , Greg Mirsky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] WGLC for IOAM Flags 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, 13 Oct 2021 12:24:41 -0000 Minor correction - here is the correct link to the updated version of the d= raft: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ :) Cheers, Tal. On Wed, Oct 13, 2021 at 3:18 PM Tal Mizrahi wro= te: > > Dear Chairs, > > Thanks again to Greg for a very thorough review that helped us improve > the quality and clarity of the draft. We believe we addressed most of > the comments, either by updating the text, or by responding to the > comments. > Some further responses can be found below, marked [[[TM]]]. > > Note (1): it looks like some of the comments are basically about the > purpose of the document. Addressing these documents would probably > require a complete rewriting of the document with a different purpose. > At this point we do not think it would make sense to align to these > comments. These comments can be easily found by searching for "(1)" > through this email. > > We have posted an updated version of this draft (07): > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > > > We believe the draft is ready to be submitted to the IESG. > > Thanks, > Authors. > > > On Fri, Oct 8, 2021 at 7:04 PM Greg Mirsky wrote: > > > > Hi Tal, > > thank you for your responses to my comments and questions. Please find = my follow-up notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi wrote: > >> > >> Hi Greg, > >> > >> Many thanks for the detailed comments. > >> Please see the responses below, as well as suggested text edits in som= e cases. > >> > >> Cheers, > >> The authors. > >> > >> On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky wro= te: > >> > > >> > Dear Authors, WG Chairs, and All, > >> > I've read the latest version of the draft and have several comments = and questions to share with you. I would much appreciate the opportunity to= discuss these before I can state my support for progressing this draft to = publication. > >> > > >> > The Abstract states that: > >> > > >> > In-situ Operations, Administration, and Maintenance (IOAM) record= s > >> > operational and telemetry information in packets while they trave= rse > >> > a path between two points in the network. > >> > > >> > I think that is not a complete description of IOAM options as it exc= ludes the Direct Export option. It might be easier to improve by s/records/= collects/. Also, what, in your opinion, is the distinction between operatio= nal and telemetry information? I think that operational information collect= ed from remote nodes is one example of telemetry information. What do you t= hink? > >> > >> [TM] Agreed. Your proposal makes sense: s/records/collects/ > >> Regarding the difference between operational and telemetry > >> information, the way I see it "telemetry" refers to measurements that > >> are being exported to an external/remote entity, whereas operational > >> information is not measurement-based, such as the Node ID or Interface > >> ID. > > > > GIM>> I think that there's no standardized definition of "telemetry" an= d "telemetry information". I share the idea expressed in the following: > > > > Telemetry is automated communication that processes from multiple data = sources. Telemetry data improves customer experiences, monitors security, a= pplication health, quality, and performance. > > > > For different cases, the set of information referred to as telemetry da= ta variates. For example, CPU and buffer utilization are valuable for virtu= alized environments. In other words, I understand telemetry data as informa= tion extracted from a remote system that characterizes the system's state. = In any case, providing a definition would be helpful to a reader of the doc= ument. > > [[[TM]]] This word is mentioned only once in the document (in the > abstract), and not sure adding a definition for this particular word > would change the readability of the document. > > >> > >> > >> > >> > > >> > nit s/the the/the/ > >> > >> [TM] Agreed. > >> > >> > I think that Abstract and Introduction can be improved by explaining= the purpose of defining the Loopback and Active flags. What each of them i= s intended to achieve and improve? > >> > >> [TM] The point is well-taken, and the following text will be added to > >> the introduction. In order to avoid text repetition, I believe it > >> would be best not to add it to the abstract as well. > >> > >> OLD: > >> - > >> NEW: > >> The Loopback flag is used to request that each transit device along > >> the path loops back a copy of the data packet to the sender. The > >> Active flag indicates that a packet is used for active measurement. > > > > GIM>> Thank you for the proposed text. I have several notes to the new = text: > > > > As I understand the behavior required from a node processing the Loopba= ck flag, the returned packet is not the complete but truncated data packet. > > Is "active measurement" used in the context of RFC 7799? If "yes", does= that mean that the packet is a specifically generated test packet? > > [[[TM]]] These are two good points. Based on these comments the > following text is proposed instead. > NEW: > The Loopback flag is used to request that each transit device along > the path loops back a truncated copy of the data packet to the sender. Th= e > Active flag indicates that a packet is used for active measurement. > The term active measurement in the context of this document is as defined > in [RFC7799]. > > >> > >> > >> > >> > It is stated in the Introduction that: > >> > > >> > This document defines > >> > two new flags in the Pre-allocated and Incremental Trace options:= the > >> > Loopback and Active flags. > >> > Does that mean that neither of the two flags is applicable in the Di= rect Export option? Should draft-ietf-ippm-ioam-direct-export have an expli= cit statement regarding the applicability of the Loopback and Active flags?= And if any is applicable, describe the behavior of an IOAM node receiving = it. > >> > >> [TM] Right. > >> The direct exporting draft explicitly states the behavior of each > >> field in the DEX option header including the flags, so there seems to > >> be no need to specify flags that are supported in other options. > > > > GIM>> I'm a bit confused. Can you help me with the text from the DEX dr= aft that specifies the use of the Loopback and Active flags in combination = with the DEX trace option? > > [[[TM]]] The DEX option does not support the loopback and active > flags. That is why the DEX document does not discuss these flags. The > DEX document defines the DEX option header including all the flags > that are relevant to the DEX option (loopback and active are not > included). > > >> > >> > >> > > >> > In Section 4 the purpose of using the Loopback flag is explained as: > >> > > >> > Loopback allows an IOAM encapsulating node to trace the path to a > >> > given destination, and to receive per-hop data about both the for= ward > >> > and the return path. > >> > In my previous comments, I've pointed out that the Loopback mode is = just a special case of the Direct Export option. In addition to that, I wou= ld appreciate your explanation of how the IOAM encapsulating node receives = per-hop data about the return path. How does that work, for example, in an = MPLS or SFC NSH environment? > >> > >> [TM] It is slightly similar to direct exporting, but is not a special > >> case of direct exporting. In direct exporting telemetry/operational > >> data is not pushed into the data packet, but the data packet with the > >> DEX option triggers the data collection and optionally also exporting, > >> but exporting is not mandatory and may be performed later, for example > >> by the management plane. On the other hand, a trace option with the > >> loopback flag causes all IOAM transit nodes to push IOAM data onto the > >> trace option, and also loop a copy of the packet back to the sender. > > > > GIM>> Thank you for providing that comparison between the result of pro= cessing DEX and the Loopback. As I understand it, the result of DEX, i.e., = immediate export or local processing with exporting a batch of telemetry da= ta, is determined by the local policy. If that is the case, the local polic= y can produce the same result as for the Loopback flag, which could be the = default behavior for the DEX. > > [[[TM]]] Not exactly, because when using DEX in node X, the policy in > node X enables immediate exporting of the IOAM data of node X, but > does not enable exporting of the IOAM data of all the transit nodes > between the encapsulating node and node X. The former is possible with > DEX, but the latter is only possible with Loopback. This is just one > example of why Loopback is not a special case of DEX. > > >> > >> > >> > >> > > >> > Further it Section 4, it is stated that: > >> > > >> > The two IOAM looped back copies are > >> > terminated by the encapsulating node. > >> > But I don't see any technical explanation that could sustain that as= sumption. As I understand the diagram in figure 1, a transit node doesn't k= now the identity of the IOAM encapsulating node. Correct? If that is the ca= se, where does the transit node direct the looped packet? > >> > >> [TM] As described in the draft, the loopback flag is not necessarily > >> applicable to all possible encapsulations. The way the return path is > >> defined is encapsulation-specific. The draft currently states: > >> > >> Loopback can be used only if a return path from transit nodes and > >> destination nodes towards the source (encapsulating node) exists. > >> Specifically, loopback is only applicable in encapsulations in whic= h > >> the identity of the encapsulating node is available in the > >> encapsulation header. If an encapsulating node receives a looped > >> back packet that was not originated from the current encapsulating > >> node, the packet is dropped. > > > > GIM>> Please help me understand, the looped back packet is transmitted = using the same encapsulation as the data packet with the Loopback flag? Wha= t is the rationale? If we use MPLS LSP Ping as an example, the response can= be sent in several ways, but the default is in IP/UDP encapsulation as the= commonly available transport. Why not use that and send the looped packet = over IP/UDP? I believe that the applicability of this mechanism will be muc= h broader. > > [[[TM]]] The rationale is to define very simple Loopback > functionality. Simplicity is an advantage as it enables hardware > implementations. > > >> > >> > >> > >> > It seems that the text in the last paragraph attempts to walk around= my questions. But I don't find that paragraph sufficient. It lacks the nor= mative language to guide a developer to produce resilient implementation. F= or example, how to interpret: > >> > Loopback can be used only if a return path from transit nodes and > >> > destination nodes towards the source (encapsulating node) exists. > >> > That reads like a recommendation, not a requirement. As a result, an= implementation may transmit an IOAM packet with the Loopback fag set regar= dless of whether there's a return path or not. Then, how must a transit nod= e process such an IOAM packet? > >> > > >> > >> [TM] Right, the last response and quoted text is relevant here as > >> well. Please also note the following text from the draft: > >> > >> it is assumed that the > >> source address is available in the encapsulation header. Thus, the > >> source address of the original packet is used as the destination > >> address in the copied packet. > >> > >> I propose to add the following sentence: > >> The loopback flag MUST NOT be set if it is not guaranteed that there > >> is a return path from each of the IOAM transit and IOAM decapsulating > >> nodes, or if the encapsulating node's address is not available in the > >> encapsulation header. > > > > GIM>> Thank you for the proposed text. I'd note that referring to the "= encapsulating node's address" and "source address" might be interpreted as = applying only to IP. In some networks, for example, BIER, the identity of t= he IOAM encapsulating node, BFIR, is known from its identifier that, in tur= n, can be mapped to the IP address. > > [[[TM]]] Right. Proposed text: > The loopback flag MUST NOT be set if it is not guaranteed that there > is a return path from each of the IOAM transit and IOAM decapsulating > nodes, or if the encapsulating node's identity is not available in the > encapsulation header. > > >> > >> > >> > >> > A very concerning statement I've found in Section 4.1 > >> > > >> > The encapsulating node either generates synthetic packets with an > >> > IOAM trace option that has the Loopback flag set ... > >> > IOAM has been defined as a hybrid measurement protocol. This stateme= nt implies that it is to be used as an active OAM protocol (all per RFC 779= 9 definitions). The requirements for active OAM protocols in terms of their= applicability and, most of, security are very different from those set for= a hybrid measurement protocol. I believe that extending IOAM into an activ= e mode of measurement requires more discussion and the audience from other = IETF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG. > >> > >> [TM] This draft does not define an active measurement protocol. The > >> point in the draft is that the loopback flag can be used in active > >> measurement packets. > > > > GIM>> I have to disagree. Per RFC 7799, the use of specially constructe= d test packets is the primary characteristic of an active measurement metho= d. By introducing the Active flag, this drat makes the IOAM into an active = measurement protocol with all the requirements to an active measurement pro= tocol to be applied. > > [[[TM]]] See note (1). > > >> > >> The following text edit is proposed: > >> > >> OLD: > >> The encapsulating node either generates synthetic packets with an > >> IOAM trace option that has the Loopback flag set, or sets the loopa= ck > >> flag in a subset of the in-transit data packets. Loopback is used > >> either proactively or on-demand, i.e., when a failure is detected. > >> NEW: > >> The loopback flag can be set in the IOAM trace option either in a > >> subset of the in-transit data packets, or in synthetic packets that > >> are generated by the encapsulating node. Loopback can be used > >> either proactively or on-demand, i.e., when a failure is detected. > >> > >> > > >> > The next statement explains the use case for the Loopback flag: > >> > > >> > Loopback is used > >> > either proactively or on-demand, i.e., when a failure is detected= . > >> > That is the same use of ICMP and LSP Ping. What is the benefit of us= ing the Loopback flag instead of readily available ICMP? Does it work as L2= Linktrace? I don't see that as a sufficient benefit considering the comple= xity, exclusions, and risks associated and identified in the draft. It is c= lear that there are tools like ICMP and LSP Ping that adequately address sc= enarios listed in the draft. Don't see any technical reason for the introdu= ction of another mechanism that does not have any significant benefit compa= red to the existing OAM tools. Especially, considering the limited informat= ion that is allowed to be collected using the Loopback IOAM flag ("every tr= ansit node that processes this trace option only adds a single data field, = which is the Hop_Lim and node_id data field"). With the abundance of inform= ation and additional verification achieved using ICMP and LSP Ping, there's= even less rationale in the introduction of this over-complex and unnatural= mechanism. > >> > >> [TM] Right, as the draft says, the loopback flag is an "...alternative > >> to Traceroute, that allows the encapsulating node to receive responses > >> from multiple transit nodes along the path". Indeed, it slightly > >> resembles ETH-LT (Ethernet Linktrace) in the sense that a single > >> packet from the encapsulating node allows to quickly trace the entire > >> path, but as with IOAM in general, using the loopback flag does not > >> mandate a specific encapsulation. > > > > GIM>> Also, I must note that "pro-active" use of the Loopback is possib= le only as part of the active measurement protocol. > > [[[TM]]] See note (1). > > >> > >> > >> > > >> > The last paragraph states the requirement: > >> > > >> > IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with= the > >> > Loopback flag onto data packets that already include an IOAM > >> > encapsulation. > >> > I couldn't find any guidance on how an IOAM node that receives such = invalid combination processes the packet. > >> > > >> > >> [TM] The current draft only specifies the flags. Specifically in the > >> scenario described above, the encapsulating node does not set the > >> loopback flag. This is intended to reduce the impact of potential > >> amplification attacks. > > > > GIM>> I am still not clear about "MUST NOT push an IOAM encapsulation w= ith the Loopback flag" in the draft and your explanation "the encapsulating= node does not set the Loopback flag". As I understand it, in the given net= work for the monitored data flow, only one IOAM encapsulating node can exis= t. If that is correct, where does the existing IOAM encapsulation come from= ? > > [[[TM]]] The scenario that was raised by Martin Duke in his security > review is a nested IOAM scenario, where traffic in an IOAM domain is > forwarded through another domain/tunnel, which is also IOAM-enabled. > This is explained in the draft: > > This requirement is intended to prevent IOAM Loopback > nesting, where looped back packets may be subject to loopback in a > nested IOAM domain. > > > >> > >> > >> > > >> > It is assumed that the identity of the IOAM encapsulating node is kn= own to the node that is expected to sent a copy of the received packet back= . But what if that is not the case? How must that node act? > >> > >> [TM] Agreed. The following new text is proposed to be added to Section= 4.1: > >> If the address of the encapsulating node is not available in the > >> encapsulation header, then the transit/decapsulating node does not > >> loop back a copy of the original packet. > > > > GIM>> I think that points to the significant limitation of the proposed= mechanism. Comparing with MPLS LSP Ping, we see that it allows tracing the= LSP even though MPLS encapsulation does not identify the ingress LER while= the proposed Loopback would not work at all. > > [[[TM]]] See note (1). > > >> > >> > >> > I believe that there's inconsistency between Figure 1 and the follow= ing text in Section 4.2 > >> > > >> > Thus, the > >> > source address of the original packet is used as the destination > >> > address in the copied packet. > >> > It seems that the text assumes that the IOAM encapsulating node adds= also a network layer encapsulation. But how would it work, for example, in= SFC NSH data plane? Or MPLS? > >> > >> [TM] Right, the paragraph beginning with "Loopback can be used > >> only..." (discussed in response to one of the previous comments) makes > >> that restriction. > >> > >> > > >> > Section 4.4 states that > >> > > >> > If the Node ID matches the current > >> > IOAM node, it indicates that this is a looped back packet that wa= s > >> > initiated by the current IOAM node, and processed accordingly. > >> > But according to the definition of node_id in Section 5.4.2.1 of dra= ft-ietf-ippm-ioam-data, "Node identifier field to uniquely identify a node = within the IOAM-Namespace and associated IOAM-Domain." It appears that simp= ly comparing Node IDs is not sufficient to verify that the node received it= s looped back packet. What is your opinion? > >> > >> [TM] Agreed. The following update is proposed: > >> OLD: > >> If the Node ID matches > >> NEW: > >> If the Node ID and IOAM-Namespace match > >> > >> > >> > > >> > If, as stated in Section 5, > >> > > >> > It [Active flag] is not intended as a replacement for existing > >> > active OAM protocols, which may run in higher layers and make use= of > >> > the Active flag. > >> > Then the question, What is the purpose of the Active flag? Existing = active protocols, Fault Management and Performance Monitoring, are identifi= ed by, for example, use of a well-known destination port number or, in case= of MPLS, Generic Associated Channel type. There's no apparent need of usin= g IOAM option header to identify the payload as a control message of an act= ive OAM protocol. On the contrary, that would likely cause more confusion a= nd challenges to interoperation among different implementations. > >> > > >> > Three cases analyzed in Section 5 require special consideration, as = these likely present the motivation for the introduction of the Active flag= : > >> > > >> > the first use case is not really using the Active flag at all and th= us the text doesn't seem adding any value to the draft; > >> > it is not clear what is viewed as the benefit of using the Active fl= ag compared with using any of the existing active OAM protocols in the seco= nd use case. I would appreciate it if you can clarify that for me. Since an= SFC NSH network is used as an example, is it required that a Service Funct= ion (SF) or an SF Proxy process the IOAM header with Active flag set? Or wo= uld a Service Function Forwarder (SFF) avoid sending a packet with the IOAM= header that has an Active flag set? And can you compare that with the proc= edures defined in the Active OAM for SFC draft? > >> > My questions for the third use case described in Section 5 are the s= ame as above because I don't see the benefit of using a replicated data pac= ket (less benefits if it is truncated) compared to a special test packet. > >> > > >> > In my conclusion on the Active flag, I don't see any clear benefit o= f introducing it and using whether in place or in addition to the existing = active OAM protocols. > >> > >> [TM] General response to all the Active flag comments: this was > >> extensively discussed on the mailing list and in previous IETF > >> meetings, and your comments about the previous versions of the > >> document have contributed to greatly improving Section 5, which > >> describes the main use cases of the Active flag. > > > > GIM>> I have to disagree with you here. I don't find the explanation in= the document sufficient to justify the introduction of another mechanism t= o achieve what has already been satisfactorily addressed in IETF. Without a= more detailed specification of the problem solved by the Active flag and h= ow that is achieved, this mechanism appears like the answer is looking for = a question, like a loaded gun without safety. > > [[[TM]]] See note (1). > > > >> > >> > >> > >> > > >> > I am looking forward to your feedback and the continued discussion. > >> > > >> > Regards, > >> > Greg > >> > > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly wrote: > >> >> > >> >> Hello IPPM, > >> >> > >> >> This email starts a Working Group Last Call on two related IOAM doc= uments, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direct-export. > >> >> > >> >> In-situ OAM Loopback and Active Flags > >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > >> >> > >> >> In-situ OAM Direct Exporting > >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export= / > >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-e= xport-06 > >> >> > >> >> Please provide feedback by replying to this email with your reviews= and if you think these documents are ready to progress, by Wednesday, Sept= ember 15. > >> >> > >> >> Best, > >> >> Tommy & Ian > >> >> > >> >> _______________________________________________ > >> >> 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 From nobody Wed Oct 13 07:38:16 2021 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 E09C53A0AAA for ; Wed, 13 Oct 2021 07:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecomitalia.it header.b=U0re8Vhb; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=telecomitalia.onmicrosoft.com header.b=luFwxe4e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGvzgVvwkcTm for ; Wed, 13 Oct 2021 07:38:06 -0700 (PDT) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F6C3A0B4F for ; Wed, 13 Oct 2021 07:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@telecomitalia.it; t=1634135834; x=2498049434; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=TYLZqG3uFrOHZl1afh5Kk1Fb235V/yH5JOe0JfK15Bg=; b=U0re8VhbCzHgm2u4RMEcUnxCHOSBSbeozjjqcdYG3mGvhWAcTlKQ+gyw/U2G8OOG vndS/JOrl1GozkVZ4eJcc5f2Lau0grQdImCyGXIq4XuNX1GtljXSzsmfQJWP8/W/ 0V+mK2Chrz2jEazy5BMf60zLiLwfU8pqVsLVLI/PFJXbxarBNNPqrPUhzgTQSJkC uBhS/IlR7BX0e5tX4A+ibw3yQqvaUMAKhHCsCFvYZA5lmdUle77QHr9NGVYxL25V NJWidvUB3N8spojXooeOWy9bvXzUdAWRocfLwe7lSnC8jBBYSzSWXwYQqUHzEq5Y jo2zJFnDBq05RsAmF2lR9Q==; X-AuditID: d9a97917-e1aeb70000009977-70-6166ef1ab4a4 Received: from TELMBXA07RM001.telecomitalia.local ( [10.14.252.36]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 0A.32.39287.A1FE6616; Wed, 13 Oct 2021 16:37:14 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iDRVBoV6RR7DIQ/3ZcBLP81WKvUlx6p1vhlPbTVo6CBdiS6SyK744NtBN50yxgFO9GuVMItRRFK+Ok3cjtyPT7TU8iHfIKHKo1cHdIG41HjO7f/MT2iP2DtjBor0FLmFtdAPKJnUj5qJFdR/OJM0gagB9bNAv5iL5JoAwMloHhiUv4Sthwug3lwjrpAu8+y3eA8Yj+ZkYzSlV34BrB26pGPHgsR4y79wiFIPOZsAu7GI+fhG5XQS9nM/mr1xNc589P9vDB1IjbehF8G8Ds7n94kgK3LDSDJtzCaM7mP33hKHgjctb0lxjBZrLoQdOPL6h1UE4C5LSQLz68MWIfbXKw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Uz+2G7iUu8wJUT2wn7dDPyhcT9gR4rSFBGBuwKZIhMM=; b=mTusBRhjeU9QpcNZkmvHW6JHUACdu+ZmWW8gFKiQ/YzGi/IESXw/jChxXSm0dUIo+j+Ur1TfkwXoeTuxzE7fBOrKvehg8fQJu3mDBXYtFyw1Bj+p82IdvpeVjEfWrnUIj35sBJUSYzsgmEw9TfU1xDOBeSffGs9gm1/dWQ8XvHQCAu0+k3hwBpLi4SNQF+RLAcO7HjR3LtM7BYsbRMLdddXqN9GXbSWQSg7uwmxCe53HLELZZugndzNYL8ENwfbMgnJFZCtvCWexg169c3Zgr4zbGaxIyKZiNbPCfXZGY7HRbAktwz98A3waMNpZr3cjsTK50pbNL6kAB6aeGSanfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telecomitalia.it; dmarc=pass action=none header.from=telecomitalia.it; dkim=pass header.d=telecomitalia.it; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecomitalia.onmicrosoft.com; s=selector1-telecomitalia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uz+2G7iUu8wJUT2wn7dDPyhcT9gR4rSFBGBuwKZIhMM=; b=luFwxe4eGfN14+0R+kVlGsN4XpKp7Z5orIgUAiCIk/HTR7oIS55Iw/DKh5qEMIINBMqEjH4AYElUiM+C/tNrxW1R3Q6ncQuNm2J1vNy7gAY9HXuPHg5Cpau8agNAmcCPu2mrTBKt2WkSMvrSehGsTXBRX9MGynuqRWhivclXW18= From: Nilo Massimo To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AdfAOeo0SHehrylVRCil90is+fgPYA== Date: Wed, 13 Oct 2021 14:37:12 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Enabled=true; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SetDate=2021-10-13T14:36:28Z; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Method=Standard; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Name=Uso Interno; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SiteId=6815f468-021c-48f2-a6b2-d65c8e979dfb; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ActionId=4f7824c4-87f0-47c6-b2fc-4a2754665084; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=telecomitalia.it; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 99254a47-de8b-4ef3-e761-08d98e56f204 x-ms-traffictypediagnostic: DB8PR07MB6331: x-microsoft-antispam-prvs: x-ti-disclaimer: ADBanner x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XaafrXF31Q4rbf2idjkMvVS8EQAuyKj7yGNhu2t5r20CX3RAZaAgV7hJN8bfPFrkQwo8jfrMx/dOyWXIqblKfoEeTHhG1Du53so1QV/c/6odg7ZPzpwJxQ0X+TfYL0box1IOJKUfFKbcyfIjaNOBRMEOU9GjiiCZA/RfraN3qjmfcstom1W7bZeXFBxOV/1iBBegFkgHwafju/gg/EXs32P7/lq8Vuvx+ncccOlDTY/vEDgQdqDBfE0AmHZSszOAFZwtOCdxsYTBL1j5RZRWallLpl8BvC/94U9uoLGFXGUBDTsA8xpSsH19fQMFMp8G5EBnuFUMERab6XDghkZLzEA7qe4p0c7AuRUvGeQ+cz0W6T61kBS4r1P4JFPZBjBd5jYhNQierg2Faw+VZ/q4SBsL9QIYfdGD2WNqH0oF7klpHeSiWJX8G/ET/QYymKazeHtEKcm9VpC1aQwB0agRMM+4XfWZW46hb/0vhWUeFE4pViH/S1UJQzh5haLsPO7tVxzK8j4M536HTQKM+j6i6O2TsesSLUtChDHNgoq1W2ZIb72obxt3BnHJsWLrERhSyEw6CZ+BHmeZC2ukLk2qJZwoMQAcxpUFEUfE5X9qheLmwREWgZiih0wf1HNByhU9oqYdymAAxhkUCL+Nq0kL4M7v9i09x1y1hacOD1+wS41fqRuDG7q9Ztsuxyvks0BkVsEJ8ljE+oUzANu7tyP1fhpA2ov4A6ex//jC711RRR6vWaNFNp8eHoVsROrkUk28PG5pLzfoQpo61JV7UanONRMW8uugwSbXzVx5iFT9xcQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7929.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(8676002)(5660300002)(122000001)(186003)(52536014)(82960400001)(8936002)(86362001)(26005)(9686003)(55016002)(316002)(110136005)(6506007)(64756008)(66476007)(7696005)(166002)(966005)(66946007)(38100700002)(53546011)(38070700005)(66446008)(66556008)(33656002)(2906002)(76116006)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6VSc3JWcYlmy39cqV1jHGNmI5DIcLe8RTaut+DDMdPsvT/8jxr97UP8Mwz?= =?iso-8859-1?Q?AQpU3Nd6SYdnBrXx/SjSJbDBmpY9peNHQ8Z350qdMURmcVj8TqjhGupC6B?= =?iso-8859-1?Q?7U2afkERXLbwz05k8VrwvpfZEyHcVzN4Dip2f1S+ECmWXsYQA3Q9wUmsyc?= =?iso-8859-1?Q?7WLxRcup4rR0YmeuntElJaJ26v4/ol5u13eot5ODNlSVVeug8a2dzSBgJa?= =?iso-8859-1?Q?L+U19kt5dcah5M/eLR04+PVb1hbbaRw7en4xrdFYz1K1AgJQf8tAwImSwN?= =?iso-8859-1?Q?DQIxU2wiCqhv50AppsfmLZLlQa2cUaIwN7gcMwVn0BuRzxNwHPs5SnD/L6?= =?iso-8859-1?Q?9hpPJefwI4fYhVhQPIQtDJqZG/KDjUbpdV48eOzfw7XZigIH2r6fbozu5F?= =?iso-8859-1?Q?NMtTpcYAh+CnKDENS/A6gUkRZusxURBEZuWPyVt9Pux3szIiYO1Lauc5uH?= =?iso-8859-1?Q?UDKp3DNEa0di/uFBWkxdbGATX6DH8/5UHp9fTY//zpW7Z5Rb8h9e+cdoI7?= =?iso-8859-1?Q?YCcBN3OBvmdf2a6DJkHVx0F70n0PMZzhtptHo9XqFbetXYyvsyNpMMzz5t?= =?iso-8859-1?Q?/R+6emGfWeMdbJCyIteVtAy6khp+4Sii9KD0+2HI4GFvwcQvAb3BCdbgIe?= =?iso-8859-1?Q?8BK22kQb/7zdgqgIEtORIXIKUiN7ROm8/pjJ2f407vzgXVPf16tnhYnbdS?= =?iso-8859-1?Q?2ae0cLedwsnUZGShai4Ej76zevKvSevZ8RREzn+DyH0qVdXLcpIKLyf4fb?= =?iso-8859-1?Q?Uumaf8fEfu6XSjXtRm+ArZV0ehvFcRqY+oETaE3Oye0xvpFqAH0mnoVUb7?= =?iso-8859-1?Q?Zjb/RV24N6Pky0GRF2fUo2gOQIkVeubhA9pFdFed2UgYVr1lcj2UBYry+T?= =?iso-8859-1?Q?E0OybBL1PeRmUYyXZ5X2ZXEW20UqQp/y9nxJTUJwJ/t3K9qlNGnMhk0sI0?= =?iso-8859-1?Q?ZMR51Y1AivKXh8VqS6NRMwHrFhf5okaXh0qU2A2GClqG2tCCMa1exG0w7g?= =?iso-8859-1?Q?Yxgiz8wrUBb8W3oskscC3VWXrgG8OQ0TK+nBy+8U2IM7Q4+RcIVu35rpgy?= =?iso-8859-1?Q?heq8ItEctG735Cirn4dCm9JpNqqsOKOcX8TLrhGVstP1FrnAOWD4jPLrcq?= =?iso-8859-1?Q?cA63Kl+xWYasNNG1XDK/PgMGNVL1tzXMuOOA00qayjEMO+41x8JlGz1C+3?= =?iso-8859-1?Q?Za6Y2AaiDJ0CSRXjWQiS6idCnf5WWSVSyQCyDEKiI4M6KPmQi0C14KaOba?= =?iso-8859-1?Q?77CbzPLvkv3q+Q72flyA/zRQIZS/senBgh4F/TyDoLGAZgKDFcm6jY3uzY?= =?iso-8859-1?Q?0foRpjiHo8T/PA+ETOz3GxP7BrrPQ3XYI0UkPL8hxFC/QTg=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB9PR07MB79291AF8B9FD4C9512E8E5C3E5B79DB9PR07MB7929eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7929.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99254a47-de8b-4ef3-e761-08d98e56f204 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 14:37:12.7737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6815f468-021c-48f2-a6b2-d65c8e979dfb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TI7HHUwpCfLdCUQwEp9p9+2VToQea50Jx8UmTd6GLqZsR8deUtaz41t7NMGt8b85GCOv1f9jMXQiiBOifELdPt9Sc/ywylKmtTjox5q8hOA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR07MB6331 X-OriginatorOrg: telecomitalia.it X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOJsWRmVeSWpSXmKPExsXCxfdHRVfqfVqiwdnrUhY9D94xW/RMesXs wORxYtkVVo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFik4ujgBJVOLlBQy U2yVzJQUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZJdYGlqcUm+Qm5qcXFienpmvkLCNNGMhSe72AvWW1ZcOvuRrYHxiVEXIyeHhICJROurZYwg tpDAVCaJB0/4uhi5OBgFljFLTPxziR3KYZV4MesaG4RzhFFiafMBJhCHRWA/s0THzpdg/WwC RhKnV/xiBbFFBFIleo7fZwKxhQW8JeZsb2GBiPtIXPpwng3C1pM4dnMJWA2LgKrEsR+tzCA2 r0CMxIGeA2A2o4CsxITdi8DmMwuIS9x6Mp8J4m4BiSV7zjND2KISLx//YwU5iFdgIYvE9bmv mSBOncsosa6jDapKVuLS/G5GCNtXYkPTT1YIW0ti1/7bUHa2RNvVVVC2pMThw5vYIGw1ifcT t0LF5SRW9T5kgbDlJaYtes8OYctIPLixHRxGEgLn2SRuTVjBDuE8Y5Y4uWc+1CQDiXnfjkBV zeWTeD/tPcsERr1ZSP6bxcgBZOdLtN/RnQUODkGJkzOfsECU6EncmDqFDcLWlli28DUzhK0r MePfIRZk8QWM7KsYRXMrDIz1SlJzUpPzczNLEnMyE/UySzYxApPuzZWV4jsYr217o3eIkYmD 8RCjBAezkgivYUZqohBvSmJlVWpRfnxRaU5q8SFGH2AETWSWEk3OB6b9vJJ4Q1MzU3NjIzNT A1MzSxzCSuK8116mJQoJpAOTfXZqakFqEcw4Jg5OqQamVaukb1/3yY3tSVVaOeHm01Kry4KZ bw0uep7u/pjq3XJZWdncQlv1TeZf4dsJhS08BjxKpd48YnLeDr2xDXHTI2fc3l4ts8F5r1tT 9uS7+6yOMK7bzJBzPX/Lxv/8PcWhzQ93lNb9Oi/yYMmBwv/bfy/6Xqy2JqZGV+b8a66jOsVa u3Y937f6gsX5/zd2RZwpnnNfiOu6w8qXySs7imqvv7m0urTu0e87TanXukRPX/Kym8WSJPLw /Uf7s4/STonzx6oot4qZfHVJOvvR/tcT7etzLG8WX2H/03xO/kSxmZudQ8ax/fZvJgbxRrsG dZrortI842sTUPrWQ+aM+aPeUp6izFO+iVcnTeD9oX1WiaU4I9FQi7moOBEAnR9YHloEAAA= Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 13 Oct 2021 14:38:12 -0000 --_000_DB9PR07MB79291AF8B9FD4C9512E8E5C3E5B79DB9PR07MB7929eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi WG, Chairs, I support the adoption of this draft as author. This document is intended to provide a complete description for the differen= t explicit performance measurement methodologies, talking about the metrics= and characteristics that are specific to each. Best regards, Massimo TIM - Uso Interno - Tutti i diritti riservati. From: ippm On Behalf Of Tommy Pauly Sent: venerd=EC 8 ottobre 2021 17:59 To: IETF IPPM WG (ippm@ietf.org) Subject: [EXT] [ippm] Adoption call for Explicit Flow Measurements Technique= s Hello IPPM, This email starts an adoption call for draft-mdt-ippm-explicit-flow-measurem= ents, "Explicit Flow Measurements Techniques". This document is proposed as= an Informational document that describes techniques that go beyond single b= it markings like the QUIC spin bit. https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/ https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measureme= nts-02 This adoption call will last until Friday, October 22. Please review the doc= ument, and reply to this email thread to indicate if you think IPPM should a= dopt this document. Best, Tommy Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_DB9PR07MB79291AF8B9FD4C9512E8E5C3E5B79DB9PR07MB7929eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi WG, Chairs,

 

I support the adoption of this draft as author.

This document is intended to provide a complete description for the dif= ferent explicit performance measurement methodologies, talking about the met= rics and characteristics that are specific to each.

 

Best regards,

Massimo

 

 

TIM - Uso Interno - Tutti i diritti riservati.

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: venerd=EC 8 ottobre 2021 17:59
To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: [EXT] [ippm] Adoption call for Explicit Flow Measurements Te= chniques

 

Hello IPPM,

 

This email starts an adoption call for draft-mdt-ippm= -explicit-flow-measurements, "Explicit Flow Measurements TechniquesR= 21;. This document is proposed as an Informational document that describes t= echniques that go beyond single bit markings like the QUIC spin bit.

 

 

This adoption call will last until Friday, October= 22. Please review the document, and reply to this email thread to indic= ate if you think IPPM should adopt this document.

 

Best,

Tommy


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_DB9PR07MB79291AF8B9FD4C9512E8E5C3E5B79DB9PR07MB7929eurp_-- From nobody Thu Oct 14 01:55:18 2021 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 BF5A63A0FDD; Thu, 14 Oct 2021 01:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqKmUSRJt1CV; Thu, 14 Oct 2021 01:54:41 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBD53A0FF7; Thu, 14 Oct 2021 01:54:41 -0700 (PDT) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HVNRF4wYgz67lJ7; Thu, 14 Oct 2021 16:51:05 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 14 Oct 2021 10:54:38 +0200 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.2308.008; Thu, 14 Oct 2021 10:54:38 +0200 From: Giuseppe Fioccola To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" CC: "explicit-meas@ietf.org" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF2JxQbTKMWCnUCA/EeIh/2STqvSMaaQ Date: Thu, 14 Oct 2021 08:54:38 +0000 Message-ID: <82bd9239c16e41879ec82bc09df8a5e7@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.48.213.109] Content-Type: multipart/alternative; boundary="_000_82bd9239c16e41879ec82bc09df8a5e7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 08:54:47 -0000 --_000_82bd9239c16e41879ec82bc09df8a5e7huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIGFzIGNvLWF1dGhvci4NClRoaXMgaW5m b3JtYXRpb25hbCBkb2N1bWVudCBkZXNjcmliZXMgbWVhc3VyZW1lbnQgdGVjaG5pcXVlcyBwb3Rl bnRpYWxseSBhcHBsaWNhYmxlIHRvIGRpZmZlcmVudCBDbGllbnQtU2VydmVyIHByb3RvY29scy4N Cg0KUmVnYXJkcywNCg0KR2l1c2VwcGUNCg0KDQpGcm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb21teSBQYXVseQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDgs IDIwMjEgNTo1OSBQTQ0KVG86IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZykgPGlwcG1AaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbaXBwbV0gQWRvcHRpb24gY2FsbCBmb3IgRXhwbGljaXQgRmxvdyBN ZWFzdXJlbWVudHMgVGVjaG5pcXVlcw0KDQpIZWxsbyBJUFBNLA0KDQpUaGlzIGVtYWlsIHN0YXJ0 cyBhbiBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1 cmVtZW50cywgIkV4cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXPigJ0uIFRoaXMg ZG9jdW1lbnQgaXMgcHJvcG9zZWQgYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRl c2NyaWJlcyB0ZWNobmlxdWVzIHRoYXQgZ28gYmV5b25kIHNpbmdsZSBiaXQgbWFya2luZ3MgbGlr ZSB0aGUgUVVJQyBzcGluIGJpdC4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMvDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVh c3VyZW1lbnRzLTAyDQoNClRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGxhc3QgdW50aWwgRnJpZGF5 LCBPY3RvYmVyIDIyLiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5IHRvIHRo aXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3VsZCBhZG9w dCB0aGlzIGRvY3VtZW50Lg0KDQpCZXN0LA0KVG9tbXkNCg== --_000_82bd9239c16e41879ec82bc09df8a5e7huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iZW4tREUiPkRlYXIgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9ImVuLURFIj5JIHN1cHBvcnQgdGhl IGFkb3B0aW9uIGFzIGNvLWF1dGhvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJlbi1ERSI+VGhpcyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 IGRlc2NyaWJlcyBtZWFzdXJlbWVudCB0ZWNobmlxdWVzIHBvdGVudGlhbGx5IGFwcGxpY2FibGUg dG8gZGlmZmVyZW50IENsaWVudC1TZXJ2ZXIgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9ImVuLURFIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJlbi1ERSI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJlbi1ERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iZW4tREUiPkdpdXNlcHBlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gaXBwbSAmbHQ7aXBw bS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KVG9tbXkgUGF1bHk8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDgsIDIwMjEgNTo1OSBQTTxicj4NCjxi PlRvOjwvYj4gSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSAmbHQ7aXBwbUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2lwcG1dIEFkb3B0aW9uIGNhbGwgZm9yIEV4cGxpY2l0 IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBJUFBNLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIHN0YXJ0cyBhbiBhZG9wdGlv biBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cywgJnF1 b3Q7RXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBkb2N1bWVu dCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVz IHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5ncw0KIGxpa2UgdGhl IFFVSUMgc3BpbiBiaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVu dHMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1t ZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMiI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVt ZW50cy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCB1bnRpbCA8Yj5GcmlkYXksIE9j dG9iZXIgMjI8L2I+LiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5IHRvIHRo aXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3VsZCBhZG9w dCB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VG9tbXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_82bd9239c16e41879ec82bc09df8a5e7huaweicom_-- From nobody Thu Oct 14 07:09:18 2021 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 BFA923A0990 for ; Thu, 14 Oct 2021 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z5blt2VCBRZO for ; Thu, 14 Oct 2021 07:09:09 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2061.outbound.protection.outlook.com [40.107.21.61]) (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 751E33A09D9 for ; Thu, 14 Oct 2021 07:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ac1npgsS0wmqlA1Y2J3OOcOs9/OrRPZXMGBX9hnQMUWdxFlJcfI7F3nJ7GELa973epWGvyRFm5a0/EOwZ/oXUf5cxDK9Y3QoqCdm/6Y6GhUW/pY7cvyM5rBxe2tZkPhJqRp6HLAynYbMMa0sfNRbTfN9lNzOZ+inlRqnYAFfaO2fwYUZ4a3cyRxGmeiumAL5+SLJi+XHRqM0FoIlUmTryHrAk885UCxcMJl/+KJPtR8m10zMUkRbBraQZaVDOxWK2OS2uupc1RTPBqztEHaikCP2zNpBqzqi5BHEb0GPRqai4mRWqYzklpYtXcZY7uFb8C6x1fXrh1MUhMN6brcSLQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L859ZEg0lj4PX9v+3382ktYCo7Jqi3UcWu9wbfLu5j8=; b=BWEetsTaH4F705p/Trn4QZqWOMnP3NfxbMisQVbdN0ON9Zp4FaV4Opjniclism+37rO4caJz6DuqRzB2MtLa20M53gr5qpPmAxxdnjVwlEK4eIr6bMw4xnVvww+9ZHGlWSf5YLlLl1pkpWhw0ae26mvR2wiHu0ulGIpJA1pUI8Ro6XYQD/tgVDHALP9zNRIeUvxjBg15nHWARPPWGBiF8G9I976sisM7tefsX7z/cW+cSMraOuYVqE8970CEyU7S9BSWPpmoNDm+tXb5ZJsmM8MR9P8nyFcdSUVGSpA4EJHnQ6OPoJE+kiKcyoFUm/bxR3SsNdZH2HeyEwneb0TQmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L859ZEg0lj4PX9v+3382ktYCo7Jqi3UcWu9wbfLu5j8=; b=tMlfubyv8BVI+g3gzXYpmHfmQu9PafyHrUNb1uEbNLuW6NsyU4iNQxwoUVS0WtrZeQdhzmCZYZVFG9H4fUBYGD13ETkafUvTDKFIaH6+HHZppSXhBjhno92akT1zKwVI2Kg0+3WY/bMq1bbS9Qs/N2BRIoNkdDFAQduyNLjxR0s= Received: from AM0PR07MB4131.eurprd07.prod.outlook.com (2603:10a6:208:4b::27) by AM0PR0702MB3745.eurprd07.prod.outlook.com (2603:10a6:208:16::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.9; Thu, 14 Oct 2021 14:09:06 +0000 Received: from AM0PR07MB4131.eurprd07.prod.outlook.com ([fe80::1061:7da4:23ad:41ee]) by AM0PR07MB4131.eurprd07.prod.outlook.com ([fe80::1061:7da4:23ad:41ee%6]) with mapi id 15.20.4628.010; Thu, 14 Oct 2021 14:09:06 +0000 From: Marcus Ihlar To: "ippm@ietf.org" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF2F3Zb/Es5/hUi90P4akyaHM6vPluiAgADQgYCAAihVAA== Date: Thu, 14 Oct 2021 14:09:06 +0000 Message-ID: References: <3240de1f-2fe5-f290-78d0-44c51dd809f9@clemm.org> In-Reply-To: <3240de1f-2fe5-f290-78d0-44c51dd809f9@clemm.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 705744e1-8922-4e76-1f27-08d98f1c2f76 x-ms-traffictypediagnostic: AM0PR0702MB3745: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rrgq57YrGRml4lgdyp6pFofv20C6/t5WoYVVGbRFClfLTVTbG6OfT+9VMc8jw3Ly3w5uKHAa9sr3EXQIQ+Y1x/nths1D8eEztj/GYAyOHjYwIN9fJClj0nUEZ0TqG4v2+8rbufczLG5oJ3MHXUk8skEJMdLIe1f6CNCzRw4g/yWQXfcfxIVgCkDtlOIurpUcfCXWuJ7X2g69BU0NMpPSMxmU3McGX+iM/3yqSS1cckVdcMJ99FE3wNr+QEuvmdQO++KCSDTnjCWSRlI3VTWMaqOUEn7B8p5Fx6VJaqzIoGur/G+y6XTx6QNtOMPZjdEsHQKm8d/nTKkCnbU2AuminqUaCq4py3Tel9PV/4dpkBydOxgUpN906688jYxsgYrlnUjfaxycxrhyPrTZv5agENGIpGzo5p34yZ3Fbjfk3VU7+S1VkYXB3WnY3W5xHVrNp9o+/05Iu5pepI5NfmiYViO0kL7H0SkKrWcszE8HXJAGhFPqjH73jX4wprSbAqWNrHA48Ys494BK+qcTqe3AMCASeMU2IcLpKdIQaNDeZXl1Sk5WHS+irpDI3Z9NdA0lLqquHxKAWiW3FxRXdsWCDk3maSUNxZLnOPqytqOETQxMb/IvPbkVAGhm8HIigRy4g1QuH1v1FP/JdrWQ25xLm/CwcmL9y8aM55d3+2FwNbQW8IQq6e1f5FticzZOF/dsmV369J8JhUmm5rEwGkK7bbDbhMD60IQ/h/Ws1qrKcw9gSgYAYJJHOnf9nL8Wd4u6R2FgcBqUoxfADvrOFsM8Vrq9IPfEN8nkvz/ORy8LF62Dz0N4dUVx0aYP8LaVm778/tiVIxdhIWqVtAQJg5eZGQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4131.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(5660300002)(33656002)(44832011)(26005)(6506007)(508600001)(7696005)(186003)(966005)(53546011)(66946007)(83380400001)(316002)(8676002)(9686003)(8936002)(71200400001)(6916009)(76116006)(86362001)(122000001)(166002)(55016002)(82960400001)(66446008)(66476007)(52536014)(38070700005)(66556008)(38100700002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RDJ1YkdJMW1aa210MWtiM1Y5bEZ5ZG9xa0Q0aUJCYzdja2V0U1NKUHRSQ1ZG?= =?utf-8?B?c3VtdlpGa2N6QWIwQmNualN2L0dUVk5VVXZ4N3JMOHBNcjR3QlBDWkVIbXZZ?= =?utf-8?B?ak5WbUs0UUtKVytIa0ErQ1ZOVlRJaTBLUUNQN2xoVEg3bC9tVnI1MFhKRVRh?= =?utf-8?B?elVLdXhqK3F6V1VIRWJpWGJvaXJudFNHd3pRVkdPUnVlZThPczlHUTI1UVJD?= =?utf-8?B?ZFRFbGtpRFMyVUFWREplSFFsa0xkNDRVdnhSWVJTZ3VuMDJoUUJwMTU5VjNQ?= =?utf-8?B?Uko4OWZhYkZUS0g4bWQ5TlNES3M1dVVCT2h6SWlsckxtalRucHJVc3YweVky?= =?utf-8?B?ZXp6RzBwMG5zSmEyMENGMVN1b3NodWR1OExwTkxKWHI3MUkwZjFNUHVwbjgw?= =?utf-8?B?enZ1MEZkVFZ3cWIwNVQ2MVBiZmZGZ0plbjJob2F0TmtTZkxZNVIrdnhLUG9E?= =?utf-8?B?K3lVL1M4R1NJeGh6dkd4TWIraG0vcGxRMFEyMHFSNXU3ZThxSnFkbFNxSmZt?= =?utf-8?B?Tyt1OXhMZElHdE4wa0NnQTFoMkc0NFFrUjltRUJuU0RWWjJCVVhTOFhTK0My?= =?utf-8?B?cTJGNmR0czVYd28rMnhnUml2ZEJON2tkR3lNeldIQWFobFZvRi96MEpjTDFQ?= =?utf-8?B?SURxeUUrOVBmQ20yS0xxcTBPZFgvUVpkVXVDaDBQSGFTL3AvMEUyY3NodDFh?= =?utf-8?B?WVV4SGxsR1l4bngzNXIxK1JhQmJVRW1odTFSZmFzVmo2Z0hoNjRhU1R1c0Vq?= =?utf-8?B?cVNFR01CbGdYeWF0ZDAzalRSZkhGWmlqeE9Ia2dVbVZTeElHVzJYVEZIcXYy?= =?utf-8?B?V2lRbFBoalBrczhHT0FLVE1tbDhuVGYwT1dwcnNIMVRxOW12Y2NsOERObWNr?= =?utf-8?B?cG1wQ0NRNm9XNUJ1T1E3M3ZPS2xZSEhOemZNNjkxaW5qb0piNkY1b2NkRjcy?= =?utf-8?B?TUUvOWNXTmIwUXRPcFRNTmFacTc2UXFIUEdFMkxPN3pLb3hxdmF5eEorVWZL?= =?utf-8?B?TVlUdXp1eW8xYVA3SXlGOUJBbExSZDlRMzViNm5CVVE1UUY2M011RGZvczI5?= =?utf-8?B?OEZLUzhMYVpJN29MVkU4QjgyTVFPbGhkNGZCS2QxSDJweHVTQWk3VkNvQWJK?= =?utf-8?B?cmFOMk1SZXYzRkFDTEpER3hUWVJIVno0YlAwSnc4ZU00cWVTbDBzY1Fkb2FK?= =?utf-8?B?c21pd2FKZHF2d2tZY2RITjJwWHhxS2h3cXZTMmdFVWVTTncrOXp1c1RTYkVN?= =?utf-8?B?enBXRVd3cFB2VkFkZnc5cmM3NFBLV2l4OGptcklrb0JEcE81alpET2owTzVX?= =?utf-8?B?U3lPdGJaeko5d2NxQWV6K0JoK1lXb2lZOUVDTFNNb0Q5QjRHMVFUa2twL2Rt?= =?utf-8?B?NTNkMytMYlJKRVdUTHVCR0JoSXlhTmhselhzMVBvRVE0ZllSWkRrWXQvelJ3?= =?utf-8?B?MWlEK082dmlWb2ljdDlIRTdFSi9FNlRxMC9rUTRGblBUU0hrZDl3bVMxOW91?= =?utf-8?B?VldySVZTOFJvZGFKL0p3KzJwS2ZjK1N0VS9EN21TSmtFdzNtd3JqaXFhVlU0?= =?utf-8?B?RWV6VWVEdFN6T1I2bllTK214aVQzMVlCS3BtTTBYaUw0TGF4NUp6NndyYTlL?= =?utf-8?B?bXRIUUYrK3U5ZGlkL0VTU2U2TkRaREJEWUt6VmhwYzhtNXJJSTllSGpqM25W?= =?utf-8?B?MHc5WCtLUnB5MU1OakhOQ1RwM1FxZFd6LzlIZnBzd293L3hQNGJkSXl6bUNK?= =?utf-8?B?NUxTRmZCc2psODYwalllLzErYlhMVk00UjhrcTJrZ0R0OG1MTGNVdFRBUmZ2?= =?utf-8?B?QnEvZjNaeDV1N0xWbG9UUkpZKzU0aWtaQmxOVzVRcW5FbU1mcHduTTRjWEwx?= =?utf-8?B?VDVzMi90bGFUenQ5MlY3RGQyeUFqdGhLVUNIUkxCYzh6Z0dxRTVxUitST1VK?= =?utf-8?B?SHhJYTRhTk1EMTNtV0wrVmdTaDdPOENaYklqTTBlaFFHM0JWSXJmbGY0b3J4?= =?utf-8?B?b0swQmxZMTd1bEcvU3VKTlM3TUc1R3VXaTFYOWNqc0xyK1lwSHlLOHUyQUQ0?= =?utf-8?B?ZHRCZTdLSnFhWWVYS0I4am1lQ2ZGMWVQbm54YW1IZmdrWGgxbU1iTlo1VnQz?= =?utf-8?B?Tm5VYmlUL2dYUXd4aU5vblhLYUtqTkVqMDZrWU5OT200ald2R1U5Q1JuTUc4?= =?utf-8?B?RXBUNnd5T3Fkc2N2U04rZWgvci96L2ZoRzNnNFUrQnVDMC9pWUhNUkV6RnRp?= =?utf-8?B?ZXRxTkt0ZURmNWhTK2dXVVFidHdBPT0=?= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB41319F00A2C8100539EE19CEE2B89AM0PR07MB4131eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB4131.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 705744e1-8922-4e76-1f27-08d98f1c2f76 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:09:06.6533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H46N+ENtUlfCDuT2p+uXnaviDIUk7pZq7+5rckYkvvpAhyP/aCib1Ax4Br8Np0AYENtpf7EikVbWb8MJ1dGjw8LsZA1wtVuAD/tLWFxSWMQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3745 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 14:09:15 -0000 --_000_AM0PR07MB41319F00A2C8100539EE19CEE2B89AM0PR07MB4131eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgcHVyZWx5IGFzIGFuIGluZGl2aWR1YWwgaGVyZSBhbmQgbm90IGFzIGNvLWNoYWly Lg0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQsIGl0IHNlcnZlcyBhcyBh IGdvb2QgZm91bmRhdGlvbiB0byBhZHZhbmNlIG91ciB1bmRlcnN0YW5kaW5nIG9mIHRoZSB1dGls aXR5IG9mIGVuZC10by1lbmQgbWFya2luZyBiaXRzLg0KDQoNCg0KTWFyY3VzDQoNCg0KDQpGcm9t OiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgTCBD bGVtbQ0KU2VudDogZGVuIDEzIG9rdG9iZXIgMjAyMSAwNzowNg0KVG86IGlwcG1AaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbaXBwbV0gQWRvcHRpb24gY2FsbCBmb3IgRXhwbGljaXQgRmxvdyBNZWFz dXJlbWVudHMgVGVjaG5pcXVlcw0KDQoNCg0KRGVhciBhbGwsDQoNCkkgdGhpbmsgdGhhdCBhIGRl c2NyaXB0aW9uIG9mIHZhcmlvdXMgZmxvdyBtZWFzdXJlbWVudCB0ZWNobmlxdWVzIHVzaW5nIHZh cmlvdXMgdHlwZXMgb2YgbWFya2luZyBiaXRzIHdpbGwgbWFrZSBmb3IgYSB1c2VmdWwgaW5mb3Jt YXRpb25hbCBkb2N1bWVudCB3aXRoIHN1YnN0YW5jZS4gICBJIHN1cHBvcnQgYWRvcHRpb24gYXMg d2VsbC4NCg0KLS0tIEFsZXgNCg0KT24gMTAvMTIvMjAyMSA5OjQwIEFNLCBHcmVnIE1pcnNreSB3 cm90ZToNCg0KICAgRGVhciBBbGwsDQoNCiAgIEkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRy YWZ0LiBPbi1wYXRoIHRlbGVtZXRyeSBpcyBhbiBlc3NlbnRpYWwgT0FNIHRvb2wuDQoNCg0KDQog ICBSZWdhcmRzLA0KDQogICBHcmVnDQoNCg0KDQogICBPbiBGcmksIE9jdCA4LCAyMDIxIGF0IDg6 NTkgQU0gVG9tbXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KICAgICAgSGVsbG8gSVBQ TSwNCg0KDQoNCiAgICAgIFRoaXMgZW1haWwgc3RhcnRzIGFuIGFkb3B0aW9uIGNhbGwgZm9yIGRy YWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzLCAiRXhwbGljaXQgRmxvdyBN ZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBkb2N1bWVudCBpcyBwcm9wb3NlZCBhcyBh biBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRlY2huaXF1ZXMgdGhhdCBn byBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5ncyBsaWtlIHRoZSBRVUlDIHNwaW4gYml0Lg0KDQoN Cg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LWlwcG0t ZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMvDQoNCiAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVu dHMtMDINCg0KDQoNCiAgICAgIFRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGxhc3QgdW50aWwgRnJp ZGF5LCBPY3RvYmVyIDIyLiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5IHRv IHRoaXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3VsZCBh ZG9wdCB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KICAgICAgQmVzdCwNCg0KICAgICAgVG9tbXkNCg0K ICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICAgIGlwcG0gbWFpbGluZyBsaXN0DQogICAgICBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGll dGYub3JnPg0KICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt DQoNCg0KDQoNCg0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgIGlwcG0gbWFpbGluZyBsaXN0DQogICBpcHBtQGlldGYub3JnPG1haWx0bzppcHBt QGlldGYub3JnPg0KICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt DQoNCg== --_000_AM0PR07MB41319F00A2C8100539EE19CEE2B89AM0PR07MB4131eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIHB1cmVseSBhcyBhbiBpbmRpdmlkdWFs IGhlcmUgYW5kIG5vdCBhcyBjby1jaGFpci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCwgaXQgc2VydmVzIGFz IGEgZ29vZCBmb3VuZGF0aW9uIHRvIGFkdmFuY2Ugb3VyIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHV0 aWxpdHkgb2YgZW5kLXRvLWVuZCBtYXJraW5nIGJpdHMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TWFyY3VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gaXBwbSAmbHQ7aXBwbS1ib3VuY2VzQGlldGYub3JnJmd0 OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQWxleGFuZGVyIEwgQ2xlbW08YnI+DQo8Yj5TZW50Ojwv Yj4gZGVuIDEzIG9rdG9iZXIgMjAyMSAwNzowNjxicj4NCjxiPlRvOjwvYj4gaXBwbUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2lwcG1dIEFkb3B0aW9uIGNhbGwgZm9yIEV4cGxp Y2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkRl YXIgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHA+SSB0aGluayB0aGF0IGEgZGVzY3JpcHRpb24gb2Yg dmFyaW91cyBmbG93IG1lYXN1cmVtZW50IHRlY2huaXF1ZXMgdXNpbmcgdmFyaW91cyB0eXBlcyBv ZiBtYXJraW5nIGJpdHMgd2lsbCBtYWtlIGZvciBhIHVzZWZ1bCBpbmZvcm1hdGlvbmFsIGRvY3Vt ZW50IHdpdGggc3Vic3RhbmNlLiZuYnNwOyZuYnNwOyBJIHN1cHBvcnQgYWRvcHRpb24gYXMgd2Vs bC48bzpwPjwvbzpwPjwvcD4NCjxwPi0tLSBBbGV4PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMTIvMjAyMSA5OjQwIEFNLCBHcmVnIE1pcnNreSB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVhciBBbGwsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg c3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LiBPbi1wYXRoIHRlbGVtZXRyeSBpcyBhbiBl c3NlbnRpYWwgT0FNIHRvb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDgsIDIwMjEgYXQgODo1OSBBTSBUb21t eSBQYXVseSAmbHQ7dHBhdWx5PTxhIGhyZWY9Im1haWx0bzo0MGFwcGxlLmNvbUBkbWFyYy5pZXRm Lm9yZyI+NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGVsbG8gSVBQTSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gY2FsbCBmb3IgZHJh ZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMsICZxdW90O0V4cGxpY2l0IEZs b3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXPigJ0uIFRoaXMgZG9jdW1lbnQgaXMgcHJvcG9zZWQg YXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyB0ZWNobmlxdWVzIHRo YXQgZ28gYmV5b25kIHNpbmdsZSBiaXQgbWFya2luZ3MNCiBsaWtlIHRoZSBRVUlDIHNwaW4gYml0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZHQtaXBwbS1l eHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVt ZW50cy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzLTAyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBs aWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCB1 bnRpbCA8Yj5GcmlkYXksIE9jdG9iZXIgMjI8L2I+LiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVu dCwgYW5kIHJlcGx5IHRvIHRoaXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGlu ayBJUFBNIHNob3VsZCBhZG9wdCB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9tbXk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N CjxwcmU+aXBwbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJt YWlsdG86aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0i Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR07MB41319F00A2C8100539EE19CEE2B89AM0PR07MB4131eurp_-- From nobody Thu Oct 14 07:31:28 2021 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 0F0BA3A16CE for ; Thu, 14 Oct 2021 07:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ipvkmJgUGVKz for ; Thu, 14 Oct 2021 07:31:20 -0700 (PDT) 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 404843A09EC for ; Thu, 14 Oct 2021 07:31:20 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id x27so28147262lfu.5 for ; Thu, 14 Oct 2021 07:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gAHUXjWVGkq64SLpKSZRESyl/ia2SwFAHx78EgLBWGc=; b=asPsSSfDtAy4QO1TeHCo3BW5i1zhnrecoMYIxjyJhRDVJ3kuUeFd9i+AYX3e+uQx28 FTiIL9ge12UmrsHQwIn2rYR8dfr076YJHR9L25+UnlVasOBUE6xNzRTqKVPLIs+zGgFZ kSPDlkQGKndSGFRsJXExDGIATLOlssJJV6HkRR2muQhcE1elR0u/itfQoc5V8yQVsIpO je/jw4AmjqPPr0Mlyw+HXEk7Nw7yLAxak0IKXu9T8YI0dowfgq/ME2kPPvBaj4Ji06U2 tY/yOzg1vfHoVdHQLYyitjJL8PdbrR4Fa5vRVNe5Yr12X+PWeqfwTFBBCzrD6QFhuuKq iydw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gAHUXjWVGkq64SLpKSZRESyl/ia2SwFAHx78EgLBWGc=; b=mMo/gqMmXYEIM3npB572OefIyRtBVtlJryX1YC9q8jv6Akh8sZY+veTaKgfPLDLrby 4GQnnmRNaUYz8cw/7mT54n+135v9qwNvH4+LlTWlJrZNFzZp8BoCg8lN5hNBn5PumD2R Rtzmg2awff2Vkpv1L+YpzL8OB1uM4vKz+cgO/fokdaU1LStC9BTeatXNwtk5vyjQZAp/ gCDPcPQYuMtryDRByvmDUGm3VF/+cVlsF3dk4Uim9LQ0wnG55fA1DudvQ+LxJX5MF2oE 4sJZzox22MM49UoeRFfhClzG5FIoO5y6AgoiZXRt7wgAqk6brL1QR+pqyGnZaTCvvEsJ /GDQ== X-Gm-Message-State: AOAM531gCOXdR3erSx4BNff0hJV9RIIVwBAZXegGpDBp4feqO0/fMtMY dhSGt+Pi41sPUAQGKC2uIPg8GObFKak12XK/mLtLpIu9Z30= X-Google-Smtp-Source: ABdhPJxV9MNIdFWnCLkJYiFS+m7G56Ed7Mdq6Bc99KNWjWDxDUmRiWOYdhnRwCXICY/rgtLNqa+8IgofD/wybyyYNMU= X-Received: by 2002:a05:6512:1508:: with SMTP id bq8mr5477707lfb.68.1634221878100; Thu, 14 Oct 2021 07:31:18 -0700 (PDT) MIME-Version: 1.0 References: <3240de1f-2fe5-f290-78d0-44c51dd809f9@clemm.org> In-Reply-To: From: Nicolas Kuhn Date: Thu, 14 Oct 2021 16:31:06 +0200 Message-ID: To: Marcus Ihlar Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000087452505ce50ee22" Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 14:31:25 -0000 --00000000000087452505ce50ee22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I support the adoption of the draft. On a side note, it may be worth pointing out RFC9065, with the proposed approach being 'beneficial' (as opposed to malicious!). " Current uses of transport header information by network devices on the Internet path are explained. These uses can be beneficial or malicious. This is written to provide input to the discussion around what is an appropriate balance by highlighting some implications of transport header encryption. " Cheers Nico On Thu, Oct 14, 2021 at 4:09 PM Marcus Ihlar wrote: > Speaking purely as an individual here and not as co-chair. > > I support the adoption of this draft, it serves as a good foundation to > advance our understanding of the utility of end-to-end marking bits. > > > > Marcus > > > > *From:* ippm *On Behalf Of * Alexander L Clemm > *Sent:* den 13 oktober 2021 07:06 > *To:* ippm@ietf.org > *Subject:* Re: [ippm] Adoption call for Explicit Flow Measurements > Techniques > > > > Dear all, > > I think that a description of various flow measurement techniques using > various types of marking bits will make for a useful informational docume= nt > with substance. I support adoption as well. > > --- Alex > > On 10/12/2021 9:40 AM, Greg Mirsky wrote: > > Dear All, > > I support adoption of this draft. On-path telemetry is an essential OAM > tool. > > > > Regards, > > Greg > > > > On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > > Hello IPPM, > > > > This email starts an adoption call for > draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements > Techniques=E2=80=9D. This document is proposed as an Informational docume= nt that > describes techniques that go beyond single bit markings like the QUIC spi= n > bit. > > > > https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurement= s/ > > > https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measur= ements-02 > > > > This adoption call will last until *Friday, October 22*. Please review > the document, and reply to this email thread to indicate if you think IPP= M > should adopt this document. > > > > Best, > > Tommy > > _______________________________________________ > 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 > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00000000000087452505ce50ee22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I support the adop= tion of the draft.

On a side note, it may be = worth pointing out RFC9065, with the proposed approach being 'beneficia= l' (as opposed to malicious!).
" 
 Current uses=
 of transport header information by network devices on
   the Internet path are explained.  These uses can be beneficial or
   malicious.  This is written to provide input to the discussion around
   what is an appropriate balance by highlighting some implications of
   transport header encryption.
"

Cheers

Nico

On Thu, Oct 14, 2021= at 4:09 PM Marcus Ihlar <marcus.ihlar=3D40ericsson.com@dmarc.ietf.org> wrote:

Speaking purely as an individual here and not as co-= chair.

I support the adoption of this draft, it serves as a= good foundation to advance our understanding of the utility of end-to-end = marking bits.

=C2=A0

Marcus

=C2=A0

From: ippm <ippm-bounces@ietf.org> On Behalf Of = Alexander L Clemm
Sent: den 13 oktober 2021 07:06
To: ippm@ietf.org=
Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Tec= hniques

=C2=A0

Dear all,

I think that a description of various flow measurement techniques using = various types of marking bits will make for a useful informational document= with substance.=C2=A0=C2=A0 I support adoption as well.

--- Alex

On 10/12/2021 9:40 AM, Greg Mirsky wrote:<= /u>

Dear All,

I support adoption of this draft. On-path telemetry = is an essential OAM tool.

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Oct 8, 2021 at 8:59 AM Tommy Pauly <tpaul= y=3D40apple= .com@dmarc.ietf.org> wrote:

Hello IPPM,

=C2=A0

This email starts an adoption call for draft-mdt-ipp= m-explicit-flow-measurements, "Explicit Flow Measurements Techniques= =E2=80=9D. This document is proposed as an Informational document that desc= ribes techniques that go beyond single bit markings like the QUIC spin bit.

=C2=A0

=C2=A0

This adoption call will last until Friday, Octobe= r 22. Please review the document, and reply to this email thread to ind= icate if you think IPPM should adopt this document.

=C2=A0

Best,

Tommy

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



_______________________________________________
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
--00000000000087452505ce50ee22-- From nobody Thu Oct 14 09:37:17 2021 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 B236A3A0B6F for ; Thu, 14 Oct 2021 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nKvBTILUf3T for ; Thu, 14 Oct 2021 09:37:10 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 28C813A0B98 for ; Thu, 14 Oct 2021 09:37:10 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4HVZn02tYFzBsxk; Thu, 14 Oct 2021 18:37:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1634229428; bh=goiEW0FcQKL3VdCb0qrO18OElZeoYVNHlQXbzBAomlc=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=cz3FZH2Lq9w/QbOzxNm/Ml2m4YYkRiq7zqUAuYhDn+gt4d70bA+Hszpe6V2gEVIij plihU5Olmk3XmbVWDBeV5JNXpVWmULkuWP+QnC7liQc3Q3byDJViQX5XmJItn6CfuD l9vVqu66q7IGNs3EMXXGjwiIFVOfXX3lo76ebpHbBo6U4+eDhmiq7H39S/5Xt1ZWw6 oya0eUx8x4p01YF408I9qsvruRVFILsc4EhzBDPxVRp2g/7Pevfuxfs7Yvn9zPQP+N zAPGLefV0q80Yz3ymxx4X6YIlz0QUjejtl9TyJ/6MgDUAHPI3jDf0qm8jI3BYiRLvc 3+PudlRU1S8ew== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar05.francetelecom.fr (ESMTP service) with ESMTPS id 4HVZn01dtFz2xCg; Thu, 14 Oct 2021 18:37:08 +0200 (CEST) From: To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF1/0oVABUtZ1EaBFxLm72MV6KvSujFw Date: Thu, 14 Oct 2021 16:37:07 +0000 Message-ID: <15572_1634229428_61685CB4_15572_5_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB935D9A921@OPEXCAUBM44.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB935D9A921OPEXCAUBM44corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 16:37:15 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB935D9A921OPEXCAUBM44corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uLg0KSXQgd2lsbCBoZWxwIHRyb3VibGVzaG9vdGlu ZyBRVUlDIHBlcmZvcm1hbmNlLg0KUmVnYXJkcw0KRW1pbGUNCg0KRGUgOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFRvbW15IFBhdWx5DQpFbnZvecOp IDogdmVuZHJlZGkgOCBvY3RvYnJlIDIwMjEgMTc6NTkNCsOAIDogSUVURiBJUFBNIFdHIChpcHBt QGlldGYub3JnKSA8aXBwbUBpZXRmLm9yZz4NCk9iamV0IDogW2lwcG1dIEFkb3B0aW9uIGNhbGwg Zm9yIEV4cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXMNCg0KSGVsbG8gSVBQTSwN Cg0KVGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtbWR0LWlwcG0t ZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMsICJFeHBsaWNpdCBGbG93IE1lYXN1cmVtZW50cyBU ZWNobmlxdWVz4oCdLiBUaGlzIGRvY3VtZW50IGlzIHByb3Bvc2VkIGFzIGFuIEluZm9ybWF0aW9u YWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgdGVjaG5pcXVlcyB0aGF0IGdvIGJleW9uZCBzaW5n bGUgYml0IG1hcmtpbmdzIGxpa2UgdGhlIFFVSUMgc3BpbiBiaXQuDQoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1l bnRzLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBw bS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMg0KDQpUaGlzIGFkb3B0aW9uIGNhbGwgd2ls bCBsYXN0IHVudGlsIEZyaWRheSwgT2N0b2JlciAyMi4gUGxlYXNlIHJldmlldyB0aGUgZG9jdW1l bnQsIGFuZCByZXBseSB0byB0aGlzIGVtYWlsIHRocmVhZCB0byBpbmRpY2F0ZSBpZiB5b3UgdGhp bmsgSVBQTSBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudC4NCg0KQmVzdCwNClRvbW15DQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB935D9A921OPEXCAUBM44corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkkgc3VwcG9ydCB0aGUgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SXQgd2lsbCBoZWxwIHRyb3VibGVzaG9vdGluZyBRVUlDIHBlcmZvcm1hbmNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5F bWlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gVG9tbXkgUGF1bHk8YnI+DQo8Yj5FbnZvecOpJm5i c3A7OjwvYj4gdmVuZHJlZGkgOCBvY3RvYnJlIDIwMjEgMTc6NTk8YnI+DQo8Yj7DgCZuYnNwOzo8 L2I+IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZykgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbaXBwbV0gQWRvcHRpb24gY2FsbCBmb3IgRXhwbGljaXQg RmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBJUFBNLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIHN0YXJ0cyBhbiBh ZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50 cywgJnF1b3Q7RXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBk b2N1bWVudCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVz Y3JpYmVzIHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5ncw0KIGxp a2UgdGhlIFFVSUMgc3BpbiBiaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzLyI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFz dXJlbWVudHMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMiI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1l YXN1cmVtZW50cy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCB1bnRpbCA8Yj5Gcmlk YXksIE9jdG9iZXIgMjI8L2I+LiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5 IHRvIHRoaXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3Vs ZCBhZG9wdCB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9tbXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB935D9A921OPEXCAUBM44corp_-- From nobody Thu Oct 14 09:57:27 2021 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 EE43E3A0BC4 for ; Thu, 14 Oct 2021 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 4Y5-xgIyzVaw for ; Thu, 14 Oct 2021 09:57:20 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2124.outbound.protection.outlook.com [40.107.237.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E0A3A0BFA for ; Thu, 14 Oct 2021 09:57:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KT1csOC+Es/nmpyl5H1AVXi7I1nAMaps+v5lfF05lXtzacp7FIxrnJpF5yxrdegK/yo+tiT6G4gDRW9IEn7TXJ/ZnJoO4xpV4QTSMZPcbej7yo4uTCGdykkQw4sLtaF1blEjPOcOsv9Sa2CS69xfOgJ/qZEgHI6g+fHOl74hJZ6hQMUhwrTWmISsBhp02qKpLNYSvUvDMf7u4RT5oeVgVZKm1UtbXs26IsQqA7QbeACq6Y44tOEfPgYNk0RkwA5DoQBT305rTsLO3+E7ecw0bypZsIyOex8gD08psB9ioCW/6RsPYpR4YYmcmgAxDaiJyinksb+k1PbpQjsqqBXRag== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=toXIwR21LQ/x4ZZy1Udg6U9b2KmWjCtwNogA8LAqpXo=; b=SQdiN4+NgvgMycUFeqb5vXKSz22aFYL59rKbKzZzj9iXJUP4O3TTmNqGLp2vcG6eqt++SSOE0smuBOP6hzl3+wzM0lnvgA6yXw9J1EHsuzw83NvmhdyJ5z7KennHt0Tvs3qrUgifKDdwvwBfwv0Bm7q8SEtKS1VL1G8Dvyr4XbjKIXGS7lU4dZGPp6Z18Z9NM11rqbqD5uw7hPd0ZTiTUTlg1/43PdPYwcMvGW2YaBBeXF7gnh4lNBVtUbf1H7QvzRyADCZoU8EGdeC2kT84f1HhTU1PzyjapFYXB5zUZEvFHCmS/jRi0bd62QzogXWJA48ZvjWmeWky3t2tIExG4Q== 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=toXIwR21LQ/x4ZZy1Udg6U9b2KmWjCtwNogA8LAqpXo=; b=cLIL3IdxpjzpIA6YZ6rm/FpJvxeDUZccHjxNpkyJ0rK+lbnwM4sCcsXEV50q77yJ9EtygTTajpAQYN+YuC1XpS2sOf/imm2438chmb2puZgLwRpXe4vm8rK719Wo458zQdCWHCweCjt9CAKaZgUKXT02xlND7nbN56KEh/GTgEA= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BYAPR13MB2248.namprd13.prod.outlook.com (2603:10b6:a02:c9::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.10; Thu, 14 Oct 2021 16:57:13 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 16:57:13 +0000 From: Haoyu Song To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF1+Hh7ouGX+R0uB71c8LFJwNqvSvnow Date: Thu, 14 Oct 2021 16:57:13 +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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef118b79-bffb-415a-c315-08d98f33abc8 x-ms-traffictypediagnostic: BYAPR13MB2248: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +zux6lCKUGvKJzOWKpJqDtrFmkrVIRwmkRskmNmh37lVtb1nuvPkFyjxLl+K4EInGTKTrLarfnONmWKBg9GYI4Tc0gAqEEILYheCNFzBDVyBg8a6EeVDNmg4Qwgi+SNBGiDTujqI8gXlu8LeDemgOecYbq6mcQNRSkegrKreGRtC4UWt0OSqwSkTQruB/AUbnYhwYMImxN+w3mlMApwVDNVf7o96w3V0PLoutWbkznMYFY8IKjSc/YJWFN2EC4U9q0WOaacvdscctvnOQHEOVRqIhGOcegr82RYO1aZAO0XXOQtME3p2iG/z34R/2xHOH44FCO/IlVKrYbOyfX7i5ei/dT4YDy/CrhThaiYYRhL+xYp4mtGHVAQa7ezFEKxoZpQS6rtHNxyikLbEO1yWBDe8WkOEC7CQJ+XwxEltXF9iUPtB5B/yApambhKvCsLQN65jdHRAQCJ0R3+SlDEj93sNFvHMSv57o2H/HX7oDkRG2Cl/ZRzZix2Goil8pd5TywLC5ksbIefth6oVk86lB6AlIzBRtwVAc9lSaLsmgO1zBz8XfnBDLmv6P4GV0OmG4J7BrKPyO3OOizbK+o2LuhPQ9mHb+1uCc68xq0ZEmK0/vnJ0W/JvyFId0g6IXtVCQVclr0eObEt7dxeQ8k9XcxR1naj+vixC9QEHhVJi4oNty+RM8apwXD5xo+Vwkqvpbx2E/RifSbnIpGhtsd3k6OdLvVg/a3O99GgM3VSLIvWptKv8q4TIEidc/DjYaYqeeMYsZbq42FEw/umsQ0b4INAO+vukEqaYTFiKp4oYcS+isnjq5Oxyiq49dzfzkgcltMdamuN0KTMjI0xupD4wow== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66476007)(2906002)(66946007)(5660300002)(166002)(8676002)(508600001)(186003)(316002)(71200400001)(33656002)(66556008)(64756008)(66446008)(8936002)(966005)(26005)(9686003)(55016002)(53546011)(6506007)(52536014)(38070700005)(122000001)(110136005)(44832011)(86362001)(38100700002)(76116006)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FgtNXXmGKVVQ4IIn8RAXZ9XbyKYflUz/0loWXrGTH3DGHZx8vnikuu6bMQtt?= =?us-ascii?Q?RVwNvIUbU8Oaw38SqTvLuOGpv4UjRFL7hggnruOFvhWMg6KuirbUf0RRpDuS?= =?us-ascii?Q?wa9Voe7vMvG/1e5D0Z5UWlDfA6cWrqOF9+SI2gWyEMW9jCQizTGU3QJHKZz8?= =?us-ascii?Q?7LA4vn/irk3tPsoWokIdorAOwqv9NX/f21+2gntH70Dnv4ZCumD4lfVJtcvt?= =?us-ascii?Q?Eb+hqtcQNmEPzyjaaWEJr4iq5M2jMhnqRGPlLAf1iLkV7BfXt1VGzEtAQvvQ?= =?us-ascii?Q?+BzDwNwEFN/d3lkw9WAC+Rf/AFt8P5znEIv0gw0psC5Kas9oP4Q5nV9NMvAo?= =?us-ascii?Q?aGueOof5XzuUx5gTBgWH2GCpnLvQKFzD5M7+XiOWVa6iDTQL7tKGfMlX1upx?= =?us-ascii?Q?1KIUAUi8UTkP5ZBjWQaNuC2WR4XSYI5raOv6Ee4tGnVMwPyyrkZwSm5XTKKO?= =?us-ascii?Q?KD40mGvxouS1l3WRp9vA9xt75HH/7gQEaWCnK+WWw5SNu5ldCoqVO4oMOURY?= =?us-ascii?Q?Vz86vZ3KDBoKSHRpalt4b1YvqxBJg+C3+fX4DZjx+5HQ69bElMBaND47IK43?= =?us-ascii?Q?9y8M4VplpUpGMNrCVJHTmtJI6Grsn/D1a0n8lq83ZX5yOX+4XQigwXjBBEUx?= =?us-ascii?Q?UsnOgmQonoIWX+Y0wK+rw9oWFqDp6KDzFB5Z2IdLqNhehofinwHxbQISxeJw?= =?us-ascii?Q?35wVP/nNHa/oKQHUY8JvHf7chYmFkXtz/7dR4L9A7sIJYPd+lLRZRnH7OQb8?= =?us-ascii?Q?CAmGAPDbWo6U1scmnfDQINGjhDN0UqOMLQy78ZxjyqII5Pm8VQFNJdNm7WoF?= =?us-ascii?Q?90zT7C37L0Ar+0Go9ayqalGCZCF5xZ7i6sCBsaBo4TYsQdwLgMmyuTiRYcAi?= =?us-ascii?Q?jPTktNgGodHSlpZnEi+KDfRmK/2BwimQokk9Go5dngVhwU/Veh6dph7pI2U4?= =?us-ascii?Q?tDbfhwoXodfnZOo9E7EkAm7KbwpIVs6EVbqt7VRvnyph6UVSKIlXuzMonZG2?= =?us-ascii?Q?Nq+/ydQRfeC2G8I6m+MJgUS7oCxfx68CNTbCzksyM/d89ashKCutC7FQvTTj?= =?us-ascii?Q?BXOD62/77rYRiuEsEnWsZTZXdk8DR0Y6Wdo6rqhwWyMFIBBF8VKCcXiDU01l?= =?us-ascii?Q?hwUveYgGWuwQ25380yZ4F7RU/PZkM1zDfyGsumvauiB031eW88rl9Zb+DYHT?= =?us-ascii?Q?mLf6yiYD7An6NRejD3orm3llfF2uJ/ryQGJIRFTCfwo/mvnVXXMJ52kbKLwe?= =?us-ascii?Q?C06IPAfUQaqzfUYbKZJb2eFW+2hFnBvmFajYw3xDH0sWDOt2Olei399uefBR?= =?us-ascii?Q?ig0R+4/Bek+w4hZJdYlrk4MJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY3PR13MB47877DB1B8A17B6FA8A240019AB89BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef118b79-bffb-415a-c315-08d98f33abc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 16:57:13.6526 (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: nudciVz0CkkVFaxoakedoPvtvQb2qRDqtfM0wYnat5PK7WzZ/8KtePLLRnCCKjpmDkRXT37QQIs3JFRb+J0B2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2248 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 16:57:25 -0000 --_000_BY3PR13MB47877DB1B8A17B6FA8A240019AB89BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPPM WG and chairs, The proposed method is interesting and useful. I support the WG adoption. I have a question to the authors. The draft says that the method is valuabl= e for encrypted transport headers but later it suggested to encapsulate the= bits in QUIC and TCP header. How does that work if the transport header is= encrypted? Best regards, Haoyu From: ippm On Behalf Of Tommy Pauly Sent: Friday, October 8, 2021 8:59 AM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] Adoption call for Explicit Flow Measurements Techniques Hello IPPM, This email starts an adoption call for draft-mdt-ippm-explicit-flow-measure= ments, "Explicit Flow Measurements Techniques". This document is proposed a= s an Informational document that describes techniques that go beyond single= bit markings like the QUIC spin bit. https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/= https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurem= ents-02 This adoption call will last until Friday, October 22. Please review the do= cument, and reply to this email thread to indicate if you think IPPM should= adopt this document. Best, Tommy --_000_BY3PR13MB47877DB1B8A17B6FA8A240019AB89BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPPM WG and chairs,

 

The proposed method is interesting and useful. I sup= port the WG adoption.

I have a question to the authors. The draft says tha= t the method is valuable for encrypted transport headers but later it sugge= sted to encapsulate the bits in QUIC and TCP header. How does that work if = the transport header is encrypted?

 

Best regards,

Haoyu

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Tommy Pauly
Sent: Friday, October 8, 2021 8:59 AM
To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: [ippm] Adoption call for Explicit Flow Measurements Techniq= ues

 

Hello IPPM,

 

This email starts an adoption call for draft-mdt-ipp= m-explicit-flow-measurements, "Explicit Flow Measurements Techniques&#= 8221;. This document is proposed as an Informational document that describe= s techniques that go beyond single bit markings like the QUIC spin bit.

 

 

This adoption call will last until Friday, Octobe= r 22. Please review the document, and reply to this email thread to ind= icate if you think IPPM should adopt this document.

 

Best,

Tommy

--_000_BY3PR13MB47877DB1B8A17B6FA8A240019AB89BY3PR13MB4787namp_-- From nobody Thu Oct 14 14:24:12 2021 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 7564E3A0CA2 for ; Thu, 14 Oct 2021 14:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 KRyeq7Wjtopf for ; Thu, 14 Oct 2021 14:24:07 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B733A0D7B for ; Thu, 14 Oct 2021 14:24:07 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HVj4f39VYz67NYL; Fri, 15 Oct 2021 05:21:06 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 14 Oct 2021 23:24:02 +0200 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.2308.008; Thu, 14 Oct 2021 23:24:02 +0200 From: Giuseppe Fioccola To: Haoyu Song , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF2JxQbTKMWCnUCA/EeIh/2STqvSns+AgABfn4A= Date: Thu, 14 Oct 2021 21:24:02 +0000 Message-ID: <607b55b18a9f4c129691b24dd7aa67ec@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.48.217.53] Content-Type: multipart/alternative; boundary="_000_607b55b18a9f4c129691b24dd7aa67echuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 14 Oct 2021 21:24:12 -0000 --_000_607b55b18a9f4c129691b24dd7aa67echuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haoyu, The methods described in this document, if applied to encrypted protocols, = need to use unencrypted header fields in order to enable the on-path measur= ements. That is the case of the examples for QUIC and TCP. In this regard, = note that the spin bit has already been defined in the QUIC short packet he= ader (RFC9000). We can further clarify this point in the next version. Regards, Giuseppe From: ippm On Behalf Of Haoyu Song Sent: Thursday, October 14, 2021 6:57 PM To: Tommy Pauly ; IETF IPPM WG (ippm@i= etf.org) Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques IPPM WG and chairs, The proposed method is interesting and useful. I support the WG adoption. I have a question to the authors. The draft says that the method is valuabl= e for encrypted transport headers but later it suggested to encapsulate the= bits in QUIC and TCP header. How does that work if the transport header is= encrypted? Best regards, Haoyu From: ippm > On Behalf = Of Tommy Pauly Sent: Friday, October 8, 2021 8:59 AM To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] Adoption call for Explicit Flow Measurements Techniques Hello IPPM, This email starts an adoption call for draft-mdt-ippm-explicit-flow-measure= ments, "Explicit Flow Measurements Techniques". This document is proposed a= s an Informational document that describes techniques that go beyond single= bit markings like the QUIC spin bit. https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements/= https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurem= ents-02 This adoption call will last until Friday, October 22. Please review the do= cument, and reply to this email thread to indicate if you think IPPM should= adopt this document. Best, Tommy --_000_607b55b18a9f4c129691b24dd7aa67echuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Haoyu,

The methods described in this d= ocument, if applied to encrypted protocols, need to use unencrypted header = fields in order to enable the on-path measurements. That is the case of the= examples for QUIC and TCP. In this regard, note that the spin bit has already been defined in the QUIC short = packet header (RFC9000).

 

We can further clarify this poi= nt in the next version.

 

Regards,

 

Giuseppe

 

 

From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Haoyu Song
Sent: Thursday, October 14, 2021 6:57 PM
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>; IETF IP= PM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Tec= hniques

 

IPPM WG and chairs,

 

The proposed method is interesting and useful. I sup= port the WG adoption.

I have a question to the authors. The draft says tha= t the method is valuable for encrypted transport headers but later it sugge= sted to encapsulate the bits in QUIC and TCP header. How does that work if = the transport header is encrypted?

 

Best regards,

Haoyu

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Friday, October 8, 2021 8:59 AM
To: IETF IPPM WG (ippm@ietf.org= ) <ippm@ietf.org>
Subject: [ippm] Adoption call for Explicit Flow Measurements Techniq= ues

 

Hello IPPM,

 

This email starts an adoption call for draft-mdt-ipp= m-explicit-flow-measurements, "Explicit Flow Measurements Techniques&#= 8221;. This document is proposed as an Informational document that describe= s techniques that go beyond single bit markings like the QUIC spin bit.

 

 

This adoption call will last until Friday, Octobe= r 22. Please review the document, and reply to this email thread to ind= icate if you think IPPM should adopt this document.

 

Best,

Tommy

--_000_607b55b18a9f4c129691b24dd7aa67echuaweicom_-- From nobody Thu Oct 14 20:44:43 2021 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 77E913A183E; Thu, 14 Oct 2021 20:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=akamai.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 26vSdVO-aMLL; Thu, 14 Oct 2021 20:44:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D6E343A183C; Thu, 14 Oct 2021 20:44:36 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19F3eHT7011088; Fri, 15 Oct 2021 04:44:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=q+u2buUiijU0lKIqU9omfxVTTYnCV0S2L7QhvTud1fQ=; b=awdqwhzjsKF4iDrjh5eSFXZjMPxzYINHXFaT30QYc5WbOL8Sc8GZ/yR4B4EExLsnA/22 DQjqAdaaJ+hw75FRri+9Tc/0N8a9gRgd1j5Mc6vTo7xh3tK6fxvmlBaamnik2QJINhzk aB4dd++vuyg08XADLNPtcK6dbhs9HzRo/zmgGAMUZWnbMMntVWTtcduOHiwxQYesWXe7 w5Zt42Nd9c5gCOlSqUoGCn0OTODA82R6jZi27H/sPR0vrzqPtibqOnvgwulu0FnGZoUg An0G0yd8B9KEWBPZA39ilb03ZMbPygmGu1wBdgrtD3M27iuyeIcKCcKNyZP9eazlTuxa dQ== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 3bph5cycx3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 04:44:35 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 19F3Y7ue015051; Thu, 14 Oct 2021 23:44:34 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint4.akamai.com with ESMTP id 3bn5jum7dm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 23:44:34 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 14 Oct 2021 22:44:33 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1497.023; Thu, 14 Oct 2021 22:44:33 -0500 From: "Lubashev, Igor" To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF1+/Zp6IJ+L9EmFoWOlHJEPJavTbvhA Date: Fri, 15 Oct 2021 03:44:33 +0000 Message-ID: <203d2d87bfb74425b139458abe532d2b@ustx2ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_203d2d87bfb74425b139458abe532d2bustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-14_09:2021-10-14, 2021-10-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 spamscore=0 mlxlogscore=932 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110150020 X-Proofpoint-GUID: P6AW5Q_rUIlibeUjYB1c20ipXSlNT6it X-Proofpoint-ORIG-GUID: P6AW5Q_rUIlibeUjYB1c20ipXSlNT6it X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-14_12,2021-10-14_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 bulkscore=0 mlxscore=0 adultscore=0 impostorscore=0 phishscore=0 spamscore=0 suspectscore=0 clxscore=1011 mlxlogscore=878 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110150022 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 15 Oct 2021 03:44:42 -0000 --_000_203d2d87bfb74425b139458abe532d2bustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uIGFzIGEgY28tYXV0aG9yLg0KDQpUaGVzZSBtZWFzdXJlbWVudCB0 ZWNobmlxdWVzIGFyZSB1c2VmdWwgZm9yIEwzIFFvUyBtb25pdG9yaW5nIGJ5IG9uLXBhdGggYWdl bnRzIHdpdGhvdXQgYWNjZXNzIHRvIGNyeXB0b2dyYXBoaWMgbWF0ZXJpYWxzLCB3aGlsZSBwcmVz ZXJ2aW5nIHByaXZhY3kgYW5kIG9zc2lmaWNhdGlvbi1yZXNpc3RhbnQgcHJvcGVydGllcyBvZiB0 aGUgZW5jcnlwdGVkIHByb3RvY29scy4gIE9uY2UgdGhlc2UgdGVjaG5pcXVlcyBhcmUgc3RhbmRh cmRpemVkIGhlcmUsIHdlIGF0IEFrYW1haSBpbnRlbmQgdG8gd29yayB3aXRoIFFVSUMgV0cgb24g YSBjb25jcmV0ZSBpbXBsZW1lbnRhdGlvbiBkcmFmdCBhbmQgdG8gaW1wbGVtZW50IGl0IGluIG91 ciBkZXBsb3llZCBzZXJ2aWNlLg0KDQoNCiAgKiAgIElnb3INCg0KRnJvbTogVG9tbXkgUGF1bHkg PHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgT2N0b2Jl ciA4LCAyMDIxIDExOjU5IEFNDQpUbzogSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSA8aXBw bUBpZXRmLm9yZz4NClN1YmplY3Q6IFtpcHBtXSBBZG9wdGlvbiBjYWxsIGZvciBFeHBsaWNpdCBG bG93IE1lYXN1cmVtZW50cyBUZWNobmlxdWVzDQoNCkhlbGxvIElQUE0sDQoNClRoaXMgZW1haWwg c3RhcnRzIGFuIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ct bWVhc3VyZW1lbnRzLCAiRXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4g VGhpcyBkb2N1bWVudCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRo YXQgZGVzY3JpYmVzIHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5n cyBsaWtlIHRoZSBRVUlDIHNwaW4gYml0Lg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy88aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMvX187ISFHanZUel92ayFGZTZDbVg2 b1JZNEJ1Q3JPQWpZamFNcDZUdkFOdDZqbUVDUDNWZFdsZHR4emxzLVVBOWEzZ21TWlVVUUFyMDAk Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1l eHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMjxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1kdC1pcHBtLWV4cGxp Y2l0LWZsb3ctbWVhc3VyZW1lbnRzLTAyX187ISFHanZUel92ayFGZTZDbVg2b1JZNEJ1Q3JPQWpZ amFNcDZUdkFOdDZqbUVDUDNWZFdsZHR4emxzLVVBOWEzZ21TWjBSN2hBZUEkPg0KDQpUaGlzIGFk b3B0aW9uIGNhbGwgd2lsbCBsYXN0IHVudGlsIEZyaWRheSwgT2N0b2JlciAyMi4gUGxlYXNlIHJl dmlldyB0aGUgZG9jdW1lbnQsIGFuZCByZXBseSB0byB0aGlzIGVtYWlsIHRocmVhZCB0byBpbmRp Y2F0ZSBpZiB5b3UgdGhpbmsgSVBQTSBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudC4NCg0KQmVz dCwNClRvbW15DQo= --_000_203d2d87bfb74425b139458abe532d2bustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDQ5Mjc1NzQwOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzk5ODA1ODA4IC0xNDgxOTQyMjAg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyMy4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTkuMjVwdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTUuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDox MzEuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY3LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjIwMy4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzOS4yNXB0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzUuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MzExLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24gYXMgYSBjby1h dXRob3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIG1lYXN1cmVtZW50IHRlY2huaXF1 ZXMgYXJlIHVzZWZ1bCBmb3IgTDMgUW9TIG1vbml0b3JpbmcgYnkgb24tcGF0aCBhZ2VudHMgd2l0 aG91dCBhY2Nlc3MgdG8gY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbHMsIHdoaWxlIHByZXNlcnZpbmcg cHJpdmFjeSBhbmQgb3NzaWZpY2F0aW9uLXJlc2lzdGFudCBwcm9wZXJ0aWVzIG9mIHRoZSBlbmNy eXB0ZWQgcHJvdG9jb2xzLiZuYnNwOyBPbmNlIHRoZXNlIHRlY2huaXF1ZXMNCiBhcmUgc3RhbmRh cmRpemVkIGhlcmUsIHdlIGF0IEFrYW1haSBpbnRlbmQgdG8gd29yayB3aXRoIFFVSUMgV0cgb24g YSBjb25jcmV0ZSBpbXBsZW1lbnRhdGlvbiBkcmFmdCBhbmQgdG8gaW1wbGVtZW50IGl0IGluIG91 ciBkZXBsb3llZCBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTEyLjc1cHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgOCwgMjAy MSAxMTo1OSBBTTxicj4NCjxiPlRvOjwvYj4gSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSAm bHQ7aXBwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2lwcG1dIEFkb3B0aW9u IGNhbGwgZm9yIEV4cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBJUFBNLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWls IHN0YXJ0cyBhbiBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93 LW1lYXN1cmVtZW50cywgJnF1b3Q7RXhwbGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVl c+KAnS4gVGhpcyBkb2N1bWVudCBpcyBwcm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3Vt ZW50IHRoYXQgZGVzY3JpYmVzIHRlY2huaXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBt YXJraW5ncw0KIGxpa2UgdGhlIFFVSUMgc3BpbiBiaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1pcHBt LWV4cGxpY2l0LWZsb3ctbWVhc3VyZW1lbnRzL19fOyEhR2p2VHpfdmshRmU2Q21YNm9SWTRCdUNy T0FqWWphTXA2VHZBTnQ2am1FQ1AzVmRXbGR0eHpscy1VQTlhM2dtU1pVVVFBcjAwJCI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1t ZWFzdXJlbWVudHMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93 LW1lYXN1cmVtZW50cy0wMl9fOyEhR2p2VHpfdmshRmU2Q21YNm9SWTRCdUNyT0FqWWphTXA2VHZB TnQ2am1FQ1AzVmRXbGR0eHpscy1VQTlhM2dtU1owUjdoQWVBJCI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVt ZW50cy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCB1bnRpbCA8Yj5GcmlkYXksIE9j dG9iZXIgMjI8L2I+LiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5IHRvIHRo aXMgZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3VsZCBhZG9w dCB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VG9tbXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_203d2d87bfb74425b139458abe532d2bustx2exdag1mb5msgcorpak_-- From nobody Fri Oct 15 00:57:18 2021 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 D8FB03A18A5 for ; Fri, 15 Oct 2021 00:57:14 -0700 (PDT) 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 8Nn63QH5TLF4 for ; Fri, 15 Oct 2021 00:57:09 -0700 (PDT) Received: from mail-out-2.itc.rwth-aachen.de (mail-out-2.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5: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 513FA3A18A4 for ; Fri, 15 Oct 2021 00:57:08 -0700 (PDT) IronPort-SDR: XlFaeB8TXNzc/DZ5lEQihVPUfAZvG7zFj40K/n5huYkFcsFYPlb7b7IKERztCFRq8gpO0uFOxH 3BYJEF5I2LQQ== X-IPAS-Result: =?us-ascii?q?A2AVAwADNGlh/xUN4olaHAEBAQEBAQcBARIBAQQEAQGCG?= =?us-ascii?q?YFRgToVgUKER5EOmQ+DKIFoCwEBAQEBAQEBAQgBKgEMCAIEAQGEfgIXgjICJ?= =?us-ascii?q?TgTAQIEAQEBAQMCAwEBAQEFAQEGAQEBAQEBBQSBJIUvOQ2GQwIBAwEBGwYwG?= =?us-ascii?q?wsQAgEIBAwvAwICAiULFBECBA4FgnEBgX6BCQEOQqtWgTGBAYNOAQMCDkFGg?= =?us-ascii?q?yyBXQaBOoV5VEkBAYZzJxCBVUSBFScPDYI3MD6CYwEBAgGBKAESATgfgmI3g?= =?us-ascii?q?i4EjTsEUQJXBEJlESqVU4kDjU+ReDMHggiBLIE4C4kElCoFLINqi22GEY5Jg?= =?us-ascii?q?meVE3WMb5N1hQkCBAIEBQIWgTBIgQ1wTSRPKgGCPlEXAg+XJoVKdAIBNQIGA?= =?us-ascii?q?QoBAQMJhWqNNgEB?= IronPort-Data: A9a23:1kS59qxP8kjvNb3/IFd6t+eNxCrEfRIJ4+MujC+fZmUNrF6WrkVVy mRJWmrTb6uDYGr3LogjbNnk8h9Q6pLVzdcySQI6pFhgHilAwSbn6XV1DW+tZX/Ifp2bJK5Dx 59DAjUVBJlsFhcwnvouW1TYhSEUOZugH9IQM8aZfHAsLeNYYH1500s6w7dk2tcAbeWRWmthh /uj+6UzB3f4g1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJM53yZWKEpfNatI88tiSG ryfluHppgs1yD92Yj+tuu6TnkTn2dc+NyDW4pZdc/DKbhSvOkXe345jXMfwZ3u7hB2YwuxVm ehUrKCdCitxLJTMyNwMUihxRnQW0a1uoNcrIFC7sNeP1AvNdH730u4oFl4qPcgR8+13DGcI+ fFwxDIlN0vcwbjsnvTiEa8236zPL+GyVG8bklBjwHf6EPA0TLjIRKDR9MQexigshoVHFP3ea sxfZTcHgBHoOkMWZQ9OVM5l9AuuriXnL2UHpXG0nJEyulTd0wFbibPTAcWAL7RmQu0QxC50v Fnu43zwHxULYYDHwCKd9n/qjejKtS/+UZgZUry16vAsh0ecrkQSEAUTfVq2vff/jVSxM++zM GQQ+zEytu4580mwX8K7RQKkoDuNtxUcVtwWH+BSBByx95c4Kj2xXgAsJgOtovR83CPqbVTGD mO0ou4= IronPort-HdrOrdr: A9a23:k2+QKKhyQRqrfgLV3vca89WgHHBQXiEji2hC6mlwRA09TyVXra GTdZMgpHvJYVcqKRQdcLW7U8O9qBznmKKdnrNhR4tKMDOLhILKFvAB0WKB+V3d8kTFn4ZgPM FbHJSWY+eAbmSS4/yV3CCIV/oG/52h2ISF7N2ut0tFfEVHTJ4l0jdBJm+gYzRLbTgDPKEeOa a326N81lydUEVSVJyaAXYCNtKz3OEjnaiWHCIuNlocyCTmt0LO1ILH X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,375,1624312800"; d="scan'208,217";a="161701443" Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-2.itc.rwth-aachen.de with ESMTP; 15 Oct 2021 09:57:03 +0200 Received: from hermes-mbx.win.comsys.rwth-aachen.de (hermes-mbx.win.comsys.rwth-aachen.de [137.226.13.41]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id BB495C04D0; Fri, 15 Oct 2021 09:57:03 +0200 (CEST) Received: from HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:dce8:101c:a3f0:7884) by HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:dce8:101c:a3f0:7884) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Fri, 15 Oct 2021 09:57:03 +0200 Received: from HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::dce8:101c:a3f0:7884]) by HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::dce8:101c:a3f0:7884%5]) with mapi id 15.01.2308.014; Fri, 15 Oct 2021 09:57:03 +0200 From: Ike Kunze To: Tommy Pauly CC: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Adoption call for Explicit Flow Measurements Techniques Thread-Index: AQHXvF2BCqTQj9EmyUWV7/EAcbhP8qvTmjcA Date: Fri, 15 Oct 2021 07:57:03 +0000 Message-ID: <9198BC1C-08A8-420C-99AF-E889ACF50BD9@comsys.rwth-aachen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a00:8a60:1014:10:c4ac:e233:911f:686] Content-Type: multipart/alternative; boundary="_000_9198BC1C08A8420C99AFE889ACF50BD9comsysrwthaachende_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 15 Oct 2021 07:57:15 -0000 --_000_9198BC1C08A8420C99AFE889ACF50BD9comsysrwthaachende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFsc28gc3VwcG9ydCBhZG9wdGlvbi4NCkZvciBvdXIgcmVjZW50IEFOUlcg cGFwZXIgWzFdLCB3ZSBoYXZlIGZpcnN0IGltcGxlbWVudGVkIHRoZSBwcm9wb3NlZCBsb3NzIG1l YXN1cmVtZW50IHRlY2huaXF1ZXMgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9ucyBpbiB0aGUgZHJh ZnQgYW5kIHRoZW4gZXZhbHVhdGVkIHRoZWlyIHBlcmZvcm1hbmNlLg0KV2hpbGUgdGhlIGRlc2Ny aXB0aW9ucyBvZiB0aGUgYXBwcm9hY2hlcyBjb3VsZCBiZSBhIGJpdCBtb3JlIHByZWNpc2UsIHRo ZWlyIHBlcmZvcm1hbmNlIGxvb2tzIHByb21pc2luZyBhbmQgSSB0aGluayB0aGV5IG9mZmVyIGEg aGVscGZ1bCBtZWFucyBmb3IgbmV0d29yayB0ZWxlbWV0cnkgaW4gdGltZXMgb2YgUVVJQy4NCg0K QmVzdCwNCklrZQ0KDQpbMV0gaHR0cHM6Ly9kbC5hY20ub3JnL2RvaS8xMC4xMTQ1LzM0NzIzMDUu MzQ3MjMxOQ0KDQpPbiA4LiBPY3QgMjAyMSwgYXQgMTc6NTksIFRvbW15IFBhdWx5IDx0cGF1bHk9 NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFy Yy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpIZWxsbyBJUFBNLA0KDQpUaGlzIGVtYWlsIHN0YXJ0cyBh biBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVt ZW50cywgIkV4cGxpY2l0IEZsb3cgTWVhc3VyZW1lbnRzIFRlY2huaXF1ZXPigJ0uIFRoaXMgZG9j dW1lbnQgaXMgcHJvcG9zZWQgYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2Ny aWJlcyB0ZWNobmlxdWVzIHRoYXQgZ28gYmV5b25kIHNpbmdsZSBiaXQgbWFya2luZ3MgbGlrZSB0 aGUgUVVJQyBzcGluIGJpdC4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWR0LWlwcG0tZXhwbGljaXQtZmxvdy1tZWFzdXJlbWVudHMvDQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVhc3Vy ZW1lbnRzLTAyDQoNClRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGxhc3QgdW50aWwgRnJpZGF5LCBP Y3RvYmVyIDIyLiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIHJlcGx5IHRvIHRoaXMg ZW1haWwgdGhyZWFkIHRvIGluZGljYXRlIGlmIHlvdSB0aGluayBJUFBNIHNob3VsZCBhZG9wdCB0 aGlzIGRvY3VtZW50Lg0KDQpCZXN0LA0KVG9tbXkNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZzxt YWlsdG86aXBwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbQ0KDQo= --_000_9198BC1C08A8420C99AFE889ACF50BD9comsysrwthaachende_ Content-Type: text/html; charset="utf-8" Content-ID: <0D274B953F161340BE5319DC1DFC09A7@comsys.rwth-aachen.de> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYWxzbyBzdXBwb3J0IGFkb3B0aW9uLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gb3Igb3VyIHJlY2VudCBBTlJXIHBhcGVyIFsxXSwgd2UgaGF2 ZSBmaXJzdCBpbXBsZW1lbnRlZCB0aGUgcHJvcG9zZWQgbG9zcyBtZWFzdXJlbWVudCB0ZWNobmlx dWVzIGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbnMgaW4gdGhlIGRyYWZ0IGFuZCB0aGVuIGV2YWx1 YXRlZCB0aGVpciBwZXJmb3JtYW5jZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hpbGUgdGhlIGRl c2NyaXB0aW9ucyBvZiB0aGUgYXBwcm9hY2hlcyBjb3VsZCBiZSBhIGJpdCBtb3JlIHByZWNpc2Us IHRoZWlyIHBlcmZvcm1hbmNlIGxvb2tzIHByb21pc2luZyBhbmQgSSB0aGluayB0aGV5IG9mZmVy IGEgaGVscGZ1bCBtZWFucyBmb3IgbmV0d29yayB0ZWxlbWV0cnkgaW4gdGltZXMgb2YgUVVJQy48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklrZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZGwu YWNtLm9yZy9kb2kvMTAuMTE0NS8zNDcyMzA1LjM0NzIzMTkiIGNsYXNzPSIiPg0KaHR0cHM6Ly9k bC5hY20ub3JnL2RvaS8xMC4xMTQ1LzM0NzIzMDUuMzQ3MjMxOTwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA4LiBPY3QgMjAyMSwgYXQgMTc6NTksIFRvbW15IFBhdWx5 ICZsdDs8YSBocmVmPSJtYWlsdG86dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnIiBj bGFzcz0iIj50cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkhlbGxvIElQUE0sPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGVtYWlsIHN0YXJ0cyBhbiBhZG9wdGlvbiBjYWxs IGZvciBkcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cywgJnF1b3Q7RXhw bGljaXQgRmxvdyBNZWFzdXJlbWVudHMgVGVjaG5pcXVlc+KAnS4gVGhpcyBkb2N1bWVudCBpcyBw cm9wb3NlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRlY2hu aXF1ZXMgdGhhdCBnbyBiZXlvbmQgc2luZ2xlIGJpdCBtYXJraW5ncyBsaWtlDQogdGhlIFFVSUMg c3BpbiBiaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy8iIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1pcHBtLWV4cGxpY2l0LWZsb3ctbWVh c3VyZW1lbnRzLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1l YXN1cmVtZW50cy0wMiIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1tZHQtaXBwbS1leHBsaWNpdC1mbG93LW1lYXN1cmVtZW50cy0wMjwvYT48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRo aXMgYWRvcHRpb24gY2FsbCB3aWxsIGxhc3QgdW50aWwgPGIgY2xhc3M9IiI+RnJpZGF5LCBPY3Rv YmVyIDIyPC9iPi4gUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQsIGFuZCByZXBseSB0byB0aGlz IGVtYWlsIHRocmVhZCB0byBpbmRpY2F0ZSBpZiB5b3UgdGhpbmsgSVBQTSBzaG91bGQgYWRvcHQg dGhpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvbW15PC9kaXY+DQo8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0KaXBwbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86aXBwbUBpZXRmLm9yZyIgY2xhc3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_9198BC1C08A8420C99AFE889ACF50BD9comsysrwthaachende_-- From nobody Fri Oct 15 15:38:06 2021 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 C8CF13A0DCA; Fri, 15 Oct 2021 15:33:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ippm@ietf.org, martin.h.duke@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433722080.17026.4472804102821963795@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:33:40 -0700 Archived-At: Subject: [ippm] ippm - Requested session has been scheduled for IETF 112 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, 15 Oct 2021 22:33:42 -0000 Dear Tommy Pauly, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ippm Session 1 (2:00 requested) Thursday, 11 November 2021, Session III 1600-1800 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/ippm.ics Request Information: --------------------------------------------------------- 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: 40 Conflicts to Avoid: People who must be present: Alfred Channon Morton Frank Brockners Greg Mirsky Ian Swett Martin Duke Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 16 15:45:13 2021 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 D24153A0B4C; Sat, 16 Oct 2021 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 MlX9s1ku7WDo; Sat, 16 Oct 2021 15:45:00 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 1C5C33A0B4B; Sat, 16 Oct 2021 15:44:59 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id r18so53756624edv.12; Sat, 16 Oct 2021 15:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CJlmmqGsHk2heKN6LKWiAiTjpZfjAawzWMKgv88TshE=; b=pBMxvBwx5r6W7k4YES0WGkfwocrvnPeFErXVg0Z7GcNim4f0cCXJxsCM0YG7FpU3im dw0Z+TD6bwNCWOx9gGmofn8Hea/xRg6ZZJE4vaA9XUCyA1rrreW2xbuenktOajXz1EC3 r4HZ6p1RRAMFeh+QKDRcN7HzwceDpmaaGGR4sT2/enbt0dp3MQWnNiYXxNCEI08BO4rM HtSLT4ndD5qf7l5vf3x+wd5va4kng6yl+JOjtXCn/KGJV4zC4OqSEBByYqMElx5wUCcQ 2KrjfYgUUxc3JPDjSOg+seCWn5JIngZRDbHE+fj1USJ347B7ENroMpYeOlMsByi/6zEF 5JOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CJlmmqGsHk2heKN6LKWiAiTjpZfjAawzWMKgv88TshE=; b=EB0nGTL1A2ZDiBIfo9ZZE+8lKqpUeduWxVUDl/CvteTaDLqwJAyNuyxHnqWsaTgvzB IvHB8/RL+KDTQ5HLo9Hsge/ugfF73PyTpBL15nq3IM1kB8vKMjukAHQrvKT0ce9eM7WT 1UdEqiJpk+IYsVM/9hOEs0w3/cPBjjU9r5CPXkQKXqhar2d0yU5+OiUFefjg338Tx4fk NDUh6P3eJFuYNI7OYFiUdt7cNZb8zzZUUFVoyg3Jr7oHZuCq1E7eedM0aIitjEjxMTRB +q4+Nkvb9kRQ0OSRuWt9XPHRrws/NruBZTbnLN05LMSvGLVK4wGAlXh/0ZCAxSHNnOxY lAjQ== X-Gm-Message-State: AOAM530lUUx234P1HbyFDQJu6WC9cX1qTQzZGIiQ+gXI08HPY+LtwhsS kY4Goqh83/Y6LM1qmLmfj8T9imovcrEscLyzezicV9XN5ck= X-Google-Smtp-Source: ABdhPJx+AJeotGujocvrXLtPLENN7A8NXx4CdUKt7Ty7vUh1ol8eb0VSQpbJh1aMVsnMnPFHXvdcejz2wP9vsAkQAoY= X-Received: by 2002:a17:906:a0c9:: with SMTP id bh9mr17799051ejb.51.1634424296029; Sat, 16 Oct 2021 15:44:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sat, 16 Oct 2021 15:44:44 -0700 Message-ID: To: Tal Mizrahi Cc: IPPM Chairs , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="00000000000093c37605ce800f9c" Archived-At: Subject: Re: [ippm] WGLC for IOAM Flags 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: Sat, 16 Oct 2021 22:45:08 -0000 --00000000000093c37605ce800f9c Content-Type: text/plain; charset="UTF-8" Hi Tal, thank you for uploading the new version of the draft. I appreciate your consideration of my comments and believe that we're converging, though I have some questions that concern me: - The added text sets new restrictions on the applicability of the Loopback flag: The loopback flag MUST NOT be set if it is not guaranteed that there is a return path from each of the IOAM transit and IOAM decapsulating nodes, or if the encapsulating node's identity is not available in the encapsulation header. Can you clarify how an encapsulating node can guarantee "that there is a return path from each of the IOAM transit and IOAM decapsulating nodes" when setting the Loopback flag for the first time? I would imagine that for the first packet marked with the Loopback flag, the encapsulating node may only know the identity of the decapsulating node, not of every node that the marked packet will traverse. Also, what is understood as "a return path"? Is that a path with the same encapsulation as the marked with the Loopback flag packet or any type? And I also have a concern about the scope of the applicability of the Loopback flag by the "MUST NOT ... if the encapsulating node's identity is not available in the encapsulation header". I believe that among encapsulation types defined at IETF, that requirement automatically excludes MPLS and SFC NSH. Depending on the interpretation of "a return path", BIER MPLS might be excluded too. As a result, it appears that the Loopback flag maybe only applicable in an IPv6 network. If that is the case, I cannot see a reason to use a constrained resource (space in the Flags field) for a very limited application. - Another update clarifies that: If the address of the encapsulating node is not available in the encapsulation header, then the transit/ decapsulating node does not loop back a copy of the original packet. That seems directly related to the requirement I've pointed out above. I have a question about the next text: - How does a node "knows" if the address of the encapsulating node is available? I can imagine a situation, for example, SFC NSH over an IPv6 network. In that case, the encapsulation includes the source address, but how the node processing Loopback flag knows that that is the address of the encapsulation node? - And the next explanation of the operation brought a new question: The address of the node performing the copy operation is used as the source address. It is not clear whether it is a requirement or a recommendation. Also, it appears that the draft assumes that a looped back packet is always encapsulated to convey the sender's identity. But, as I've noted earlier, that is the case for a very few types of encapsulation defined at IETF. - For our discussion of the use of the Active flag, it seems as you've added only the following: The Active flag indicates that a packet is used for active measurement. The term active measurement in the context of this document is as defined in [RFC7799]. I firmly believe that the document does not provide sufficient information about types of active measurement in which a packet with the Active flag is recommended or required to be used. In that situation, because the use of the Active flag is clearly underdefined, I suggest its definition and all references be removed from the draft. Once there is a better understanding of a type of active measurement that benefits from using this method, the definition of the Active flag would be appropriate. Regards, Greg On Wed, Oct 13, 2021 at 5:24 AM Tal Mizrahi wrote: > Minor correction - here is the correct link to the updated version of the > draft: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > :) > Cheers, > Tal. > > On Wed, Oct 13, 2021 at 3:18 PM Tal Mizrahi > wrote: > > > > Dear Chairs, > > > > Thanks again to Greg for a very thorough review that helped us improve > > the quality and clarity of the draft. We believe we addressed most of > > the comments, either by updating the text, or by responding to the > > comments. > > Some further responses can be found below, marked [[[TM]]]. > > > > Note (1): it looks like some of the comments are basically about the > > purpose of the document. Addressing these documents would probably > > require a complete rewriting of the document with a different purpose. > > At this point we do not think it would make sense to align to these > > comments. These comments can be easily found by searching for "(1)" > > through this email. > > > > We have posted an updated version of this draft (07): > > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > > > > > > We believe the draft is ready to be submitted to the IESG. > > > > Thanks, > > Authors. > > > > > > On Fri, Oct 8, 2021 at 7:04 PM Greg Mirsky > wrote: > > > > > > Hi Tal, > > > thank you for your responses to my comments and questions. Please find > my follow-up notes in-lined below under the GIM>> tag. > > > > > > Regards, > > > Greg > > > > > > On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi < > tal.mizrahi.phd@gmail.com> wrote: > > >> > > >> Hi Greg, > > >> > > >> Many thanks for the detailed comments. > > >> Please see the responses below, as well as suggested text edits in > some cases. > > >> > > >> Cheers, > > >> The authors. > > >> > > >> On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky > wrote: > > >> > > > >> > Dear Authors, WG Chairs, and All, > > >> > I've read the latest version of the draft and have several comments > and questions to share with you. I would much appreciate the opportunity to > discuss these before I can state my support for progressing this draft to > publication. > > >> > > > >> > The Abstract states that: > > >> > > > >> > In-situ Operations, Administration, and Maintenance (IOAM) > records > > >> > operational and telemetry information in packets while they > traverse > > >> > a path between two points in the network. > > >> > > > >> > I think that is not a complete description of IOAM options as it > excludes the Direct Export option. It might be easier to improve by > s/records/collects/. Also, what, in your opinion, is the distinction > between operational and telemetry information? I think that operational > information collected from remote nodes is one example of telemetry > information. What do you think? > > >> > > >> [TM] Agreed. Your proposal makes sense: s/records/collects/ > > >> Regarding the difference between operational and telemetry > > >> information, the way I see it "telemetry" refers to measurements that > > >> are being exported to an external/remote entity, whereas operational > > >> information is not measurement-based, such as the Node ID or Interface > > >> ID. > > > > > > GIM>> I think that there's no standardized definition of "telemetry" > and "telemetry information". I share the idea expressed in the following: > > > > > > Telemetry is automated communication that processes from multiple data > sources. Telemetry data improves customer experiences, monitors security, > application health, quality, and performance. > > > > > > For different cases, the set of information referred to as telemetry > data variates. For example, CPU and buffer utilization are valuable for > virtualized environments. In other words, I understand telemetry data as > information extracted from a remote system that characterizes the system's > state. In any case, providing a definition would be helpful to a reader of > the document. > > > > [[[TM]]] This word is mentioned only once in the document (in the > > abstract), and not sure adding a definition for this particular word > > would change the readability of the document. > > > > >> > > >> > > >> > > >> > > > >> > nit s/the the/the/ > > >> > > >> [TM] Agreed. > > >> > > >> > I think that Abstract and Introduction can be improved by > explaining the purpose of defining the Loopback and Active flags. What each > of them is intended to achieve and improve? > > >> > > >> [TM] The point is well-taken, and the following text will be added to > > >> the introduction. In order to avoid text repetition, I believe it > > >> would be best not to add it to the abstract as well. > > >> > > >> OLD: > > >> - > > >> NEW: > > >> The Loopback flag is used to request that each transit device along > > >> the path loops back a copy of the data packet to the sender. The > > >> Active flag indicates that a packet is used for active measurement. > > > > > > GIM>> Thank you for the proposed text. I have several notes to the new > text: > > > > > > As I understand the behavior required from a node processing the > Loopback flag, the returned packet is not the complete but truncated data > packet. > > > Is "active measurement" used in the context of RFC 7799? If "yes", > does that mean that the packet is a specifically generated test packet? > > > > [[[TM]]] These are two good points. Based on these comments the > > following text is proposed instead. > > NEW: > > The Loopback flag is used to request that each transit device along > > the path loops back a truncated copy of the data packet to the sender. > The > > Active flag indicates that a packet is used for active measurement. > > The term active measurement in the context of this document is as defined > > in [RFC7799]. > > > > >> > > >> > > >> > > >> > It is stated in the Introduction that: > > >> > > > >> > This document defines > > >> > two new flags in the Pre-allocated and Incremental Trace > options: the > > >> > Loopback and Active flags. > > >> > Does that mean that neither of the two flags is applicable in the > Direct Export option? Should draft-ietf-ippm-ioam-direct-export have an > explicit statement regarding the applicability of the Loopback and Active > flags? And if any is applicable, describe the behavior of an IOAM node > receiving it. > > >> > > >> [TM] Right. > > >> The direct exporting draft explicitly states the behavior of each > > >> field in the DEX option header including the flags, so there seems to > > >> be no need to specify flags that are supported in other options. > > > > > > GIM>> I'm a bit confused. Can you help me with the text from the DEX > draft that specifies the use of the Loopback and Active flags in > combination with the DEX trace option? > > > > [[[TM]]] The DEX option does not support the loopback and active > > flags. That is why the DEX document does not discuss these flags. The > > DEX document defines the DEX option header including all the flags > > that are relevant to the DEX option (loopback and active are not > > included). > > > > >> > > >> > > >> > > > >> > In Section 4 the purpose of using the Loopback flag is explained as: > > >> > > > >> > Loopback allows an IOAM encapsulating node to trace the path to a > > >> > given destination, and to receive per-hop data about both the > forward > > >> > and the return path. > > >> > In my previous comments, I've pointed out that the Loopback mode is > just a special case of the Direct Export option. In addition to that, I > would appreciate your explanation of how the IOAM encapsulating node > receives per-hop data about the return path. How does that work, for > example, in an MPLS or SFC NSH environment? > > >> > > >> [TM] It is slightly similar to direct exporting, but is not a special > > >> case of direct exporting. In direct exporting telemetry/operational > > >> data is not pushed into the data packet, but the data packet with the > > >> DEX option triggers the data collection and optionally also exporting, > > >> but exporting is not mandatory and may be performed later, for example > > >> by the management plane. On the other hand, a trace option with the > > >> loopback flag causes all IOAM transit nodes to push IOAM data onto the > > >> trace option, and also loop a copy of the packet back to the sender. > > > > > > GIM>> Thank you for providing that comparison between the result of > processing DEX and the Loopback. As I understand it, the result of DEX, > i.e., immediate export or local processing with exporting a batch of > telemetry data, is determined by the local policy. If that is the case, the > local policy can produce the same result as for the Loopback flag, which > could be the default behavior for the DEX. > > > > [[[TM]]] Not exactly, because when using DEX in node X, the policy in > > node X enables immediate exporting of the IOAM data of node X, but > > does not enable exporting of the IOAM data of all the transit nodes > > between the encapsulating node and node X. The former is possible with > > DEX, but the latter is only possible with Loopback. This is just one > > example of why Loopback is not a special case of DEX. > > > > >> > > >> > > >> > > >> > > > >> > Further it Section 4, it is stated that: > > >> > > > >> > The two IOAM looped back copies are > > >> > terminated by the encapsulating node. > > >> > But I don't see any technical explanation that could sustain that > assumption. As I understand the diagram in figure 1, a transit node doesn't > know the identity of the IOAM encapsulating node. Correct? If that is the > case, where does the transit node direct the looped packet? > > >> > > >> [TM] As described in the draft, the loopback flag is not necessarily > > >> applicable to all possible encapsulations. The way the return path is > > >> defined is encapsulation-specific. The draft currently states: > > >> > > >> Loopback can be used only if a return path from transit nodes and > > >> destination nodes towards the source (encapsulating node) exists. > > >> Specifically, loopback is only applicable in encapsulations in > which > > >> the identity of the encapsulating node is available in the > > >> encapsulation header. If an encapsulating node receives a looped > > >> back packet that was not originated from the current encapsulating > > >> node, the packet is dropped. > > > > > > GIM>> Please help me understand, the looped back packet is transmitted > using the same encapsulation as the data packet with the Loopback flag? > What is the rationale? If we use MPLS LSP Ping as an example, the response > can be sent in several ways, but the default is in IP/UDP encapsulation as > the commonly available transport. Why not use that and send the looped > packet over IP/UDP? I believe that the applicability of this mechanism will > be much broader. > > > > [[[TM]]] The rationale is to define very simple Loopback > > functionality. Simplicity is an advantage as it enables hardware > > implementations. > > > > >> > > >> > > >> > > >> > It seems that the text in the last paragraph attempts to walk > around my questions. But I don't find that paragraph sufficient. It lacks > the normative language to guide a developer to produce resilient > implementation. For example, how to interpret: > > >> > Loopback can be used only if a return path from transit nodes and > > >> > destination nodes towards the source (encapsulating node) exists. > > >> > That reads like a recommendation, not a requirement. As a result, > an implementation may transmit an IOAM packet with the Loopback fag set > regardless of whether there's a return path or not. Then, how must a > transit node process such an IOAM packet? > > >> > > > >> > > >> [TM] Right, the last response and quoted text is relevant here as > > >> well. Please also note the following text from the draft: > > >> > > >> it is assumed that the > > >> source address is available in the encapsulation header. Thus, the > > >> source address of the original packet is used as the destination > > >> address in the copied packet. > > >> > > >> I propose to add the following sentence: > > >> The loopback flag MUST NOT be set if it is not guaranteed that there > > >> is a return path from each of the IOAM transit and IOAM decapsulating > > >> nodes, or if the encapsulating node's address is not available in the > > >> encapsulation header. > > > > > > GIM>> Thank you for the proposed text. I'd note that referring to the > "encapsulating node's address" and "source address" might be interpreted as > applying only to IP. In some networks, for example, BIER, the identity of > the IOAM encapsulating node, BFIR, is known from its identifier that, in > turn, can be mapped to the IP address. > > > > [[[TM]]] Right. Proposed text: > > The loopback flag MUST NOT be set if it is not guaranteed that there > > is a return path from each of the IOAM transit and IOAM decapsulating > > nodes, or if the encapsulating node's identity is not available in the > > encapsulation header. > > > > >> > > >> > > >> > > >> > A very concerning statement I've found in Section 4.1 > > >> > > > >> > The encapsulating node either generates synthetic packets with an > > >> > IOAM trace option that has the Loopback flag set ... > > >> > IOAM has been defined as a hybrid measurement protocol. This > statement implies that it is to be used as an active OAM protocol (all per > RFC 7799 definitions). The requirements for active OAM protocols in terms > of their applicability and, most of, security are very different from those > set for a hybrid measurement protocol. I believe that extending IOAM into > an active mode of measurement requires more discussion and the audience > from other IETF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG. > > >> > > >> [TM] This draft does not define an active measurement protocol. The > > >> point in the draft is that the loopback flag can be used in active > > >> measurement packets. > > > > > > GIM>> I have to disagree. Per RFC 7799, the use of specially > constructed test packets is the primary characteristic of an active > measurement method. By introducing the Active flag, this drat makes the > IOAM into an active measurement protocol with all the requirements to an > active measurement protocol to be applied. > > > > [[[TM]]] See note (1). > > > > >> > > >> The following text edit is proposed: > > >> > > >> OLD: > > >> The encapsulating node either generates synthetic packets with an > > >> IOAM trace option that has the Loopback flag set, or sets the > loopack > > >> flag in a subset of the in-transit data packets. Loopback is used > > >> either proactively or on-demand, i.e., when a failure is detected. > > >> NEW: > > >> The loopback flag can be set in the IOAM trace option either in a > > >> subset of the in-transit data packets, or in synthetic packets that > > >> are generated by the encapsulating node. Loopback can be used > > >> either proactively or on-demand, i.e., when a failure is detected. > > >> > > >> > > > >> > The next statement explains the use case for the Loopback flag: > > >> > > > >> > Loopback is used > > >> > either proactively or on-demand, i.e., when a failure is > detected. > > >> > That is the same use of ICMP and LSP Ping. What is the benefit of > using the Loopback flag instead of readily available ICMP? Does it work as > L2 Linktrace? I don't see that as a sufficient benefit considering the > complexity, exclusions, and risks associated and identified in the draft. > It is clear that there are tools like ICMP and LSP Ping that adequately > address scenarios listed in the draft. Don't see any technical reason for > the introduction of another mechanism that does not have any significant > benefit compared to the existing OAM tools. Especially, considering the > limited information that is allowed to be collected using the Loopback IOAM > flag ("every transit node that processes this trace option only adds a > single data field, which is the Hop_Lim and node_id data field"). With the > abundance of information and additional verification achieved using ICMP > and LSP Ping, there's even less rationale in the introduction of this > over-complex and unnatural mechanism. > > >> > > >> [TM] Right, as the draft says, the loopback flag is an "...alternative > > >> to Traceroute, that allows the encapsulating node to receive responses > > >> from multiple transit nodes along the path". Indeed, it slightly > > >> resembles ETH-LT (Ethernet Linktrace) in the sense that a single > > >> packet from the encapsulating node allows to quickly trace the entire > > >> path, but as with IOAM in general, using the loopback flag does not > > >> mandate a specific encapsulation. > > > > > > GIM>> Also, I must note that "pro-active" use of the Loopback is > possible only as part of the active measurement protocol. > > > > [[[TM]]] See note (1). > > > > >> > > >> > > >> > > > >> > The last paragraph states the requirement: > > >> > > > >> > IOAM encapsulating nodes MUST NOT push an IOAM encapsulation > with the > > >> > Loopback flag onto data packets that already include an IOAM > > >> > encapsulation. > > >> > I couldn't find any guidance on how an IOAM node that receives such > invalid combination processes the packet. > > >> > > > >> > > >> [TM] The current draft only specifies the flags. Specifically in the > > >> scenario described above, the encapsulating node does not set the > > >> loopback flag. This is intended to reduce the impact of potential > > >> amplification attacks. > > > > > > GIM>> I am still not clear about "MUST NOT push an IOAM encapsulation > with the Loopback flag" in the draft and your explanation "the > encapsulating node does not set the Loopback flag". As I understand it, in > the given network for the monitored data flow, only one IOAM encapsulating > node can exist. If that is correct, where does the existing IOAM > encapsulation come from? > > > > [[[TM]]] The scenario that was raised by Martin Duke in his security > > review is a nested IOAM scenario, where traffic in an IOAM domain is > > forwarded through another domain/tunnel, which is also IOAM-enabled. > > This is explained in the draft: > > > > This requirement is intended to prevent IOAM Loopback > > nesting, where looped back packets may be subject to loopback in a > > nested IOAM domain. > > > > > > >> > > >> > > >> > > > >> > It is assumed that the identity of the IOAM encapsulating node is > known to the node that is expected to sent a copy of the received packet > back. But what if that is not the case? How must that node act? > > >> > > >> [TM] Agreed. The following new text is proposed to be added to > Section 4.1: > > >> If the address of the encapsulating node is not available in the > > >> encapsulation header, then the transit/decapsulating node does not > > >> loop back a copy of the original packet. > > > > > > GIM>> I think that points to the significant limitation of the > proposed mechanism. Comparing with MPLS LSP Ping, we see that it allows > tracing the LSP even though MPLS encapsulation does not identify the > ingress LER while the proposed Loopback would not work at all. > > > > [[[TM]]] See note (1). > > > > >> > > >> > > >> > I believe that there's inconsistency between Figure 1 and the > following text in Section 4.2 > > >> > > > >> > Thus, the > > >> > source address of the original packet is used as the destination > > >> > address in the copied packet. > > >> > It seems that the text assumes that the IOAM encapsulating node > adds also a network layer encapsulation. But how would it work, for > example, in SFC NSH data plane? Or MPLS? > > >> > > >> [TM] Right, the paragraph beginning with "Loopback can be used > > >> only..." (discussed in response to one of the previous comments) makes > > >> that restriction. > > >> > > >> > > > >> > Section 4.4 states that > > >> > > > >> > If the Node ID matches the current > > >> > IOAM node, it indicates that this is a looped back packet that > was > > >> > initiated by the current IOAM node, and processed accordingly. > > >> > But according to the definition of node_id in Section 5.4.2.1 of > draft-ietf-ippm-ioam-data, "Node identifier field to uniquely identify a > node within the IOAM-Namespace and associated IOAM-Domain." It appears that > simply comparing Node IDs is not sufficient to verify that the node > received its looped back packet. What is your opinion? > > >> > > >> [TM] Agreed. The following update is proposed: > > >> OLD: > > >> If the Node ID matches > > >> NEW: > > >> If the Node ID and IOAM-Namespace match > > >> > > >> > > >> > > > >> > If, as stated in Section 5, > > >> > > > >> > It [Active flag] is not intended as a replacement for existing > > >> > active OAM protocols, which may run in higher layers and make > use of > > >> > the Active flag. > > >> > Then the question, What is the purpose of the Active flag? Existing > active protocols, Fault Management and Performance Monitoring, are > identified by, for example, use of a well-known destination port number or, > in case of MPLS, Generic Associated Channel type. There's no apparent need > of using IOAM option header to identify the payload as a control message of > an active OAM protocol. On the contrary, that would likely cause more > confusion and challenges to interoperation among different implementations. > > >> > > > >> > Three cases analyzed in Section 5 require special consideration, as > these likely present the motivation for the introduction of the Active flag: > > >> > > > >> > the first use case is not really using the Active flag at all and > thus the text doesn't seem adding any value to the draft; > > >> > it is not clear what is viewed as the benefit of using the Active > flag compared with using any of the existing active OAM protocols in the > second use case. I would appreciate it if you can clarify that for me. > Since an SFC NSH network is used as an example, is it required that a > Service Function (SF) or an SF Proxy process the IOAM header with Active > flag set? Or would a Service Function Forwarder (SFF) avoid sending a > packet with the IOAM header that has an Active flag set? And can you > compare that with the procedures defined in the Active OAM for SFC draft? > > >> > My questions for the third use case described in Section 5 are the > same as above because I don't see the benefit of using a replicated data > packet (less benefits if it is truncated) compared to a special test packet. > > >> > > > >> > In my conclusion on the Active flag, I don't see any clear benefit > of introducing it and using whether in place or in addition to the existing > active OAM protocols. > > >> > > >> [TM] General response to all the Active flag comments: this was > > >> extensively discussed on the mailing list and in previous IETF > > >> meetings, and your comments about the previous versions of the > > >> document have contributed to greatly improving Section 5, which > > >> describes the main use cases of the Active flag. > > > > > > GIM>> I have to disagree with you here. I don't find the explanation > in the document sufficient to justify the introduction of another mechanism > to achieve what has already been satisfactorily addressed in IETF. Without > a more detailed specification of the problem solved by the Active flag and > how that is achieved, this mechanism appears like the answer is looking for > a question, like a loaded gun without safety. > > > > [[[TM]]] See note (1). > > > > > > >> > > >> > > >> > > >> > > > >> > I am looking forward to your feedback and the continued discussion. > > >> > > > >> > Regards, > > >> > Greg > > >> > > > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > > >> >> > > >> >> Hello IPPM, > > >> >> > > >> >> This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags and > draft-ietf-ippm-ioam-direct-export. > > >> >> > > >> >> In-situ OAM Loopback and Active Flags > > >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > > >> >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > > >> >> > > >> >> In-situ OAM Direct Exporting > > >> >> > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > > >> >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 > > >> >> > > >> >> Please provide feedback by replying to this email with your > reviews and if you think these documents are ready to progress, by > Wednesday, September 15. > > >> >> > > >> >> Best, > > >> >> Tommy & Ian > > >> >> > > >> >> _______________________________________________ > > >> >> 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 > --00000000000093c37605ce800f9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal,
thank you for uploa= ding the new version of the draft. I appreciate your consideration of my co= mments and believe that we're converging, though I have some questions = that concern me:
  • The added text sets new restrictions on the applica= bility of the Loopback flag:
=C2=A0 =C2=A0The loopback flag M= UST NOT be set if it is not guaranteed that there
=C2=A0 =C2=A0is= a return path from each of the IOAM transit and IOAM decapsulating
=C2=A0 =C2=A0nodes, or if the encapsulating node's identity is not a= vailable in
=C2=A0 =C2=A0the encapsulation header.
Can you clarify how an encapsulating node can guarantee "tha= t there is a return path from each of the IOAM transit and IOAM decapsulati= ng nodes" when setting the Loopback flag for the first=C2=A0time? I wo= uld imagine that for the first packet marked with the Loopback flag, the en= capsulating node may only know the identity of the decapsulating node, not = of every node that the marked packet will traverse. Also, what is understoo= d as "a return path"? Is that a path with the same encapsulation = as the marked with the Loopback flag packet or any type?=C2=A0
And I also have a concern about the scope of the applicability of the= Loopback flag by the "MUST NOT ...=C2=A0 if the encapsulating node= 9;s identity is not available in the encapsulation header". I believe = that among encapsulation types defined at IETF, that requirement automatica= lly excludes MPLS and SFC NSH. Depending on the interpretation of "a r= eturn path", BIER MPLS might be excluded too. As a result, it appears = that the Loopback flag maybe only applicable in an IPv6 network. If that is= the case, I cannot see a reason to use a constrained resource (space in th= e Flags field) for a very limited application.
  • An= other update clarifies that:
=
=C2=A0 =C2=A0If the ad= dress of the encapsulating
=C2=A0 =C2=A0node is not available in = the encapsulation header, then the transit/
=C2=A0 =C2=A0decapsul= ating node does not loop back a copy of the original packet.
That seems directly related to the requirement I've point= ed out above. I have a question about the next text:
  • How does a node "knows" if the address of the encapsulating= node is available? I can imagine a situation, for example, SFC NSH over an= IPv6 network. In that case, the encapsulation includes the source address,= but how the node processing Loopback flag knows that that is the address o= f the encapsulation node?
    • And the next explanation of the operation brought a new questi= on:
    =C2=A0 =C2=A0The address of the node= performing the copy operation is used as the
    =C2=A0 =C2=A0source addres= s.
    It is not clear whether it is a requirement or a recommendation. Also= , it appears that the draft assumes that a looped back packet is always enc= apsulated to convey the sender's identity. But, as I've noted earli= er, that is the case for a very few types of encapsulation defined at IETF.=
    • For our discussion = of the use of the Active flag, it seems as you've added only the follow= ing:
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0The Active flag indicates that a packet is used for= active
    =C2=A0 =C2=A0 =C2=A0measurement.=C2=A0 The term activ= e measurement in the context of this
    =C2=A0 =C2=A0 =C2=A0docu= ment is as defined in [RFC7799].
    I firmly believe that the document does not provide sufficient= information about types of active measurement in which a packet with the A= ctive flag is recommended or required to be used. In that situation, becaus= e the use of the Active flag is clearly underdefined, I suggest its definit= ion and all references be removed from the draft. Once there is a better un= derstanding of a type of active measurement that benefits from using this m= ethod, the definition of the Active flag would be appropriate.
    Regards,
    Greg
    <= div dir=3D"ltr">



    <= div class=3D"gmail_quote">
    On Wed, Oct= 13, 2021 at 5:24 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
    Minor correction - here is the correct lin= k to the updated version of the draft:
    https://datatracker.ietf.org/doc/draft-i= etf-ippm-ioam-flags/
    :)
    Cheers,
    Tal.

    On Wed, Oct 13, 2021 at 3:18 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote= :
    >
    > Dear Chairs,
    >
    > Thanks again to Greg for a very thorough review that helped us improve=
    > the quality and clarity of the draft. We believe we addressed most of<= br> > the comments, either by updating the text, or by responding to the
    > comments.
    > Some further responses can be found below, marked [[[TM]]].
    >
    > Note (1): it looks like some of the comments are basically about the > purpose of the document. Addressing these documents would probably
    > require a complete rewriting of the document with a different purpose.=
    > At this point we do not think it would make sense to align to these > comments. These comments can be easily found by searching for "(1= )"
    > through this email.
    >
    > We have posted an updated version of this draft (07):
    > https://datatracker.ietf.or= g/doc/draft-ietf-ippm-ioam-direct-export/
    >
    >
    > We believe the draft is ready to be submitted to the IESG.
    >
    > Thanks,
    > Authors.
    >
    >
    > On Fri, Oct 8, 2021 at 7:04 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > >
    > > Hi Tal,
    > > thank you for your responses to my comments and questions. Please= find my follow-up notes in-lined below under the GIM>> tag.
    > >
    > > Regards,
    > > Greg
    > >
    > > On Thu, Sep 30, 2021 at 12:42 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
    > >>
    > >> Hi Greg,
    > >>
    > >> Many thanks for the detailed comments.
    > >> Please see the responses below, as well as suggested text edi= ts in some cases.
    > >>
    > >> Cheers,
    > >> The authors.
    > >>
    > >> On Wed, Sep 8, 2021 at 1:00 AM Greg Mirsky <    gregimirsky@gmail.com> = wrote:
    > >> >
    > >> > Dear Authors, WG Chairs, and All,
    > >> > I've read the latest version of the draft and have s= everal comments and questions to share with you. I would much appreciate th= e opportunity to discuss these before I can state my support for progressin= g this draft to publication.
    > >> >
    > >> > The Abstract states that:
    > >> >
    > >> >=C2=A0 =C2=A0 In-situ Operations, Administration, and Mai= ntenance (IOAM) records
    > >> >=C2=A0 =C2=A0 operational and telemetry information in pa= ckets while they traverse
    > >> >=C2=A0 =C2=A0 a path between two points in the network. > >> >
    > >> > I think that is not a complete description of IOAM optio= ns as it excludes the Direct Export option. It might be easier to improve b= y s/records/collects/. Also, what, in your opinion, is the distinction betw= een operational and telemetry information? I think that operational informa= tion collected from remote nodes is one example of telemetry information. W= hat do you think?
    > >>
    > >> [TM] Agreed. Your proposal makes sense: s/records/collects/ > >> Regarding the difference between operational and telemetry > >> information, the way I see it "telemetry" refers to= measurements that
    > >> are being exported to an external/remote entity, whereas oper= ational
    > >> information is not measurement-based, such as the Node ID or = Interface
    > >> ID.
    > >
    > > GIM>> I think that there's no standardized definition o= f "telemetry" and "telemetry information". I share the = idea expressed in the following:
    > >
    > > Telemetry is automated communication that processes from multiple= data sources. Telemetry data improves customer experiences, monitors secur= ity, application health, quality, and performance.
    > >
    > > For different cases, the set of information referred to as teleme= try data variates. For example, CPU and buffer utilization are valuable for= virtualized environments. In other words, I understand telemetry data as i= nformation extracted from a remote system that characterizes the system'= ;s state. In any case, providing a definition would be helpful to a reader = of the document.
    >
    > [[[TM]]] This word is mentioned only once in the document (in the
    > abstract), and not sure adding a definition for this particular word > would change the readability of the document.
    >
    > >>
    > >>
    > >>
    > >> >
    > >> > nit s/the the/the/
    > >>
    > >> [TM] Agreed.
    > >>
    > >> > I think that Abstract and Introduction can be improved b= y explaining the purpose of defining the Loopback and Active flags. What ea= ch of them is intended to achieve and improve?
    > >>
    > >> [TM] The point is well-taken, and the following text will be = added to
    > >> the introduction. In order to avoid text repetition, I believ= e it
    > >> would be best not to add it to the abstract as well.
    > >>
    > >> OLD:
    > >> -
    > >> NEW:
    > >> The Loopback flag is used to request that each transit device= along
    > >> the path loops back a copy of the data packet to the sender. = The
    > >> Active flag indicates that a packet is used for active measur= ement.
    > >
    > > GIM>> Thank you for the proposed text. I have several notes= to the new text:
    > >
    > > As I understand the behavior required from a node processing the = Loopback flag, the returned packet is not the complete but truncated data p= acket.
    > > Is "active measurement" used in the context of RFC 7799= ? If "yes", does that mean that the packet is a specifically gene= rated test packet?
    >
    > [[[TM]]] These are two good points. Based on these comments the
    > following text is proposed instead.
    > NEW:
    > The Loopback flag is used to request that each transit device along > the path loops back a truncated copy of the data packet to the sender.= The
    > Active flag indicates that a packet is used for active measurement. > The term active measurement in the context of this document is as defi= ned
    > in [RFC7799].
    >
    > >>
    > >>
    > >>
    > >> > It is stated in the Introduction that:
    > >> >
    > >> >=C2=A0 =C2=A0 This document defines
    > >> >=C2=A0 =C2=A0 two new flags in the Pre-allocated and Incr= emental Trace options: the
    > >> >=C2=A0 =C2=A0 Loopback and Active flags.
    > >> > Does that mean that neither of the two flags is applicab= le in the Direct Export option? Should draft-ietf-ippm-ioam-direct-export h= ave an explicit statement regarding the applicability of the Loopback and A= ctive flags? And if any is applicable, describe the behavior of an IOAM nod= e receiving it.
    > >>
    > >> [TM] Right.
    > >> The direct exporting draft explicitly states the behavior of = each
    > >> field in the DEX option header including the flags, so there = seems to
    > >> be no need to specify flags that are supported in other optio= ns.
    > >
    > > GIM>> I'm a bit confused. Can you help me with the text= from the DEX draft that specifies the use of the Loopback and Active flags= in combination with the DEX trace option?
    >
    > [[[TM]]] The DEX option does not support the loopback and active
    > flags. That is why the DEX document does not discuss these flags. The<= br> > DEX document defines the DEX option header including all the flags
    > that are relevant to the DEX option (loopback and active are not
    > included).
    >
    > >>
    > >>
    > >> >
    > >> > In Section 4 the purpose of using the Loopback flag is e= xplained as:
    > >> >
    > >> >=C2=A0 =C2=A0 Loopback allows an IOAM encapsulating node = to trace the path to a
    > >> >=C2=A0 =C2=A0 given destination, and to receive per-hop d= ata about both the forward
    > >> >=C2=A0 =C2=A0 and the return path.
    > >> > In my previous comments, I've pointed out that the L= oopback mode is just a special case of the Direct Export option. In additio= n to that, I would appreciate your explanation of how the IOAM encapsulatin= g node receives per-hop data about the return path. How does that work, for= example, in an MPLS or SFC NSH environment?
    > >>
    > >> [TM] It is slightly similar to direct exporting, but is not a= special
    > >> case of direct exporting. In direct exporting telemetry/opera= tional
    > >> data is not pushed into the data packet, but the data packet = with the
    > >> DEX option triggers the data collection and optionally also e= xporting,
    > >> but exporting is not mandatory and may be performed later, fo= r example
    > >> by the management plane. On the other hand, a trace option wi= th the
    > >> loopback flag causes all IOAM transit nodes to push IOAM data= onto the
    > >> trace option, and also loop a copy of the packet back to the = sender.
    > >
    > > GIM>> Thank you for providing that comparison between the r= esult of processing DEX and the Loopback. As I understand it, the result of= DEX, i.e., immediate export or local processing with exporting a batch of = telemetry data, is determined by the local policy. If that is the case, the= local policy can produce the same result as for the Loopback flag, which c= ould be the default behavior for the DEX.
    >
    > [[[TM]]] Not exactly, because when using DEX in node X, the policy in<= br> > node X enables immediate exporting of the IOAM data of node X, but
    > does not enable exporting of the IOAM data of all the transit nodes > between the encapsulating node and node X. The former is possible with=
    > DEX, but the latter is only possible with Loopback. This is just one > example of why Loopback is not a special case of DEX.
    >
    > >>
    > >>
    > >>
    > >> >
    > >> > Further it Section 4, it is stated that:
    > >> >
    > >> >=C2=A0 =C2=A0 The two IOAM looped back copies are
    > >> >=C2=A0 =C2=A0 terminated by the encapsulating node.
    > >> > But I don't see any technical explanation that could= sustain that assumption. As I understand the diagram in figure 1, a transi= t node doesn't know the identity of the IOAM encapsulating node. Correc= t? If that is the case, where does the transit node direct the looped packe= t?
    > >>
    > >> [TM] As described in the draft, the loopback flag is not nece= ssarily
    > >> applicable to all possible encapsulations. The way the return= path is
    > >> defined is encapsulation-specific. The draft currently states= :
    > >>
    > >>=C2=A0 =C2=A0 Loopback can be used only if a return path from = transit nodes and
    > >>=C2=A0 =C2=A0 destination nodes towards the source (encapsulat= ing node) exists.
    > >>=C2=A0 =C2=A0 Specifically, loopback is only applicable in enc= apsulations in which
    > >>=C2=A0 =C2=A0 the identity of the encapsulating node is availa= ble in the
    > >>=C2=A0 =C2=A0 encapsulation header.=C2=A0 If an encapsulating = node receives a looped
    > >>=C2=A0 =C2=A0 back packet that was not originated from the cur= rent encapsulating
    > >>=C2=A0 =C2=A0 node, the packet is dropped.
    > >
    > > GIM>> Please help me understand, the looped back packet is = transmitted using the same encapsulation as the data packet with the Loopba= ck flag? What is the rationale? If we use MPLS LSP Ping as an example, the = response can be sent in several ways, but the default is in IP/UDP encapsul= ation as the commonly available transport. Why not use that and send the lo= oped packet over IP/UDP? I believe that the applicability of this mechanism= will be much broader.
    >
    > [[[TM]]] The rationale is to define very simple Loopback
    > functionality. Simplicity is an advantage as it enables hardware
    > implementations.
    >
    > >>
    > >>
    > >>
    > >> > It seems that the text in the last paragraph attempts to= walk around my questions. But I don't find that paragraph sufficient. = It lacks the normative language to guide a developer to produce resilient i= mplementation. For example, how to interpret:
    > >> >=C2=A0 =C2=A0 Loopback can be used only if a return path = from transit nodes and
    > >> >=C2=A0 =C2=A0 destination nodes towards the source (encap= sulating node) exists.
    > >> > That reads like a recommendation, not a requirement. As = a result, an implementation may transmit an IOAM packet with the Loopback f= ag set regardless of whether there's a return path or not. Then, how mu= st a transit node process such an IOAM packet?
    > >> >
    > >>
    > >> [TM] Right, the last response and quoted text is relevant her= e as
    > >> well. Please also note the following text from the draft:
    > >>
    > >> it is assumed that the
    > >>=C2=A0 =C2=A0 source address is available in the encapsulation= header.=C2=A0 Thus, the
    > >>=C2=A0 =C2=A0 source address of the original packet is used as= the destination
    > >>=C2=A0 =C2=A0 address in the copied packet.
    > >>
    > >> I propose to add the following sentence:
    > >> The loopback flag MUST NOT be set if it is not guaranteed tha= t there
    > >> is a return path from each of the IOAM transit and IOAM decap= sulating
    > >> nodes, or if the encapsulating node's address is not avai= lable in the
    > >> encapsulation header.
    > >
    > > GIM>> Thank you for the proposed text. I'd note that re= ferring to the "encapsulating node's address" and "sourc= e address" might be interpreted as applying only to IP. In some networ= ks, for example, BIER, the identity of the IOAM encapsulating node, BFIR, i= s known from its identifier that, in turn, can be mapped to the IP address.=
    >
    > [[[TM]]] Right. Proposed text:
    > The loopback flag MUST NOT be set if it is not guaranteed that there > is a return path from each of the IOAM transit and IOAM decapsulating<= br> > nodes, or if the encapsulating node's identity is not available in= the
    > encapsulation header.
    >
    > >>
    > >>
    > >>
    > >> > A very concerning statement I've found in Section 4.= 1
    > >> >
    > >> >=C2=A0 =C2=A0 The encapsulating node either generates syn= thetic packets with an
    > >> >=C2=A0 =C2=A0 IOAM trace option that has the Loopback fla= g set ...
    > >> > IOAM has been defined as a hybrid measurement protocol. = This statement implies that it is to be used as an active OAM protocol (all= per RFC 7799 definitions). The requirements for active OAM protocols in te= rms of their applicability and, most of, security are very different from t= hose set for a hybrid measurement protocol. I believe that extending IOAM i= nto an active mode of measurement requires more discussion and the audience= from other IETF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG.
    > >>
    > >> [TM] This draft does not define an active measurement protoco= l. The
    > >> point in the draft is that the loopback flag can be used in a= ctive
    > >> measurement packets.
    > >
    > > GIM>> I have to disagree. Per RFC 7799, the use of speciall= y constructed test packets is the primary characteristic of an active measu= rement method. By introducing the Active flag, this drat makes the IOAM int= o an active measurement protocol with all the requirements to an active mea= surement protocol to be applied.
    >
    > [[[TM]]] See note (1).
    >
    > >>
    > >> The following text edit is proposed:
    > >>
    > >> OLD:
    > >>=C2=A0 =C2=A0 The encapsulating node either generates syntheti= c packets with an
    > >>=C2=A0 =C2=A0 IOAM trace option that has the Loopback flag set= , or sets the loopack
    > >>=C2=A0 =C2=A0 flag in a subset of the in-transit data packets.= =C2=A0 Loopback is used
    > >>=C2=A0 =C2=A0 either proactively or on-demand, i.e., when a fa= ilure is detected.
    > >> NEW:
    > >>=C2=A0 =C2=A0 The loopback flag can be set in the IOAM trace o= ption either in a
    > >>=C2=A0 =C2=A0 subset of the in-transit data packets, or in syn= thetic packets that
    > >>=C2=A0 =C2=A0 are generated by the encapsulating node. Loopbac= k can be used
    > >>=C2=A0 =C2=A0 either proactively or on-demand, i.e., when a fa= ilure is detected.
    > >>
    > >> >
    > >> > The next statement explains the use case for the Loopbac= k flag:
    > >> >
    > >> >=C2=A0 =C2=A0 Loopback is used
    > >> >=C2=A0 =C2=A0 either proactively or on-demand, i.e., when= a failure is detected.
    > >> > That is the same use of ICMP and LSP Ping. What is the b= enefit of using the Loopback flag instead of readily available ICMP? Does i= t work as L2 Linktrace? I don't see that as a sufficient benefit consid= ering the complexity, exclusions, and risks associated and identified in th= e draft. It is clear that there are tools like ICMP and LSP Ping that adequ= ately address scenarios listed in the draft. Don't see any technical re= ason for the introduction of another mechanism that does not have any signi= ficant benefit compared to the existing OAM tools. Especially, considering = the limited information that is allowed to be collected using the Loopback = IOAM flag ("every transit node that processes this trace option only a= dds a single data field, which is the Hop_Lim and node_id data field")= . With the abundance of information and additional verification achieved us= ing ICMP and LSP Ping, there's even less rationale in the introduction = of this over-complex and unnatural mechanism.
    > >>
    > >> [TM] Right, as the draft says, the loopback flag is an "= ...alternative
    > >> to Traceroute, that allows the encapsulating node to receive = responses
    > >> from multiple transit nodes along the path". Indeed, it = slightly
    > >> resembles ETH-LT (Ethernet Linktrace) in the sense that a sin= gle
    > >> packet from the encapsulating node allows to quickly trace th= e entire
    > >> path, but as with IOAM in general, using the loopback flag do= es not
    > >> mandate a specific encapsulation.
    > >
    > > GIM>> Also, I must note that "pro-active" use of = the Loopback is possible only as part of the active measurement protocol. >
    > [[[TM]]] See note (1).
    >
    > >>
    > >>
    > >> >
    > >> > The last paragraph states the requirement:
    > >> >
    > >> >=C2=A0 =C2=A0 IOAM encapsulating nodes MUST NOT push an I= OAM encapsulation with the
    > >> >=C2=A0 =C2=A0 Loopback flag onto data packets that alread= y include an IOAM
    > >> >=C2=A0 =C2=A0 encapsulation.
    > >> > I couldn't find any guidance on how an IOAM node tha= t receives such invalid combination processes the packet.
    > >> >
    > >>
    > >> [TM] The current draft only specifies the flags. Specifically= in the
    > >> scenario described above, the encapsulating node does not set= the
    > >> loopback flag. This is intended to reduce the impact of poten= tial
    > >> amplification attacks.
    > >
    > > GIM>> I am still not clear about "MUST NOT push an IOA= M encapsulation with the Loopback flag" in the draft and your explanat= ion "the encapsulating node does not set the Loopback flag". As I= understand it, in the given network for the monitored data flow, only one = IOAM encapsulating node can exist. If that is correct, where does the exist= ing IOAM encapsulation come from?
    >
    > [[[TM]]] The scenario that was raised by Martin Duke in his security > review is a nested IOAM scenario, where traffic in an IOAM domain is > forwarded through another domain/tunnel, which is also IOAM-enabled. > This is explained in the draft:
    >
    >=C2=A0 =C2=A0 This requirement is intended to prevent IOAM Loopback
    >=C2=A0 =C2=A0 nesting, where looped back packets may be subject to loop= back in a
    >=C2=A0 =C2=A0 nested IOAM domain.
    >
    >
    > >>
    > >>
    > >> >
    > >> > It is assumed that the identity of the IOAM encapsulatin= g node is known to the node that is expected to sent a copy of the received= packet back. But what if that is not the case? How must that node act?
    > >>
    > >> [TM] Agreed. The following new text is proposed to be added t= o Section 4.1:
    > >> If the address of the encapsulating node is not available in = the
    > >> encapsulation header, then the transit/decapsulating node doe= s not
    > >> loop back a copy of the original packet.
    > >
    > > GIM>> I think that points to the significant limitation of = the proposed mechanism. Comparing with MPLS LSP Ping, we see that it allows= tracing the LSP even though MPLS encapsulation does not identify the ingre= ss LER while the proposed Loopback would not work at all.
    >
    > [[[TM]]] See note (1).
    >
    > >>
    > >>
    > >> > I believe that there's inconsistency between Figure = 1 and the following text in Section 4.2
    > >> >
    > >> >=C2=A0 =C2=A0 Thus, the
    > >> >=C2=A0 =C2=A0 source address of the original packet is us= ed as the destination
    > >> >=C2=A0 =C2=A0 address in the copied packet.
    > >> > It seems that the text assumes that the IOAM encapsulati= ng node adds also a network layer encapsulation. But how would it work, for= example, in SFC NSH data plane? Or MPLS?
    > >>
    > >> [TM] Right, the paragraph beginning with "Loopback can b= e used
    > >> only..." (discussed in response to one of the previous c= omments) makes
    > >> that restriction.
    > >>
    > >> >
    > >> > Section 4.4 states that
    > >> >
    > >> >=C2=A0 =C2=A0 If the Node ID matches the current
    > >> >=C2=A0 =C2=A0 IOAM node, it indicates that this is a loop= ed back packet that was
    > >> >=C2=A0 =C2=A0 initiated by the current IOAM node, and pro= cessed accordingly.
    > >> > But according to the definition of node_id in Section 5.= 4.2.1 of draft-ietf-ippm-ioam-data, "Node identifier field to uniquely= identify a node within the IOAM-Namespace and associated IOAM-Domain."= ; It appears that simply comparing Node IDs is not sufficient to verify tha= t the node received its looped back packet. What is your opinion?
    > >>
    > >> [TM] Agreed. The following update is proposed:
    > >> OLD:
    > >> If the Node ID matches
    > >> NEW:
    > >> If the Node ID and IOAM-Namespace match
    > >>
    > >>
    > >> >
    > >> > If, as stated in Section 5,
    > >> >
    > >> >=C2=A0 =C2=A0 It [Active flag] is not intended as a repla= cement for existing
    > >> >=C2=A0 =C2=A0 active OAM protocols, which may run in high= er layers and make use of
    > >> >=C2=A0 =C2=A0 the Active flag.
    > >> > Then the question, What is the purpose of the Active fla= g? Existing active protocols, Fault Management and Performance Monitoring, = are identified by, for example, use of a well-known destination port number= or, in case of MPLS, Generic Associated Channel type. There's no appar= ent need of using IOAM option header to identify the payload as a control m= essage of an active OAM protocol. On the contrary, that would likely cause = more confusion and challenges to interoperation among different implementat= ions.
    > >> >
    > >> > Three cases analyzed in Section 5 require special consid= eration, as these likely present the motivation for the introduction of the= Active flag:
    > >> >
    > >> > the first use case is not really using the Active flag a= t all and thus the text doesn't seem adding any value to the draft;
    > >> > it is not clear what is viewed as the benefit of using t= he Active flag compared with using any of the existing active OAM protocols= in the second use case. I would appreciate it if you can clarify that for = me. Since an SFC NSH network is used as an example, is it required that a S= ervice Function (SF) or an SF Proxy process the IOAM header with Active fla= g set? Or would a Service Function Forwarder (SFF) avoid sending a packet w= ith the IOAM header that has an Active flag set? And can you compare that w= ith the procedures defined in the Active OAM for SFC draft?
    > >> > My questions for the third use case described in Section= 5 are the same as above because I don't see the benefit of using a rep= licated data packet (less benefits if it is truncated) compared to a specia= l test packet.
    > >> >
    > >> > In my conclusion on the Active flag, I don't see any= clear benefit of introducing it and using whether in place or in addition = to the existing active OAM protocols.
    > >>
    > >> [TM] General response to all the Active flag comments: this w= as
    > >> extensively discussed on the mailing list and in previous IET= F
    > >> meetings, and your comments about the previous versions of th= e
    > >> document have contributed to greatly improving Section 5, whi= ch
    > >> describes the main use cases of the Active flag.
    > >
    > > GIM>> I have to disagree with you here. I don't find th= e explanation in the document sufficient to justify the introduction of ano= ther mechanism to achieve what has already been satisfactorily addressed in= IETF. Without a more detailed specification of the problem solved by the A= ctive flag and how that is achieved, this mechanism appears like the answer= is looking for a question, like a loaded gun without safety.
    >
    > [[[TM]]] See note (1).
    >
    >
    > >>
    > >>
    > >>
    > >> >
    > >> > I am looking forward to your feedback and the continued = discussion.
    > >> >
    > >> > Regards,
    > >> > Greg
    > >> >
    > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly= =3D40apple.= com@dmarc.ietf.org> wrote:
    > >> >>
    > >> >> Hello IPPM,
    > >> >>
    > >> >> This email starts a Working Group Last Call on two r= elated IOAM documents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-= direct-export.
    > >> >>
    > >> >> In-situ OAM Loopback and Active Flags
    > >> >> https://datatrack= er.ietf.org/doc/draft-ietf-ippm-ioam-flags/
    > >> >> https://da= tatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06
    > >> >>
    > >> >> In-situ OAM Direct Exporting
    > >> >> https://d= atatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
    > >> >> ht= tps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06
    > >> >>
    > >> >> Please provide feedback by replying to this email wi= th your reviews and if you think these documents are ready to progress, by = Wednesday, September 15.
    > >> >>
    > >> >> Best,
    > >> >> Tommy & Ian
    > >> >>
    > >> >> _______________________________________________
    > >> >> ippm mailing list
    > >> >>     i= ppm@ietf.org
    > >> >> https://www.ietf.org/mailman/listin= fo/ippm
    > >> >
    > >> > _______________________________________________
    > >> > ippm mailing list
    > >> > ippm@= ietf.org
    > >> > https://www.ietf.org/mailman/listinfo/i= ppm
    --00000000000093c37605ce800f9c-- From nobody Sat Oct 16 16:09:56 2021 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 986BB3A0C5A; Sat, 16 Oct 2021 16:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtgB1Pxj7VPK; Sat, 16 Oct 2021 16:09:45 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D026B3A0C57; Sat, 16 Oct 2021 16:09:44 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 5so23570535edw.7; Sat, 16 Oct 2021 16:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AE2NZKOydmcrCsm1GX46L4KpCnJv2ilp2NqYyCHW1wc=; b=DiVQzcsuKBa3aEBNsTzyt8O1PEYYXbW9OB8ROt2lE212Jqhof7Hs9dRkFphFweOYo9 HGaexN7Y5qECtJCQXFLlktbKSLxZTw1ukG0xtONZtHLjKpMw9zJMMAl3WO0h4EESTI+b cgZFsv3ZPXqZJ/qkYoVqCVdD7xXqydHOqk3iGXgFkKmYqyxLl4SpBoJNXpC8AoEFjcF5 xvKAj2gJeCB6b4TwFUp21HCeKUfkhUMTtsxG6k3s1QO+naemKT/QJ8J8HE1Dt7uEuIrn dAe6c4w1FP5pgX+Ksck6QTGroOPT891B5rI0GYJofLXtobHnKt++Op0zN4wkCFlaXiTU bLjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AE2NZKOydmcrCsm1GX46L4KpCnJv2ilp2NqYyCHW1wc=; b=8PkLWH71I02ng8wVVKVQ7B9ogtdcHkh59BUjlboLqCBXd6uW4+UMX8DqapfCcWxWYJ Of8EhCsSvbjN4+Mvo/h3Ez5fkal+ta8VNaViX8YtBWrQuYPhGQGU4fUYbL7vbtZvFiv1 bp1Iq4T5wvPvpkqfZSCospDq2YX/lHyVjxAdhjmkA5V5kcUdCMpSzthRm8IXb2Iw0Tjm 7JvFWZvQojEm7M3B8apqo2W6tg0jIb9HrULXgCGZ+ZW+MFg/Smw9/TZD/SYGEzTXxxfk hS/Jy/PMOMxKzTbzVde2S7HIfZyKDl9x8DKWykhAugFgOpEz+/iUp1tyCM/ih+mhRaKl Y+og== X-Gm-Message-State: AOAM532ud2s+30re++qrcaOJBvcyrInRjET4htfc18Of4vVbz9qcxAVJ q8NVbcWH3ODTaBixN15uqqsmp30O8KK7Ay/TPeU= X-Google-Smtp-Source: ABdhPJyqQup/quK3P4A/LUAIVWWGB4hujjgxyC+DHMFllUlb+YNHCclRZCLjiADqA6gBBZuWIbFYfxZuftv5sOLEx9w= X-Received: by 2002:a50:e106:: with SMTP id h6mr30510102edl.295.1634425782637; Sat, 16 Oct 2021 16:09:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sat, 16 Oct 2021 16:09:31 -0700 Message-ID: To: Tal Mizrahi Cc: IPPM Chairs , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000002f968e05ce8068ed" Archived-At: Subject: Re: [ippm] WGLC for IOAM Direct Exports 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: Sat, 16 Oct 2021 23:09:51 -0000 --0000000000002f968e05ce8068ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tal, thank you for posting a new version with updates resulting from our discussion. I greatly appreciate the consideration you extended to my comments. As I've mentioned, my comments are non-blocking further progress of this document. I've read the new version and have some suggestions you can consider for the next update of the draft: - I think that the added text can be a recommendation as the out-of-band transport has a lesser adverse impact on the customer traffic: It should be noted that in some networks DEX data may be exporte= d over an out-of-band network, in which a large volume of exported traffic does not compromise user traffic. - I propose a minor editorial update as follows: OLD TEXT: In this case an operator may choose to disable the exporting rate limiting. NEW TEXT: In this case an operator may choose to relax the exporting rate limiting. - A new requirement added to the Security Consideration is very useful but it seems to suggest a particular implementation: Furthermore, an IOAM node MUST gain explicit consent to export data to a receiving entity before starting to send exported data. I can imagine that an orchestrator, not an exporting telemetry information node, obtains the required consent. The sentence might be re-worded as follows: Furthermore, explicit consent to export data to a receiving entity MUST be obtained before activating the IOAM Direct Export trace option. Regards, Greg On Wed, Oct 13, 2021 at 5:12 AM Tal Mizrahi wrote: > Dear Chairs, > > We want to thank Greg for his thorough review and useful comments. > Although these comments were defined by Greg as non-blocking we made > an effort to address them either by updating the draft or by > responding to Greg's comments. > Some further responses can be found below, marked [[TM]]. > > We have posted an updated version (07) that seems to address these > comments, as well as comments received from Bernard Aboba (TSV-ART > reviewer). > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > > > We believe the draft is ready to be submitted to the IESG. > > Thanks, > Authors. > > > > On Sun, Oct 10, 2021 at 8:23 PM Greg Mirsky wrote= : > > > > Hi Tal, > > thank you for carefully considering my comments and suggestions. Please > find my follow-up notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi > wrote: > >> > >> Hi Greg, > >> > >> Many thanks for the thorough review. > >> Below you can find responses to your comments, and in some cases > >> proposed text edits. > >> > >> If there are no further comments we will update the document > accordingly. > >> > >> Thanks, > >> The authors. > >> > >> > >> On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky > wrote: > >> > > >> > Dear Authors, WG Chairs, and All, > >> > I've read the latest version of the draft and have several comments > and questions to share with you. None of these are blocking, I support > progressing this draft to publication. Please consider the notes below as > an invitation to a discussion: > >> > > >> > It seems that the characterization of the Direct Export IOAM option > in the following is not entirely accurate: > >> > > >> > The DEX option is used as a trigger to collect and/or export IOAM > data. > >> > > >> > I propose re-wording: > >> > The DEX option is used as a trigger to collect and export or only > collect locally the IOAM data. > >> > > >> > Using "exporting and/or collecting" reflects the use of the Direct > Export option type technically accurate but the order of actions is > backward. What are your thoughts? > >> > > >> > >> [TM] Right. The following text edit is proposed in the introduction. > >> > >> OLD: > >> This option is used as > >> a trigger for IOAM nodes to locally aggregate and process IOAM data= , > >> and/or to export it to a receiving entity (or entities). > >> NEW: > >> This option is used as > >> a trigger for IOAM nodes to locally aggregate and process IOAM data= , > >> and/or to export it to a receiving entity (or entities). Throughout > >> the document this functionality is referred to as collection and/or > >> exporting. > > > > GIM>> As I understand it, it is the local policy that controls the > behavior of the node receiving the IOAM DEX indicator. Similar to IPFIX, > the information can be aggregated and exported as a calculated metric, > e.g., percentile or mean value, or exported as soon as possible as > recorded. The new text is certainly better but it seems it does not expre= ss > the role of the local policy in defining the processing behavior, the > transport to be used, and the identity of the Collector. One of possible > ways could be to state that the definition of all these controls is outsi= de > the scope of the document. > > [[TM]] Right. The following text edit is proposed. > OLD: > Note that even though the IOAM Option-Type is called "Direct Export", > it depends on the deployment whether the receipt of a packet with D= EX > option type leads to the creation of another packet. Some deploymen= ts > might simply use the packet with the DEX option type to trigger loc= al > processing of OAM data. > NEW: > Note that even though the IOAM Option-Type is called "Direct Export", > it depends on the deployment whether the receipt of a packet with D= EX > option type leads to the creation of another packet. Some deploymen= ts > might simply use the packet with the DEX option type to trigger loc= al > processing of OAM data. The functionality of this local processing > is not > within the scope of this document. > > >> > >> > >> > >> > I find references to RFC 5475 and 7014 very appropriate and helpful. > But I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data.= I > think that excessive use of not only the Direct Export IAOM option but th= e > IOAM method, in general, may adversely affect a network and the > recommendations listed in RFC 5475 and 7014 are equally applicable. > >> > Similarly, the good and helpful discussion of how to practically > control the use of the Direct Export option is, in my opinion, equally > applicable to other IOAM trace options and should be in the Security > Considerations section of draft-ietf-ippm-ioam-data. > >> > >> > >> [TM] The last two comments are about draft-ietf-ippm-ioam-data, which > >> is currently in IESG review. I will take this feedback with the other > >> authors to see how we can address this input at this point. > > > > GIM>> Thanks. > >> > >> > >> > >> > The second paragraph in Section 3.1.2 is re-phrasing if not repeatin= g > what is already expressed in the last paragraph of the previous sub-secti= on > (though the limit is applied to exporting telemetry information). I think > that it can be removed without any loss to the document. > >> > >> [TM] The second par of 3.1.2 refers to *exporting*, while the last par > >> of 3.1.1 refers to *encapsulating*, so these are two complementary > >> requirements. > > > > GIM>> Is it the intention of this draft to define the encapsulation of > exported information? What if the local policy mandates the node > calculating p95 and p99 of packet delay and inter-packet delay variation? > Can you help me by describing how these metrics are encapsulated? > > [[TM]] As emphasized in the document: "The exporting method and format > are outside the scope of this document." > Section 3.1.2 actually refers (as its name suggests) to "Responding to > the DEX Trigger". > > >> > >> > >> > >> > I think that it will be helpful to provide some recommendations, > i.e., SHOULD do this, how an implementation handles the excess of packets > to export. Drop silently, drop and log notification, or try to shape that > flow? > >> > >> [TM] Assuming an amplification scenario, a large number of packets may > >> be dropped, so logging each drop may defeat the purpose. A drop > >> counter may be a good idea here, but this document does not really > >> define counter requirements in general, so it seems like more of an > >> implementation-specific aspect, or possibly can be considered as part > >> of the YANG model. > > > > GIM>> I am still struggling to understand how IOAM DEX triggers > amplification. Can you add more details, steps to help me understand it? > > [[TM]] This is explained in the document: > > The amplification effect of DEX may be worse in wide area networks in > which there are multiple IOAM domains. For example, if DEX is used > in IOAM domain 1 for exporting IOAM data to a receiving entity, then > the exported packets of domain 1 can be forwarded through IOAM domain > 2, in which they are subject to DEX. The exported packets of domain > 2 may in turn be forwarded through another IOAM domain (or through > domain 1), and theoretically this recursive amplification may > continue infinitely. > > > >> > >> > >> > I was really puzzled by this requirement in Section 3.1.2 > >> > > >> > Exported packets SHOULD NOT be exported over a path or a tunnel > that > >> > > >> > is subject to IOAM direct exporting. > >> > > >> > I hope you can clarify it for me. > >> > >> > >> [TM] As explained later in that paragraph: "This requirement is > >> intended to prevent nested exporting and/or exporting loops." > >> This was thoroughly discussed in the working group, and came out of > >> the security-related review. > > > > GIM>> If the definition of exporting, including the encapsulation, > choice of transport, and the Collector is outside the scope, then this > statement, in my opinion, should be removed. If all these issues are in t= he > scope, then there is more, much more information that is missing. > > [[TM]] As explained in the abstract, "The exporting method and format > are outside the scope of this document." > However, the current document has a paragraph that defines security > requirements for the export method. These requirements came out of the > very detailed security discussions we had with Martin Duke and Mirja > K=C3=BChlewind. > > >> > >> > >> > > >> > This requirement > >> > > >> > Furthermore, IOAM encapsulating > >> > nodes that can identify a packet as an IOAM exported packet MUST > NOT > >> > push a DEX option into such a packet. > >> > brings up questions: > >> > > >> > How can a node identify a packet as the IOAM exported packet? > >> > >> [TM] The requirement means that if an encapsulating node's ACL can > >> detect exported packets, then DEX should not be applied. > > > > GIM>> I think that whether this belongs in the document depends on the > answer to my question above - what is in the scope of this document. > > [[TM]] See the response above. > > >> > >> > >> > What should be done if the IOAM exported packet contains the IOAM > header with the DEX option? > >> > >> [TM] The current document does not require an IOAM transit node to > >> parse beyond the (external) IOAM encapsulation if there are nested > >> IOAM encapsulations. > > > > GIM>> Same, as above - need to clarify the scope of the document first. > >> > >> > >> > > >> > What is special about the decapsulating node that is not DEX-capable= ? > >> > > >> > A decapsulating node that does not support the DEX option > >> > MUST remove it, along with any other IOAM options carried in the > >> > packet if such exist. > >> > Shouldn't that be a general behavior of a decapsulating IOAM node? > >> > >> [TM] Right. The following text edit is proposed: > >> > >> OLD: > >> A transit IOAM node that does not support the DEX option SHOULD > >> ignore it. A decapsulating node that does not support the DEX opti= on > >> MUST remove it, along with any other IOAM options carried in the > >> packet if such exist. > >> NEW: > >> A transit or decapsulating IOAM node that does not support the DEX > >> option SHOULD > >> ignore it. Note that as per target=3D"I-D.ietf-ippm-ioam-data"/> a > >> decapsulating node removes the IOAM encapsulation and all its IOAM > options, > >> and specifically in the case where one of these options is a > >> (possibly unknown) > >> DEX option. > > > > GIM>> Why is it SHOULD? In what situation a node MAY act on the DEX? > > Right. > Proposed text: > A transit or decapsulating IOAM node that receives an > unknown IOAM option > type ignores it (as defined in target=3D"I-D.ietf-ippm-ioam-data"/>), and > specifically nodes that do not support the DEX option ignore it= . > Note that as per a > decapsulating node removes the IOAM encapsulation and all > its IOAM options, > and specifically in the case where one of these options is a > (possibly unknown) DEX option. > > >> > >> > >> > >> > > >> > The format of the first four-octet word in Figure 2 is different fro= m > the format defined in draft-ietf-ippm-ioam-data: > >> > > >> > 0 1 2 3 > >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > | Namespace-ID |NodeLen | Flags | RemainingLen| > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > | IOAM-Trace-Type | Reserved | > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > Is this intentional? If it is, how does an implementation know which > format to use? > >> > >> [TM] Each IOAM Option-Type has a different header format. The current > >> document defines a new Option-Type, which was not defined in > >> draft-ietf-ippm-ioam-data. > >> The IOAM-Type field in the lower layer header determines which > >> Option-Type is used and how its header should be parsed. > > > > GIM>> Thank you for the clarification. Is that the intention to start > new drafts to define the DEX IOAM Option-Type separately? > > [[TM]] Right. IOAM-Type values are defined in per encapsulation > drafts, such as draft-ietf-ippm-ioam-ipv6-options. > > > >> > >> > >> > >> > > >> > It is stated in the draft that: > >> > > >> > The length of the DEX option is at least 8 octets. > >> > > >> > But the figure 2 in the draft does not include any field that > reflects the length of the IOAM option. Is that because the figure is out > of sync? If not, how can an implementation verify the length? Also, what = is > the behavior if the length is less than 8 octets? > >> > > >> > >> [TM] Quoting the draft: > >> > >> The existence of the optional fields is > >> indicated by the corresponding flags in the Extension-Flags field. > >> ... > >> Thus, the Extension-Flags field explicitly indicates > >> the length of the DEX option. > >> > >> > >> > RE: PerformanceConsiderations > >> > > >> > I agree with you that a DEX-encapsulating node and DEX-transit nodes > must have rate-limiting controls (as noted earlier, the behavior of the > transit node needs more detailed specification). But I think that the > document should also note that exported packets could be sent over the > network out-of-band, relative to the monitored flow. As a result, the > impact of packets carrying telemetry information might be not direct and > harmful to the data flow. I see that as one of the important benefits of > the Direct Export method transporting on-path telemetry information. > >> > > >> > >> [TM] Right. The following new text is proposed: > >> > >> It should be noted that in some networks DEX data may be exported over > >> an out-of-band network, in which a large volume of exported traffic > >> does not compromise user traffic. In this case an operator may choose > >> to disable the exporting rate limiting. > > > > GIM>> I think that the text can be stronger, recommending that > information is exported out-of-band and explaining the interpretation of > out-of-band in the case of IOAM. > >> > >> > >> > > >> > Regards, > >> > Greg > >> > > >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> >> > >> >> Hello IPPM, > >> >> > >> >> This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags and > draft-ietf-ippm-ioam-direct-export. > >> >> > >> >> In-situ OAM Loopback and Active Flags > >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > >> >> > >> >> In-situ OAM Direct Exporting > >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export= / > >> >> > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-= 06 > >> >> > >> >> Please provide feedback by replying to this email with your reviews > and if you think these documents are ready to progress, by Wednesday, > September 15. > >> >> > >> >> Best, > >> >> Tommy & Ian > >> >> > >> >> _______________________________________________ > >> >> 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 > --0000000000002f968e05ce8068ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tal,
    thank you for posting a new version = with updates resulting from our discussion. I greatly appreciate the consid= eration you extended to my comments. As I've=C2=A0mentioned, my comment= s are non-blocking further progress of this document. I've read the new= version and have some suggestions you can consider for the next update of = the draft:
    • I think that the added text can be a recommend= ation as the out-of-band transport has a lesser adverse impact on the custo= mer traffic:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It should be= noted that in some networks DEX data may be exported
    =C2=A0 = =C2=A0 =C2=A0over an out-of-band network, in which a large volume of export= ed
    =C2=A0 =C2=A0 =C2=A0traffic does not compromise user traff= ic.=C2=A0=C2=A0
    • I propose a minor editorial u= pdate as follows:
    OLD TEXT:
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0In this case an operator
    =C2=A0 =C2=A0 = =C2=A0may choose to disable the exporting rate limiting.
    NE= W TEXT:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In this cas= e an operator
    =C2=A0 =C2=A0 =C2=A0may choose to relax the exp= orting rate limiting.
    • A new requirement added to th= e Security Consideration is very useful but it seems to suggest a particula= r implementation:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fu= rthermore, an IOAM node MUST
    <= div>=C2=A0 =C2=A0 =C2=A0gain explici= t consent to export data to a receiving entity before
    =C2=A0 = =C2=A0 =C2=A0starting to send exported data.
    <= /div>
    =
    I = can imagine that an orchestrator, not an exporting telemetry information no= de, obtains the required consent. The sentence might be re-worded as follow= s:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Furthermore, explicit consent to export data to a receiving en= tity
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be= obtained before activating the IOAM Direct Export trace
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option.

    Regards,=
    Greg

    On Wed, Oct 13, 2021 at 5:12 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wr= ote:
    Dear Chairs= ,

    We want to thank Greg for his thorough review and useful comments.
    Although these comments were defined by Greg as non-blocking we made
    an effort to address them either by updating the draft or by
    responding to Greg's comments.
    Some further responses can be found below, marked [[TM]].

    We have posted an updated version (07) that seems to address these
    comments, as well as comments received from Bernard Aboba (TSV-ART
    reviewer).
    https://datatracker.ietf.org/doc= /draft-ietf-ippm-ioam-direct-export/


    We believe the draft is ready to be submitted to the IESG.

    Thanks,
    Authors.



    On Sun, Oct 10, 2021 at 8:23 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    >
    > Hi Tal,
    > thank you for carefully considering my comments and suggestions. Pleas= e find my follow-up notes in-lined below under the GIM>> tag.
    >
    > Regards,
    > Greg
    >
    > On Thu, Sep 30, 2021 at 12:17 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com>= wrote:
    >>
    >> Hi Greg,
    >>
    >> Many thanks for the thorough review.
    >> Below you can find responses to your comments, and in some cases >> proposed text edits.
    >>
    >> If there are no further comments we will update the document accor= dingly.
    >>
    >> Thanks,
    >> The authors.
    >>
    >>
    >> On Wed, Sep 8, 2021 at 1:01 AM Greg Mirsky <gregimirsky@gmail.com> wrote= :
    >> >
    >> > Dear Authors, WG Chairs, and All,
    >> > I've read the latest version of the draft and have severa= l comments and questions to share with you. None of these are blocking, I s= upport progressing this draft to publication. Please consider the notes bel= ow as an invitation to a discussion:
    >> >
    >> > It seems that the characterization of the Direct Export IOAM = option in the following is not entirely accurate:
    >> >
    >> > The DEX option is used as a trigger to collect and/or export = IOAM data.
    >> >
    >> > I propose re-wording:
    >> > The DEX option is used as a trigger to collect and export or = only collect locally the IOAM data.
    >> >
    >> > Using "exporting and/or collecting" reflects the us= e of the Direct Export option type technically accurate but the order of ac= tions is backward. What are your thoughts?
    >> >
    >>
    >> [TM] Right. The following text edit is proposed in the introductio= n.
    >>
    >> OLD:
    >>=C2=A0 =C2=A0 This option is used as
    >>=C2=A0 =C2=A0 a trigger for IOAM nodes to locally aggregate and pro= cess IOAM data,
    >>=C2=A0 =C2=A0 and/or to export it to a receiving entity (or entitie= s).
    >> NEW:
    >>=C2=A0 =C2=A0 This option is used as
    >>=C2=A0 =C2=A0 a trigger for IOAM nodes to locally aggregate and pro= cess IOAM data,
    >>=C2=A0 =C2=A0 and/or to export it to a receiving entity (or entitie= s). Throughout
    >>=C2=A0 =C2=A0 the document this functionality is referred to as col= lection and/or
    >> exporting.
    >
    > GIM>> As I understand it, it is the local policy that controls t= he behavior of the node receiving the IOAM DEX indicator. Similar to IPFIX,= the information can be aggregated and exported as a calculated metric, e.g= ., percentile or mean value, or exported as soon as possible as recorded. T= he new text is certainly better but it seems it does not express the role o= f the local policy in defining the processing behavior, the transport to be= used, and the identity of the Collector. One of possible ways could be to = state that the definition of all these controls is outside the scope of the= document.

    [[TM]] Right. The following text edit is proposed.
    OLD:
    Note that even though the IOAM Option-Type is called "Direct Export&qu= ot;,
    =C2=A0 =C2=A0 =C2=A0 it depends on the deployment whether the receipt of a = packet with DEX
    =C2=A0 =C2=A0 =C2=A0 option type leads to the creation of another packet. S= ome deployments
    =C2=A0 =C2=A0 =C2=A0 might simply use the packet with the DEX option type t= o trigger local
    =C2=A0 =C2=A0 =C2=A0 processing of OAM data.
    NEW:
    Note that even though the IOAM Option-Type is called "Direct Export&qu= ot;,
    =C2=A0 =C2=A0 =C2=A0 it depends on the deployment whether the receipt of a = packet with DEX
    =C2=A0 =C2=A0 =C2=A0 option type leads to the creation of another packet. S= ome deployments
    =C2=A0 =C2=A0 =C2=A0 might simply use the packet with the DEX option type t= o trigger local
    =C2=A0 =C2=A0 =C2=A0 processing of OAM data. The functionality of this loca= l processing is not
    =C2=A0 within the scope of this document.

    >>
    >>
    >>
    >> > I find references to RFC 5475 and 7014 very appropriate and h= elpful. But I don't see these RFCs being referenced in draft-ietf-ippm-= ioam-data. I think that excessive use of not only the Direct Export IAOM op= tion but the IOAM method, in general, may adversely affect a network and th= e recommendations listed in RFC 5475 and 7014 are equally applicable.
    >> > Similarly, the good and helpful discussion of how to practica= lly control the use of the Direct Export option is, in my opinion, equally = applicable to other IOAM trace options and should be in the Security Consid= erations section of draft-ietf-ippm-ioam-data.
    >>
    >>
    >> [TM] The last two comments are about draft-ietf-ippm-ioam-data, wh= ich
    >> is currently in IESG review. I will take this feedback with the ot= her
    >> authors to see how we can address this input at this point.
    >
    > GIM>> Thanks.
    >>
    >>
    >>
    >> > The second paragraph in Section 3.1.2 is re-phrasing if not r= epeating what is already expressed in the last paragraph of the previous su= b-section (though the limit is applied to exporting telemetry information).= I think that it can be removed without any loss to the document.
    >>
    >> [TM] The second par of 3.1.2 refers to *exporting*, while the last= par
    >> of 3.1.1 refers to *encapsulating*, so these are two complementary=
    >> requirements.
    >
    > GIM>> Is it the intention of this draft to define the encapsulat= ion of exported information? What if the local policy mandates the node cal= culating p95 and p99 of packet delay and inter-packet delay variation? Can = you help me by describing how these metrics are encapsulated?

    [[TM]] As emphasized in the document: "The exporting method and format=
    are outside the scope of this document."
    Section 3.1.2 actually refers (as its name suggests) to "Responding to=
    the DEX Trigger".

    >>
    >>
    >>
    >> > I think that it will be helpful to provide some recommendatio= ns, i.e., SHOULD do this, how an implementation handles the excess of packe= ts to export. Drop silently, drop and log notification, or try to shape tha= t flow?
    >>
    >> [TM] Assuming an amplification scenario, a large number of packets= may
    >> be dropped, so logging each drop may defeat the purpose. A drop >> counter may be a good idea here, but this document does not really=
    >> define counter requirements in general, so it seems like more of a= n
    >> implementation-specific aspect, or possibly can be considered as p= art
    >> of the YANG model.
    >
    > GIM>> I am still struggling to understand how IOAM DEX triggers = amplification. Can you add more details, steps to help me understand it?
    [[TM]] This is explained in the document:

    =C2=A0 =C2=A0The amplification effect of DEX may be worse in wide area netw= orks in
    =C2=A0 =C2=A0which there are multiple IOAM domains.=C2=A0 For example, if D= EX is used
    =C2=A0 =C2=A0in IOAM domain 1 for exporting IOAM data to a receiving entity= , then
    =C2=A0 =C2=A0the exported packets of domain 1 can be forwarded through IOAM= domain
    =C2=A0 =C2=A02, in which they are subject to DEX.=C2=A0 The exported packet= s of domain
    =C2=A0 =C2=A02 may in turn be forwarded through another IOAM domain (or thr= ough
    =C2=A0 =C2=A0domain 1), and theoretically this recursive amplification may<= br> =C2=A0 =C2=A0continue infinitely.


    >>
    >>
    >> > I was really puzzled by this requirement in Section 3.1.2
    >> >
    >> >=C2=A0 =C2=A0 Exported packets SHOULD NOT be exported over a p= ath or a tunnel that
    >> >
    >> >=C2=A0 =C2=A0 is subject to IOAM direct exporting.
    >> >
    >> > I hope you can clarify it for me.
    >>
    >>
    >> [TM] As explained later in that paragraph: "This requirement = is
    >> intended to prevent nested exporting and/or exporting loops."=
    >> This was thoroughly discussed in the working group, and came out o= f
    >> the security-related review.
    >
    > GIM>> If the definition of exporting, including the encapsulatio= n, choice of transport, and the Collector is outside the scope, then this s= tatement, in my opinion, should be removed. If all these issues are in the = scope, then=C2=A0 there is more, much more information that is missing.

    [[TM]] As explained in the abstract, "The exporting method and format<= br> are outside the scope of this document."
    However, the current document has a paragraph that defines security
    requirements for the export method. These requirements came out of the
    very detailed security discussions we had with Martin Duke and Mirja
    K=C3=BChlewind.

    >>
    >>
    >> >
    >> > This requirement
    >> >
    >> >=C2=A0 =C2=A0 Furthermore, IOAM encapsulating
    >> >=C2=A0 =C2=A0 nodes that can identify a packet as an IOAM expo= rted packet MUST NOT
    >> >=C2=A0 =C2=A0 push a DEX option into such a packet.
    >> > brings up questions:
    >> >
    >> > How can a node identify a packet as the IOAM exported packet?=
    >>
    >> [TM] The requirement means that if an encapsulating node's ACL= can
    >> detect exported packets, then DEX should not be applied.
    >
    > GIM>> I think that whether this belongs in the document depends = on the answer to my question above - what is in the scope of this document.=

    [[TM]] See the response above.

    >>
    >>
    >> > What should be done if the IOAM exported packet contains the = IOAM header with the DEX option?
    >>
    >> [TM] The current document does not require an IOAM transit node to=
    >> parse beyond the (external) IOAM encapsulation if there are nested=
    >> IOAM encapsulations.
    >
    > GIM>> Same, as above - need to clarify the scope of the document= first.
    >>
    >>
    >> >
    >> > What is special about the decapsulating node that is not DEX-= capable?
    >> >
    >> >=C2=A0 =C2=A0 A decapsulating node that does not support the D= EX option
    >> >=C2=A0 =C2=A0 MUST remove it, along with any other IOAM option= s carried in the
    >> >=C2=A0 =C2=A0 packet if such exist.
    >> > Shouldn't that be a general behavior of a decapsulating I= OAM node?
    >>
    >> [TM] Right. The following text edit is proposed:
    >>
    >> OLD:
    >>=C2=A0 =C2=A0 A transit IOAM node that does not support the DEX opt= ion SHOULD
    >>=C2=A0 =C2=A0 ignore it.=C2=A0 A decapsulating node that does not s= upport the DEX option
    >>=C2=A0 =C2=A0 MUST remove it, along with any other IOAM options car= ried in the
    >>=C2=A0 =C2=A0 packet if such exist.
    >> NEW:
    >>=C2=A0 =C2=A0 A transit or decapsulating IOAM node that does not su= pport the DEX
    >> option SHOULD
    >>=C2=A0 =C2=A0 ignore it.=C2=A0 Note that as per <xref target=3D&= quot;I-D.ietf-ippm-ioam-data"/> a
    >>=C2=A0 =C2=A0 decapsulating node removes the IOAM encapsulation and= all its IOAM options,
    >>=C2=A0 =C2=A0 and specifically in the case where one of these optio= ns is a
    >> (possibly unknown)
    >>=C2=A0 =C2=A0 DEX option.
    >
    > GIM>> Why is it SHOULD? In what situation a node MAY act on the = DEX?

    Right.
    Proposed text:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A transit or decapsulating IOAM node tha= t receives an
    unknown IOAM option
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type ignores it (as defined in <xref<= br> target=3D"I-D.ietf-ippm-ioam-data"/>), and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifically nodes that do not support t= he DEX option ignore it.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that as per <xref target=3D"= ;I-D.ietf-ippm-ioam-data"/> a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 decapsulating node removes the IOAM enca= psulation and all
    its IOAM options,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and specifically in the case where one o= f these options is a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (possibly unknown) DEX option.

    >>
    >>
    >>
    >> >
    >> > The format of the first four-octet word in Figure 2 is differ= ent from the format defined in draft-ietf-ippm-ioam-data:
    >> >
    >> >=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
    >> >=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
    >> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
    >> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 Namespace-ID=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|NodeLen=C2=A0 | Flags | RemainingLen| >> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
    >> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0IOAM-Trace-Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0|
    >> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
    >> > Is this intentional? If it is, how does an implementation kno= w which format to use?
    >>
    >> [TM] Each IOAM Option-Type has a different header format. The curr= ent
    >> document defines a new Option-Type, which was not defined in
    >> draft-ietf-ippm-ioam-data.
    >> The IOAM-Type field in the lower layer header determines which
    >> Option-Type is used and how its header should be parsed.
    >
    > GIM>> Thank you for the clarification. Is that the intention to = start new drafts to define the DEX IOAM Option-Type separately?

    [[TM]] Right. IOAM-Type values are defined in per encapsulation
    drafts, such as draft-ietf-ippm-ioam-ipv6-options.


    >>
    >>
    >>
    >> >
    >> > It is stated in the draft that:
    >> >
    >> > The length of the DEX option is at least 8 octets.
    >> >
    >> > But the figure 2 in the draft does not include any field that= reflects the length of the IOAM option. Is that because the figure is out = of sync? If not, how can an implementation verify the length? Also, what is= the behavior if the length is less than 8 octets?
    >> >
    >>
    >> [TM] Quoting the draft:
    >>
    >>=C2=A0 =C2=A0 The existence of the optional fields is
    >>=C2=A0 =C2=A0 indicated by the corresponding flags in the Extension= -Flags field.
    >>=C2=A0 =C2=A0 ...
    >>=C2=A0 =C2=A0 Thus, the Extension-Flags field explicitly indicates<= br> >>=C2=A0 =C2=A0 the length of the DEX option.
    >>
    >>
    >> > RE: PerformanceConsiderations
    >> >
    >> > I agree with you that a DEX-encapsulating node and DEX-transi= t nodes must have rate-limiting controls (as noted earlier, the behavior of= the transit node needs more detailed specification). But I think that the = document should also note that exported packets could be sent over the netw= ork out-of-band, relative to the monitored flow. As a result, the impact of= packets carrying telemetry information might be not direct and harmful to = the data flow. I see that as one of the important benefits of the Direct Ex= port method transporting on-path telemetry information.
    >> >
    >>
    >> [TM] Right. The following new text is proposed:
    >>
    >> It should be noted that in some networks DEX data may be exported = over
    >> an out-of-band network, in which a large volume of exported traffi= c
    >> does not compromise user traffic. In this case an operator may cho= ose
    >> to disable the exporting rate limiting.
    >
    > GIM>> I think that the text can be stronger, recommending that i= nformation is exported out-of-band and explaining the interpretation of out= -of-band in the case of IOAM.
    >>
    >>
    >> >
    >> > Regards,
    >> > Greg
    >> >
    >> > On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=3D40apple.com@dma= rc.ietf.org> wrote:
    >> >>
    >> >> Hello IPPM,
    >> >>
    >> >> This email starts a Working Group Last Call on two relate= d IOAM documents, draft-ietf-ippm-ioam-flags and draft-ietf-ippm-ioam-direc= t-export.
    >> >>
    >> >> In-situ OAM Loopback and Active Flags
    >> >> https://datatracker.ie= tf.org/doc/draft-ietf-ippm-ioam-flags/
    >> >> https://datatra= cker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06
    >> >>
    >> >> In-situ OAM Direct Exporting
    >> >> https://datatr= acker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
    >> >> https:/= /datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 >> >>
    >> >> Please provide feedback by replying to this email with yo= ur reviews and if you think these documents are ready to progress, by Wedne= sday, September 15.
    >> >>
    >> >> Best,
    >> >> Tommy & Ian
    >> >>
    >> >> _______________________________________________
    >> >> ippm mailing list
    >> >> ippm@i= etf.org
    >> >> https://www.ietf.org/mailman/listinfo/ip= pm
    >> >
    >> > _______________________________________________
    >> > ippm mailing list
    >> > ippm@ietf.= org
    >> > https://www.ietf.org/mailman/listinfo/ippm
    --0000000000002f968e05ce8068ed-- From nobody Tue Oct 19 12:19:10 2021 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 2F71A3A0B03; Tue, 19 Oct 2021 12:17:43 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163467106311.32433.7900708948786530983@ietfa.amsl.com> Date: Tue, 19 Oct 2021 12:17:43 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-data-integrity-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: Tue, 19 Oct 2021 19:17:44 -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 : Integrity of In-situ OAM Data Fields Authors : Frank Brockners Shwetha Bhandari Tal Mizrahi Filename : draft-ietf-ippm-ioam-data-integrity-00.txt Pages : 16 Date : 2021-10-19 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. IETF protocols require features to ensure their security. This document describes the integrity protection of IOAM data fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data-integrity/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 19 12:19:21 2021 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 948293A0CC8; Tue, 19 Oct 2021 12:18:35 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163467111556.5058.15739530670737001778@ietfa.amsl.com> Date: Tue, 19 Oct 2021 12:18:35 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-deployment-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: Tue, 19 Oct 2021 19:18:36 -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 Deployment Authors : Frank Brockners Shwetha Bhandari Daniel Bernier Tal Mizrahi Filename : draft-ietf-ippm-ioam-deployment-00.txt Pages : 23 Date : 2021-10-19 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides best current practices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-deployment/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 19 15:32:17 2021 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 C62FE3A0A4D for ; Tue, 19 Oct 2021 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09PA1_v5egdx for ; Tue, 19 Oct 2021 15:32:02 -0700 (PDT) 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 3CB573A0A3F for ; Tue, 19 Oct 2021 15:32:02 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 19JMMug3047583 for ; Tue, 19 Oct 2021 18:31:59 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 3bt6rv09s4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Oct 2021 18:31:59 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19JMVxYg012174 for ; Tue, 19 Oct 2021 18:31:59 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19JMVuqn012126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 19 Oct 2021 18:31:57 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id BDC4F400576C for ; Tue, 19 Oct 2021 22:31:56 +0000 (GMT) Received: from GAALPA1MSGED2BA.ITServices.sbc.com (unknown [135.50.89.126]) by zlp30485.vci.att.com (Service) with ESMTP id 7C55240056DB for ; Tue, 19 Oct 2021 22:31:56 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Tue, 19 Oct 2021 18:31:56 -0400 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Tue, 19 Oct 2021 18:31:56 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.171) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Tue, 19 Oct 2021 18:31:54 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dzQ9pimrqjeMDIgqLtaOvcSJChidlE1+g3TH4nx3plDWVHbRTVi3zGwdqd44uq67Xo/GlqLHQ6IOAhN73u9OMzXwi16lLYCGP/3DnllVoPaUK3QVmu6/YAEehokQflIXbOuliMAVwtsykNbJAu3a79qg36mH6zpCe0C/fesIIoJd5G55eyyw3OqGrMQkyniTIgQSPB+NvkhS8daEU0jZGED0AlU726YTixV768F93NJBelwYIpYoqsBbpSO5csCLCEbeRSv4l+0KMbE19hkbpSBoLiLYyEriEsKSjlYBjtif4jf2Ppa3p/w50LFC11Vcy7NjbWR4tS16Z07tapoAgg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RY6zmVj+crB3lPr07BzvkrEMprMT4lT1acReoI0/Pec=; b=MNveQTtndOmKcMUlGoMyYpLpJj9LYjTiJMo5EM6jwYI4tFQ+EKfIFY8NvG5ozE2WGLjDkNlAoqrZmR3EJxAoEfCUKtHsdan9AFph85gQttzAlrBSBLUHwKvDQ7PguuHLbtr/7reiWIE3BJXEAl0EmB+6wfdOJn6+nMgQatd80h/kcLyws1xGCbCm+ZgIAXPR7w5S/XW3sVcR0yMMunILqk3dIEp4nPUwVshK3XHksKjywIBl46WAoVfBrDzTtM6gumpUi/s75E6/TjxNw+2M4tYdFWaEO3fO0nOPwMETA3Wxzl5IC+lM0bTIOrv5ty6LVsUHcWZo/QwnOhE752vwnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RY6zmVj+crB3lPr07BzvkrEMprMT4lT1acReoI0/Pec=; b=apH9ki2XJfeLfs8o4R4GJDb/mM+yDJS2aeksWQnXuttONaqrynmkMiVkIAE8+xL+pXe6wKtpqV4YhVDamgZE7p6G7P5Wb1yhjxFcGECoE6JuuFFTFgmIGiKhFRhGA1fpIlrc4s8afy/1GrFzEr736g7Hu5ykrcR+C9tSEOpgg7g= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by SJ0PR02MB7629.namprd02.prod.outlook.com (2603:10b6:a03:32c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Tue, 19 Oct 2021 22:31:53 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%7]) with mapi id 15.20.4608.018; Tue, 19 Oct 2021 22:31:53 +0000 From: "MORTON JR., AL" To: IETF IPPM WG Thread-Topic: Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AdfFK9goV64vTz3BSZKe4qsMDY7MVg== Date: Tue, 19 Oct 2021 22:31:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be255baa-71b4-43ad-b760-08d993504046 x-ms-traffictypediagnostic: SJ0PR02MB7629: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0KN5QEMlkoxYR3FRJiQ6ePRKCvV7Kab50HiBShJTlW8JoDLH0QopQykqlH3giOfL6qCDOEMHoNtnMo1RS5saSLsXZ6SlV17G7suwLOX86sF1HGLIzpb4Dh8lPbttj2uihu2ZLGy9SDrfhhkGZFLWwzWDYACMjcu5eIfNnof1X4Iu0wwkZRcmymZUhJDuryFFx+eGWU93AAhNwbYitSds2QyoF3f7rsv0cctmB6r2k7jCMvyXCFv/M6nDmYH5IreOiT/M4Qwt0NT14Dz4lcIVzg31UMdW1MLNe2LpWKl7lchnraZSODdr5Nha26YkeqCU/Cj0Sjl/8ANd0hYhZw/Vd2dvakhQhHLcvGp+iZfhcL5byOemPF34KAn4A6lyBEp/celz130ieImWFBCJqvieb4/rsDFTeu6fYtIOUQnPkoGXLdFUNEQwBndpHNli0BhyihHT5s3jGhqcLYw6QMgcC+4MjtNHb7W8PufsdjETQF8oAqdU1C6tE7Cw39mq9qwtn5MHqKjFrThqIt+O6INWXJEaBUiKjkuiH716+UIe7vqwnd+KW7+ok4CEEh/VNB+Dr5Hl+MVyrLLQ31vduhYu9glXQQ1Lc5nvI66Lp38OItcUMR3HarkzpgWjPHVC3H1DJVAy89if5Y0SEg+dZQwSYEcAPlYpQngnODayJQVILMlssACWfaIpz2RdUrg+/HFdn+zT6Osm2jNPqD74BL85tjaiWDlRnA/EkYQfUqYVCzcRDr3KoyiQOzTeFNhPbXpXN9xhfsoRvtucJ7C3ueMO711Ov0uRS2d66p4NW1otkDw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(26005)(6916009)(9686003)(38070700005)(66556008)(6506007)(186003)(5660300002)(83380400001)(52536014)(55016002)(7696005)(122000001)(2906002)(38100700002)(71200400001)(316002)(86362001)(82202003)(33656002)(966005)(508600001)(82960400001)(76116006)(66476007)(64756008)(66446008)(8936002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Iesa4F22AH1R03SDZe5mQ35fJTNShLlmEYSIs7Q6dR69q8S13ipCje4gdk3N?= =?us-ascii?Q?aX0rhWdEG8AjGeXYH13RylXIdahEHMAQFDCIvM3MJDT3AjPgN05rD+ewD78u?= =?us-ascii?Q?sT0vpI2SgmO5RDb6VfrJhDQa+lQUJHdsTjQeTUpzc3SfrhIJwlPzX/Fgx2xp?= =?us-ascii?Q?09Gr2A3ETJWwNYP3ZNtaMYh3s0oJeIvBoi4ltOPBzQu+lR7L3QSRazSgbbqH?= =?us-ascii?Q?rK/6Rs9b54me2UvCWqFge3BY3sMB6VYtqzvs7pa6Awy47nVyabfNZzTZKOtg?= =?us-ascii?Q?dZR8mD4piAWXNo1MLoRlu3V18o+waNQjRZYrzVsPMdx3hcGsYGcDeWP/M0I2?= =?us-ascii?Q?yA9d/fMYcqmt/Af2/sU3XydmWHA1eIDcpscVSYrCDLIBtGcmzj+gPD71g2Ih?= =?us-ascii?Q?ec8SoU81qqnUXdtiizA0xywBdhQWhsPkXyWstApra6syXIhqisspaBkPn/xq?= =?us-ascii?Q?dcy1WCwNSbRgGTIwfzouQFi4B0298E6+lCT568QygZIywYWXVRyY4DIwkiUn?= =?us-ascii?Q?XnnapM9zd6G64B3AVZ9IqK20UdBfwTTkffMBvMknCrTGlc7byZbujBfYwl65?= =?us-ascii?Q?vag24sXNN3+yUsN/Z536a9gRfX+AiXXOdRv58MKJjssKO9Hhn5z6YgUpaUU4?= =?us-ascii?Q?gNEdchNzpx8L8H5Hh13qhgBbGATXxkMZUpVSVilKPhD1wASBcHUyWqZ7sWE5?= =?us-ascii?Q?6EYHD0s4CA3BgcvhEnynVjeQIl/l+hoS62VXC9MLPq7UosAf6Ekx69Upacb7?= =?us-ascii?Q?Qnm5kfwmQRo0QB4Er/MbczVSK7otfKSZqcTE6IeuCXD95f0Hxo+dJlqcFcsw?= =?us-ascii?Q?ZHcNf24j/+vQqCWtTPd393l6s/mACUK8arGL/51fPADMSPeM9XedqujP4fPb?= =?us-ascii?Q?6Cjt6vfK+HOiQad5PnZsy6igrVRfSge07jUpHNV/fu4ovVIv7MXXVUk7s7Iy?= =?us-ascii?Q?4oyo8WJoLKoLM7qvZYv/d87erhijm0SFFSOwuOqsUKUy+odjS7HQAxvtZ/gV?= =?us-ascii?Q?HXk0jlLnkZizwsjRZ7RcsdeJ8GZIIs62+b0eG2z0j3EHy81IUWdnojzIAit+?= =?us-ascii?Q?xL47OtbVsLxuzZllNZwUxzMYG8EyMj/szt0wDq9G7hAvYfVoAu2Eu0sIeGev?= =?us-ascii?Q?4NHiyeVO/Cx/w8v4iIMPJvRj4/6nSAqoLH7/DE9MwcBGrqh/j5girBT4Y+Ft?= =?us-ascii?Q?/lzIrs4zGcRkaE8wf2vjsLDFJzTSdd+Vg3hhucRx48OKb80NXsSGmb0Dp0/k?= =?us-ascii?Q?6TOmFozRQltAyHilpQ7FXlOMDj+du96nbiQVijBnuXOpbmWMxKS3mfPo4Fz3?= =?us-ascii?Q?xYhjZ2PtmBf0y85DN1HIIwzL?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: be255baa-71b4-43ad-b760-08d993504046 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2021 22:31:53.3364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: am2935@att.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR02MB7629 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 0E5A4E76233AD851481FB88753739D1496D07BF751D113D412F6ED51733471B82 X-Proofpoint-GUID: _JWa_ooqJJrvSYNDdU--l7nfHN5DKsol X-Proofpoint-ORIG-GUID: _JWa_ooqJJrvSYNDdU--l7nfHN5DKsol X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-19_02,2021-10-19_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 mlxlogscore=615 mlxscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 spamscore=0 phishscore=0 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110190128 Archived-At: Subject: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 19 Oct 2021 22:32:14 -0000 Hi IPPM, Len Ciavattone and I am looking for some feedback on our protocol [0] desig= ned to help measure the Maximum IP-Layer Capacity Metric (which will be pub= lished as an RFC shortly). We are asking folks to take a look at the draft, because we are fairly sure= you will have some questions! One area where we know more development is required is the Modes of operati= on, which essentially describes how the different aspects/exchanges of the = protocol will be made secure. This is pretty-much a green-field in our spec= ification, so suggestions are very welcome. Section 10 currently describes= the different modes that we imagined to be useful (A through F below), but= practical aspects of any proposed solution might indicate modes that shoul= d be combined, split-up, or new modes. So, please give the draft and/or the list below a look, and let us know wha= t you think. thanks! Al=20 [0] https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric= -protocol-01.txt 3. Client-server authentication and integrity protection for feedback messages conveying measurements is RECOMMENDED. To accomodate different host limitations and testing circumstances, different modes of operation are recommended: A. Un-authenticated mode (for all phases) AND B. OPTIONAL Authenticated set-up only SHA-256 HMAC time-window verification (5 min time stamp verification) (could add silent failure option) -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- C. Encrypted setup and test-activation (currently using OpenSSL Library, so KISS, but may be too slow for test packets) -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D-=3D= -=3D-=3D-=3D-=3D- D. Encrypted feedback messages E. Integrity protection for test packets SHA-256 HMAC F. Encrypted test packets (maybe also valuable to defeat compression on li= nks) From nobody Tue Oct 19 16:16:54 2021 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 CE3403A08CD for ; Tue, 19 Oct 2021 16:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 aT5ZtNweu_R8 for ; Tue, 19 Oct 2021 16:14:49 -0700 (PDT) Received: from sonic313-15.consmr.mail.ne1.yahoo.com (sonic313-15.consmr.mail.ne1.yahoo.com [66.163.185.38]) (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 B3BFF3A0881 for ; Tue, 19 Oct 2021 16:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634685283; bh=HIsyshSLlcOqrzCQDieT73+2VT6ehtLoEss+iU767M8=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=R3dh2ajETdWMMWcWtL2aEEYvJ/tNJIiR1g/v8kZDb8l6dNbLvyYyil9JW8NHJJkFq/DwCq8Y7S5y+Wj7e8iq2FVDZ/IzTry+kbGEbsx6t2vCY6ChiSSHhwTY68J9yUCkkxxRCHTSa2B92PPlu5sMDiwWXvGWEgHeyFd0MXgV25T9j5qMN3SjEo/z8hpx5v0yD4YedUQkysYtGTJ3gy/14TP+bvERbsuFtM8MSEvSPVqcNBVXzBg7ktWFRZLykMtEFLY9NVaDltFdIDe8bLEcE4zkP1V6NdNl586rPV8k21QnWqSz/D7wHmfHOOGrmU8gGBg14CmRXDLvDCBRCCegKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634685283; bh=nsE9zkN2p/d7nXJY0hA2y5tcEU6GOsRpvtVx6QKB0wB=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=dkxqfAj4g7+w5anelhX0vTBNCrmMEr/CLPf1xVHKMmOZqPidnR5YsvRC5QXFLBhtteKT9Azo6SjOHrgc+/Q1RLtZYhQa0FWngPpjkV5AbT4/hT0ypZ/rIqcYe2oE4gQzNJC8Ngwu0gRjUn8FSVGTUnTC7pygpPpZIeGe3lDwgZclsJPc3AgqhxUz2eSzsxmE/NiLbQ9YtlXcUTrqejciMovTcKC559pS+sSpRpPNH3LltRaJgCvpgvXcCoysfP9/N/3dxWSWaqzJl8NypXj+BhFv0utAYIeBd1g+2yQYXm8j4Nn8g1gH195RTudxTVzTtHgGP+kYu1Cx3aroH5dzjA== X-YMail-OSG: eMP1xKgVM1llUL0U.D3XYCBBNPmwa.3rNv5ZJdvZm3MUjR3Wu4BEnMOxFEa5Dkl rTJIHClE_Dh_YEI0AkvBjsyZh0Ja8iEfTEg9YHyhIOdCZWr6ELDr0ontNQCBmehcIpQX.p1kzrnw vYfuBbOhZqRcXqki98D_pMV74LkgnPUKbOa0._cV60DZPWcJ0RFX7qUeQubfkSWYx2NwyhcnQEBL h9xQ923cCV38Lf7vVXo34nKERxSLQpj7g_Kg14J3fody3JFGUUv4umyvf0LzSMOZUpKc11pitJ5L _xkzFC50PbnWZvhXDU2CqTNkOWfbKfmUakEJNYQ_cE25IAH3yExwtIdABAgTdHGTD3VePsLJhgvv bjQ0YjYBDMhg6bbRipkZWHFtcwGKqhULBjXpDAVU1lsSOb0Zx_O8nsFY4ZlOYiuux0DAW_hpnHO1 COzbxYU8M3QGmqOrkVCe9nUGsMPUuuOvhOqBg6wXsTnPkQ9qCCsf63t57Pt2.xPuJIlY5T2YQllo _ymXGf_GMytHC8rz9zuJBeMLXp2sP2_1VmoFq.UXxtctZc590As9t259j.C_KRJwZqICSQ44KK77 9jrhBLFKdhBt_12kP0uAZdwpFNIpqQESlL7GD_tEdJ2VgGrUOBnWKKrDMXoppxS66X0L7blLqzyp aIHuvxbKSpQtqV_VjjkxhqziombbTlVy5Kby27BW6ON0V_Sd779QxluW1e7yx9PjHsedpgy6lEhc WlhjqfXDahjRsrhhW6W8vSlGlvZjbjXSZW4TjX90BdscOyQUGEjgyRUv6b5mA1OaN91Mcuzrktbj PrFO_kgLgOvQstXkUyeef_hCiAE2quABVPH4GLYZ2tXUGndgKqt55znZhPv1x8wUMp8WlQgsK3zW KV8_.nhc9rYfGZMFyDy1pUIGmTrSmPH4DzcQM.Kq.S6OXGoLGrw0yFIQLIfBzkCDMlytIesuMWJq fPE8gRFF4dPrV4S4uYZH1xaJcj9RPHlqEmgXKPpsfZgagJU9qwGj5ckAQ4DrEmVriuZiCepqNBRa OY1.kvzwYYDa867YUEUnxQ_kOIv05.ya3n6eUYhybIxLcA_1KY7c6.QpPrGHs53XOTvGgeQpGhTm zeGmfCOjDv0msl7zg4GF.x8R_LYROepoAIBrC5h4nWh1VBehnPptYvq.Y6m0P8z5h2qiX76gPOff eKhbvxPJgus_ijq88zrDy9aFKJD5gm01SKUF2bpyJuxYt1W6JffY4i5ASbuqdUWnlfB_Kd_YNTBU j95M4_QwXmtS4EFaBhjyMiAOgGfuVUNvjvGlEjNXwU2m8LFxr_9V3o_zhHz30hPMSS1qdAsll5vS bNM6AXxrZ8nVeCL7xTu1uRcLXOlbwUz91Q7FyZI7xA7mWNqoq41q9d9pveMS2mdhWcFfcqJPM.UJ j0ZJ2hM39Q8MRO1FpGnzU32ZiBkr51Zjq2FjSFhanCqrBJGEPLpkgesq9LrDL6YBwKy0xhQuEnWt DAhptQVPsBoD2X8j4APmBAC0tMbSGZrV09aD6x5RzJHx3BCm8l.ePJni_gz.wZurphb9aao61JvQ nSw7TnaLBj1CCWYYPDYId8xg_Y5F.GVtwD2y0tP.7gs1rvpynXM6H1.p9YDEE9AvXzu.ve2DbE6T H4kFiwEJPxQFI0mnlIJ7SiE1D_BopaBM7J5GdFqdCGjdYcpgCTXiQo7T24H8WANjuOf608vHsaEo mc2HvKsWeD_vzmaDH.8e739eGWwErhxQHKOWRnxkXRj1zUF2mUsD80k8zcXnWLaTs1Xdr3W_or0G q2eHh8h.JFgoIgHPU4tg0DFO6UI4Ekx4.ssLhm.4jL5pTS24GqPOyI1IS1Fm1T3mdPDF4qnE8qVE 2Mi8ldp7Ztfm8lQOW8mqBCB1q0nDlnqm_K.HnJfs_81SXHaMsWWyuk7.LI.EZcKglnt1p_TC2_5J nFsW4bxpAGS593kvk13nKSIvQVeNp8CkqtUewI379AD1cwoImLZZcnQU4uOWI.GtAInSZyI3.D2d 8KXWk_hzBwi1uUGiqxzA06lPLzGS9wliK.5tuyZ3m.dt1mS3nmV5KdcyS8VSrbS4qfiKpsfDob3T 4jPKzeVF.ZNx794yqDUl3pBMruhBc3fEWtJLUBluLXIIH6s4i4fSOizxrBSTRQe0mtY2AsaBA0Bk 9ZOdmWUlMcLV4cacUquZqAwDnoUTe9ED_j_xOfqx.kP4K6dJBqsbTGpHsJJw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Tue, 19 Oct 2021 23:14:43 +0000 Date: Tue, 19 Oct 2021 22:52:53 +0000 (UTC) From: "nalini.elkins@insidethestack.com" To: IETF IPPM WG Message-ID: <588593855.4818260.1634683973344@mail.yahoo.com> In-Reply-To: <163468369743.11633.16855587749342120994@ietfa.amsl.com> References: <163468369743.11633.16855587749342120994@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4818259_1868562321.1634683973341" X-Mailer: WebService/1.1.19116 YMailNorrin Archived-At: Subject: [ippm] Fw: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-01.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: Tue, 19 Oct 2021 23:15:05 -0000 ------=_Part_4818259_1868562321.1634683973341 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello IPPM, We are working on the following two issues which were pointed out in the si= de meeting: >Securing the Master (Km) by reducing its scope, so that only the Primary C= lient and Server can use it. >Deriving Client-Specific Master keys (Kmi) for all Secondary Clients so th= ey can use them for the construction of TemporarySessionKeys (Ksi).=C2=A0 We will post that as version 2. I will soon schedule another side meeting to show everyone the implementati= on as far as we have it.=C2=A0 =C2=A0We are doing well on the base packet f= low.=C2=A0 We have started internal discussions and definitions of the Regi= stration protocol (Primary Reader - Primary Writer and Primary - Secondary)= . As always, we welcome any comments! Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360=20 ----- Forwarded Message ----- From: internet-drafts@ietf.org To: mackermann@bcbsm.com ; Adnan Rashi= d ; Ameya Deshpande ; Michael Ac= kermann ; Nalini Elkins ; Tommaso Pecorella Sent: Tuesday, October= 19, 2021, 03:48:30 PM PDTSubject: New Version Notification for draft-elkin= s-ippm-encrypted-pdmv2-01.txt =20 A new version of I-D, draft-elkins-ippm-encrypted-pdmv2-01.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 draft-elkins-ippm-encrypted-pdmv= 2 Revision:=C2=A0=C2=A0=C2=A0 01 Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IPv6 Performance and Diagnostic= Metrics Version 2 (PDMv2) Destination Option Document date:=C2=A0=C2=A0=C2=A0 2021-10-19 Group:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Individual Submission Pages:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 16 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/= id/draft-elkins-ippm-encrypted-pdmv2-01.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-e= lkins-ippm-encrypted-pdmv2/ Htmlized:=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/html/draft-e= lkins-ippm-encrypted-pdmv2 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/rfcdiff?url2= =3Ddraft-elkins-ippm-encrypted-pdmv2-01 Abstract: =C2=A0 RFC8250 describes an optional Destination Option (DO) header embedde= d =C2=A0 in each packet to provide sequence numbers and timing information as =C2=A0 a basis for measurements.=C2=A0 As this data is sent in clear- text,= this =C2=A0 may create an opportunity for malicious actors to get information fo= r =C2=A0 subsequent attacks.=C2=A0 This document defines PDMv2 which has a =C2=A0 lightweight handshake (registration procedure) and encryption to =C2=A0 secure this data.=C2=A0 Additional performance metrics which may be = of use =C2=A0 are also defined. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 The IETF Secretariat =20 ------=_Part_4818259_1868562321.1634683973341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello IPPM,
    We are working on the following two issues which were pointed o= ut in the side meeting:

    >Securing the Master (K= m) by reducing its scope, so that only the Primary Client and Server can us= e it.

    >Deriving Client-Specific Master keys (Km= i) for all Secondary Clients so they can use them for the construction of T= emporarySessionKeys (Ksi). 

    We will post tha= t as version 2.

    I will soon schedule another side meeting= to show everyone the implementation as far as we have it.   We a= re doing well on the base packet flow.  We have started internal discu= ssions and definitions of the Registration protocol (Primary Reader - Prima= ry Writer and Primary - Secondary).

    As always, we welcome= any comments!

    Than= ks,

    Nalini Elkins
    CEO and Founder
    Inside Products, Inc.
    www= .insidethestack.com
    (831) 659-8360


    =20
    ----- Forwarded Message -----
    From: internet-drafts@ietf.org <internet-dra= fts@ietf.org>
    To: mackermann@bcbsm.com <mackermann@b= cbsm.com>; Adnan Rashid <adnan.rashid@unifi.it>; Ameya Deshpande &= lt;ameyanrd@gmail.com>; Michael Ackermann <mackermann@bcbsm.com>; = Nalini Elkins <nalini.elkins@insidethestack.com>; Tommaso Pecorella &= lt;tommaso.pecorella@unifi.it>
    Sent: Tuesday, October 1= 9, 2021, 03:48:30 PM PDT
    Subject: New Version Notification= for draft-elkins-ippm-encrypted-pdmv2-01.txt


    A new vers= ion of I-D, draft-elkins-ippm-encrypted-pdmv2-01.txt
    has been successfully submitted by Nalini Elkins and posted to the
    <= /div>
    IETF repository.

    =
    Name:        draft-elkins-ip= pm-encrypted-pdmv2
    Revision:    01=
    Title:        IPv6= Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
    Document date:    2021-10-19
    Group:        Individual S= ubmission
    Pages:      &n= bsp; 16
    Diff:    &n= bsp;     https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-elkins-ippm-encrypted-pdmv2-01

    Abstract:
      RFC8250 describes an optional Destination Option (DO) header = embedded
      in each packet to provide sequen= ce numbers and timing information as
      a ba= sis for measurements.  As this data is sent in clear- text, this
      may create an opportunity for malicious actors= to get information for
      subsequent attack= s.  This document defines PDMv2 which has a
    =   lightweight handshake (registration procedure) and encryption to
      secure this data.  Additional performa= nce metrics which may be of use
      are also = defined.

       =                     &nbs= p;                     &n= bsp;                     =              


    The IETF Secretariat=


    ------=_Part_4818259_1868562321.1634683973341-- From nobody Wed Oct 20 12:53:33 2021 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 1844A3A08A9 for ; Wed, 20 Oct 2021 12:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxl2XEW_Oat0 for ; Wed, 20 Oct 2021 12:53:26 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 70CD43A1031 for ; Wed, 20 Oct 2021 12:52:56 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id r4so1162888edi.5 for ; Wed, 20 Oct 2021 12:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YZhbdvOP7Itfmkb4P0c4+W3j1P8iPLciE8XS7iYF8mQ=; b=aoSy7+B4Mp9ZEx3Eo49MWV1fvcJCa/+OcbgTY/klf9Xk00i2v3sBwH/eJBpIY0Ue17 p1XkLvXqX9SEKofPsf2BRTdzAuqk9sbCiy02Gj4WdwYeQHWXvFUTh2mq1pf7KxtKVA8b o0LYfAIs1yEnZxUihUjRBiIVphCBm/ex50uoc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YZhbdvOP7Itfmkb4P0c4+W3j1P8iPLciE8XS7iYF8mQ=; b=Z/JVYgeKU2mLEZWPLD0QPqFwFdU83wwK1UXxlkX2q+xxxQGbxgjKGSeKeeh2Uo8nru KWmjj7CzatXeT3mRVNUp9c8ZewMYBYT9OUO52NBgtWnqB5zMbhvl5kbeSKl9GpoEqeFA xDkJLmNNzLdqvEhW7ljwN5hVR9G2GKHl/yzlq4NdBRHKgeGDUNeVbpWdgQSBYbdRSuhp Zb8LqLetO7R5EY0MsR4JV1wEakDdECfSt+Yg74x+iIKGoLUZi//Mc559xMYl9phjpaZr UIudZ170BztHU/F/rn8R4dtq0dw9Gty3mQXkP0QUabkd+z7D+igOdMnu1wuHkgrPbnkg iuKQ== X-Gm-Message-State: AOAM5322a3EtD3o9J/m2yM0kHVvRBuED7PUxDmomyMypGJmGLIPq198F +B4kh00oT5Sy+pQRoCLCtYjw+L4j+TrX+UfCrrTgYDxdcSI= X-Google-Smtp-Source: ABdhPJxg3T8e2QSKALS03d0AjCaKGamlzuW1dVK5xXdC1o6O+Q7FU4pG0XsA0xQ0/67xDG1exk3I3Gex3tTaQj/7yOc= X-Received: by 2002:a17:906:ae53:: with SMTP id lf19mr1681679ejb.97.1634759572370; Wed, 20 Oct 2021 12:52:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lincoln Lavoie Date: Wed, 20 Oct 2021 15:52:41 -0400 Message-ID: To: IETF IPPM WG Cc: "MORTON JR., AL" Content-Type: multipart/alternative; boundary="0000000000009ad27605cece1fbd" Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 20 Oct 2021 19:53:32 -0000 --0000000000009ad27605cece1fbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Al (and everyone), I give a quick read through and have some comments and questions on the current draft. Section 3, Phase Item 1: It=E2=80=99s not clear if the expectation is for a= lignment of the mentioned items, i.e. both the client and server must support jumbo datagrams, or for a mismatch the connection is rejected. Put another way, is this a negotiation phase, where options are mutually agreed between client and server? This is more clear in the setup section below, in terms of an =E2=80=9CAND=E2=80=9D type requirement. Section 3, Phase Item 2: The set up of firewall rules. It is unclear if this is a requirement or informative, such that linkage between the client implementation and a device's firewall might be required. Similarly, careful security considerations should be taken here, akin to duration of those =E2=80=9Copenings=E2=80=9D Should a comment be added to Item 4 about= closing of firewall rules, etc. I'm thinking about this separately then the opening of a socket / network port and the creation of the actual firewall rule allowing access to that port. In section 7.1, is the watchdog timer updated each time a test PDU is received, or each time a test PDU or status message is received. In the case of downstream testing, for example, the server is sending down test PDUs and receiving upstream status information from the client. If the client or its connection were to die, the server should be able to detect this, from a lack of upstream status messages. It is not clear if / how this is accomplished only at the receiver of test PDUs. For the Setup Command Response Codes in Section 5, these seem to be indicated as an ENUM type parameter, but as an example, what if there were multiple conditions to be indicated to the client. Could these be made into =E2=80=9Cflags=E2=80=9D such that multiple could be set. The conseque= nce would be limiting the maximum number within the 8-bit size (which is already exceeded). Currently none of the status messages are protected against bit errors (i.e. no checksum or similar). Would there be benefit in adding that level of protection to the control channel? This would protect against a bit flip that could cause "misalignment" between what the client / server are "doing." Also within the Section 5 Setup Command I=E2=80=99m guessing the authDigest= of the setup request message is intended as a sort of =E2=80=9Cshared password=E2= =80=9D the valid clients would use to identify themselves. Would it make sense to mention, as an informative comment it might be worth setting more unique credentials per client via an out of band mechanism, like TR-069, assuming tests are being directed by someone like a service provider? I know security is a much larger topic, but discouraging any type of shared credential is always good practice in my opinion. Please let me know if there are any other ways I can help out, great start on the protocol! Cheers, Lincoln On Tue, Oct 19, 2021 at 6:32 PM MORTON JR., AL wrote: > Hi IPPM, > > Len Ciavattone and I am looking for some feedback on our protocol [0] > designed to help measure the Maximum IP-Layer Capacity Metric (which will > be published as an RFC shortly). > > We are asking folks to take a look at the draft, because we are fairly > sure you will have some questions! > > One area where we know more development is required is the Modes of > operation, which essentially describes how the different aspects/exchange= s > of the protocol will be made secure. This is pretty-much a green-field in > our specification, so suggestions are very welcome. Section 10 currently > describes the different modes that we imagined to be useful (A through F > below), but practical aspects of any proposed solution might indicate mod= es > that should be combined, split-up, or new modes. > > So, please give the draft and/or the list below a look, and let us know > what you think. > > thanks! > Al > > > [0] > https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-p= rotocol-01.txt > > 3. Client-server authentication and integrity protection for > feedback messages conveying measurements is RECOMMENDED. To > accomodate different host limitations and testing circumstances, > different modes of operation are recommended: > > A. Un-authenticated mode (for all phases) > AND > B. OPTIONAL Authenticated set-up only > SHA-256 HMAC time-window verification (5 min time stamp verification) > (could add silent failure option) > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > C. Encrypted setup and test-activation > (currently using OpenSSL Library, so KISS, but may be too slow for > test packets) > > -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D-= =3D-=3D-=3D-=3D-=3D- > > D. Encrypted feedback messages > > E. Integrity protection for test packets SHA-256 HMAC > > F. Encrypted test packets (maybe also valuable to defeat compression on > links) > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --=20 *Lincoln Lavoie* Principal Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) --0000000000009ad27605cece1fbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hel= lo Al (and everyone),

    I g= ive a quick read through and have some comments and questions on the curren= t draft.=C2=A0
    =
    Section 3,= Phase Item 1: It=E2=80=99s not clear if the expectation is for alignment o= f the mentioned items, i.e. both the client and server must support jumbo d= atagrams, or for a mismatch the connection is rejected. Put another way, is= this a negotiation phase, where options are mutually agreed between client= and server?=C2=A0 This is more clear in the setup section below, in terms = of an =E2=80=9CAND=E2=80=9D type requirement.

    Section 3, Phase Item = 2: The set up of firewall rules.=C2=A0 It is unclear if this is a requireme= nt or informative, such that linkage between the client implementation and = a device's firewall might be required. Similarly, careful security cons= iderations should be taken here, akin to duration of those =E2=80=9Copening= s=E2=80=9D =C2=A0Should a comment be added to Item 4 about closing of firew= all rules, etc.=C2=A0 I'm thinking about this separately then the openi= ng of a socket / network port and the creation of the actual firewall rule = allowing access to that port.

    In section 7.1, is the watchdog timer = updated each time a test PDU is received, or each time a test PDU or status= message is received.=C2=A0 In the case of downstream testing, for example,= the server is sending down test PDUs and receiving upstream status informa= tion from the client. If the client or its connection were to die, the serv= er should be able to detect this, from a lack of upstream status messages.= =C2=A0 It is not clear if / how this is accomplished only at the receiver o= f test PDUs.

    For the Setup Command Response Codes in Section 5, thes= e seem to be indicated as an ENUM type parameter, but as an example, what i= f there were multiple conditions to be indicated to the client.=C2=A0 Could= these be made into =E2=80=9Cflags=E2=80=9D such that multiple could be set= .=C2=A0 The consequence would be limiting the maximum number within the 8-b= it size (which is already exceeded).=C2=A0=C2=A0

    Currently none of t= he status messages are protected against bit errors (i.e. no checksum or si= milar).=C2=A0 Would there be benefit in adding that level of protection to = the control channel?=C2=A0 This would protect against a bit flip that could= cause "misalignment" between what the client / server are "= doing."

    Also within the Section 5 Setup Command I=E2=80=99m gue= ssing the authDigest of the setup request message is intended as a sort of = =E2=80=9Cshared password=E2=80=9D the valid clients would use to identify t= hemselves. Would it make sense to mention, as an informative comment it mig= ht be worth setting more unique credentials per client via an out of band m= echanism, like TR-069, assuming tests are being directed by someone like a = service provider?=C2=A0 I know security is a much larger topic, but discour= aging any type of shared credential is always good practice in my opinion.<= br>

    <= div class=3D"gmail_default" style=3D"font-size:small">Please let me know if= there are any other ways I can help out, great start on the protocol!

    Cheers,
    Lincoln

    On Tu= e, Oct 19, 2021 at 6:32 PM MORTON JR., AL <acmorton@att.com> wrote:
    Hi IPPM,

    Len Ciavattone and I am looking for some feedback on our protocol [0] desig= ned to help measure the Maximum IP-Layer Capacity Metric (which will be pub= lished as an RFC shortly).

    We are asking folks to take a look at the draft, because we are fairly sure= you will have some questions!

    One area where we know more development is required is the Modes of operati= on, which essentially describes how the different aspects/exchanges of the = protocol will be made secure. This is pretty-much a green-field in our spec= ification, so suggestions are very welcome.=C2=A0 Section 10 currently desc= ribes the different modes that we imagined to be useful (A through F below)= , but practical aspects of any proposed solution might indicate modes that = should be combined, split-up, or new modes.

    So, please give the draft and/or the list below a look, and let us know wha= t you think.

    thanks!
    Al


    [0] https://d= atatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.= txt

    =C2=A0 =C2=A03.=C2=A0 Client-server authentication and integrity protection= for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0feedback messages conveying measurements is RECO= MMENDED.=C2=A0 To
    =C2=A0 =C2=A0 =C2=A0 =C2=A0accomodate different host limitations and testin= g circumstances,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0different modes of operation are recommended:
    =C2=A0A. Un-authenticated mode (for all phases)
    AND
    =C2=A0B. OPTIONAL Authenticated set-up only
    SHA-256 HMAC time-window verification (5 min time stamp verification)
    (could add silent failure option)

    =C2=A0 =C2=A0 =C2=A0-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

    =C2=A0C. Encrypted setup and test-activation
    (currently using OpenSSL Library, so KISS, but may be too slow for
    test packets)

    =C2=A0 =C2=A0 =C2=A0-=3D-=3D-=3D-=3D--=3D- Old/low-power host performance i= mpacts -=3D-=3D-=3D-=3D-=3D-=3D-

    =C2=A0D. Encrypted feedback messages

    =C2=A0E. Integrity protection for test packets SHA-256 HMAC

    =C2=A0F. Encrypted test packets (maybe also valuable to defeat compression = on links)

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


    --
    Lincoln Lavoie
    Prin= cipal Engineer, Broadband Technologies
    21 Madbury Rd., Ste. 100, = Durham, NH 03824
    +1-603-674-= 2755 (m)

    --0000000000009ad27605cece1fbd-- From nobody Wed Oct 20 13:39:22 2021 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 DCE1B3A1047 for ; Wed, 20 Oct 2021 13:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGCzXaTPHATG for ; Wed, 20 Oct 2021 13:39:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 D9CBD3A103C for ; Wed, 20 Oct 2021 13:39:13 -0700 (PDT) Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lfl9w-1n27SJ1mvq-00pLd8; Wed, 20 Oct 2021 22:39:09 +0200 Message-ID: <010dd135-4efd-f2e5-6eec-cdc64cafd375@clemm.org> Date: Wed, 20 Oct 2021 13:39:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US From: Alexander L Clemm To: ippm@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:nJZLRBwRJf5AtcBRKTmfpz2fAVQtWDqZyn0oOMpmxVSdmjy5cV7 yHhAi3sYpzxXk1+/W+U0yVZrPhYqSeZxQ3XCBSvL0OQzvl8VQrQg6LiVI1ED79k8/9rseSA 6AiSEFgAJWQLeBvyEb9Z6JanVfn+txqAlmEre9IRYHGrLaIK8YlZaF22v7uVK6BgvYa4F7A giVcDG5lYawzFlLMoC0cg== X-UI-Out-Filterresults: notjunk:1;V03:K0:6XNBDb1X4UQ=:aJ2ekeKQELcSe5C92NQNEO lcndgqgtOT3pTyCSF/KWKNq0I94jobCxTBH22Gpw+DTN7Uf8lnsQrdeKPFAG0XfsnD8bI/2Aj KpKQA1nVJ/sPtSRfuji8KRZFPGl88CLjxOfhOX0MUQL8IdL/AEA4iERTCx25BUgdF3G5M7Wp4 lwwaVK1LHcXkOczYMEAWjCUZWV0sb2N1J/62NqbUuG98CF+/l1884YLGX+qWtxOXuk5z/PJk2 kobnolWxNrv7ndEIWa9HRqVC1Ju6NLfkljTdCBHAVIbIAJUgJzCRXV+o2Kz2UeiD3upUEuvF2 sOjvtLqdNKc/t8Wp4e3NAigQLdCxEya6IVPyHVaZWRburO8/O2qBUPdDaVGZIMFYVTzDU7FAu qu9EfkBMBPrDqtnZjNK7pTnDkPJbkWFf0bekcVk0UrSyauV+AYlM1K/sBkBu09PBQSzAo3PQ4 FJN2ilHjjqk7ncZvfl/h/Rwrw+iXHKxRX5iFjwqUlGla7iZb3TYZUrGFGzqVeyFRv0fIIf1JJ 4oDSJNc3MMqQj4MGKTGKZX1I17FHnO7ws3VIU8b/nWGm3CNcawm2t+P8ShGecHbKI/G9JeqdL jIuKr7KLRWigrIK0Nv8sQqXevuW8sLfalllHTyA+8fMDxAlsDhkFuIpWABbAo60wJWK6sW2D7 6j0aarpmhI+kJyiSi/ZwvObz7Hh1IgF+o/+abvZ+d6FQDTf9bf/K9DBgD+p8abF7haLI= Archived-At: Subject: [ippm] High-Precision Service Metrics draft 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, 20 Oct 2021 20:39:20 -0000 Hello IPPM working group, we have just uploaded a new draft on High-Precision Service Metrics, draft-csfx-ippm-hipmetrics-00, which we hope to discuss at IETF 112 and which we believe fits well into IPPM.  The abstract is as follows: "This document defines a set of metrics for high-precision networking services. These metrics can be used to assess the service levels that are being delivered for a networking flow. Specifically, they can be used to determine the degree of compliance with which service levels are being delivered relative to service level objectives that were defined for the flow. The metrics can be used as part of flow records and/or accounting records.  They can also be used to continuously monitor the quality with which high-precision networking service are being delivered." We are looking forward to your feedback and also for collaborators. --- Alex (also on behalf of co-authors: John, Jerome) From nobody Thu Oct 21 00:29:25 2021 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 B54A73A1067 for ; Thu, 21 Oct 2021 00:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 98LxzYc-Atje for ; Thu, 21 Oct 2021 00:29:17 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29D73A1065 for ; Thu, 21 Oct 2021 00:29:16 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id r6so1481140ljg.6 for ; Thu, 21 Oct 2021 00:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aEzGbE+2uDW21jc/uN5wvAUtmUVAg/HOFY4RcNPy0vI=; b=KnpkKUCrPQRSMmLIsBB9rzoCFtqsqyVY1I9F6dMsH55Cda5RMgE+yhEL6AVaPkoczx c84jGWx3Sr2jhO0pR3e6dqDBFMq99hrCZgvBvd75BZp1H73L/P6JMc4JtouK+ixvItlP 4ZVS7S7g9orDZJGp+l4HjNZ0UrIvjOp9ndUFoKP76g/6mILgEE+k8vJhE87+RbIztfft oAVFgYiYjhTDa+6myHg5JGx/+cC1rxwnV3lEop+kTwUcufT2yDIRQzGb0GlZz4Xv1jeQ 2V5MmqIp0CAqoayvJ1ylWSr7ct+9NKGmlqidgrV0MuWHRXyOJnezFsPbzsNIfBgBazck LUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aEzGbE+2uDW21jc/uN5wvAUtmUVAg/HOFY4RcNPy0vI=; b=gsuXYswd2tAHJ2GAUBKOLxY8rgoMl0dugpGR9xaAP9YKtIWQhPQZGXiIfbk23XvR9p TaUBk0tLq5Pd+BWQXbaIxIbbxDXLi00xnfdu3n0oMIYLgBy5gRc1oM3I+C8ujIR64tJd q+3yhNLa6XFst8Gak26M1rlpfF+oWham+AQqdViNVq0v0mhXQnEGvLkbsE/tfyq42OOv 8jqjQY5NDenoUfEvm+VKRcg2tWJmyTkjXAOrqlC1ziXO9+aT+NltdzLuvbFRyQYUkp7U MzlI0/6G0EHDKmi1CHSB2aN6caMqzfBcDQsDbVGmJc5F9fkwFQD+ILcvJLp5S0O2DNLt F/yQ== X-Gm-Message-State: AOAM530oOLhAHGu48X7pFoiC7/bp3nVFD+m1++pmYYgzNYyKfKzPW2H6 pV7lnLTLZaVte0C+H4s2XF5wnnPJK9+09k395aU= X-Google-Smtp-Source: ABdhPJwH9emKhO5rJnS4/ujELM5yjhpqTbs2rU0+rjPCgT5ndx8NVRQWGczctV5JHu6dCsRwFOSBNdzA+hGvcMfQiOg= X-Received: by 2002:a05:651c:283:: with SMTP id b3mr4142176ljo.459.1634801353505; Thu, 21 Oct 2021 00:29:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: can desem Date: Thu, 21 Oct 2021 18:29:02 +1100 Message-ID: To: "MORTON JR., AL" Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000f442f905ced7d935" Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 21 Oct 2021 07:29:23 -0000 --000000000000f442f905ced7d935 Content-Type: text/plain; charset="UTF-8" Hi Al, IPPM group, I believe this will potentially be a really useful tool for measuring speeds, especially if we can incorporate it in network terminating devices such as customer gateways etc. With regards the various options for the modes of operation, I think encrypting the payload will add additional cpu load without adding much benefit even though it may be valuable to defeat compression on links. Instead, having an option to randomize the payload may be less process intensive and achieve the same goal. Another suggestion that would be extremely useful, if this measurement tool were to be employed in a gateway like device, would be to take into consideration the existing traffic that may be present while running such a test. For example, monitoring the total traffic (which could be as simple as counting the bytes on a WAN interface on a gateway) as the test is run and including this as part of the measurement process would result in more accurate measurements of the line speed. This could be added as an option in the protocol which can be used when required in the described scenario. Regards, Can Desem --000000000000f442f905ced7d935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Al, IPPM group,

    I believe this will = potentially be a really useful tool for measuring speeds, especially if we = can incorporate it in network terminating devices such as customer gateways= etc.

    With regards the various options for the mod= es of operation, I think encrypting the payload will add additional cpu loa= d without adding much benefit even though it may be valuable to defeat comp= ression on links. Instead, having an option to randomize the payload may be= less process intensive and achieve the same goal.

    Another suggestion that would be extremely useful, if this measurement too= l were to be employed in a gateway like device, would be to take into consi= deration the existing traffic that may be present while running such a test= . For example, monitoring the total traffic (which could be as simple as co= unting the bytes on a WAN interface on a gateway) as the test is run and in= cluding this as part of the measurement process would result in more accura= te measurements of the line speed. This could be added as an option in the = protocol which can be used when required in the described scenario.

    Regards,
    Can Desem=C2=A0



    --000000000000f442f905ced7d935-- From nobody Thu Oct 21 02:54:23 2021 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 6C5F23A1496 for ; Thu, 21 Oct 2021 02:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpY9URPcLMEe for ; Thu, 21 Oct 2021 02:54:08 -0700 (PDT) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 C73F93A1491 for ; Thu, 21 Oct 2021 02:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1634810048; x=1666346048; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IF+FTS5wICmhSrh3buB8v6xsqK3ZrqAZyz64fE9tqK8=; b=cb6DgO/jrvjuDRPF3HREFLirAR1eUsaA29nt+SK6Pa7XJw3MV5J71uPo 26MC0L632bPZMaEIuQ7fW9+470r4YvZAxiGtnEUMNYvp/AMV6ngjitcoH 9TZP4GP9b5WBj2ISiruPVw+2QtGLF2RjylMWwhX+guD6ofahruvOmmv0a NBVuWqyhkKHEGXIw0mIe1aEPeBpazwCV8kZ4ZktK6VH0kDE7H3I+/IndG fZO6ocz4exuUQRvqujoRZqXdmuH9K4Ypnj4udGYoQ47VOZmSnj5X3vQQQ zG5oWm5ynNuRVoSe68/grqRZyV0C/3zmosVLlQ8EWJlJV7oKglTiPy9/l w==; IronPort-SDR: KjGwU1kyt7uyucPG5Be2xagrjc5hYFCH0/ba02UI4Fdg0hPxoFERRHQ8WxOmL1rsbAxacHhxAk ldskk6N+QlCA== IronPort-Data: =?us-ascii?q?A9a23=3AGHuiq65kRR/ayUH1AGYzHwxRtB3FchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmcaX2yBbq3eNmOhf490Pom/9B8OuMCDy99mGgRkqC1mQ?= =?us-ascii?q?iMRo6IpJzg5wmQcns+qw0WqoHtPt63yUfGdapBrJpPgjk31aOG49SMljfjgq?= =?us-ascii?q?ofUU4YoBAggHGeIdw9x0XqPq8Zh6mJZqYDR7zGl4LsekOWDULOR4AOYB0pPg?= =?us-ascii?q?061RLODi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vg0zp8OuLjnru9bggLRKLfJw6HjjxdXK3Kbhpq/3R0i/licqBBNQEM0V1ln?= =?us-ascii?q?PgooDlJnaatRAsoMaDW3ssQUhNwDyx6MK5B/fnLLBBTtOTCkBGbKyW3qxlpJ?= =?us-ascii?q?ARsVWECwc52GXlL3f0VND5LaQqM799aaprTpvJEn8gufdn6eo8S/G0lzDfFA?= =?us-ascii?q?OwgSJSFSKLPjeK0FQwY3qhmdcsyreJDAda3UCn9Xg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AfC6B5K6n4mmf/tZVagPXwW6BI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiYlEPBwxvre/8jziyWVtN9IYgBQpTiBUJPwOE80hqQFkbX5Wo3SHz?= =?us-ascii?q?UO2VHYbL2KgrGSvgEIdxeOkdK1kJ0QDZSWBeeaMbEYt7e53ODbKadd/DDvys?= =?us-ascii?q?nB6YixrgYJPGVXguNbnnhE426gYxFLrWJ9dOIE/e+nl7B6Tk2bCA8qh6qAdx?= =?us-ascii?q?84tu74zeEjdqiKXTc2QzocrCWehzKh77D3VzKC2A0Fbj9JybA+tUDYjg3Q/M?= =?us-ascii?q?yYwrSG4y6Z81WWw4VdmdPnxNcGLteLkNIpJjLljRvtTJh9WoeFoCs+rIiUmR?= =?us-ascii?q?IXeZj30lAd1vZImirsl1KO0EPQMs7boW0TAkrZuBmlaL3Y0JbErXwBepd8bM?= =?us-ascii?q?liA2jkAgIbzaNBOeRwrj2kXtNsfGb9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZ?= =?us-ascii?q?ATcblLsOUkjQxo+bo7bW/HAbocYaVT5QDnlb9rWELfa2qcsnhkwdSqUHh2Fh?= =?us-ascii?q?CaQlIassjQ1zRNhnh2w0YR2cRaxx47hdMAYogB4/6BPrVjlblIQMNTZaVhBP?= =?us-ascii?q?0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla+XUY1NyIF3lIXKUVteu2?= =?us-ascii?q?J3c0XyCdeW1JkO6RzJSHXVZ0Wm9iif3ekzhlTRfsudDcSzciFnryL7mYRqPi?= =?us-ascii?q?TyYYfEBK5r?= Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by mailout41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 21 Oct 2021 11:54:03 +0200 IronPort-SDR: xwll5v6YOKdeVc6DqvbYJtylsH+ysp7wjZYhOlIFeZFGScdksw8jLozl5NldtwKe6pMRZvFCRF e1kGgEpv6q17cvDz9Krckg4Mk+Y1gaTq0= X-IronPort-AV: E=Sophos;i="5.87,169,1631570400"; d="scan'208";a="396622858" X-MGA-submission: =?us-ascii?q?MDHKBGpRue5zpZ1GE5yr9ZOVucdU3SyaNJAm+W?= =?us-ascii?q?qDvwLiaJksY4HqZXr6kp4yKlJj95m9SmmWqqjFMkYhg5pKghX1QmSPom?= =?us-ascii?q?P41RQmbPQoVjx4zu35tOUGbLdyKiHloNr+n8L2pnFpZfZ8CY2dFWOpfu?= =?us-ascii?q?4MXnxQE1keBWVCwFccds9f7Q=3D=3D?= Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 21 Oct 2021 11:54:03 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 21 Oct 2021 11:54:02 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.23 via Frontend Transport; Thu, 21 Oct 2021 11:54:01 +0200 Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.175) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 21 Oct 2021 11:54:01 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RMtKwOucB824m+usWDeIYs1+FOrE++j1wqkCzuT38U85YZ8s9+ZBCAEavt/I6N9P50wHMctzxoTn3hkYh95BxOLlmn7u9BBzBSehvTrwjiJW1gHmmGt6npSxzSSwvbfofJqDl+fYndttjdmxUDxLfBbzn7ZPY1+RcU8BF1meuUkabKjndNOC/AXgWofuRDEO8FJpdihYWvi6KQFAAfmE+sq4eqVnLTIQebvfkr2V0iDNM4me5cXs4OmCtCHLP6wdqsvA6ZYv8Iu8cOzL3jcsAmN4TRnd5aP9phVOXHqOrZuT4h3bTqrnMLgoIuPo6tLXuoRv9n1wHowCqm3Lh9xY5A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IF+FTS5wICmhSrh3buB8v6xsqK3ZrqAZyz64fE9tqK8=; b=iXPLIKKQOu5RER0p51HoDugmYIxDq9ZDWVfgRHk7fYC+BoXrlnatfyu/hS7I4wePpc6TNaOHRjbYRJ8CpPJGqdcHypnLE684l+uTTCupbiTZh1CG5ZXxCClbb3Z28RVMG2U04yD3ZROhxRclCSgUFYD0dASnKxEbuXd5e00hFSE85AhQx5FNz4zR5eP2zcK6BcTL5JyxPRjrjLBmcNybDGCJn5GL4Imd+e3jUkiilOT6+a067Sh6PQMwnvOZJe6yxCNzL7duoRJT2G4uF6GRoFYnTuVw0k6Nj5RkVSn7uNkznZo4z8Eom9gKnkD5q/9QkDKZ8XNNJRY6d/jns/k1Ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2c::12) by FR2P281MB0218.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.10; Thu, 21 Oct 2021 09:54:01 +0000 Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b875:2268:60fe:d12a]) by FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b875:2268:60fe:d12a%9]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 09:54:01 +0000 From: To: CC: Thread-Topic: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AdfFK9goV64vTz3BSZKe4qsMDY7MVgBLmSNg Date: Thu, 21 Oct 2021 09:54:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=telekom.de; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b48a9fc0-66c7-4842-1f89-08d99478b5ab x-ms-traffictypediagnostic: FR2P281MB0218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nK7o7MNXNtYts00/ueQMXtWiJvxUFN9o0HFKmWouVxTT1u3cSLxwf6R8gUuRe61DQbS50vPYdJ3aMyvvioxiQne4nqnhLy7hZNGSmCC3qXr7uu8aG0qauxMsqvCJ8F69ZGbw6wsgrpg1EfcrRMV3elC6Iucuyla2/CLuqoCGI/PS8R9NMdxDHWfIpxqMUHBzE7ZfCFTb6kHuO6LNTjs6tRSnoa9xkizskHOIv/fIAo1F9aU/hH/KBR21/W5wW98A5m+vbFEJA/Owl/mrYSzxkLf2rPDAtkHQzg4u/qwswFH9n1Jkry4UJiRMTW5062JYMuo/t3W6iteH643rq54UHqWxKbV1WCA6UCSgIWcomyZhV2/NDBfl81IHECGLMgqAIm766PUMDbJIXSI09If8ikAt8GkgETkm+iwycpRemlUw+rOyKg1Iu057LKBomZfGY8NRQjOuN6kqph0glpe2W5F6/BnhmT+b5JZOueX27+m8B5hrUkE/jcqvOZOQotk/YdLHETzlAS/mK8G0UPC9kpxiUL1ivprG/RjAyE0bIAvic9PS0XFqmg6eCZOJivOP6221MIOvhzFVcdpDdWNIq4Ex3RoOEP0Pr3C1BBW5eOT8KqtyNy7XMrLUff6hp839SILjdgeCbHdc27/7e8Pgm7lP9LGa1x3r0n5N++j8L6kY63ZrLeQa41g4V6dcxNPNPNGqrMyCVKF5R/x2BXkJ2BvaTKAHSYRXYtdE6A3/VaPooE8p35+oLb+/8QDHDNExs+FMhWONiHajsPveZ9L1m2WtJ3IQvd89Qk/PAj+fumg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(8936002)(38070700005)(8676002)(66574015)(6916009)(4326008)(66946007)(5660300002)(2906002)(33656002)(966005)(83380400001)(71200400001)(52536014)(38100700002)(7696005)(86362001)(76116006)(498600001)(55016002)(186003)(66556008)(64756008)(66476007)(122000001)(6506007)(9686003)(66446008)(82960400001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6+pih5I52Dwisc4BOABPwNTB1B2hcdK1TNwTPRl5OcDzjEYyAecaDCQabC?= =?iso-8859-1?Q?xVnI0QVtMLAvZ+hncg2FTW7pgMb6WksJ0DkgQ8lCB8qZBoLsl8nD7tTLYB?= =?iso-8859-1?Q?ffCnWUk3BJPDG947AEOWz+0yv0GeVJai6VS1xrq2S0kcacAM+/WqmEgloc?= =?iso-8859-1?Q?gQ1iJKlDSZAA7DiEoWLcRftJSsJLgqD6Dg02K3wvU2C0/Ww4qOgA7LyegN?= =?iso-8859-1?Q?8Wz3LdKI64P48f3FG1n300l58UPGXv7J5FUDha19RTIs0AQz4R0jIU/FgW?= =?iso-8859-1?Q?6fFHRCcCq6syvY+cYpRb6eyIwdHGtXVFG8omHITtrxAzI12kjgNoXny4/z?= =?iso-8859-1?Q?ZAHMUJHkZ2xvgSRnwOlG/CgJU+kvDIfrjlgxdjizVy+CAV3rnxJr0F8XEo?= =?iso-8859-1?Q?4jOYw+ZOgmzcwa8pRtSnIGTDfTy2MGFulw83sLac7HIbSWFyQ5DfzbxFQ9?= =?iso-8859-1?Q?s28qwF+KvuxlP4YcB87pzEA9cemD/dMpB0mB6sH/nzD7eDMlaaS83wJGHu?= =?iso-8859-1?Q?snP2gHkQaGnKQKejAQvNBIHQGtcq0LzSfmay89UIQ1ZS+zIJ3RZdOFTci5?= =?iso-8859-1?Q?Q2qI3rUqiF+s5m3eVtFDRKtQ5al2W6Aw7D0HE832+wqGikoFsLw1bPjuWt?= =?iso-8859-1?Q?HhCt0T35AoAPUfJa28u909en1vKeqlD+fLbmU/p0/pGEF6DuNfYKhbYhrI?= =?iso-8859-1?Q?CvF2tmcEsqlPLxyZVbT7w/C3xWLMeoO5F2tUO/fUIYzj3rfNozWHhnFHe8?= =?iso-8859-1?Q?jkOUqUIMv5xt2DE7ycEm5hwDreygfxCg7NK3bGnI4d1Z0SAdzJxSAi2aGi?= =?iso-8859-1?Q?7/9eoUH5yJejLbSM5XRlsyxh1cfyYIml2Js9IUJsFx6MOEkIBaKz+yS5ym?= =?iso-8859-1?Q?+NLIkqAbSAkk6mFTssgD+pFW60gD2ZU5C8FfEoRfQh4UBogt+9orHNmAwI?= =?iso-8859-1?Q?eFI1w0gPHbW6VRey1o4f5zGworYBCLuqn4i2jiMe+isUNv9QBLZXr6pqUb?= =?iso-8859-1?Q?dGgrkspm9sTqpXUI2iIOfB+zuWLEbsI2+NYvYdnh6wh5ZdxnS0ptXwmQ/u?= =?iso-8859-1?Q?KN79uakuaB1ZLH1MaIRW5bMp9owZxi6XRh60VQyk3kuEr9XA6TxFpHCCOp?= =?iso-8859-1?Q?kiDS35K+WIcMBG3x/z5fpYyqda8Fre8zC0iHUp9fkxkEcj0DQ62aqjivfD?= =?iso-8859-1?Q?iETI6+P6CEzBM+VpMcR/PgwZukTQGk60jatMvO9Tcmr+9l5PkFmBOu5vEn?= =?iso-8859-1?Q?YiUAmoA9Xmv3nqYtH4d5vwegbOv7+JDns1dAeyb919salVKzZ5QNLG82yD?= =?iso-8859-1?Q?xQMEow+1EhW9KQWidR7lqPcVmHMBiDT1vhAEJCt0udS/uxRG+yoCNBwV+H?= =?iso-8859-1?Q?PwjRSE3n2xP2Bhh5RU8e68dyq0dQqpnPSD+BJlBg/WSvbtMDDPCMeiNvpN?= =?iso-8859-1?Q?pXA9Fm3bXFk0yIq7BEq8J+BeqDFHL0DUl+DimF0ZC462jbx6nyKGVCmoi3?= =?iso-8859-1?Q?g=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b48a9fc0-66c7-4842-1f89-08d99478b5ab X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 09:54:01.3796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0218 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 21 Oct 2021 09:54:17 -0000 Hi Al, A standardized protocol to request a standardized access bandwidth measurem= ent is a generic requirement and I appreciate your initiative. As a person = not personally implementing software, some high level comments on the doc o= nly: 2. Scope, Goals, and Applicability, last sentence:=20 "The primary application of the protocol described here is the same as in Section 2 of [RFC7479] where:" That's a mis-quote, isn't it? You target another RFC, don't you? >From numbers I guessed:=09 https://www.rfc-editor.org/rfc/rfc7497.html#section-2 I started with a minor issue, as it points to RFC7497. The latter RFC conta= ins the following statement: https://www.rfc-editor.org/rfc/rfc7497.html#section-7 "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do not = possess the asymmetric size generation capability with two-way testing." Adding a brief section to draft-morton-ippm-capacity-metric-protocol discus= sing why e.g. TWAMP (or a simplified version) isn't applied or rather enhan= ced for the measurement protocol may be useful. If existing IETF IPPM measu= rement control protocols don't offer any benefits justifying their adaption= for a capacity-metric-protocol, the section will be brief. If there's pro = and con, what's worth adding functionality to TWAMP and what's the "cost" (= in terms of work and changes) may be worth some words. Should inclusion of = a capacity-metric-protocol to TWAMP be worth a thought, a few words on requ= ired features and changes (a sketch on what to add) may be useful. I'm not = a TWAMP expert, I excuse if my comment doesn't apply. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: ippm Im Auftrag von MORTON JR., AL Gesendet: Mittwoch, 20. Oktober 2021 00:32 An: IETF IPPM WG Betreff: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Hi IPPM, Len Ciavattone and I am looking for some feedback on our protocol [0] desig= ned to help measure the Maximum IP-Layer Capacity Metric (which will be pub= lished as an RFC shortly). We are asking folks to take a look at the draft, because we are fairly sure= you will have some questions! One area where we know more development is required is the Modes of operati= on, which essentially describes how the different aspects/exchanges of the = protocol will be made secure. This is pretty-much a green-field in our spec= ification, so suggestions are very welcome. Section 10 currently describes= the different modes that we imagined to be useful (A through F below), but= practical aspects of any proposed solution might indicate modes that shoul= d be combined, split-up, or new modes. So, please give the draft and/or the list below a look, and let us know wha= t you think. thanks! Al=20 [0] https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric= -protocol-01.txt 3. Client-server authentication and integrity protection for feedback messages conveying measurements is RECOMMENDED. To accomodate different host limitations and testing circumstances, different modes of operation are recommended: A. Un-authenticated mode (for all phases) AND B. OPTIONAL Authenticated s= et-up only SHA-256 HMAC time-window verification (5 min time stamp verification) (coul= d add silent failure option) -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- C. Encrypted setup and test-activation (currently using OpenSSL Library, so KISS, but may be too slow for test pac= kets) -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D-=3D= -=3D-=3D-=3D-=3D- D. Encrypted feedback messages E. Integrity protection for test packets SHA-256 HMAC F. Encrypted test packets (maybe also valuable to defeat compression on li= nks) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Oct 21 13:26:57 2021 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 CA65B3A0A88 for ; Thu, 21 Oct 2021 13:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jiy9rGRLJKnl for ; Thu, 21 Oct 2021 13:26:45 -0700 (PDT) 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 7EDC13A0A84 for ; Thu, 21 Oct 2021 13:26:44 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 19LKQOHQ003381; Thu, 21 Oct 2021 16:26:42 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 3buf89g0a4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 16:26:42 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19LKQekn015014; Thu, 21 Oct 2021 16:26:41 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19LKQcVl014958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Oct 2021 16:26:38 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 21E614067503; Thu, 21 Oct 2021 20:26:38 +0000 (GMT) Received: from GAALPA1MSGEX1AD.ITServices.sbc.com (unknown [135.50.89.99]) by zlp30486.vci.att.com (Service) with ESMTP id B56B44067500; Thu, 21 Oct 2021 20:26:37 +0000 (GMT) Received: from GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) by GAALPA1MSGEX1AD.ITServices.sbc.com (135.50.89.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Thu, 21 Oct 2021 16:26:37 -0400 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Thu, 21 Oct 2021 16:26:37 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Thu, 21 Oct 2021 16:26:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oOYqTbJ/pydfHOveK+oA8Vi5Wwygh6xPdVYXp4TBrfvZ0GoLYjkBAKkxRaVt3EQHZnXBO62sJ81daozI4XRFCvlf41+XU/SCUJErAk6zA8oPRJLfmJjK/K+B1IHZWKs7n/j4ffCYO/xf7qmW1IdkL1RqR36cVhK+q3353Y+U7BdaEYC7xWhaLVJBkyfzWjIyw9/Vnvdb1hKxlc/TqQ5jtcuoIJ+ZS6NK7kOSk1Iug//Gd91BxffD4yNoGMUxZ4mjwu/a4lG4x4x9klpAYYTIVjTqvnxREmR9LUqcr5pUupsdh7nan5NLQZjCB7+dR4Uxf8ztg5t+cphKC4GzYK7wMQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WsCishGOav0vjxBFxi85kUIXBexiv7+Xyc5u34eBvuY=; b=cSpc9lRS3opPuy+cgUNcGDmCdI3l9qSpZ956QOjt3+XnzoSNk7TJmNx/fKcN+yuyjP5pYGR7wA780M2ejhNfxVrgDyS0Dauo9VaL3IhxI3qdjOwkr9lRqnoqzrfPtw+QMnfGyHo85AbucJJXd8K7AZ2KWAPf3nXPgrYh4bhQNE5H/GHPSqXsurEOyg6SsDYU2UPAB73igkzzlv+dBsnT6p83krO/QQxyp51kK9T5CpQPfs8iRUYA4rjx2/mDiVs6pOw7PMojK7uyrw18xBNJda6vrnDdnhgFJHCbpZDPJvpIzV8nCrD8AFJH4a8CswZPU4YWJMLRVLtNX8PnldgR7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WsCishGOav0vjxBFxi85kUIXBexiv7+Xyc5u34eBvuY=; b=k8qBpmMQD44tyZzNW2/g/R0jjAPGCaiwki6iOFXAMIRRzh9ZhNYjk7fVNWoBhrPdBF0KkBLt180ixKW36+ZckZ1WYQITMYL0+t733wZiTr/vjfpjqVUdSYwZ4Z9T8IUeMDVOmAm6tvegJPLSQsclTs23hxeaPqS/EcdwWHBuJbk= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB5032.namprd02.prod.outlook.com (2603:10b6:a03:71::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.15; Thu, 21 Oct 2021 20:26:11 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%5]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 20:26:11 +0000 From: "MORTON JR., AL" To: Lincoln Lavoie , IETF IPPM WG Thread-Topic: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AQHXxewcIkcZuhY1wEGo2hM8lGifgKvdw8pw Date: Thu, 21 Oct 2021 20:26:10 +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: iol.unh.edu; dkim=none (message not signed) header.d=none;iol.unh.edu; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1cddb71-3811-4c7f-2dc6-08d994d10575 x-ms-traffictypediagnostic: BYAPR02MB5032: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AUdBV8ZBKfRqEcgv5wBC5d2cJvvGaoYrjjyv1R3a3tAztMCQSi0Iwidkata7FuiBfJa+iVOpbAQdI7D1DvnGiQMH0LChgBu6ZYEKRznPhQcdNelc2hDlhHa1IUHiWxtkwI6BwqoJ5aA2TKwwyz/s6U0PhyPZ6da7VOVmNQSpb29vt6nRMeb93EzImi1qRX+iuyCbW8BF25WW6IkLtUSiLzhXZn2S+lBBJ+QQHKq9K3AdheRYzebXDmymNO52PtpFKV+WJDi1TPXtrcBhPZK6DQDu28Us/cMNVWveqmtCdRug5faozrQAIpP7wqpt1m5w/KyvBHiAPxE1YEfFLg/JDF0HRMi4a8I633i3brsBeHleKtlGUSgRtwYtYEt1WenbAWNr3yGdOQR9xl+WHbjl+SLqMZOt0iU9TYU5dPcWnqhDsmO56UFKqAk8gCCiZFLgJq0EXtFpcC5qyTsB02gRPd1QgoxUDQi98U8Qc60g8tH5uiY6nUyG5GD1ui1c6eWE2lg88A5PBNFPQVniSjbbV89vrQzq7nefR5XOzwYLeUYhuc3VFhvzCmcRCnjeU2tk4hof1rebSi7WJshC21/FioIHO3bMyywS5iGG6pnVHl+LLWWlSaiEegmYpE6QnKw8bFTST3C7NPgSyhcoQKJgEnDGtG35TBdK5oPAaqoASou6DhUlKbLkX06eBOEQJH5icDOyiz9hk9lTwnBsoPJikqhDuYq3B6QYBUA9+PAswaLLn5xTyylpYwtG+53ZIKJAK4B7CEQlBmGXsiMfyTG0ocj5iFRTUX12DkEuPky7GUu6SwhpLwwcOoz2q5YApDqj326LJmL7lkjVU7mtDNlgKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(53546011)(7696005)(6506007)(316002)(26005)(38070700005)(186003)(82960400001)(52536014)(5660300002)(966005)(110136005)(9686003)(9326002)(508600001)(64756008)(66446008)(82202003)(8676002)(83380400001)(8936002)(2906002)(38100700002)(66946007)(76116006)(40140700001)(66476007)(86362001)(66556008)(71200400001)(55016002)(166002)(122000001)(33656002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UDBpTTVQNHl0aU9xN295bjRlcUZhNGVPYkNuWUNQeGxZUVpxU2wzT1pKUjVo?= =?utf-8?B?Vlp4MjF3YUdsQXlaSnpobWJ4bC9UZnRMT3JaRHhOR3RVa3JrcXo5ZEtTamhp?= =?utf-8?B?RnhiUmFId1Y3ek95SDJJK28zZXRwYzV0TmVRaHJ5cHBTay83MWtVNUxUeFln?= =?utf-8?B?Q2JONTZKR2d6Z2JrSy9neDBPUEU3eUJtMkhDS0xoSlZpM1VNL3FBaUI1ZkZN?= =?utf-8?B?S2dhK2EyZ3kyRGczQzNrV0pBalR5SUE2ZUNXVlM0NW5WUklzMmI1WnhXdVV3?= =?utf-8?B?VXBGdDV4VGVXNGhYVC9LTGJLbkRZU1NVSnFvd08xMDY2RGVDdUwyT0hodkNE?= =?utf-8?B?S2ExbVJodHRkSVlUMjZVWFdNZnZURGNDRjg3cEtKVW93Uk9IcW1RSkd1L3Zp?= =?utf-8?B?T1U3YzdTTVJUV2R1ZHhEVzNtaG5XZ0JZam5BeDkvTEs2bWtWTkhOSTkyOUpz?= =?utf-8?B?c0YyQ3J1T3FxU091RVV2ZTY0RVR4dU9DTnZYSXRRTTdTWGtYWUpiU1NxWU5P?= =?utf-8?B?U2czdDJHenFyRHk2VkFRQTZHcCtHa1Y0L3FMcjM1NDlBeUdvRG1QanNrdy9L?= =?utf-8?B?TWJockJ1NW1JcDg4VXNsWkRWaElGakJDTnNmdTg5Vy9aUmtWcXdUMys5TkZY?= =?utf-8?B?cmdMRVhTV1FQQUJZU2Z4NEtteGhjTkxCWDZuQWZqRUVqTDcwNi9KcFVWOGNH?= =?utf-8?B?NjFKc1U4QS9GK2dFcUc1S0V3Q05aejErczVmV2lrcnZZLzIxUjdqTDJyZExQ?= =?utf-8?B?OGNyN0cxRG9zOEFLK3dDcWJuQTh6SDNCclZTaVFEMEdDUS9QbkdSVC8rTHRX?= =?utf-8?B?aUJsamQyRmp5eG9BK1RFZE9Ta1B3TUpqbVRNazhuaHp1amQ3Z0E1djhDUHhr?= =?utf-8?B?a2RkNENzMUFWVGtRa09ISzhueFdBeUFDQXI0MVd0UWU4TGptZERJL2N3My90?= =?utf-8?B?VnQvNi9xR1JKOG5SMytUSTI0NWNRbG9jeDYyY0hLUWY1SHhpaGIwZkVOS1M4?= =?utf-8?B?N0NybVRvK1Zyb1Zjc0Z0dVNtNjVyL1FJOFVHTUd4ZmxyWE12MHp2ZGdROUFS?= =?utf-8?B?c01FTVozT0phdHcvZGY1V3ZneFVDOXJ3OVRvUXJHNjVDMmhMNkp3MW55KzQy?= =?utf-8?B?SFUzNEYyQXJkVXlNUTZpZzRDeHZNSlBtUTJkL1NvT0RTMWVtNUVxc2tpWWVa?= =?utf-8?B?eElTWDRKanlvNndNSjVQcWpnZWtRMXNtUnVqZW5ZUUM0T2xjalpOYUk5VzR1?= =?utf-8?B?M2h2UkNQbUZGWmc0TEZQOG9VZVM4UDRxZVBLNExkUEcraWZ4TGpHQXl4OHdl?= =?utf-8?B?WkFyZGVLN1E2cUk3M245NmNqOCtSMzcySmdGVHhTaWI5Rk4xRzR2N2lhenUw?= =?utf-8?B?dVJQVytMYUxhVDB1Q0J3ajRmTnFFVEhsVEZtTFM3OEkvLy9MWTduOFcraExI?= =?utf-8?B?OElHMjlRODZMTWF6cGI3elBHRzZ5WjRWMGZLOFdOV2VhR3ZqUXc2WEZ5bWk0?= =?utf-8?B?OUN3VTdSMUxFZy9GMlA2WWhtOVl6OVhLQjhNK05DQ0k5NER0MWR3d1EwOUN5?= =?utf-8?B?SHRLZUphelRXV3NhWjVBK0pyR0tCeHp5aUo1b2tldnRuZmhneEJLeTkzdHYw?= =?utf-8?B?cDhXSFZzTGtDQkx3eGkzWFFDWHBVRjdQQTJWYXU4bUg2cjROd0Y1WWdlUEZL?= =?utf-8?B?WXZiUHdTQTVkdnNkUUpkS1BUYzV6T2Y4ZWo1Umx4NGlSQXFKMHZpRUg1Lys1?= =?utf-8?B?dzdhMU5mQjRidytiMzJRWk1SWmowclMrYk9FYlFmSFF1cVd1ZXBWR2Z4Q0pW?= =?utf-8?B?RXRrdWFDRlpUanFBclNhRWtrQ0c2bHZuWk5TbEN5OWpqTm5aNGRJbkhoY1Az?= =?utf-8?B?c3o2bjcrdUhscytNMXR1c3ZBNVBXRXZ3VzZmL1ZsZlpGaXc9PQ==?= Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB7853902AF803C61008D55523D3BF9SJ0PR02MB7853namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1cddb71-3811-4c7f-2dc6-08d994d10575 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 20:26:10.8773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: am2935@att.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5032 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 6C80CA4AB356DEEDCB476B66BD8943EC058452C62D1766D5D4BD32DCD6E714742 X-Proofpoint-ORIG-GUID: 83pAteDCK7YdW8JpjTOZO663T0tjrB9A X-Proofpoint-GUID: 83pAteDCK7YdW8JpjTOZO663T0tjrB9A X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_05,2021-10-21_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110210104 Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 21 Oct 2021 20:26:52 -0000 --_000_SJ0PR02MB7853902AF803C61008D55523D3BF9SJ0PR02MB7853namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGluY29sbiwNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXchIFlvdeKAmXZl IHJhaXNlZCBzb21lIGdvb2QgcXVlc3Rpb25zIGFuZCBpZGVudGlmaWVkIGFyZWFzIHRvIGltcHJv dmUgdGhlIGRyYWZ0Lg0KDQpJ4oCZbGwgcmVwbHkgcG9pbnQtYnktcG9pbnQgYmVsb3csIFthY21d LiBJ4oCZdmUgbGVmdCBhIGZldyBpdGVtcyBmb3IgbW9yZSBkaXNjdXNzaW9uIChoYXZlbuKAmXQg aW1wbGVtZW50ZWQgY2hhbmdlcyB5ZXQpLg0KQWwNCg0KRnJvbTogTGluY29sbiBMYXZvaWUgPGx5 bGF2b2llQGlvbC51bmguZWR1Pg0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIwLCAyMDIxIDM6 NTMgUE0NClRvOiBJRVRGIElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc+DQpDYzogTU9SVE9OIEpSLiwg QUwgPGFjbW9ydG9uQGF0dC5jb20+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFF1ZXN0aW9ucyBvbiBk cmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtMDENCg0KSGVsbG8gQWwg KGFuZCBldmVyeW9uZSksDQoNCkkgZ2l2ZSBhIHF1aWNrIHJlYWQgdGhyb3VnaCBhbmQgaGF2ZSBz b21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgb24gdGhlIGN1cnJlbnQgZHJhZnQuDQoNClNlY3Rp b24gMywgUGhhc2UgSXRlbSAxOiBJdOKAmXMgbm90IGNsZWFyIGlmIHRoZSBleHBlY3RhdGlvbiBp cyBmb3IgYWxpZ25tZW50IG9mIHRoZSBtZW50aW9uZWQgaXRlbXMsIGkuZS4gYm90aCB0aGUgY2xp ZW50IGFuZCBzZXJ2ZXIgbXVzdCBzdXBwb3J0IGp1bWJvIGRhdGFncmFtcywgb3IgZm9yIGEgbWlz bWF0Y2ggdGhlIGNvbm5lY3Rpb24gaXMgcmVqZWN0ZWQuDQoNClthY21dDQp0aGFua3MsIEnigJls bCB3cml0ZSBjbGVhcmVyIHRleHQgdG8gcmVwbGFjZSAjMSwgYW5kIGRpc2VudGFuZ2xlIHRoZSBj bGllbnQgYW5kIHNlcnZlciBvcGVyYXRpb24gaW4gdGhlIGZpcnN0IHNlbnRlbmNlIGJlbG93IChu b3QgeWV0IG1vZGlmaWVkKS4NCjEuICBTZXR1cCBSZXF1ZXN0IGFuZCBSZXNwb25zZSBFeGNoYW5n ZTogY2xpZW50IGFuZCBzZXJ2ZXIgY29uZmlybQ0KICAgICAgIG1hdGNoaW5nIHByb3RvY29sIHZl cnNpb25zLCBhdXRoZW50aWNhdGlvbiBtb2RlLCBhbmQganVtYm8NCiAgICAgICBkYXRhZ3JhbSBz dXBwb3J0LCBvciByZWplY3QgdGhlIGNvbm5lY3Rpb24uDQpCVFcsIGFsbCB0aHJlZSBvZiB0aGVz ZSBjb25maWd1cmF0aW9uIHNldHRpbmdzIGhhdmUgdG8gbWF0Y2gsIG9yIHRoZSBzZXJ2ZXIgc2Vu ZHMgdGhlIHJlamVjdCByZXBseS4NCg0KUHV0IGFub3RoZXIgd2F5LCBpcyB0aGlzIGEgbmVnb3Rp YXRpb24gcGhhc2UsIHdoZXJlIG9wdGlvbnMgYXJlIG11dHVhbGx5IGFncmVlZCBiZXR3ZWVuIGNs aWVudCBhbmQgc2VydmVyPyAgVGhpcyBpcyBtb3JlIGNsZWFyIGluIHRoZSBzZXR1cCBzZWN0aW9u IGJlbG93LCBpbiB0ZXJtcyBvZiBhbiDigJxBTkTigJ0gdHlwZSByZXF1aXJlbWVudC4NClthY21d DQpBdCB0aGlzIGJlZ2lubmluZyBTZXR1cCBFeGNoYW5nZSwgdGhlcmUgaXMgbm8gbmVnb3RpYXRp b24gcG9zc2libGUgaW4gdGhlIGN1cnJlbnQgcHJvdG9jb2wuDQpCdXQgYXNzdW1pbmcgd2UgZXhw YW5kIHRoZSBudW1iZXIgb2Ygc2VjdXJpdHkgbW9kZXMgKGJleW9uZCB0aGUgYmluYXJ5IOKAnGF1 dGhlbnRpY2F0aW9uIG9yIHVuYXV0aGVudGljYXRlZOKAnSBtb2RlcyksIHRoZSBTZXR1cCBFeGNo YW5nZSBjb3VsZCBiZWNvbWUgbW9yZSBjb21wbGljYXRlZCwgb3IgYmUgcHJlY2VkZWQgYnkgYSBu ZXcgZXhjaGFuZ2UgdG8gc2VjdXJlIHRoZSBjb21tdW5pY2F0aW9ucy4NCg0KU2VjdGlvbiAzLCBQ aGFzZSBJdGVtIDI6IFRoZSBzZXQgdXAgb2YgZmlyZXdhbGwgcnVsZXMuICBJdCBpcyB1bmNsZWFy IGlmIHRoaXMgaXMgYSByZXF1aXJlbWVudCBvciBpbmZvcm1hdGl2ZSwgc3VjaCB0aGF0IGxpbmth Z2UgYmV0d2VlbiB0aGUgY2xpZW50IGltcGxlbWVudGF0aW9uIGFuZCBhIGRldmljZSdzIGZpcmV3 YWxsIG1pZ2h0IGJlIHJlcXVpcmVkLiBTaW1pbGFybHksIGNhcmVmdWwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2hvdWxkIGJlIHRha2VuIGhlcmUsIGFraW4gdG8gZHVyYXRpb24gb2YgdGhvc2Ug 4oCcb3BlbmluZ3PigJ0NClthY21dDQpUaGlzIGlzIGFuIGluZm9ybWF0aXZlIG92ZXJ2aWV3IG9m IHRoZSBkZXRhaWxzIGluIGxhdGVyIHNlY3Rpb25zIHRoYXQgZm9sbG93LCBhbmQgcmVxdWlyZW1l bnRzIHdpbGwgYXBwZWFyIGluIHRoZSBsYXRlciBzZWN0aW9ucy4gKEkgbmVlZCB0byBhZGQgdGhp cyB0ZXh0IGluIGZyb250IG9mIHRoZSBsaXN0IGluIFNlY3Rpb24gMykuDQoNClRoaXMgaXMgdGhl IGN1cnJlbnQgdGV4dCBpbiBxdWVzdGlvbjoNCiAgIDIuICBUZXN0IEFjdGl2YXRpb24gUmVxdWVz dCBhbmQgUmVzcG9uc2U6IC4uLiAgTm90ZSB0aGF0IHRoZQ0KICAgICAgIFRlc3QgQWN0aXZhdGlv biBleGNoYW5nZSBoYXMgb3BlbmVkIGFueSBmaXJld2FsbHMgYW5kIG5ldHdvcmsNCiAgICAgICBh ZGRyZXNzL3BvcnQgdHJhbnNsYXRvcnMgZm9yIHRoZSB0ZXN0IGNvbm5lY3Rpb24gYW5kIHRoZSB0 cmFmZmljDQogICAgICAgdGhhdCBmb2xsb3dzLg0KDQpUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwg dGhlIGNsaWVudCBhc3N1bWVzIHRoYXQgdGhlIGNvLWxvY2F0ZWQgZmlyZXdhbGwgd2lsbCBvcGVu IHRoZSBiaS1kaXJlY3Rpb25hbCBhZGRyZXNzIGFuZCBwb3J0IGNvbWJpbmF0aW9ucyBpbiByZXNw b25zZSB0byBhIGNsaWVudOKAmXMgcGFja2V0IHNlbnQgaW50byB0aGUgbmV0d29yaywgYW5kIHN1 YnNlcXVlbnRseSBjbG9zZSB0aGF0IGNvbWJpbmF0aW9uIGFmdGVyIGFuIGlkbGUgdGltZS1vdXQg ZGV0ZXJtaW5lZCBieSB0aGUgZmlyZXdhbGwuIFdlIGRpZG7igJl0IGltYWdpbmUgZXhwbGljaXQg Y29udHJvbCBvZiB0aGUgZmlyZXdhbGwsIGJ1dCBub3RoaW5nIHN0b3BzIGEgbWFuYWdlbWVudCBz eXN0ZW0gZnJvbSBleGVydGluZyBpdHMgY29udHJvbC4NCg0KDQpTZWN0aW9uIDMsIFBoYXNlIEl0 ZW0gNDogU2hvdWxkIGEgY29tbWVudCBiZSBhZGRlZCB0byBJdGVtIDQgYWJvdXQgY2xvc2luZyBv ZiBmaXJld2FsbCBydWxlcywgZXRjLiAgSSdtIHRoaW5raW5nIGFib3V0IHRoaXMgc2VwYXJhdGVs eSB0aGVuIHRoZSBvcGVuaW5nIG9mIGEgc29ja2V0IC8gbmV0d29yayBwb3J0IGFuZCB0aGUgY3Jl YXRpb24gb2YgdGhlIGFjdHVhbCBmaXJld2FsbCBydWxlIGFsbG93aW5nIGFjY2VzcyB0byB0aGF0 IHBvcnQuDQpbYWNtXQ0Kb2ssIHdlIGNvdWxkIHNheSB0aGF0IHdlIGRvbuKAmXQgY29udHJvbCB0 aGUgRmlyZXdhbGwsIGFuZCBpdCBpcyBhc3N1bWVkIHRvIGRlbGV0ZSB0aGUgc3RhdGUgZm9yIHRo ZSB0ZXN0IGNvbW11bmljYXRpb24gYWZ0ZXIgdHJhZmZpYyBzdG9wcyAoaW4gcGhhc2VzIDIgYW5k IDQpLg0KDQoNCkluIHNlY3Rpb24gNy4xLCBpcyB0aGUgd2F0Y2hkb2cgdGltZXIgdXBkYXRlZCBl YWNoIHRpbWUgYSB0ZXN0IFBEVSBpcyByZWNlaXZlZCwgb3IgZWFjaCB0aW1lIGEgdGVzdCBQRFUg b3Igc3RhdHVzIG1lc3NhZ2UgaXMgcmVjZWl2ZWQuICBJbiB0aGUgY2FzZSBvZiBkb3duc3RyZWFt IHRlc3RpbmcsIGZvciBleGFtcGxlLCB0aGUgc2VydmVyIGlzIHNlbmRpbmcgZG93biB0ZXN0IFBE VXMgYW5kIHJlY2VpdmluZyB1cHN0cmVhbSBzdGF0dXMgaW5mb3JtYXRpb24gZnJvbSB0aGUgY2xp ZW50LiBJZiB0aGUgY2xpZW50IG9yIGl0cyBjb25uZWN0aW9uIHdlcmUgdG8gZGllLCB0aGUgc2Vy dmVyIHNob3VsZCBiZSBhYmxlIHRvIGRldGVjdCB0aGlzLCBmcm9tIGEgbGFjayBvZiB1cHN0cmVh bSBzdGF0dXMgbWVzc2FnZXMuICBJdCBpcyBub3QgY2xlYXIgaWYgLyBob3cgdGhpcyBpcyBhY2Nv bXBsaXNoZWQgb25seSBhdCB0aGUgcmVjZWl2ZXIgb2YgdGVzdCBQRFVzLg0KW2FjbV0NCkluIHRo ZSBjdXJyZW50IGRyYWZ0LCBJIGRlc2NyaWJlZCB0aGUgdGltZS1vdXRzIG9uIHRoZSBUZXN0IFNl dHVwLCBUZXN0IEFjdGl2YXRpb24sIGFuZCBUZXN0IFN0cmVhbSByZWNlcHRpb24uDQpTcGVjaWZp Y2FsbHkgaW4gNy4xOg0KDQogICBUaGUgd2F0Y2hkb2cgdGltZXIgYXQgdGhlIHJlY2VpdmVyIFNI QUxMIGJlIHJlc2V0IGVhY2ggdGltZSBhIHRlc3QNCg0KICAgUERVIGlzIHJlY2VpdmVkLg0KYnV0 IEkgbmVlZCB0byBhZGQgdGhlIHN5bW1ldHJpY2FsIHRpbWUtb3V0IGZvciBTdGF0dXMgUERVcyBp biA3LDIgKGF0IGxlYXN0IEkgZG9u4oCZdCBzZWUgaXQgaW4gdGhlIGRyYWZ0KS4NCkhvd2V2ZXIs IHdlIGhhdmUgdGhlIHN5bW1ldHJpY2FsIHdhdGNoZG9nIHRpbWVycyBpbiB0aGUgcnVubmluZyBj b2RlLCBhbmQgYXJlIGVuc3VyaW5nIGFsbCB0aGUgbmVlZGVkIHRpbWVycyBhbmQgdGltZS1vdXRz IGFwcGVhciBpbiBUUi00NzEgSXNzdWUgMiwgUkZDIDkwOTctdG8tYmUsIFRSLTE4MSwgZXRjLg0K DQpGb3IgdGhlIFNldHVwIENvbW1hbmQgUmVzcG9uc2UgQ29kZXMgaW4gU2VjdGlvbiA1LCB0aGVz ZSBzZWVtIHRvIGJlIGluZGljYXRlZCBhcyBhbiBFTlVNIHR5cGUgcGFyYW1ldGVyLCBidXQgYXMg YW4gZXhhbXBsZSwgd2hhdCBpZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGNvbmRpdGlvbnMgdG8gYmUg aW5kaWNhdGVkIHRvIHRoZSBjbGllbnQuICBDb3VsZCB0aGVzZSBiZSBtYWRlIGludG8g4oCcZmxh Z3PigJ0gc3VjaCB0aGF0IG11bHRpcGxlIGNvdWxkIGJlIHNldC4gIFRoZSBjb25zZXF1ZW5jZSB3 b3VsZCBiZSBsaW1pdGluZyB0aGUgbWF4aW11bSBudW1iZXIgd2l0aGluIHRoZSA4LWJpdCBzaXpl ICh3aGljaCBpcyBhbHJlYWR5IGV4Y2VlZGVkKS4NClthY21dDQoNCkNvbW1hbmQgUmVzcG9uc2Ug Q29kZXMNCg0KQ29udHJvbCBIZWFkZXIgU2V0dXAgUmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9OT05F ICAgICAwID0gTm9uZQ0KDQpDb250cm9sIEhlYWRlciBTZXR1cCBSZXF1ZXN0IENvZGUgQ0hTUl9D UlNQX0FDS09LICAgIDEgPSBBY2tub3dsZWRnZW1lbnQNCg0KQ29udHJvbCBIZWFkZXIgU2V0dXAg UmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9CQURWRVIgICAyID0gQmFkIFByb3RvY29sIFZlcnNpb24N Cg0KQ29udHJvbCBIZWFkZXIgU2V0dXAgUmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9CQURKUyAgICAz ID0gSW52YWxpZCBKdW1ibyBkYXRhZ3JhbSBvcHRpb24NCg0KQ29udHJvbCBIZWFkZXIgU2V0dXAg UmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9BVVRITkMgICA0ID0gVW5leHBlY3RlZCBBdXRoZW50aWNh dGlvbiBpbiBTZXR1cCBSZXF1ZXN0DQoNCkNvbnRyb2wgSGVhZGVyIFNldHVwIFJlcXVlc3QgQ29k ZSBDSFNSX0NSU1BfQVVUSFJFUSAgNSA9IEF1dGhlbnRpY2F0aW9uIG1pc3NpbmcgaW4gU2V0dXAg UmVxdWVzdA0KDQpDb250cm9sIEhlYWRlciBTZXR1cCBSZXF1ZXN0IENvZGUgQ0hTUl9DUlNQX0FV VEhJTlYgIDYgPSBJbnZhbGlkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZA0KDQpDb250cm9sIEhlYWRl ciBTZXR1cCBSZXF1ZXN0IENvZGUgQ0hTUl9DUlNQX0FVVEhGQUlMIDcgPSBBdXRoZW50aWNhdGlv biBmYWlsdXJlDQoNCkNvbnRyb2wgSGVhZGVyIFNldHVwIFJlcXVlc3QgQ29kZSBDSFNSX0NSU1Bf QVVUSFRJTUUgOCA9IEF1dGhlbnRpY2F0aW9uIHRpbWUgaXMgaW52YWxpZCBpbiBTZXR1cCBSZXF1 ZXN0DQpZZXMsIGl04oCZcyBhIGdvb2QgcG9pbnQgSG93IGRvZXMgdGhlIHByb3RvY29sIGhhbmRs ZSB0aGUgbXVsdGlwbGUgZXJyb3IgY2FzZSBleHBsaWNpdGx5IChJ4oCZbSBub3Qgc3VyZSB0aGF0 IHdlIGRvbuKAmXQsIGJ1dCBtb3JlIG5lZWRzIHRvIGJlIHNhaWQsIG9yIGNvbnZlcnQgdG8gZmxh Z3MgKGV4Y2VwdCB0aGF0IHdlIHJhbiBvdXQgb2YgOCBiaXRzIGFscmVhZHksIGFzIHlvdSBwb2lu dC1vdXQhKS4NCg0KSeKAmW0gbGVhdmluZyB0aGlzIGFzIGFuIG9wZW4gaXNzdWUgZm9yIG1vcmUg ZGlzY3Vzc2lvbi4NCg0KDQpDdXJyZW50bHkgbm9uZSBvZiB0aGUgc3RhdHVzIG1lc3NhZ2VzIGFy ZSBwcm90ZWN0ZWQgYWdhaW5zdCBiaXQgZXJyb3JzIChpLmUuIG5vIGNoZWNrc3VtIG9yIHNpbWls YXIpLiAgV291bGQgdGhlcmUgYmUgYmVuZWZpdCBpbiBhZGRpbmcgdGhhdCBsZXZlbCBvZiBwcm90 ZWN0aW9uIHRvIHRoZSBjb250cm9sIGNoYW5uZWw/ICBUaGlzIHdvdWxkIHByb3RlY3QgYWdhaW5z dCBhIGJpdCBmbGlwIHRoYXQgY291bGQgY2F1c2UgIm1pc2FsaWdubWVudCIgYmV0d2VlbiB3aGF0 IHRoZSBjbGllbnQgLyBzZXJ2ZXIgYXJlICJkb2luZy4iDQpbYWNtXQ0KUG9zc2libHksIHRoZSBT dGF0dXMgUERVIGNvdWxkIGJlbmVmaXQuICBUaGUgZmVlZGJhY2sgc3RhdHVzIG1lc3NhZ2VzIGNv bnZleSBjcml0aWNhbCBtZWFzdXJlbWVudHMgZnJvbSwgT1IgdGhlIFNlbmRpbmcgUmF0ZSBTdHJ1 Y3R1cmUgdG8sIHRoZSBjbGllbnQuIE1heWJlIHdlIGFkZCBhIHN0cm9uZ2VyIHByb3RlY3Rpb24g YXQgdGhpcyBwb2ludCBpbiB0aW1lLCB0byBlbnN1cmUgdGhlc2UgbWVzc2FnZXMgYXJlIG5vdCBz cG9vZmVkIGJ5IGFuIG9uLXBhdGggYXR0YWNrIChBdHRhY2sgaW4gdGhlIG1pZGRsZSkuDQoNCkni gJltIGxlYXZpbmcgdGhpcyBhcyBhbiBvcGVuIGlzc3VlIGZvciBtb3JlIGRpc2N1c3Npb24uDQoN Cg0KQWxzbyB3aXRoaW4gdGhlIFNlY3Rpb24gNSBTZXR1cCBDb21tYW5kIEnigJltIGd1ZXNzaW5n IHRoZSBhdXRoRGlnZXN0IG9mIHRoZSBzZXR1cCByZXF1ZXN0IG1lc3NhZ2UgaXMgaW50ZW5kZWQg YXMgYSBzb3J0IG9mIOKAnHNoYXJlZCBwYXNzd29yZOKAnSB0aGUgdmFsaWQgY2xpZW50cyB3b3Vs ZCB1c2UgdG8gaWRlbnRpZnkgdGhlbXNlbHZlcy4gV291bGQgaXQgbWFrZSBzZW5zZSB0byBtZW50 aW9uLCBhcyBhbiBpbmZvcm1hdGl2ZSBjb21tZW50IGl0IG1pZ2h0IGJlIHdvcnRoIHNldHRpbmcg bW9yZSB1bmlxdWUgY3JlZGVudGlhbHMgcGVyIGNsaWVudCB2aWEgYW4gb3V0IG9mIGJhbmQgbWVj aGFuaXNtLCBsaWtlIFRSLTA2OSwgYXNzdW1pbmcgdGVzdHMgYXJlIGJlaW5nIGRpcmVjdGVkIGJ5 IHNvbWVvbmUgbGlrZSBhIHNlcnZpY2UgcHJvdmlkZXI/ICBJIGtub3cgc2VjdXJpdHkgaXMgYSBt dWNoIGxhcmdlciB0b3BpYywgYnV0IGRpc2NvdXJhZ2luZyBhbnkgdHlwZSBvZiBzaGFyZWQgY3Jl ZGVudGlhbCBpcyBhbHdheXMgZ29vZCBwcmFjdGljZSBpbiBteSBvcGluaW9uLg0KW2FjbV0NClll cywgc2hhcmVkIHBhc3N3b3JkIHdhcyBhIGZlYXR1cmUgZm9yIHRoZSBiZWdpbm5pbmcgb3Blbi1z b3VyY2UgaW1wbGVtZW50YXRpb24uIFdlIGRpZG7igJl0IHdhbnQgdG8gcHV0IHVwIGEgcHJvdG9j b2wgd2l0aCBhYnNvbHV0ZWx5IHplcm8gYXV0aGVudGljYXRpb24sIGFuZCBMZW4gYWRkZWQgdGhp cyBsYXN0IFN1bW1lciBiZWZvcmUgdGhlIGZpcnN0IE9CLVVEUFNUIFJlbGVhc2UuDQpXZSBjYW4g bWFrZSBtb3JlIGV4dGVuc2l2ZSBjaGFuZ2VzIHdoZW4gYWRkcmVzc2luZyB0aGUgcXVlc3Rpb24g b2YgU2VjdXJpdHkgbW9kZXMgYW5kIG1ldGhvZHMsIGFuZCBUUi0wNjkgaXMgc3VyZWx5IGEgZ29v ZCBPT0IgZXhhbXBsZS4NCg0KSeKAmW0gbGVhdmluZyB0aGlzIGFzIGFuIG9wZW4gaXNzdWUgZm9y IG1vcmUgZGlzY3Vzc2lvbiwgd2hpY2ggd2lsbCBiZSBzdWJzdW1lZCBieSBkZXRlcm1pbmluZyBu ZXcgU2VjdXJpdHkgTW9kZXMgYW5kIGhvdyB0byBpbXBsZW1lbnQgdGhlbSAoU2VjdGlvbiAxMCku DQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGVyZSBhcmUgYW55IG90aGVyIHdheXMgSSBjYW4g aGVscCBvdXQsIGdyZWF0IHN0YXJ0IG9uIHRoZSBwcm90b2NvbCENClthY21dDQpXaWxsIGRvLCBh bmQgVGhhbmtzIGFnYWluISAgTG9vayBmb3IgYW4gdXBkYXRlZCBkcmFmdCBvbiBPY3QgMjUgYXQg dGhlIHN1Ym1pc3Npb24gZGVhZGxpbmUuDQoNCkNoZWVycywNCkxpbmNvbG4NCg0KT24gVHVlLCBP Y3QgMTksIDIwMjEgYXQgNjozMiBQTSBNT1JUT04gSlIuLCBBTCA8YWNtb3J0b25AYXR0LmNvbTxt YWlsdG86YWNtb3J0b25AYXR0LmNvbT4+IHdyb3RlOg0KSGkgSVBQTSwNCg0KTGVuIENpYXZhdHRv bmUgYW5kIEkgYW0gbG9va2luZyBmb3Igc29tZSBmZWVkYmFjayBvbiBvdXIgcHJvdG9jb2wgWzBd IGRlc2lnbmVkIHRvIGhlbHAgbWVhc3VyZSB0aGUgTWF4aW11bSBJUC1MYXllciBDYXBhY2l0eSBN ZXRyaWMgKHdoaWNoIHdpbGwgYmUgcHVibGlzaGVkIGFzIGFuIFJGQyBzaG9ydGx5KS4NCg0KV2Ug YXJlIGFza2luZyBmb2xrcyB0byB0YWtlIGEgbG9vayBhdCB0aGUgZHJhZnQsIGJlY2F1c2Ugd2Ug YXJlIGZhaXJseSBzdXJlIHlvdSB3aWxsIGhhdmUgc29tZSBxdWVzdGlvbnMhDQoNCk9uZSBhcmVh IHdoZXJlIHdlIGtub3cgbW9yZSBkZXZlbG9wbWVudCBpcyByZXF1aXJlZCBpcyB0aGUgTW9kZXMg b2Ygb3BlcmF0aW9uLCB3aGljaCBlc3NlbnRpYWxseSBkZXNjcmliZXMgaG93IHRoZSBkaWZmZXJl bnQgYXNwZWN0cy9leGNoYW5nZXMgb2YgdGhlIHByb3RvY29sIHdpbGwgYmUgbWFkZSBzZWN1cmUu IFRoaXMgaXMgcHJldHR5LW11Y2ggYSBncmVlbi1maWVsZCBpbiBvdXIgc3BlY2lmaWNhdGlvbiwg c28gc3VnZ2VzdGlvbnMgYXJlIHZlcnkgd2VsY29tZS4gIFNlY3Rpb24gMTAgY3VycmVudGx5IGRl c2NyaWJlcyB0aGUgZGlmZmVyZW50IG1vZGVzIHRoYXQgd2UgaW1hZ2luZWQgdG8gYmUgdXNlZnVs IChBIHRocm91Z2ggRiBiZWxvdyksIGJ1dCBwcmFjdGljYWwgYXNwZWN0cyBvZiBhbnkgcHJvcG9z ZWQgc29sdXRpb24gbWlnaHQgaW5kaWNhdGUgbW9kZXMgdGhhdCBzaG91bGQgYmUgY29tYmluZWQs IHNwbGl0LXVwLCBvciBuZXcgbW9kZXMuDQoNClNvLCBwbGVhc2UgZ2l2ZSB0aGUgZHJhZnQgYW5k L29yIHRoZSBsaXN0IGJlbG93IGEgbG9vaywgYW5kIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5r Lg0KDQp0aGFua3MhDQpBbA0KDQoNClswXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LW1vcnRvbi1pcHBtLWNhcGFjaXR5LW1ldHJpYy1wcm90b2NvbC0wMS50eHQ8 aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtMDEudHh0 X187ISFCaGRUITN0dmhWcDVLQ2NPT0x1cUZuM29lNWhKUzM1N0ZJVlRxYXRmZ2tZSERndGRicG9Y OVZKazh4T0ZPLWhiViQ+DQoNCiAgIDMuICBDbGllbnQtc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFu ZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3INCiAgICAgICBmZWVkYmFjayBtZXNzYWdlcyBjb252 ZXlpbmcgbWVhc3VyZW1lbnRzIGlzIFJFQ09NTUVOREVELiAgVG8NCiAgICAgICBhY2NvbW9kYXRl IGRpZmZlcmVudCBob3N0IGxpbWl0YXRpb25zIGFuZCB0ZXN0aW5nIGNpcmN1bXN0YW5jZXMsDQog ICAgICAgZGlmZmVyZW50IG1vZGVzIG9mIG9wZXJhdGlvbiBhcmUgcmVjb21tZW5kZWQ6DQoNCiBB LiBVbi1hdXRoZW50aWNhdGVkIG1vZGUgKGZvciBhbGwgcGhhc2VzKQ0KQU5EDQogQi4gT1BUSU9O QUwgQXV0aGVudGljYXRlZCBzZXQtdXAgb25seQ0KU0hBLTI1NiBITUFDIHRpbWUtd2luZG93IHZl cmlmaWNhdGlvbiAoNSBtaW4gdGltZSBzdGFtcCB2ZXJpZmljYXRpb24pDQooY291bGQgYWRkIHNp bGVudCBmYWlsdXJlIG9wdGlvbikNCg0KICAgICAtPS09LT0tPS09LT0tPS09LT0tDQoNCiBDLiBF bmNyeXB0ZWQgc2V0dXAgYW5kIHRlc3QtYWN0aXZhdGlvbg0KKGN1cnJlbnRseSB1c2luZyBPcGVu U1NMIExpYnJhcnksIHNvIEtJU1MsIGJ1dCBtYXkgYmUgdG9vIHNsb3cgZm9yDQp0ZXN0IHBhY2tl dHMpDQoNCiAgICAgLT0tPS09LT0tLT0tIE9sZC9sb3ctcG93ZXIgaG9zdCBwZXJmb3JtYW5jZSBp bXBhY3RzIC09LT0tPS09LT0tPS0NCg0KIEQuIEVuY3J5cHRlZCBmZWVkYmFjayBtZXNzYWdlcw0K DQogRS4gSW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRlc3QgcGFja2V0cyBTSEEtMjU2IEhNQUMN Cg0KIEYuIEVuY3J5cHRlZCB0ZXN0IHBhY2tldHMgKG1heWJlIGFsc28gdmFsdWFibGUgdG8gZGVm ZWF0IGNvbXByZXNzaW9uIG9uIGxpbmtzKQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFp bHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwcG08aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHBtX187ISFCaGRUITN0dmhWcDVLQ2NPT0x1cUZuM29lNWhKUzM1N0ZJ VlRxYXRmZ2tZSERndGRicG9YOVZKazh4SUFJeGI0cyQ+DQoNCg0KLS0NCkxpbmNvbG4gTGF2b2ll DQpQcmluY2lwYWwgRW5naW5lZXIsIEJyb2FkYmFuZCBUZWNobm9sb2dpZXMNCjIxIE1hZGJ1cnkg UmQuLCBTdGUuIDEwMCwgRHVyaGFtLCBOSCAwMzgyNA0KbHlsYXZvaWVAaW9sLnVuaC5lZHU8bWFp bHRvOmx5bGF2b2llQGlvbC51bmguZWR1Pg0KaHR0cHM6Ly93d3cuaW9sLnVuaC5lZHU8aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaW9sLnVuaC5lZHVfXzshIUJoZFQhM3R2 aFZwNUtDY09PTHVxRm4zb2U1aEpTMzU3RklWVHFhdGZna1lIRGd0ZGJwb1g5VkprOHhCYVFHT25u JD4NCisxLTYwMy02NzQtMjc1NSAobSkNCltodHRwczovL2RvY3MuZ29vZ2xlLmNvbS91Yz9leHBv cnQ9ZG93bmxvYWQmaWQ9MWpfaUk2YW53cm5iUVdOcFR5dXZ1a01MU05KSjhfOFFVJnJldmlkPTBC XzB1andBQkRuRlpUbUppUjNFekswZDFWakZLVGpRdk1FTkJXVk0wUW5BNGFqaGpQUV08aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaW9sLnVuaC5lZHVfXzshIUJoZFQhM3R2 aFZwNUtDY09PTHVxRm4zb2U1aEpTMzU3RklWVHFhdGZna1lIRGd0ZGJwb1g5VkprOHhCYVFHT25u JD4NCg== --_000_SJ0PR02MB7853902AF803C61008D55523D3BF9SJ0PR02MB7853namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDdDNjk4LjVBRDY5NTYwIj48bGluayByZWw9IkVkaXQtVGltZS1EYXRhIiBocmVm PSJjaWQ6ZWRpdGRhdGEubXNvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPC9vOk9mZmlj ZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjx3OldvcmREb2N1bWVudD4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxp bmdTdGF0ZT4NCjx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4N Cjx3OlRyYWNrTW92ZXM+ZmFsc2U8L3c6VHJhY2tNb3Zlcz4NCjx3OlRyYWNrRm9ybWF0dGluZy8+ DQo8dzpFbnZlbG9wZVZpcy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJ ZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29u dGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xk ZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21v dGVRRi8+DQo8dzpMaWRUaGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRU aGVtZUFzaWFuPlgtTk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21wbGV4U2Ny aXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+DQo8dzpDb21wYXRpYmlsaXR5Pg0K PHc6RG9Ob3RFeHBhbmRTaGlmdFJldHVybi8+DQo8dzpCcmVha1dyYXBwZWRUYWJsZXMvPg0KPHc6 U25hcFRvR3JpZEluQ2VsbC8+DQo8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQo8dzpVc2VBc2lhbkJy ZWFrUnVsZXMvPg0KPHc6RG9udEdyb3dBdXRvZml0Lz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFN YXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8dzpEb250RmxpcE1pcnJvckluZGVu dHMvPg0KPHc6T3ZlcnJpZGVUYWJsZVN0eWxlSHBzLz4NCjwvdzpDb21wYXRpYmlsaXR5Pg0KPG06 bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06 dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZy YWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8 bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxt OndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8 bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5 bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBEZWZT ZW1pSGlkZGVuPSJmYWxzZSIgRGVmUUZvcm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSIgTGF0 ZW50U3R5bGVDb3VudD0iMzc2Ij4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iaW5kZXggMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImluZGV4IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Imlu ZGV4IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJpbmRleCA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDkiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i dG9jIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA4Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iTm9ybWFsIEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290bm90ZSB0 ZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gdGV4dCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJoZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdGVyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImluZGV4IGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzUiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRhYmxlIG9mIGZpZ3VyZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgYWRkcmVz cyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSByZXR1cm4iLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iZm9vdG5vdGUgcmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90 YXRpb24gcmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImxpbmUgbnVtYmVyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InBhZ2UgbnVtYmVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVu ZG5vdGUgcmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVuZG5vdGUgdGV4dCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBhdXRob3JpdGllcyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJtYWNybyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2EgaGVhZGluZyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3Qg QnVsbGV0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3Qg TnVtYmVyIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3Qg TnVtYmVyIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAi IFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkNsb3Np bmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCBDb250aW51ZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGlu dWUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik1lc3Nh Z2UgSGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEx IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJT YWx1dGF0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRhdGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5 IFRleHQgRmlyc3QgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm90ZSBIZWFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IkJvZHkgVGV4dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iQmxvY2sgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIeXBlcmxpbmsi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRm9sbG93ZWRIeXBlcmxpbmsiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0 cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRG9jdW1l bnQgTWFwIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlBsYWluIFRleHQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iRS1tYWlsIFNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFRv cCBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQm90dG9tIG9mIEZvcm0iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIChXZWIpIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkhUTUwgQWNyb255bSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFkZHJlc3MiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBDaXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg Q29kZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIERlZmluaXRpb24iLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iSFRNTCBLZXlib2FyZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFBy ZWZvcm1hdHRlZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFNhbXBsZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJIVE1MIFR5cGV3cml0ZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN TCBWYXJpYWJsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgVGFibGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiBzdWJqZWN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ik5vIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0 bGluZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU2ltcGxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBDbGFzc2ljIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3Np YyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBDb2xvcmZ1bCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgQ29sdW1ucyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgR3JpZCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgR3JpZCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgOCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgTGlzdCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg TGlzdCA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgM0QgZWZmZWN0cyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbnRl bXBvcmFyeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBFbGVnYW50Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIFByb2Zlc3Npb25hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBTdWJ0bGUgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTdWJ0bGUgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBXZWIgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBXZWIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBXZWIgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJCYWxsb29uIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgVGhlbWUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9Ikxp Z2h0IFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9 Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBH cmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5h bWU9IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM0IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAi IFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlz dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQg TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg TmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xv cmZ1bCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1l PSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJN ZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5h bWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRp bmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9 Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjki IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGln aHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVt IEdyaWQgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xv cmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFj Y2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRp dW0gTGlzdCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVs IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMTkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i SW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzMiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MSIgTmFtZT0iUGxhaW4gVGFibGUg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MiIgTmFtZT0i UGxhaW4gVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0MyIgTmFtZT0iUGxhaW4gVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NCIgTmFtZT0iUGxhaW4gVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NSIgTmFtZT0iUGxhaW4gVGFibGUgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MCIgTmFtZT0iR3JpZCBUYWJs ZSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIg TmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJH cmlkIFRhYmxlIDUgRGFyayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikdy aWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlk IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO YW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRh YmxlIDYgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBU YWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt ZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi bGUgMSBMaWdodCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 IkdyaWQgVGFibGUgNCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUg NiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxl IDEgTGlnaHQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH cmlkIFRhYmxlIDQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYg Q29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAx IExpZ2h0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp ZCBUYWJsZSA0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENv bG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBM aWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3Qg VGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi IE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5h bWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1l PSJMaXN0IFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO YW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1l PSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt ZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i TGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxp c3QgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0 IFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJM aXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0 IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBU YWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz dCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBU YWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik1lbnRpb24i Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU21hcnQgSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikhhc2h0YWciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVW5yZXNvbHZlZCBNZW50aW9u Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNtYXJ0IExpbmsiLz4NCjwvdzpMYXRlbnRTdHlsZXM+ DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiUGFsYXRpbm8gTGlub3R5cGUiOw0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg2OTEyMSAxMTA3 MzA1NzI3IDMzNTU0NDMyIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiQ2Vu dHVyeSBHb3RoaWMiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1 cmU6LTQ2OTc1MDAxNyAtMTA3MzczMjQ4NSA5IDAgNTExIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVu dDoiIjsNCgltYXJnaW46MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS11 bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNvLXBh Z2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglt c28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1hc2NpaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1oYW5zaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1i aWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YXNjaWktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uU3BlbGxFDQoJ e21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KLk1zb1BhcERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbGlu ZS1oZWlnaHQ6MTEyJTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41 aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3Jt YWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJv d2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7 DQoJbXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2lu OjBpbjsNCglsaW5lLWhlaWdodDoxMTIlOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCjwvc3R5 bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0idGFiLWludGVydmFsOi41aW47d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkhpIExpbmNvbG4sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VGhhbmtz IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXchIFlvdeKAmXZlIHJhaXNlZCBzb21lIGdvb2QgcXVl c3Rpb25zIGFuZCBpZGVudGlmaWVkIGFyZWFzIHRvIGltcHJvdmUgdGhlIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PknigJlsbCByZXBseSBwb2ludC1ieS1wb2ludCBiZWxvdywgWzxzcGFuIGNsYXNzPSJTcGVsbEUi PmFjbTwvc3Bhbj5dLiBJ4oCZdmUgbGVmdCBhIGZldyBpdGVtcyBmb3IgbW9yZSBkaXNjdXNzaW9u IChoYXZlbuKAmXQgaW1wbGVtZW50ZWQgY2hhbmdlcyB5ZXQpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkFsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+IExpbmNvbG4g TGF2b2llICZsdDtseWxhdm9pZUBpb2wudW5oLmVkdSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE9jdG9iZXIgMjAsIDIwMjEgMzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBJ UFBNIFdHICZsdDtpcHBtQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gTU9SVE9OIEpSLiwg QUwgJmx0O2FjbW9ydG9uQGF0dC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXBw bV0gUXVlc3Rpb25zIG9uIGRyYWZ0LW1vcnRvbi1pcHBtLWNhcGFjaXR5LW1ldHJpYy1wcm90b2Nv bC0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2xpbmUtaGVpZ2h0OjExMiUiPkhlbGxvIEFsIChhbmQgZXZlcnlvbmUpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMTIlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhl aWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTEyJSI+SSBnaXZlIGEgcXVpY2sgcmVhZCB0 aHJvdWdoIGFuZCBoYXZlIHNvbWUgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBvbiB0aGUgY3VycmVu dCBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTEyJSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjExMiUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExMiUi PlNlY3Rpb24gMywgUGhhc2UgSXRlbSAxOiBJdOKAmXMgbm90IGNsZWFyIGlmIHRoZSBleHBlY3Rh dGlvbiBpcyBmb3IgYWxpZ25tZW50IG9mIHRoZSBtZW50aW9uZWQgaXRlbXMsIGkuZS4gYm90aCB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXIgbXVzdCBzdXBwb3J0IGp1bWJvIGRhdGFncmFtcywgb3INCiBm b3IgYSBtaXNtYXRjaCB0aGUgY29ubmVjdGlvbiBpcyByZWplY3RlZC4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxi IHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1m b250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTExJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2Vp Z2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5bPHNwYW4gY2xhc3M9IlNwZWxsRSI+ YWNtPC9zcGFuPl0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMSUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250 LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+dGhhbmtzLCBJ4oCZbGwgd3Jp dGUgY2xlYXJlciB0ZXh0IHRvIHJlcGxhY2UgIzEsIGFuZCBkaXNlbnRhbmdsZQ0KIHRoZSBjbGll bnQgYW5kIHNlcnZlciBvcGVyYXRpb24gaW4gdGhlIGZpcnN0IHNlbnRlbmNlIGJlbG93IChub3Qg eWV0IG1vZGlmaWVkKS4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4xLjxzcGFu IHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5TZXR1cCBSZXF1ZXN0IGFu ZCBSZXNwb25zZSBFeGNoYW5nZTogY2xpZW50IGFuZCBzZXJ2ZXIgY29uZmlybTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0 IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0 MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDcz Mi44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+bWF0Y2hpbmcgcHJvdG9jb2wgdmVyc2lv bnMsIGF1dGhlbnRpY2F0aW9uIG1vZGUsIGFuZCBqdW1ibzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcu NHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4w cHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZGF0YWdyYW0gc3VwcG9ydCwgb3IgcmVqZWN0IHRoZSBjb25u ZWN0aW9uLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTExJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9 Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij5CVFcsIGFsbCB0aHJlZSBvZiB0aGVzZSBjb25maWd1cmF0aW9uIHNldHRp bmdzIGhhdmUgdG8NCiBtYXRjaCwgb3IgdGhlIHNlcnZlciBzZW5kcyB0aGUgcmVqZWN0IHJlcGx5 Ljwvc3Bhbj48L2k+PC9iPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxp IHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48 aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExMiUiPlB1dCBhbm90aGVyIHdheSwg aXMgdGhpcyBhIG5lZ290aWF0aW9uIHBoYXNlLCB3aGVyZSBvcHRpb25zIGFyZSBtdXR1YWxseSBh Z3JlZWQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlcj8mbmJzcDsgVGhpcyBpcyBtb3JlIGNsZWFy IGluIHRoZSBzZXR1cCBzZWN0aW9uIGJlbG93LCBpbiB0ZXJtcw0KIG9mIGFuIOKAnEFOROKAnSB0 eXBlIHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWln aHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPls8c3BhbiBjbGFzcz0iU3BlbGxFIj5h Y208L3NwYW4+XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQt d2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5BdCB0aGlzIGJlZ2lubmluZyBT ZXR1cCBFeGNoYW5nZSwgdGhlcmUgaXMgbm8gbmVnb3RpYXRpb24NCiBwb3NzaWJsZSBpbiB0aGUg Y3VycmVudCBwcm90b2NvbC4gPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRp LWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5CdXQgYXNzdW1pbmcg d2UgZXhwYW5kIHRoZSBudW1iZXIgb2Ygc2VjdXJpdHkgbW9kZXMgKGJleW9uZA0KIHRoZSBiaW5h cnkg4oCcYXV0aGVudGljYXRpb24gb3IgdW5hdXRoZW50aWNhdGVk4oCdIG1vZGVzKSwgdGhlIFNl dHVwIEV4Y2hhbmdlIGNvdWxkIGJlY29tZSBtb3JlIGNvbXBsaWNhdGVkLCBvciBiZSBwcmVjZWRl ZCBieSBhIG5ldyBleGNoYW5nZSB0byBzZWN1cmUgdGhlIGNvbW11bmljYXRpb25zLg0KPC9zcGFu PjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTEyJSI+ PGJyPg0KPGJyPg0KU2VjdGlvbiAzLCBQaGFzZSBJdGVtIDI6IFRoZSBzZXQgdXAgb2YgZmlyZXdh bGwgcnVsZXMuJm5ic3A7IEl0IGlzIHVuY2xlYXIgaWYgdGhpcyBpcyBhIHJlcXVpcmVtZW50IG9y IGluZm9ybWF0aXZlLCBzdWNoIHRoYXQgbGlua2FnZSBiZXR3ZWVuIHRoZSBjbGllbnQgaW1wbGVt ZW50YXRpb24gYW5kIGEgZGV2aWNlJ3MgZmlyZXdhbGwgbWlnaHQgYmUgcmVxdWlyZWQuIFNpbWls YXJseSwgY2FyZWZ1bCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzaG91bGQgYmUNCiB0YWtlbiBo ZXJlLCBha2luIHRvIGR1cmF0aW9uIG9mIHRob3NlIOKAnG9wZW5pbmdz4oCdICZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0i bXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPls8c3BhbiBjbGFzcz0iU3BlbGxFIj5hY208L3NwYW4+XQ0KPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTExJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5 bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij5UaGlzIGlzIGFuIGluZm9ybWF0aXZlIG92ZXJ2aWV3IG9mIHRoZSBk ZXRhaWxzIGluIGxhdGVyDQogc2VjdGlvbnMgdGhhdCBmb2xsb3csIGFuZCByZXF1aXJlbWVudHMg d2lsbCBhcHBlYXIgaW4gdGhlIGxhdGVyIHNlY3Rpb25zLiAoSSBuZWVkIHRvIGFkZCB0aGlzIHRl eHQgaW4gZnJvbnQgb2YgdGhlIGxpc3QgaW4gU2VjdGlvbiAzKS48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTEl Ij48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJp ZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMSUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250 LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VGhpcyBpcyB0aGUgY3VycmVu dCB0ZXh0IGluIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsNCjwvc3Bh bj4yLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsgPC9zcGFuPlRlc3QgQWN0 aXZhdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZTogLi4uPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPk5vdGUgdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3 LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTgu MHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlRlc3QgQWN0aXZhdGlvbiBleGNoYW5n ZSBoYXMgb3BlbmVkIGFueSBmaXJld2FsbHMgYW5kIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQg MTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0 NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmFkZHJlc3MvcG9ydCB0cmFuc2xh dG9ycyBmb3IgdGhlIHRlc3QgY29ubmVjdGlvbiBhbmQgdGhlIHRyYWZmaWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5 MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEy LjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIu OHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPnRoYXQgZm9sbG93cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTExJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5 bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTElIj48YiBzdHlsZT0ibXNv LWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpu b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztt c28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPlRvIGFuc3dl ciB5b3VyIHF1ZXN0aW9uLCB0aGUgY2xpZW50IGFzc3VtZXMgdGhhdCB0aGUgY28tbG9jYXRlZA0K IGZpcmV3YWxsIHdpbGwgb3BlbiB0aGUgYmktZGlyZWN0aW9uYWwgYWRkcmVzcyBhbmQgcG9ydCBj b21iaW5hdGlvbnMgaW4gcmVzcG9uc2UgdG8gYSBjbGllbnTigJlzIHBhY2tldCBzZW50IGludG8g dGhlIG5ldHdvcmssIGFuZCBzdWJzZXF1ZW50bHkgY2xvc2UgdGhhdCBjb21iaW5hdGlvbiBhZnRl ciBhbiBpZGxlIHRpbWUtb3V0IGRldGVybWluZWQgYnkgdGhlIGZpcmV3YWxsLiBXZSBkaWRu4oCZ dCBpbWFnaW5lIGV4cGxpY2l0IGNvbnRyb2wgb2YgdGhlDQogZmlyZXdhbGwsIGJ1dCBub3RoaW5n IHN0b3BzIGEgbWFuYWdlbWVudCBzeXN0ZW0gZnJvbSBleGVydGluZyBpdHMgY29udHJvbC48bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48 aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxl PSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0 eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGlu ZS1oZWlnaHQ6MTEyJSI+U2VjdGlvbiAzLCBQaGFzZSBJdGVtIDQ6IFNob3VsZCBhIGNvbW1lbnQg YmUgYWRkZWQgdG8gSXRlbSA0IGFib3V0IGNsb3Npbmcgb2YgZmlyZXdhbGwgcnVsZXMsIGV0Yy4m bmJzcDsgSSdtIHRoaW5raW5nIGFib3V0IHRoaXMgc2VwYXJhdGVseSB0aGVuIHRoZSBvcGVuaW5n IG9mIGEgc29ja2V0DQogLyBuZXR3b3JrIHBvcnQgYW5kIHRoZSBjcmVhdGlvbiBvZiB0aGUgYWN0 dWFsIGZpcmV3YWxsIHJ1bGUgYWxsb3dpbmcgYWNjZXNzIHRvIHRoYXQgcG9ydC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEy JSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1i aWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij5bPHNwYW4gY2xhc3M9IlNwZWxsRSI+YWNtPC9zcGFuPl0NCjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjExMSUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJt c28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+b2ssIHdlIGNvdWxkIHNheSB0aGF0IHdlIGRvbuKAmXQgY29udHJvbCB0aGUg RmlyZXdhbGwsIGFuZA0KIGl0IGlzIGFzc3VtZWQgdG8gZGVsZXRlIHRoZSBzdGF0ZSBmb3IgdGhl IHRlc3QgY29tbXVuaWNhdGlvbiBhZnRlciB0cmFmZmljIHN0b3BzIChpbiBwaGFzZXMgMiBhbmQg NCkuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjExMiUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0 OjExMiUiPjxicj4NCjxicj4NCkluIHNlY3Rpb24gNy4xLCBpcyB0aGUgd2F0Y2hkb2cgdGltZXIg dXBkYXRlZCBlYWNoIHRpbWUgYSB0ZXN0IFBEVSBpcyByZWNlaXZlZCwgb3IgZWFjaCB0aW1lIGEg dGVzdCBQRFUgb3Igc3RhdHVzIG1lc3NhZ2UgaXMgcmVjZWl2ZWQuJm5ic3A7IEluIHRoZSBjYXNl IG9mIGRvd25zdHJlYW0gdGVzdGluZywgZm9yIGV4YW1wbGUsIHRoZSBzZXJ2ZXIgaXMgc2VuZGlu ZyBkb3duIHRlc3QgUERVcyBhbmQgcmVjZWl2aW5nIHVwc3RyZWFtIHN0YXR1cyBpbmZvcm1hdGlv bg0KIGZyb20gdGhlIGNsaWVudC4gSWYgdGhlIGNsaWVudCBvciBpdHMgY29ubmVjdGlvbiB3ZXJl IHRvIGRpZSwgdGhlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgdGhpcywgZnJvbSBh IGxhY2sgb2YgdXBzdHJlYW0gc3RhdHVzIG1lc3NhZ2VzLiZuYnNwOyBJdCBpcyBub3QgY2xlYXIg aWYgLyBob3cgdGhpcyBpcyBhY2NvbXBsaXNoZWQgb25seSBhdCB0aGUgcmVjZWl2ZXIgb2YgdGVz dCBQRFVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFs Ij48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPls8c3BhbiBjbGFzcz0iU3BlbGxFIj5hY208L3NwYW4+ XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5v cm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5JbiB0aGUgY3VycmVudCBkcmFmdCwgSSBkZXNj cmliZWQgdGhlIHRpbWUtb3V0cyBvbiB0aGUNCiBUZXN0IFNldHVwLCBUZXN0IEFjdGl2YXRpb24s IGFuZCBUZXN0IFN0cmVhbSByZWNlcHRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxl PSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0 eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+U3Bl Y2lmaWNhbGx5IGluIDcuMTo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5UaGUgd2F0Y2hkb2cgdGltZXIgYXQgdGhlIHJlY2VpdmVyIFNIQUxM IGJlIHJlc2V0IGVhY2ggdGltZSBhIHRlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+ Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5QRFUgaXMgcmVjZWl2ZWQuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5 bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQt c3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5i dXQgSSBuZWVkIHRvIGFkZCB0aGUgc3ltbWV0cmljYWwgdGltZS1vdXQgZm9yIFN0YXR1cyBQRFVz DQogaW4gNywyIChhdCBsZWFzdCBJIGRvbuKAmXQgc2VlIGl0IGluIHRoZSBkcmFmdCkuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxp IHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+SG93ZXZlciwgd2UgaGF2ZSB0aGUgc3ltbWV0cmljYWwgd2F0 Y2hkb2cgdGltZXJzIGluIHRoZQ0KIHJ1bm5pbmcgY29kZSwgYW5kIGFyZSBlbnN1cmluZyBhbGwg dGhlIG5lZWRlZCB0aW1lcnMgYW5kIHRpbWUtb3V0cyBhcHBlYXIgaW4gVFItNDcxIElzc3VlIDIs IFJGQyA5MDk3LXRvLWJlLCBUUi0xODEsIGV0Yy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTIlIj48YnI+DQo8YnI+DQpGb3IgdGhlIFNl dHVwIENvbW1hbmQgUmVzcG9uc2UgQ29kZXMgaW4gU2VjdGlvbiA1LCB0aGVzZSBzZWVtIHRvIGJl IGluZGljYXRlZCBhcyBhbiBFTlVNIHR5cGUgcGFyYW1ldGVyLCBidXQgYXMgYW4gZXhhbXBsZSwg d2hhdCBpZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGNvbmRpdGlvbnMgdG8gYmUgaW5kaWNhdGVkIHRv IHRoZSBjbGllbnQuJm5ic3A7IENvdWxkIHRoZXNlIGJlIG1hZGUgaW50byDigJxmbGFnc+KAnSBz dWNoIHRoYXQgbXVsdGlwbGUgY291bGQgYmUgc2V0LiZuYnNwOw0KIFRoZSBjb25zZXF1ZW5jZSB3 b3VsZCBiZSBsaW1pdGluZyB0aGUgbWF4aW11bSBudW1iZXIgd2l0aGluIHRoZSA4LWJpdCBzaXpl ICh3aGljaCBpcyBhbHJlYWR5IGV4Y2VlZGVkKS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIg c3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZv bnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij5bPHNwYW4gY2xhc3M9IlNwZWxsRSI+YWNtPC9zcGFuPl0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHByZT5Db21tYW5kIFJlc3BvbnNlIENvZGVzPG86cD48L286cD48L3ByZT4N CjxwcmU+Q29udHJvbCBIZWFkZXIgU2V0dXAgUmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9OT05FPHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+MCA9IE5vbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Db250cm9sIEhlYWRlciBTZXR1cCBS ZXF1ZXN0IENvZGUgQ0hTUl9DUlNQX0FDS09LPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+MSA9IEFja25vd2xlZGdlbWVudDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPkNvbnRyb2wgSGVhZGVyIFNldHVwIFJlcXVlc3QgQ29kZSBDSFNSX0NSU1Bf QkFEVkVSPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+ MiA9IEJhZCBQcm90b2NvbCBWZXJzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Q29udHJvbCBI ZWFkZXIgU2V0dXAgUmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9CQURKUzxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjMgPSBJbnZhbGlkIEp1bWJv IGRhdGFncmFtIG9wdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNvbnRyb2wgSGVhZGVyIFNl dHVwIFJlcXVlc3QgQ29kZSBDSFNSX0NSU1BfQVVUSE5DPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+NCA9IFVuZXhwZWN0ZWQgQXV0aGVudGljYXRpb24g aW4gU2V0dXAgUmVxdWVzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNvbnRyb2wgSGVhZGVyIFNl dHVwIFJlcXVlc3QgQ29kZSBDSFNSX0NSU1BfQVVUSFJFUTxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46eWVzIj4mbmJzcDsgPC9zcGFuPjUgPSBBdXRoZW50aWNhdGlvbiBtaXNzaW5nIGluIFNldHVw IFJlcXVlc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Db250cm9sIEhlYWRlciBTZXR1cCBSZXF1 ZXN0IENvZGUgQ0hTUl9DUlNQX0FVVEhJTlY8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+ Jm5ic3A7IDwvc3Bhbj42ID0gSW52YWxpZCBhdXRoZW50aWNhdGlvbiBtZXRob2Q8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5Db250cm9sIEhlYWRlciBTZXR1cCBSZXF1ZXN0IENvZGUgQ0hTUl9DUlNQ X0FVVEhGQUlMIDcgPSBBdXRoZW50aWNhdGlvbiBmYWlsdXJlPG86cD48L286cD48L3ByZT4NCjxw cmU+Q29udHJvbCBIZWFkZXIgU2V0dXAgUmVxdWVzdCBDb2RlIENIU1JfQ1JTUF9BVVRIVElNRSA4 ID0gQXV0aGVudGljYXRpb24gdGltZSBpcyBpbnZhbGlkIGluIFNldHVwIFJlcXVlc3Q8bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUi PjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlk aS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+WWVzLCBpdOKAmXMgYSBnb29kIHBvaW50IEhvdyBkb2VzIHRoZSBwcm90b2NvbCBoYW5k bGUgdGhlDQogbXVsdGlwbGUgZXJyb3IgY2FzZSBleHBsaWNpdGx5IChJ4oCZbSBub3Qgc3VyZSB0 aGF0IHdlIGRvbuKAmXQsIGJ1dCBtb3JlIG5lZWRzIHRvIGJlIHNhaWQsIG9yIGNvbnZlcnQgdG8g ZmxhZ3MgKGV4Y2VwdCB0aGF0IHdlIHJhbiBvdXQgb2YgOCBiaXRzIGFscmVhZHksIGFzIHlvdSBw b2ludC1vdXQhKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13 ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjExMiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJt c28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+SeKAmW0gbGVhdmluZyB0aGlzIGFzIGFuIG9wZW4gaXNzdWUgZm9yIG1vcmUg ZGlzY3Vzc2lvbi48L3NwYW4+PC9pPjwvYj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6 bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjExMiUiPjxicj4NCjxicj4NCkN1 cnJlbnRseSBub25lIG9mIHRoZSBzdGF0dXMgbWVzc2FnZXMgYXJlIHByb3RlY3RlZCBhZ2FpbnN0 IGJpdCBlcnJvcnMgKGkuZS4gbm8gY2hlY2tzdW0gb3Igc2ltaWxhcikuJm5ic3A7IFdvdWxkIHRo ZXJlIGJlIGJlbmVmaXQgaW4gYWRkaW5nIHRoYXQgbGV2ZWwgb2YgcHJvdGVjdGlvbiB0byB0aGUg Y29udHJvbCBjaGFubmVsPyZuYnNwOyBUaGlzIHdvdWxkIHByb3RlY3QgYWdhaW5zdCBhIGJpdCBm bGlwIHRoYXQgY291bGQgY2F1c2UgJnF1b3Q7bWlzYWxpZ25tZW50JnF1b3Q7IGJldHdlZW4NCiB3 aGF0IHRoZSBjbGllbnQgLyBzZXJ2ZXIgYXJlICZxdW90O2RvaW5nLiZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIl Ij48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJp ZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPls8c3BhbiBjbGFzcz0iU3BlbGxFIj5hY208L3NwYW4+XQ0KPG86cD48L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1z by1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij5Qb3NzaWJseSwgdGhlIFN0YXR1cyBQRFUgY291bGQgYmVuZWZpdC48c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7DQo8L3NwYW4+VGhlIGZlZWRiYWNrIHN0YXR1 cyBtZXNzYWdlcyBjb252ZXkgY3JpdGljYWwgbWVhc3VyZW1lbnRzIGZyb20sIE9SIHRoZSBTZW5k aW5nIFJhdGUgU3RydWN0dXJlIHRvLCB0aGUgY2xpZW50LiBNYXliZSB3ZSBhZGQgYSBzdHJvbmdl ciBwcm90ZWN0aW9uIGF0IHRoaXMgcG9pbnQgaW4gdGltZSwgdG8gZW5zdXJlIHRoZXNlIG1lc3Nh Z2VzIGFyZSBub3Qgc3Bvb2ZlZCBieSBhbiBvbi1wYXRoIGF0dGFjayAoQXR0YWNrIGluIHRoZSBt aWRkbGUpLg0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2Vp Z2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox MTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNv LWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPknigJltIGxlYXZpbmcgdGhpcyBhcyBhbiBvcGVuIGlzc3VlIGZvciBtb3JlIGRp c2N1c3Npb24uPC9zcGFuPjwvaT48L2I+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5v cm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTIlIj48YnI+DQo8YnI+DQpBbHNv IHdpdGhpbiB0aGUgU2VjdGlvbiA1IFNldHVwIENvbW1hbmQgSeKAmW0gZ3Vlc3NpbmcgdGhlIGF1 dGhEaWdlc3Qgb2YgdGhlIHNldHVwIHJlcXVlc3QgbWVzc2FnZSBpcyBpbnRlbmRlZCBhcyBhIHNv cnQgb2Yg4oCcc2hhcmVkIHBhc3N3b3Jk4oCdIHRoZSB2YWxpZCBjbGllbnRzIHdvdWxkIHVzZSB0 byBpZGVudGlmeSB0aGVtc2VsdmVzLiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIG1lbnRpb24sIGFz IGFuIGluZm9ybWF0aXZlIGNvbW1lbnQgaXQgbWlnaHQNCiBiZSB3b3J0aCBzZXR0aW5nIG1vcmUg dW5pcXVlIGNyZWRlbnRpYWxzIHBlciBjbGllbnQgdmlhIGFuIG91dCBvZiBiYW5kIG1lY2hhbmlz bSwgbGlrZSBUUi0wNjksIGFzc3VtaW5nIHRlc3RzIGFyZSBiZWluZyBkaXJlY3RlZCBieSBzb21l b25lIGxpa2UgYSBzZXJ2aWNlIHByb3ZpZGVyPyZuYnNwOyBJIGtub3cgc2VjdXJpdHkgaXMgYSBt dWNoIGxhcmdlciB0b3BpYywgYnV0IGRpc2NvdXJhZ2luZyBhbnkgdHlwZSBvZiBzaGFyZWQgY3Jl ZGVudGlhbCBpcw0KIGFsd2F5cyBnb29kIHByYWN0aWNlIGluIG15IG9waW5pb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEx MiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28t YmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+WzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbTwvc3Bhbj5dDQo8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMTElIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0i bXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPlllcywgc2hhcmVkIHBhc3N3b3JkIHdhcyBhIGZlYXR1cmUgZm9yIHRoZSBi ZWdpbm5pbmcgb3Blbi1zb3VyY2UNCiBpbXBsZW1lbnRhdGlvbi4gV2UgZGlkbuKAmXQgd2FudCB0 byBwdXQgdXAgYSBwcm90b2NvbCB3aXRoIGFic29sdXRlbHkgemVybyBhdXRoZW50aWNhdGlvbiwg YW5kIExlbiBhZGRlZCB0aGlzIGxhc3QgU3VtbWVyIGJlZm9yZSB0aGUgZmlyc3QgT0ItVURQU1Qg UmVsZWFzZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTElIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWln aHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPldlIGNhbiBtYWtlIG1vcmUgZXh0ZW5z aXZlIGNoYW5nZXMgd2hlbiBhZGRyZXNzaW5nIHRoZQ0KIHF1ZXN0aW9uIG9mIFNlY3VyaXR5IG1v ZGVzIGFuZCBtZXRob2RzLCBhbmQgVFItMDY5IGlzIHN1cmVseSBhIGdvb2QgT09CIGV4YW1wbGUu PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTExJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1h bCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBz dHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9u dC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PknigJltIGxlYXZpbmcgdGhpcyBhcyBhbiBvcGVuIGlzc3VlIGZvciBtb3JlIGRpc2N1c3Npb24s DQogd2hpY2ggd2lsbCBiZSBzdWJzdW1lZCBieSBkZXRlcm1pbmluZyBuZXcgU2VjdXJpdHkgTW9k ZXMgYW5kIGhvdyB0byBpbXBsZW1lbnQgdGhlbSAoU2VjdGlvbiAxMCkuPC9zcGFuPjwvaT48L2I+ PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRp LWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTEyJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTEyJSI+ UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZXJlIGFyZSBhbnkgb3RoZXIgd2F5cyBJIGNhbiBoZWxw IG91dCwgZ3JlYXQgc3RhcnQgb24gdGhlIHByb3RvY29sITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0i bXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHls ZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPls8c3Bh biBjbGFzcz0iU3BlbGxFIj5hY208L3NwYW4+XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5 bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQt c3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5X aWxsIGRvLCBhbmQgVGhhbmtzIGFnYWluITxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4m bmJzcDsNCjwvc3Bhbj5Mb29rIGZvciBhbiB1cGRhdGVkIGRyYWZ0IG9uIE9jdCAyNSBhdCB0aGUg c3VibWlzc2lvbiBkZWFkbGluZS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTEyJSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjExMiUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0 OjExMiUiPkNoZWVycyw8YnI+DQpMaW5jb2xuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPk9uIFR1ZSwgT2N0IDE5LCAyMDIxIGF0IDY6MzIgUE0g TU9SVE9OIEpSLiwgQUwgJmx0OzxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIj5hY21v cnRvbkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPkhpIElQUE0sPGJyPg0KPGJyPg0K TGVuIENpYXZhdHRvbmUgYW5kIEkgYW0gbG9va2luZyBmb3Igc29tZSBmZWVkYmFjayBvbiBvdXIg cHJvdG9jb2wgWzBdIGRlc2lnbmVkIHRvIGhlbHAgbWVhc3VyZSB0aGUgTWF4aW11bSBJUC1MYXll ciBDYXBhY2l0eSBNZXRyaWMgKHdoaWNoIHdpbGwgYmUgcHVibGlzaGVkIGFzIGFuIFJGQyBzaG9y dGx5KS48YnI+DQo8YnI+DQpXZSBhcmUgYXNraW5nIGZvbGtzIHRvIHRha2UgYSBsb29rIGF0IHRo ZSBkcmFmdCwgYmVjYXVzZSB3ZSBhcmUgZmFpcmx5IHN1cmUgeW91IHdpbGwgaGF2ZSBzb21lIHF1 ZXN0aW9ucyE8YnI+DQo8YnI+DQpPbmUgYXJlYSB3aGVyZSB3ZSBrbm93IG1vcmUgZGV2ZWxvcG1l bnQgaXMgcmVxdWlyZWQgaXMgdGhlIE1vZGVzIG9mIG9wZXJhdGlvbiwgd2hpY2ggZXNzZW50aWFs bHkgZGVzY3JpYmVzIGhvdyB0aGUgZGlmZmVyZW50IGFzcGVjdHMvZXhjaGFuZ2VzIG9mIHRoZSBw cm90b2NvbCB3aWxsIGJlIG1hZGUgc2VjdXJlLiBUaGlzIGlzIHByZXR0eS1tdWNoIGEgZ3JlZW4t ZmllbGQgaW4gb3VyIHNwZWNpZmljYXRpb24sIHNvIHN1Z2dlc3Rpb25zIGFyZSB2ZXJ5DQogd2Vs Y29tZS4mbmJzcDsgU2VjdGlvbiAxMCBjdXJyZW50bHkgZGVzY3JpYmVzIHRoZSBkaWZmZXJlbnQg bW9kZXMgdGhhdCB3ZSBpbWFnaW5lZCB0byBiZSB1c2VmdWwgKEEgdGhyb3VnaCBGIGJlbG93KSwg YnV0IHByYWN0aWNhbCBhc3BlY3RzIG9mIGFueSBwcm9wb3NlZCBzb2x1dGlvbiBtaWdodCBpbmRp Y2F0ZSBtb2RlcyB0aGF0IHNob3VsZCBiZSBjb21iaW5lZCwgc3BsaXQtdXAsIG9yIG5ldyBtb2Rl cy48YnI+DQo8YnI+DQpTbywgcGxlYXNlIGdpdmUgdGhlIGRyYWZ0IGFuZC9vciB0aGUgbGlzdCBi ZWxvdyBhIGxvb2ssIGFuZCBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluay48YnI+DQo8YnI+DQp0 aGFua3MhPGJyPg0KQWwgPGJyPg0KPGJyPg0KPGJyPg0KWzBdIDxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtbW9ydG9uLWlwcG0tY2FwYWNpdHktbWV0cmljLXByb3RvY29sLTAxLnR4dF9fOyEhQmhkVCEz dHZoVnA1S0NjT09MdXFGbjNvZTVoSlMzNTdGSVZUcWF0ZmdrWUhEZ3RkYnBvWDlWSms4eE9GTy1o YlYkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LW1vcnRvbi1pcHBtLWNhcGFjaXR5LW1ldHJpYy1wcm90b2NvbC0wMS50eHQ8L2E+ PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzMuJm5ic3A7IENsaWVudC1zZXJ2ZXIgYXV0aGVudGlj YXRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2ZlZWRiYWNrIG1lc3NhZ2VzIGNvbnZleWluZyBtZWFzdXJlbWVudHMgaXMgUkVD T01NRU5ERUQuJm5ic3A7IFRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWNjb21v ZGF0ZSBkaWZmZXJlbnQgaG9zdCBsaW1pdGF0aW9ucyBhbmQgdGVzdGluZyBjaXJjdW1zdGFuY2Vz LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RpZmZlcmVudCBtb2RlcyBvZiBvcGVy YXRpb24gYXJlIHJlY29tbWVuZGVkOjxicj4NCjxicj4NCiZuYnNwO0EuIFVuLWF1dGhlbnRpY2F0 ZWQgbW9kZSAoZm9yIGFsbCBwaGFzZXMpPGJyPg0KQU5EPGJyPg0KJm5ic3A7Qi4gT1BUSU9OQUwg QXV0aGVudGljYXRlZCBzZXQtdXAgb25seTxicj4NClNIQS0yNTYgSE1BQyB0aW1lLXdpbmRvdyB2 ZXJpZmljYXRpb24gKDUgbWluIHRpbWUgc3RhbXAgdmVyaWZpY2F0aW9uKTxicj4NCihjb3VsZCBh ZGQgc2lsZW50IGZhaWx1cmUgb3B0aW9uKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 LT0tPS09LT0tPS09LT0tPS09LTxicj4NCjxicj4NCiZuYnNwO0MuIEVuY3J5cHRlZCBzZXR1cCBh bmQgdGVzdC1hY3RpdmF0aW9uPGJyPg0KKGN1cnJlbnRseSB1c2luZyBPcGVuU1NMIExpYnJhcnks IHNvIEtJU1MsIGJ1dCBtYXkgYmUgdG9vIHNsb3cgZm9yPGJyPg0KdGVzdCBwYWNrZXRzKTxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7LT0tPS09LT0tLT0tIE9sZC9sb3ctcG93ZXIgaG9z dCBwZXJmb3JtYW5jZSBpbXBhY3RzIC09LT0tPS09LT0tPS08YnI+DQo8YnI+DQombmJzcDtELiBF bmNyeXB0ZWQgZmVlZGJhY2sgbWVzc2FnZXM8YnI+DQo8YnI+DQombmJzcDtFLiBJbnRlZ3JpdHkg cHJvdGVjdGlvbiBmb3IgdGVzdCBwYWNrZXRzIFNIQS0yNTYgSE1BQzxicj4NCjxicj4NCiZuYnNw O0YuIEVuY3J5cHRlZCB0ZXN0IHBhY2tldHMgKG1heWJlIGFsc28gdmFsdWFibGUgdG8gZGVmZWF0 IGNvbXByZXNzaW9uIG9uIGxpbmtzKTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaXBwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtX187ISFCaGRUITN0dmhWcDVLQ2NPT0x1cUZu M29lNWhKUzM1N0ZJVlRxYXRmZ2tZSERndGRicG9YOVZKazh4SUFJeGI0cyQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9Im1zby1zcGVjaWFs LWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGI+TGluY29sbiBMYXZvaWU8L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTEyJSI+UHJpbmNpcGFsIEVuZ2luZWVyLCBCcm9hZGJhbmQgVGVjaG5vbG9naWVz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTEyJSI+MjEgTWFkYnVyeSBSZC4sIFN0ZS4gMTAwLCBEdXJoYW0sIE5I IDAzODI0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGEgaHJlZj0ibWFpbHRvOmx5bGF2b2llQGlvbC51 bmguZWR1IiB0YXJnZXQ9Il9ibGFuayI+bHlsYXZvaWVAaW9sLnVuaC5lZHU8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTEyJSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93 d3cuaW9sLnVuaC5lZHVfXzshIUJoZFQhM3R2aFZwNUtDY09PTHVxRm4zb2U1aEpTMzU3RklWVHFh dGZna1lIRGd0ZGJwb1g5VkprOHhCYVFHT25uJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlvbC51bmguZWR1PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPisxLTYwMy02NzQtMjc1NSAobSk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMTIlIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6L3d3dy5pb2wudW5oLmVkdV9fOyEhQmhkVCEzdHZoVnA1S0NjT09MdXFGbjNvZTVoSlMz NTdGSVZUcWF0ZmdrWUhEZ3RkYnBvWDlWSms4eEJhUUdPbm4kIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9Im1zby1uby1wcm9vZjp5ZXM7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRl cmxpbmU6bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyMDAiIGhlaWdodD0iNDMiIGlkPSJf eDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vdWM/ZXhwb3J0PWRvd25s b2FkJmFtcDtpZD0xal9pSTZhbndybmJRV05wVHl1dnVrTUxTTkpKOF84UVUmYW1wO3JldmlkPTBC XzB1andBQkRuRlpUbUppUjNFekswZDFWakZLVGpRdk1FTkJXVk0wUW5BNGFqaGpQUSI+PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SJ0PR02MB7853902AF803C61008D55523D3BF9SJ0PR02MB7853namp_-- From nobody Thu Oct 21 15:13:28 2021 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 1B2863A0DDA for ; Thu, 21 Oct 2021 15:13:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTy4SfY9Qz3t for ; Thu, 21 Oct 2021 15:13:20 -0700 (PDT) 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 B69663A0DD3 for ; Thu, 21 Oct 2021 15:13:19 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 19LLuZHt016995; Thu, 21 Oct 2021 18:13:15 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 3bugjd0hsn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 18:13:15 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19LMDEqw030826; Thu, 21 Oct 2021 18:13:14 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19LMD6Zw030706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Oct 2021 18:13:07 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 89A424000691; Thu, 21 Oct 2021 22:13:06 +0000 (GMT) Received: from MISOUT7MSGEX2BE.ITServices.sbc.com (unknown [135.66.184.177]) by zlp27129.vci.att.com (Service) with ESMTP id 6CD3840393F2; Thu, 21 Oct 2021 22:13:06 +0000 (GMT) Received: from MISOUT7MSGEX2AF.ITServices.sbc.com (135.66.184.205) by MISOUT7MSGEX2BE.ITServices.sbc.com (135.66.184.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Thu, 21 Oct 2021 18:13:06 -0400 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2AF.ITServices.sbc.com (135.66.184.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Thu, 21 Oct 2021 18:13:06 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.172) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Thu, 21 Oct 2021 18:13:05 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jQuSCVWza4Vfw7xhZdf5K+TCV/0w/p+J1H+yqenVThKRFZgMViqf0++OQhlP9Uyzw9WZHuXwS22lA8xY0NN4arEHwMjmp+MyrD4xSha2jtV1OXrSdx3WHdeeXXmTV61Zx2JBwaKcJVtBj3uIomRb/nl/YWQUG/LbLx0ximZg8nhwiHjTj8Bs8iG/HZvFwbezP1QogirQZ1Z5JbcoPAfhENMnuySPC2XIKN8PPmVccuJxSKCUT5FkhLm+VzBvnm6UYrSFxXL1++15ucNX5FX8Cvu75eJf2ySGbRFF4Z7hC6VyNyHCgUry0muEUxrtzgZH6h70cDynDgmfpcbxt1vdow== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TL/uhz1nghAl8vWbGaAWkE9CXg7iEE+M/JlSQ7xaE8I=; b=h2usGeTRpKrq2facWuGwkA4+pD9EWSbG1GzdEJBqgFtkfUzV6yR0wL/K/JDqfvApJI8IY2DKO2oFaK9auDrQuQBZw3y8zq643keyBYCAgnru7O4twbTNlNPuVqg9JZGoeuMOcNkwSdMoRn/QBy/RIh0BW4VPtzz6mSS3LH9kTizXAtXZMWgkGai7Zub7mSh9N7a9CtoBxQ+EQ5rald8KdVW4XjAGEyhhJJ4gdoo9digDOeMEPDUa5DqTgVKfWu/WJ2wPV2+6QM9WQEGSQgmws2lT6u6KeYAwuFNam/YUhU5n4RCunCTM43TSL528xpGmHlXsb21h3aa45Q+jKmEP7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TL/uhz1nghAl8vWbGaAWkE9CXg7iEE+M/JlSQ7xaE8I=; b=s0meSP6ap3FzYwHOlpdIRDZuglyxDzVmnsEquVLJ6ObBP7/Tw3kDna2nBuTyljL+U2tfZH749x1H5JtSXhKtA954arJGKtYs6VVvMPb/7MWlLoGGKKXFzXHJORUR2XauEiN9oRPHxtntXU7fL/sS0TDp55R/kb8zBdFJ3AMN2Zo= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB3912.namprd02.prod.outlook.com (2603:10b6:a02:f3::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Thu, 21 Oct 2021 22:12:58 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%5]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 22:12:58 +0000 From: "MORTON JR., AL" To: can desem CC: IETF IPPM WG Thread-Topic: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AQHXxk1huB4ab3lltkyFtEOpcbBpI6vd/D3w Date: Thu, 21 Oct 2021 22:12:58 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19d511d3-1aa9-4c95-7d4e-08d994dff0d1 x-ms-traffictypediagnostic: BYAPR02MB3912: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nXW0tNvR7tzX1ElUAOluqMp8tQF2wMLGmQ93YV5nw12CuMXY0Mas6fMvbKLPS01UfP9DE5daYPzro7K1EElRAHPpDc/lsLJZfsITo2aGvG4/KHQuDo3IaGKi2drCO1fVnftZmvYmmJaun/RqXUmkVrn69YqsqQXn1RMKnFmlM2r4z92M412LZrzt+GOM3fGwUIn+g5AEctY0F8ifbHNDsd4wva8w9o6H48Fpj4RBOhS8ELcK8D3AbE/LDYxPTQDAkhp+b+ERo++0YUfUCK1efk0m0hOAnE4roh6hP51LaSVzL0U+/W+dT+QILmTLcxVoLM1UomxDO42E/y8yLm0JSgm2cql/iB8mqzw4f7q0uFt0pUL2xiWFzIcK7Qlabd7U1OTWxY5ZPnDsd6Q5V3ZeJmT5DxR3k2gxbWqh5LKj+CQ0gnmr/1j9FtZpXZNVo3i08mCvBxpeZzT/YUo/90J4eKSe63VMM7+cKeEGkO6SeMv6/YNT9C48vPCqhltVwSwa/5okNsli1cPokAwnUxxCYAZwJPAxFAPyC9Klzc6wu3YJidikvBy3jpemb0YO+RhrcdUtmacLbS6hfzXObnQZRjBuG4WOJL7CkcwuLcdzeGmIdUjHe1a6Cc1AvqITxSFkXABoDMQWXj6G8d4RrQCeDLLCDQf0ioeXABZsrOIiEcDbGRaPTqH+PjVCyNCLCax78lfa4O+LZk0y2QIQHjZjGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(8936002)(508600001)(316002)(9326002)(8676002)(9686003)(71200400001)(38070700005)(82202003)(86362001)(6506007)(55016002)(52536014)(5660300002)(38100700002)(4326008)(82960400001)(6916009)(83380400001)(66946007)(53546011)(7696005)(2906002)(76116006)(64756008)(66556008)(186003)(66476007)(26005)(66446008)(122000001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bzlWU1UyQVJaWTJVS0RKNHNGaHZpNE9vaGJia1NaYThMVjVzdnR0cGpCS2Rl?= =?utf-8?B?Y3V0cHRKcmNHV0htQzNzek5DNVFUNG9LaTIwRXNlc1RaMmNDREpZWk5scDZx?= =?utf-8?B?QytjZk5LVVprTHo3NlRhaUNBQnRyN3BQUjk3RzllaDBndFlwOGVMK3ptNGtT?= =?utf-8?B?ZnFWOFpvNi9TSGJQUk5mTzU0eWtJSVVINHFWWENRVVhOVENTdGlWd3RWa0FT?= =?utf-8?B?VFFMYUdvK3pvdWNnQmZxWTQ3MHQxdUhtN2ZxeDNjTkJzam5JNzQ0cGVUM3Ra?= =?utf-8?B?WXBRMzlWcDM5c3FFRjVJYlBFY0d3RDdTMUVIZTBuVnFLZmlMMVVPVk1ZQlc2?= =?utf-8?B?S251V09hVWgvWHQzOEhpQkhIMUNtY3krL2RrNGxaOXRzR09jNmZjS3NFN0Qv?= =?utf-8?B?SS9raTArYzlmZFVvdmNqSTJ3MXRwU3VlOGNwaHpuNi9VckgzRll6cy9FTXhL?= =?utf-8?B?RzVIOFlSL2dJalNaUW4wK3BPSFZ3alpjUC9XdzVRWWtoM2JYb3F0ZUxGY3dF?= =?utf-8?B?RWF1dW9JZU16Y0MwTUQxTEU0OTF5UXVjNmtJZi91Y2U2Zk0zUDhORStvVkNi?= =?utf-8?B?bXR2Rm51OHlZUGpwQXBWNDFMaVBKZnhlZjF1NkVFS1IvbWhOSEtSSzlCOWVR?= =?utf-8?B?ZHhObkJWYWdjUXRGeUwzdnNxdTNXblpLbXk3cGU2Q0UwQ0EwUGNVcWwrRTIy?= =?utf-8?B?MkhqNTZDR3cvK0U2ZXpBdlNRenZkQ0I0WVhIRUpnci90My9NVnAwdEpXa0Rq?= =?utf-8?B?YXNibDU2cm5YT1NDQWxuM0NQVXlhZ0tpanMzSU1IZnFMSjhrNC9sQ1BoSUNE?= =?utf-8?B?SmwwMnVzOWNoQWxJc3dlNllLdFpvMUdNK2tXbysrS0tLSHhxS2JjYTZpWHlk?= =?utf-8?B?LzBGMzg5bVBMWnF2RWt1MkVIaXlZVEZzd3R2N2JTRURhUi9pTytYeCtlR3Bh?= =?utf-8?B?NmtWZitUeTN3R2REendsdy9NbGlUdlc3akk1Ny90dTBmalJ3VXR2ZWdJRm9q?= =?utf-8?B?UkdKM1BLakpkNUJPUlMzRTB4V2pZdjhoaXlqeUQvdzNMalhXbWdHbkJuMzg1?= =?utf-8?B?RTFlQlpxeGhTVi81RklHQmZsdHVYZGVES2ZEOG9uSHVJV2xCRG1oaVkvdUFI?= =?utf-8?B?TXNzU0E1VVJqUjdFRjl1aXVPaFJnRXlUSkRLakJJdkFqbTNnTkpvRnN1N1Fs?= =?utf-8?B?SFp3M2xKZTlXaVorbHpmMldRTkdJL0F3Vnl4MlJDK2lOdWxGOVdEYTI5dTlr?= =?utf-8?B?ZG1SemlWemNhUVppQTEvell6WEJMUEUzR2Z1bXJpOENxS0s5Z3NOK2dRcGxL?= =?utf-8?B?YndEcjBCbVV2OHA0NGRPaVRMVm5nbGl6aU9QeEExN3pESnVIVytLYXNsZ3Bp?= =?utf-8?B?eFZTTU9JazBJeGpIdlM2TVZLVk5MeFVURVRVRU5abDdMWlVBMWwzWlc0VnFV?= =?utf-8?B?eHdhcFNWSmY5RnNmNHk0WURoTGFLQW5GT1pLdTdPTVNGMmlpSnROWUlEVFBJ?= =?utf-8?B?QTZqN1BFNDFURkhodnhHcFJjaDA0VmlaYjUzRUZlS0tRbHhMK05ueCtCOHky?= =?utf-8?B?MXN0SENBNk92MmltdDloTzd1RkdmTVZENEJaclg5VmxnWkwrT3d1MWFyNnd1?= =?utf-8?B?SGFES254M2RObnlycnBZU1hvaVpLRk1NL2xTNk9TZWFaYzJ6a0pvK3ZOSjlz?= =?utf-8?B?MCs2NTVZMVIxUSs4a1FIVlY1cm9oK1kvWFJFZ0FRZS9sMzdiTUNXbCsrWWNR?= =?utf-8?Q?JbP7oViNjsBAzEwp3FphNI9RS9HhccQGDI5iJU2?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB78530D4D2CF2CFDE85179D8DD3BF9SJ0PR02MB7853namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19d511d3-1aa9-4c95-7d4e-08d994dff0d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 22:12:58.8036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: am2935@att.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB3912 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 2583F7CE7CB757FECCB0A443094F19895717AC149225F27886588495BEE35B2D2 X-Proofpoint-ORIG-GUID: dnXPMKOR3V2i2mrFuyhI-UOjXya67qZ6 X-Proofpoint-GUID: dnXPMKOR3V2i2mrFuyhI-UOjXya67qZ6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_06,2021-10-21_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 clxscore=1015 impostorscore=0 adultscore=0 mlxscore=0 malwarescore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110210111 Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 21 Oct 2021 22:13:25 -0000 --_000_SJ0PR02MB78530D4D2CF2CFDE85179D8DD3BF9SJ0PR02MB7853namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FuLA0KDQpUaGFua3MgZm9yIGpvaW5pbmcgdGhlIGRpc2N1c3Npb24gaGVyZSwgYW5kIGZv ciBzaGFyaW5nIHlvdXIgcmV2aWV3IHdpdGggZ29vZCBpZGVhcyENCg0KSeKAmWxsIHJlcGx5IHRv IGVhY2ggbWFqb3IgcG9pbnQgYW5kIHN1Z2dlc3Rpb24gYmVsb3csIFthY21dLCBhbmQgd29yayB3 aXRoIExlbiB0byBzZWUgaG93IHdlIG1pZ2h0IGFkZCB0aGVzZSBmZWF0dXJlcyB0byB0aGUgcHJv dG9jb2wuDQoNCkFsDQoNCkZyb206IGNhbiBkZXNlbSA8Y2Rlc2VtQGdtYWlsLmNvbT4NClNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDIxLCAyMDIxIDM6MjkgQU0NClRvOiBNT1JUT04gSlIuLCBBTCA8 YWNtb3J0b25AYXR0LmNvbT4NCkNjOiBJRVRGIElQUE0gV0cgPGlwcG1AaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW2lwcG1dIFF1ZXN0aW9ucyBvbiBkcmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1t ZXRyaWMtcHJvdG9jb2wtMDENCg0KSGkgQWwsIElQUE0gZ3JvdXAsDQoNCkkgYmVsaWV2ZSB0aGlz IHdpbGwgcG90ZW50aWFsbHkgYmUgYSByZWFsbHkgdXNlZnVsIHRvb2wgZm9yIG1lYXN1cmluZyBz cGVlZHMsIGVzcGVjaWFsbHkgaWYgd2UgY2FuIGluY29ycG9yYXRlIGl0IGluIG5ldHdvcmsgdGVy bWluYXRpbmcgZGV2aWNlcyBzdWNoIGFzIGN1c3RvbWVyIGdhdGV3YXlzIGV0Yy4NClthY21dDQpU aGFua3MhDQpXZSBoYXZlIGhhZCBzb21lIHN1Y2Nlc3Mgb24gdGhpcyBmcm9udCwgd2l0aCBjdXN0 b21lciBwcmVtaXNlcyBlcXVpcG1lbnQgYW5kIHNtYWxsL2luZXhwZW5zaXZlIGhvc3RzLiBUaGUg cnVubmluZyBjb2RlIGhhcyBhbiBvcHRpb24gdG8gaGVscCB3aXRoIG9sZGVyIGhhcmR3YXJlLCBj bG9ja3MgdGhhdCBhcmUgc2xvdyBieSB0b2RheeKAmXMgc3RhbmRhcmRzLCBldGMuDQoNCldpdGgg cmVnYXJkcyB0aGUgdmFyaW91cyBvcHRpb25zIGZvciB0aGUgbW9kZXMgb2Ygb3BlcmF0aW9uLCBJ IHRoaW5rIGVuY3J5cHRpbmcgdGhlIHBheWxvYWQgd2lsbCBhZGQgYWRkaXRpb25hbCBjcHUgbG9h ZCB3aXRob3V0IGFkZGluZyBtdWNoIGJlbmVmaXQgZXZlbiB0aG91Z2ggaXQgbWF5IGJlIHZhbHVh YmxlIHRvIGRlZmVhdCBjb21wcmVzc2lvbiBvbiBsaW5rcy4NClthY21dDQpBZ3JlZWQsIHRoZXJl IGlzIGEgdGVuc2lvbiBiZXR3ZWVuIHRoZSBzZWN1cml0eSBiZW5lZml0cyBhbmQgdGhlIGFiaWxp dHkgb2Ygc29tZSBuZXR3b3JrIHRlcm1pbmF0aW5nIGRldmljZXMgdG8gb3BlcmF0ZSBhdCBmdWxs IGxpbmUgcmF0ZS4gVGhlIHNpbXBsZSBhcHByb2FjaCBvZiBlbmNyeXB0aW5nIGV2ZXJ5dGhpbmcg bWlnaHQgcmVkdWNlIHRoZSB1bml2ZXJzZSBvZiBoYXJkd2FyZSBzdXBwb3J0IG9mIG1lYXN1cmVt ZW50cyBhdCAxIEdicHMsIGZvciBleGFtcGxlLg0KDQpJbnN0ZWFkLCBoYXZpbmcgYW4gb3B0aW9u IHRvIHJhbmRvbWl6ZSB0aGUgcGF5bG9hZCBtYXkgYmUgbGVzcyBwcm9jZXNzIGludGVuc2l2ZSBh bmQgYWNoaWV2ZSB0aGUgc2FtZSBnb2FsLg0KW2FjbV0NClllcywgdGhhdCBzZWVtcyBsaWtlIGEg Z29vZCBvcHRpb24gdG8gaGF2ZSBhdmFpbGFibGUgd2hlbiBsaW5rIGNvbXByZXNzaW9uIGlzIHBy ZXNlbnQuIFRoYW5rcyEgIFdlIGNvdWxkIGhhdmUgc2V2ZXJhbCBvcHRpb25zIGluIGFkZGl0aW9u IHRvIHBzZXVkby1yYW5kb20gcGF5bG9hZCBjb250ZW50LiBJ4oCZbGwgYWRkIHRoaXMgYXMgYSBU byBEbyBpbiB0aGUgbmV4dCBkcmFmdC4NCg0KQW5vdGhlciBzdWdnZXN0aW9uIHRoYXQgd291bGQg YmUgZXh0cmVtZWx5IHVzZWZ1bCwgaWYgdGhpcyBtZWFzdXJlbWVudCB0b29sIHdlcmUgdG8gYmUg ZW1wbG95ZWQgaW4gYSBnYXRld2F5IGxpa2UgZGV2aWNlLCB3b3VsZCBiZSB0byB0YWtlIGludG8g Y29uc2lkZXJhdGlvbiB0aGUgZXhpc3RpbmcgdHJhZmZpYyB0aGF0IG1heSBiZSBwcmVzZW50IHdo aWxlIHJ1bm5pbmcgc3VjaCBhIHRlc3QuIEZvciBleGFtcGxlLCBtb25pdG9yaW5nIHRoZSB0b3Rh bCB0cmFmZmljICh3aGljaCBjb3VsZCBiZSBhcyBzaW1wbGUgYXMgY291bnRpbmcgdGhlIGJ5dGVz IG9uIGEgV0FOIGludGVyZmFjZSBvbiBhIGdhdGV3YXkpIGFzIHRoZSB0ZXN0IGlzIHJ1biBhbmQg aW5jbHVkaW5nIHRoaXMgYXMgcGFydCBvZiB0aGUgbWVhc3VyZW1lbnQgcHJvY2VzcyB3b3VsZCBy ZXN1bHQgaW4gbW9yZSBhY2N1cmF0ZSBtZWFzdXJlbWVudHMgb2YgdGhlIGxpbmUgc3BlZWQuIFRo aXMgY291bGQgYmUgYWRkZWQgYXMgYW4gb3B0aW9uIGluIHRoZSBwcm90b2NvbCB3aGljaCBjYW4g YmUgdXNlZCB3aGVuIHJlcXVpcmVkIGluIHRoZSBkZXNjcmliZWQgc2NlbmFyaW8uDQpbYWNtXQ0K WWVzLCBpZGVhbGx5IHRoZSBNYXhpbXVtIElQLUxheWVyIENhcGFjaXR5IG1lYXN1cmVtZW50IHdv dWxkIGJlIG1hZGUgd2l0aG91dCBjb21wZXRpbmcgdHJhZmZpYywgaGF2aW5nIGEgd2F5IHRvIGNv dW50IHRoZSBjb21wZXRpbmcgdHJhZmZpYyBnb2VzIGEgbG9uZyB3YXkgdG8gZXhwbGFpbmluZyBt ZWFzdXJlbWVudCByZXN1bHRzIHdoZW4gYWRkaXRpb25hbCB0cmFmZmljIGlzIHByZXNlbnQuIFdl IHN0aWxsIG5lZWQgdG8gZmlsbCB0aGUgcGlwZSB0byBtZWFzdXJlIHRoZSBtYXgsIGFuZCBub3Jt YWwgYXBwbGljYXRpb25zIGRvbuKAmXQgdGVuZCB0byBkbyB0aGF0LiBZb3UgYW5kIExlbiBhbmQg SSBoYXZlIGJlZW4gcnVubmluZyBzb21lIHRlc3RzIHRvIGludmVzdGlnYXRlIHRoZSBmZWFzaWJp bGl0eSBvZiB0aGlzIGZlYXR1cmUg4oCTIHNvIGZhciBzbyBnb29kLi4uICBUaGlzIGlzIGFsc28g b24gdGhlIFRvIERvIGxpc3QuDQoNClJlZ2FyZHMsDQpDYW4gRGVzZW0NClthY21dDQpBZ2Fpbiwg bWFueSB0aGFua3MsIENhbiENCg0KDQoNCg0K --_000_SJ0PR02MB78530D4D2CF2CFDE85179D8DD3BF9SJ0PR02MB7853namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDdDNkE3LjQ2NjQxMDgwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRLaW5kPg0KPHc6VHJhY2tN b3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRh dGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhN TEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250 ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxh Y2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1V UzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4 U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0K PHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNuYXBUb0dyaWRJbkNlbGwvPg0KPHc6V3JhcFRl eHRXaXRoUHVuY3QvPg0KPHc6VXNlQXNpYW5CcmVha1J1bGVzLz4NCjx3OkRvbnRHcm93QXV0b2Zp dC8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5p bmcvPg0KPHc6RG9udEZsaXBNaXJyb3JJbmRlbnRzLz4NCjx3Ok92ZXJyaWRlVGFibGVTdHlsZUhw cy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJD YW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIg bTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYv Pg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVm SmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8 bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8 L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERl ZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9 ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjM3NiI+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9 Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXgg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJh bm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2Fw dGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52 ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJl ciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2Yg YXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNp Z25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJh Z3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0 bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5 IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxv d2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAo V2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i SFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3Vi amVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBs ZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBD bGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29s dW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg R3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlz dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZm ZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9u YWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2Vi IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJs ZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIg VGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlk Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRp dW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4 IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNv bG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5h bWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNl IFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1l ZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0i Q29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xv cmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJM aWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9 Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwg TGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVt IEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWlu IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUi IE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBU YWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIg TmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQg VGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikdy aWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRh YmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlk IFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRh YmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJs ZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBU YWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJs ZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUg MiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFi bGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUg NyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxl IDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1 IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0 IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi IE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBD b2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIg TmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3Qg VGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFt ZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5h bWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRh YmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9 Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1l PSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJs ZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJM aXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0i TGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUg MyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlz dCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxp c3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3Qg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0 IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO YW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRh YmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZW50aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNtYXJ0 IEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIYXNodGFnIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlVucmVzb2x2ZWQgTWVudGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTbWFy dCBMaW5rIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1h bHQ6IlBhbGF0aW5vIExpbm90eXBlIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy aWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOi01MzY4NjkxMjEgMTEwNzMwNTcyNyAzMzU1NDQzMiAwIDQxNSAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNlbnR1cnkgR290aGljIjsNCgltc28tZm9udC1jaGFy c2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi00Njk3NTAwMTcgLTEwNzM3MzI0ODUgOSAw IDUxMSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFm b3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltc28tcGFn aW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ dGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS11bmhp ZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1hc2NpaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1oYW5zaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5TcGVsbEUNCgl7 bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLXNwbC1lOnllczt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9wczp5ZXM7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQouTXNvUGFwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglsaW5l LWhlaWdodDoxMTIlO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVp bjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MGluOw0KCWxpbmUtaGVpZ2h0OjExMiU7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KPC9zdHls ZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIiBzdHlsZT0idGFiLWludGVydmFsOi41aW47d29yZC13cmFwOmJyZWFrLXdvcmQiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkhpIENhbiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5UaGFua3Mg Zm9yIGpvaW5pbmcgdGhlIGRpc2N1c3Npb24gaGVyZSwgYW5kIGZvciBzaGFyaW5nIHlvdXIgcmV2 aWV3IHdpdGggZ29vZCBpZGVhcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5J4oCZbGwgcmVwbHkgdG8gZWFjaCBtYWpvciBw b2ludCBhbmQgc3VnZ2VzdGlvbiBiZWxvdywgWzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbTwvc3Bh bj5dLCBhbmQgd29yayB3aXRoIExlbiB0byBzZWUgaG93IHdlIG1pZ2h0IGFkZCB0aGVzZSBmZWF0 dXJlcyB0byB0aGUgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+QWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4gY2FuIGRlc2VtICZsdDtjZGVz ZW1AZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDIx LCAyMDIxIDM6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IE1PUlRPTiBKUi4sIEFMICZsdDthY21vcnRv bkBhdHQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBJUFBNIFdHICZsdDtpcHBtQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2lwcG1dIFF1ZXN0aW9ucyBvbiBkcmFm dC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjExMiUiPkhpIEFsLCBJUFBNIGdyb3VwLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMTIlIj5JIGJlbGlldmUgdGhpcyB3aWxsIHBvdGVudGlhbGx5IGJlIGEgcmVhbGx5IHVzZWZ1 bCB0b29sIGZvciBtZWFzdXJpbmcgc3BlZWRzLCBlc3BlY2lhbGx5IGlmIHdlIGNhbiBpbmNvcnBv cmF0ZSBpdCBpbiBuZXR3b3JrIHRlcm1pbmF0aW5nIGRldmljZXMgc3VjaCBhcyBjdXN0b21lciBn YXRld2F5cyBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCI+ PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5bPHNwYW4gY2xhc3M9IlNwZWxsRSI+YWNtPC9zcGFuPl0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3Jt YWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VGhhbmtzITxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46eWVzIj4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNv LWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpu b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztt c28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPldlIGhhdmUg aGFkIHNvbWUgc3VjY2VzcyBvbiB0aGlzIGZyb250LCB3aXRoIGN1c3RvbWVyIHByZW1pc2VzDQog ZXF1aXBtZW50IGFuZCBzbWFsbC9pbmV4cGVuc2l2ZSBob3N0cy4gVGhlIHJ1bm5pbmcgY29kZSBo YXMgYW4gb3B0aW9uIHRvIGhlbHAgd2l0aCBvbGRlciBoYXJkd2FyZSwgY2xvY2tzIHRoYXQgYXJl IHNsb3cgYnkgdG9kYXnigJlzIHN0YW5kYXJkcywgZXRjLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox MTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj5XaXRoIHJlZ2FyZHMgdGhlIHZhcmlvdXMg b3B0aW9ucyBmb3IgdGhlIG1vZGVzIG9mIG9wZXJhdGlvbiwgSSB0aGluayBlbmNyeXB0aW5nIHRo ZSBwYXlsb2FkIHdpbGwgYWRkIGFkZGl0aW9uYWwgY3B1IGxvYWQgd2l0aG91dCBhZGRpbmcgbXVj aCBiZW5lZml0IGV2ZW4gdGhvdWdoIGl0IG1heSBiZSB2YWx1YWJsZSB0byBkZWZlYXQgY29tcHJl c3Npb24gb24gbGlua3MuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9y bWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPls8c3BhbiBjbGFzcz0iU3BlbGxFIj5hY208L3Nw YW4+XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0 Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5BZ3JlZWQsIHRoZXJlIGlzIGEgdGVuc2lv biBiZXR3ZWVuIHRoZSBzZWN1cml0eSBiZW5lZml0cw0KIGFuZCB0aGUgYWJpbGl0eSBvZiBzb21l IG5ldHdvcmsgdGVybWluYXRpbmcgZGV2aWNlcyB0byBvcGVyYXRlIGF0IGZ1bGwgbGluZSByYXRl LiBUaGUgc2ltcGxlIGFwcHJvYWNoIG9mIGVuY3J5cHRpbmcgZXZlcnl0aGluZyBtaWdodCByZWR1 Y2UgdGhlIHVuaXZlcnNlIG9mIGhhcmR3YXJlIHN1cHBvcnQgb2YgbWVhc3VyZW1lbnRzIGF0IDEg R2JwcywgZm9yIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PGIgc3R5bGU9Im1zby1iaWRp LWZvbnQtd2VpZ2h0Om5vcm1hbCI+PGkgc3R5bGU9Im1zby1iaWRpLWZvbnQtc3R5bGU6bm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxMTIlIj5JbnN0ZWFkLCBoYXZpbmcgYW4gb3B0aW9uIHRvIHJhbmRvbWl6ZSB0aGUg cGF5bG9hZCBtYXkgYmUgbGVzcyBwcm9jZXNzIGludGVuc2l2ZSBhbmQgYWNoaWV2ZSB0aGUgc2Ft ZSBnb2FsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjExMiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0 eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+WzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbTwvc3Bhbj5dDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48 aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPlllcywgdGhhdCBzZWVtcyBsaWtlIGEgZ29vZCBvcHRpb24g dG8gaGF2ZSBhdmFpbGFibGUgd2hlbg0KIGxpbmsgY29tcHJlc3Npb24gaXMgcHJlc2VudC4gVGhh bmtzITxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsgPC9zcGFuPldlIGNvdWxk IGhhdmUgc2V2ZXJhbCBvcHRpb25zIGluIGFkZGl0aW9uIHRvIHBzZXVkby1yYW5kb20gcGF5bG9h ZCBjb250ZW50LiBJ4oCZbGwgYWRkIHRoaXMgYXMgYSBUbyBEbyBpbiB0aGUgbmV4dCBkcmFmdC48 L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEyJSI+QW5v dGhlciBzdWdnZXN0aW9uIHRoYXQgd291bGQgYmUgZXh0cmVtZWx5IHVzZWZ1bCwgaWYgdGhpcyBt ZWFzdXJlbWVudCB0b29sIHdlcmUgdG8gYmUgZW1wbG95ZWQgaW4gYSBnYXRld2F5IGxpa2UgZGV2 aWNlLCB3b3VsZCBiZSB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbiB0aGUgZXhpc3RpbmcgdHJh ZmZpYyB0aGF0IG1heSBiZSBwcmVzZW50IHdoaWxlIHJ1bm5pbmcNCiBzdWNoIGEgdGVzdC4gRm9y IGV4YW1wbGUsIG1vbml0b3JpbmcgdGhlIHRvdGFsIHRyYWZmaWMgKHdoaWNoIGNvdWxkIGJlIGFz IHNpbXBsZSBhcyBjb3VudGluZyB0aGUgYnl0ZXMgb24gYSBXQU4gaW50ZXJmYWNlIG9uIGEgZ2F0 ZXdheSkgYXMgdGhlIHRlc3QgaXMgcnVuIGFuZCBpbmNsdWRpbmcgdGhpcyBhcyBwYXJ0IG9mIHRo ZSBtZWFzdXJlbWVudCBwcm9jZXNzIHdvdWxkIHJlc3VsdCBpbiBtb3JlIGFjY3VyYXRlIG1lYXN1 cmVtZW50cyBvZiB0aGUNCiBsaW5lIHNwZWVkLiBUaGlzIGNvdWxkIGJlIGFkZGVkIGFzIGFuIG9w dGlvbiBpbiB0aGUgcHJvdG9jb2wgd2hpY2ggY2FuIGJlIHVzZWQgd2hlbiByZXF1aXJlZCBpbiB0 aGUgZGVzY3JpYmVkIHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdo dDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+WzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFj bTwvc3Bhbj5dDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHlsZT0ibXNvLWJpZGktZm9udC13 ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPlllcywgaWRlYWxseSB0aGUgTWF4 aW11bSBJUC1MYXllciBDYXBhY2l0eSBtZWFzdXJlbWVudA0KIHdvdWxkIGJlIG1hZGUgd2l0aG91 dCBjb21wZXRpbmcgdHJhZmZpYywgaGF2aW5nIGEgd2F5IHRvIGNvdW50IHRoZSBjb21wZXRpbmcg dHJhZmZpYyBnb2VzIGEgbG9uZyB3YXkgdG8gZXhwbGFpbmluZyBtZWFzdXJlbWVudCByZXN1bHRz IHdoZW4gYWRkaXRpb25hbCB0cmFmZmljIGlzIHByZXNlbnQuIFdlIHN0aWxsIG5lZWQgdG8gZmls bCB0aGUgcGlwZSB0byBtZWFzdXJlIHRoZSBtYXgsIGFuZCBub3JtYWwgYXBwbGljYXRpb25zIGRv buKAmXQgdGVuZA0KIHRvIGRvIHRoYXQuIFlvdSBhbmQgTGVuIGFuZCBJIGhhdmUgYmVlbiBydW5u aW5nIHNvbWUgdGVzdHMgdG8gaW52ZXN0aWdhdGUgdGhlIGZlYXNpYmlsaXR5IG9mIHRoaXMgZmVh dHVyZSDigJMgc28gZmFyIHNvIGdvb2QuLi48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+ Jm5ic3A7DQo8L3NwYW4+VGhpcyBpcyBhbHNvIG9uIHRoZSBUbyBEbyBsaXN0LiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPkNhbiBEZXNlbSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxiIHN0eWxlPSJt c28tYmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxpIHN0eWxlPSJtc28tYmlkaS1mb250LXN0eWxl Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+WzxzcGFu IGNsYXNzPSJTcGVsbEUiPmFjbTwvc3Bhbj5dDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48YiBzdHls ZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48aSBzdHlsZT0ibXNvLWJpZGktZm9udC1z dHlsZTpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkFn YWluLCBtYW55IHRoYW5rcywgQ2FuITxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExMiUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox MTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIlIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTIl Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_SJ0PR02MB78530D4D2CF2CFDE85179D8DD3BF9SJ0PR02MB7853namp_-- From nobody Thu Oct 21 23:27:42 2021 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 666273A0835 for ; Thu, 21 Oct 2021 23:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5MSb7P54G6Y for ; Thu, 21 Oct 2021 23:27:36 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D791E3A003C for ; Thu, 21 Oct 2021 23:27:35 -0700 (PDT) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HbDnP2tj5z67Ys9 for ; Fri, 22 Oct 2021 14:23:37 +0800 (CST) Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 08:27:32 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 14:27:30 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Fri, 22 Oct 2021 14:27:30 +0800 From: Tianran Zhou To: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 Thread-Index: AdfHDWLNvY93aiAGSwChY0Q0ZX5bBQ== Date: Fri, 22 Oct 2021 06:27:29 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_ce971b44dfcf45be897b7415797cf133huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 22 Oct 2021 06:27:41 -0000 --_000_ce971b44dfcf45be897b7415797cf133huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, There are many interests in this working group working on the alternate mar= king, RFC8321 and RFC8889. As you may have seen, we applied this method in IPv6, and the draft is in I= ESG review. https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ Based on the above draft, and the comments/suggestions we received, we prod= uced an Enhanced Alternate Marking Method. https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking= / This document extends the IPv6 Alternate Marking Option, to provide the en= hanced capabilities and allow advanced functionalities. We hope you like this idea. Any comments are welcome. Thanks, Tianran --_000_ce971b44dfcf45be897b7415797cf133huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi WG,

     

    There are many interests in this working group worki= ng on the alternate marking, RFC8321 and RFC8889.

    As you may have seen, we applied this method in IPv6= , and the draft is in IESG review.

    https://datatracker.ietf.org/doc/draft-ietf-6man-ip= v6-alt-mark/

     

    Based on the above draft, and the comments/suggestio= ns we received, we produced an Enhanced Alternate Marking Method.

    https://datatracker.= ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/

     

    This document extends the IPv6 Alt= ernate Marking Option,  to provide the enha= nced capabilities and allow advanced functionalities.

     

    We hope you like this idea.

    Any comments are welcome.

     

    Thanks,

    Tianran

    --_000_ce971b44dfcf45be897b7415797cf133huaweicom_-- From nobody Fri Oct 22 10:48:42 2021 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 365C43A081C for ; Fri, 22 Oct 2021 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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=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 12yCeYqFsedn for ; Fri, 22 Oct 2021 10:48:34 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (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 6AADA3A080B for ; Fri, 22 Oct 2021 10:48:34 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19MHltgS015731 for ; Fri, 22 Oct 2021 10:48:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=1xESU+VrKVs8nty7Bfv77DFDPHmBFxMgE1jLqz1Z8q4=; b=onRmxZkd45lPCnab5r1Sv1KLed1c6YysvyGl/mstRuIYpURk2DFfq/WdhBsBV2FJVSj1 iq0yFPYiQwnSryi9QE/2wBYQCsCaJ3b+Nfdw/2JHahZjNV3GeYtte0VLbJl6pU+2jEFA 0D0f0N1BcvbZMh4DOyXbYadA0hq/sOSDOALv5+mYXm0blkHecA8t3t1hazovOLlghoKa 4DinQzG8J1D7F3qkVej1r23y7Jvpd9ZUWm/6KklYixniJ6/25d38rbuN5yy/2RGkSqie okbFy6eNq+RRQCadFSRttsdZqfrYsZJZ3tIuI7ejo+mXcbKj1ojyP19OsDKrHwYrA0mC Pg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3bumaxcc8k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 22 Oct 2021 10:48:34 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1E0029D44Y1230@rn-mailsvcp-mta-lapp03.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 10:48:34 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1E00M004068600@rn-mailsvcp-mmp-lapp03.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 10:48:34 -0700 (PDT) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: 1a686b6648ba45b2bcd89bc1a2891c89 X-Va-R-CD: 7d773399d3b0c0ea77a47aab80506fe4 X-Va-CD: 0 X-Va-ID: 1fe90a82-c2f0-4104-a6c0-c2f52410d96c X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: 1a686b6648ba45b2bcd89bc1a2891c89 X-V-R-CD: 7d773399d3b0c0ea77a47aab80506fe4 X-V-CD: 0 X-V-ID: c0f17f16-1201-4f1f-92af-02a1ad2c0ef6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_04:2021-10-22, 2021-10-22 signatures=0 Received: from smtpclient.apple (unknown [17.234.65.163]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1E009BD44XBW00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 10:48:33 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_6637E0CC-3DB1-43BA-B829-3E1112B302A0" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Date: Fri, 22 Oct 2021 10:48:32 -0700 References: To: "IETF IPPM WG (ippm@ietf.org)" In-reply-to: Message-id: <901AB676-DEC6-4ECD-A5F6-CA3898FF9743@apple.com> X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_04:2021-10-22, 2021-10-22 signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for Explicit Flow Measurements Techniques 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, 22 Oct 2021 17:48:39 -0000 --Apple-Mail=_6637E0CC-3DB1-43BA-B829-3E1112B302A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello IPPM, Thanks to everyone who provided feedback! It sounds like we have support = to take on this work in IPPM. Authors, please submit draft-ietf-ippm-explicit-flow-measurements-00 = when ready. Best, Tommy > On Oct 8, 2021, at 8:59 AM, Tommy Pauly = wrote: >=20 > Hello IPPM, >=20 > This email starts an adoption call for = draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements = Techniques=E2=80=9D. This document is proposed as an Informational = document that describes techniques that go beyond single bit markings = like the QUIC spin bit. >=20 > = https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-measurements= / = > = https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measure= ments-02 = >=20 > This adoption call will last until Friday, October 22. Please review = the document, and reply to this email thread to indicate if you think = IPPM should adopt this document. >=20 > Best, > Tommy > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_6637E0CC-3DB1-43BA-B829-3E1112B302A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= IPPM,

    Thanks to = everyone who provided feedback! It sounds like we have support to take = on this work in IPPM.

    Authors, please = submit draft-ietf-ippm-explicit-flow-measurements-00 when = ready.

    Best,
    Tommy

    On Oct = 8, 2021, at 8:59 AM, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

    Hello = IPPM,

    This = email starts an adoption call for = draft-mdt-ippm-explicit-flow-measurements, "Explicit Flow Measurements = Techniques=E2=80=9D. This document is proposed as an Informational = document that describes techniques that go beyond single bit markings = like the QUIC spin bit.

    https://datatracker.ietf.org/doc/draft-mdt-ippm-explicit-flow-m= easurements/
    https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-f= low-measurements-02

    This adoption call will last until Friday, = October 22. Please review the document, and reply to this email = thread to indicate if you think IPPM should adopt this = document.

    Best,
    Tommy
    ______________________________________________= _
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm

    = --Apple-Mail=_6637E0CC-3DB1-43BA-B829-3E1112B302A0-- From nobody Fri Oct 22 10:59:32 2021 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 4F4DF3A0855 for ; Fri, 22 Oct 2021 10:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5zolHUd8XG3 for ; Fri, 22 Oct 2021 10:59:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2135.outbound.protection.outlook.com [40.107.96.135]) (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 C859E3A085C for ; Fri, 22 Oct 2021 10:59:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VammUnJB12+OpRowmed0VPE7tvqPeSIoTCPY3knm6F9tFZ5cGViY66BY+AA5cBWfenBtNXwYGpB7jIvyKQNkZZ4MOeRzmXOyg4BcaXEy2ndIFPijGwz68A8b3KOOQKutp91S6IFRlUpDGNviqQI2XTa10tqGkLeHVh7eMN/KmedojbYtYPgc2p2Lqqvl4zxEoHbTW6SeDFWovfTer+uIX9P9x7Cf7uSUC+D1FxJ86ur5mRk+p9pYpAEtcSKLVh9T6ex7hNks1g8XoV7MM0cPmQIG5QNJcM+0hf1vph74AjD/5jSdkxwMHSmx1Squ4TAxVfKkE70ZXXHTWx73BHCCnw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Smq6rz127Kx60gUIsk1v8QbF3RToTQNcD5kT2lwXfAQ=; b=BOKXeyPovEJqpDbqvV7bmu3eiJoBzWlkpNXVPOK3r4JOwQOVOjFKT8earxUuyT3KyrE9sKtF2UuqCVAJ6QlaJ/dN5oe6GBlnts/RrHIky2+oHw8V7pzGSp0LXc79qmHoV/BQGVpAU2hTQqcg2NoNuemp2VE8Q1URFMBFiqvQwEMpRXzNmyeuUHennntPGy+k55kdVm9rQY4HwRNXi3P2cYwXfW3SBDhjKKZ3cUsQlbj1RiYGHLOleqXuYxAw2dY/N8wTvjEK/ifa3ZWswvV0phG6nxDPrAK2IR6PfYfzmcIY5ed/ShToBEOaYBJrc8t60j3qnBdCkjlL+QFiehFxTA== 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=Smq6rz127Kx60gUIsk1v8QbF3RToTQNcD5kT2lwXfAQ=; b=bQ8Pha+xEu7twziG29oCNiFucN5K38y0crfsmfote/zIVNZ3kZA2rNhj52E0KILGEY3LzOZBngW5AKbuH059+N36OaIRu5Ka9CuffSsmBg1BKZSn129Im0Jj758UIL7XE3RWPxpwO0jOHTb/60nmwFWsujfhZCX1kN2sPc3lR1A= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BY5PR13MB3316.namprd13.prod.outlook.com (2603:10b6:a03:1a4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.13; Fri, 22 Oct 2021 17:59:19 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5%7]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 17:59:19 +0000 From: Haoyu Song To: Tianran Zhou , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 Thread-Index: AdfHDWLNvY93aiAGSwChY0Q0ZX5bBQAXyUag Date: Fri, 22 Oct 2021 17:59:19 +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: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 396091f2-cdfb-4dc4-474f-08d99585abb8 x-ms-traffictypediagnostic: BY5PR13MB3316: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sgV0GaVXl/BG361BLR0BpVmMAg4nR9DQED1WqueP/f0m/Q4bg2RlDHNvNaC7obsrnfIzhDh4ZNv4S/8Df2feI32QTDX2iiEVOOtmPaMigHDn17leJDHEoco4IN85/y1YRRra35iCGTzSlkndPuDQM4WDmfPvuNL7x/HTkpBr5bDOsOqVGy+zRTU57IyCuO77VmPt9JCrG6uLvLHNlIZHgQur37FiG6xecHshr25RFM2rwsticsBi5JDRSynF1Rc3Va5dKLp2TzKEpL+r1+OmUAhQ+55/SEeudxhMRfWrmDoAroidy8qeZEysqSg+bZzANtgPLspm+X67Fl3IXekogT2D9GhwFRa6EfAkGKMNwux+Bsgna3ytlhVZMEf98KBZHFY6+URQ/pX08JKXPmY+XBFJJ8sVKWpziNHGQ+ma0mHot0y1/vuZD5YdEnw05CCHlzmQwrfPtflFNE/LAA5HW7un5Zhf7V/oMmPUb7fNAcfEXqCWPnOSya79IIG8EIxD+tqVHB/+0VtzlUgzVmQd4ZS2XuhcL7oDiehf9GDMT/VFOhyiblbadUBdzofqyrcEILvTmu2cW4/xPZKFj2xvjkHAR6cMMrvm1IG7yZHD0Rqvk5l30heglMN6PNo+sq7IW0WsceTOX0T6XSnxEqMUy7FkTDWeavgfer6zvxlfz5eAIy7yaCcVh5wafP4rT5NjYBrGZXmBcVdbV15L1T5yypCo4BrhOp19UfkY4viLpX489htOT6dyKZLsxV7VB3lil6wTwLtUTwcIPOeirgXjDmlj3KhISocFKJEnsGzvs0tNcb2E6LkG3GCkqceVL5L/2F7vOEzdHTlW6fff66bwhw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(966005)(52536014)(66446008)(64756008)(71200400001)(76116006)(5660300002)(316002)(8936002)(44832011)(66556008)(38070700005)(110136005)(33656002)(122000001)(8676002)(53546011)(66946007)(55016002)(38100700002)(9686003)(7696005)(86362001)(9326002)(166002)(186003)(2906002)(508600001)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iuxPyodbgtixTOW8u5DF4mxu4gkg+VtQfLT9hpEfZ6A2kz/EtwocjhulE60A?= =?us-ascii?Q?SDAKt5Z+UpkMqgAO1SYS81fU5JAt9p1yXF/S/0M0bgmItk6gr1v1Oq4Yw2n/?= =?us-ascii?Q?mQjbrwsMblL43GYvuUWFneQDStLDd/g6x/xU7vavEe63hfWtcrWoBJc8RQaQ?= =?us-ascii?Q?FeaR21Iwn0x0h0c7VpxY+5sFCLs1W+Na1wWrNbNMutDYGJAyVR47WW/alNAX?= =?us-ascii?Q?b3ea6P7abKHnIpsqZAgGI+CiOIK4trPj4j53cRNVaPRiftv+vxMBwzpvZBGT?= =?us-ascii?Q?YgKifqpET+a3WrbyfXrXWdUW+wxT6ofLY9i59lij+UvDJaY0ovJr3eXd7p/G?= =?us-ascii?Q?AZW30njs1rEovDzX5H59AInR6Tq4bAuh2/H76PIOcn3rZDw3n3u+kBoPzTZN?= =?us-ascii?Q?d46sTQc7Q/xE1OrFgyCyOLzu21ZlDten1Hs5V8USeYUk4PBQnyXooOQ1SU6B?= =?us-ascii?Q?Kp9efNzRcVemy2lpIeUXEvjOmHopwQhy9pVqJ5ybp1F5WeOd3RfSj8e8mun9?= =?us-ascii?Q?Lrk0ZjMqS2+G8OZbrt0kqv/FeQq690h438NXKBZBXu3Rn14q2w/fum0ybu6b?= =?us-ascii?Q?JVjvrqnMaLPdRRB1FjCLu9kopmwD+++hGXsitvAj3WH7hMVPduyR68NACezs?= =?us-ascii?Q?iL2NiUyVs8e0ySXC8RIWkCybyzXiR5ED9V6CgzmjiomLyq1Vei1fwv4V5ONg?= =?us-ascii?Q?qtSp0vYZSc9eSUs8GhKAuNccxRghL8CpisveJ0Z9fCbX76m2CQ1ArR9AXXZv?= =?us-ascii?Q?LquVAAqXQgLVz4OAiDCBl2jbKL5apf4roJbtQ6IeJiXWoHqfHAvFlpsRE+2W?= =?us-ascii?Q?Y8wBoScZMtZf2mzASQzPbvOMAsIpTTRWlUcm664JYTGIEsjJKyYPtKLbEzgH?= =?us-ascii?Q?uh9Dm92yHQVjkygYjwqJzqRItMThXFZ9MOC/GquLWZvSm9KP0YtUWU4J4s5+?= =?us-ascii?Q?7eAnEquJFw0ffldE12xoRdc43GS9SjqqcW408Gjy+4lwS5/6emycviczvQEs?= =?us-ascii?Q?bW/xXGNWoN0Li/VP5bWC95WMRFIhmxRjHL9XAECxvkzZnHXGaVgVoqrhxxvO?= =?us-ascii?Q?I3ptln42yVGFOWR2ZAp+QDfTGcoUz10F5BIBDWbDQs4yYa1XxUdt6F6EkmdN?= =?us-ascii?Q?PA2yDpwMMTfdXe7T9m0ubsXUuYmq7d66zZlSzG30JfyGgwYNm8YJaf+cVIHT?= =?us-ascii?Q?B/rZDYl3jAgglG/elUbWM8dfNZl5UF7EEBNtkWl54ori7a9bOqVRrciQvV9x?= =?us-ascii?Q?bWaBF/9Yl0A6H16vHmiXbAoBZ8rt89QhdITzA+M5F5fn8TBzd0864GVIr7iD?= =?us-ascii?Q?0YTl/Ro6WePFiXJ23PWlICyZ0F9Lty2GGytNd6Wolca81xvt7YbUkK79XnDr?= =?us-ascii?Q?ZAKYgmtMu6l0TYqk+jGFbe3UJMlhK0KeA3zW0Q/d4F9BPAsWBFopL3N1GiWY?= =?us-ascii?Q?xWZktl44vppfpV/oSYebN3SPeAQdCQ/H0+s31+01CmWGWKZdhfMkVeSbAq2x?= =?us-ascii?Q?5qXY1fJ/HofLiEE=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478799E60F0C4D7DEE13537E9A809BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 396091f2-cdfb-4dc4-474f-08d99585abb8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 17:59:19.2023 (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: hsong@futurewei.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3316 Archived-At: Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 22 Oct 2021 17:59:30 -0000 --_000_BY3PR13MB478799E60F0C4D7DEE13537E9A809BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, I'm interested in this work but I think the draft needs to be expanded to c= larify several points 1. The meaning and usage of the flag bits need to be further explained. = For example, what's the true meaning of "flow direction"? 2. The use of meta info is not explained. 3. The capability description is too terse for me to catch the real impa= ct of the enhancement. For example, what's the thicker loss measurement and= more dense delay measurement? How does the new enhancement help to achieve= the goal and how much can it help? Thanks, Haoyu From: ippm On Behalf Of Tianran Zhou Sent: Thursday, October 21, 2021 11:27 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alterna= te-marking-07 Hi WG, There are many interests in this working group working on the alternate mar= king, RFC8321 and RFC8889. As you may have seen, we applied this method in IPv6, and the draft is in I= ESG review. https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ Based on the above draft, and the comments/suggestions we received, we prod= uced an Enhanced Alternate Marking Method. https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking= / This document extends the IPv6 Alternate Marking Option, to provide the en= hanced capabilities and allow advanced functionalities. We hope you like this idea. Any comments are welcome. Thanks, Tianran --_000_BY3PR13MB478799E60F0C4D7DEE13537E9A809BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Tianran,

     

    I’m interested in this work but I think the dr= aft needs to be expanded to clarify several points

     

    1. The meaning and usage of the flag bits need to be further explained= . For example, what’s the true meaning of “flow direction”= ;?
    2. The use of meta info is not explained.
    3. The capability description is too terse for me to catch the real= impact of the enhancement. For example, what’s the thicker loss meas= urement and more dense delay measurement? How does the new enhancement help to achieve the goal and how much can it help= ?

     

    Thanks,

    Haoyu

     

    From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Tianran Zhou
    Sent: Thursday, October 21, 2021 11:27 PM
    To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-= alternate-marking-07

     

    Hi WG,

     

    There are many interests in this working group worki= ng on the alternate marking, RFC8321 and RFC8889.

    As you may have seen, we applied this method in IPv6= , and the draft is in IESG review.

    https://datatracker.ietf.org/doc/draft-= ietf-6man-ipv6-alt-mark/

     

    Based on the above draft, and the comments/suggestio= ns we received, we produced an Enhanced Alternate Marking Method.

    https= ://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/=

     

    This document extends the IPv6 Alt= ernate Marking Option,  to provide the enhanced capabilities and allow= advanced functionalities.

     

    We hope you like this idea.

    Any comments are welcome.

     

    Thanks,

    Tianran

    --_000_BY3PR13MB478799E60F0C4D7DEE13537E9A809BY3PR13MB4787namp_-- From nobody Fri Oct 22 13:49:12 2021 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 B39553A09F5 for ; Fri, 22 Oct 2021 13:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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=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 zQKaYlwLv9do for ; Fri, 22 Oct 2021 13:48:58 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (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 51FF73A09EF for ; Fri, 22 Oct 2021 13:48:58 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19MKmiHU008334 for ; Fri, 22 Oct 2021 13:48:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=uwTA6+YbyOA+l0VsKH+v5ztJMiiCNN8vdUJr45QxvpQ=; b=cilp/EJ66GJOnjqm+VCOPgm8heLDTbMejXK00GKO7MhISeS77f9qF5zAjcJRsjVzvUeS IVpl2gVffKmJ5Cjsd99QuGLNfXOgxvVkhcBQWYY4heicjg4TpFIAIc/wBIbVv9dW80lt yzqfRUXmWaCHbfkiVuQQBv1GzzxBa/Jr/SSYeux4v/ERXQwLugI3OVtYG8QQIbCVpjlM tkwql9GVZuhdJgY6OshTKK0yDL7mNTxPGYMuxv4IWfHXicWji06OIgojSuUWGq4BhQZ9 XDO/JLpnKjHyCD2ProKSS9CgS5pip/kVeY8/OabWIpa3WX6NIgSS9vFhY8ewnZWaCqqi Yg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3bunhs5mvc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 22 Oct 2021 13:48:57 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1E002IFCHKS550@rn-mailsvcp-mta-lapp01.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 13:48:56 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1E00000CHICH00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 13:48:56 -0700 (PDT) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: bf412d8e23fa04c8c9f838c4e3c47c64 X-Va-R-CD: fdeed5a8265e119575ce7482fe515695 X-Va-CD: 0 X-Va-ID: ea477591-a458-498b-abff-4e9ce819c32c X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: bf412d8e23fa04c8c9f838c4e3c47c64 X-V-R-CD: fdeed5a8265e119575ce7482fe515695 X-V-CD: 0 X-V-ID: fc389a2c-f37a-4974-91aa-73fcf829c101 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Received: from smtpclient.apple (unknown [17.234.65.163]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1E00EEBCHISB00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for ippm@ietf.org; Fri, 22 Oct 2021 13:48:54 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_0832A35C-FDCC-4B34-950D-28258A6A02E6" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Message-id: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> Date: Fri, 22 Oct 2021 13:48:53 -0700 To: "IETF IPPM WG (ippm@ietf.org)" X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Archived-At: Subject: [ippm] Request for presentations at IETF 112 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, 22 Oct 2021 20:49:04 -0000 --Apple-Mail=_0832A35C-FDCC-4B34-950D-28258A6A02E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi IPPM, At IETF 112, we=E2=80=99ll have a two-hour session on Thursday, November = 11 (https://datatracker.ietf.org/meeting/112/agenda/ = ). We=E2=80=99ll mainly focus on adopted documents, but please do email the = chairs or the list with requests for other topics / new work. Best, Tommy= --Apple-Mail=_0832A35C-FDCC-4B34-950D-28258A6A02E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = IPPM,

    At IETF 112, = we=E2=80=99ll have a two-hour session on Thursday, November 11 (https://datatracker.ietf.org/meeting/112/agenda/).

    We=E2=80=99ll mainly = focus on adopted documents, but please do email the chairs or the list = with requests for other topics / new work.

    Best,
    Tommy
    = --Apple-Mail=_0832A35C-FDCC-4B34-950D-28258A6A02E6-- From nobody Fri Oct 22 13:52:26 2021 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 60D223A0AD7; Fri, 22 Oct 2021 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_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=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 mRsqIA4XQVJ4; Fri, 22 Oct 2021 13:52:14 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (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 2BF2B3A0AAA; Fri, 22 Oct 2021 13:52:14 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19MKla7c014179; Fri, 22 Oct 2021 13:52:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=szEglN1XqS2x6YYKulUkxBjTjN0YYCMwJDFGNviTCaE=; b=ZqnWnBKQc494yTwlgF9I/9qH6OFxLFTcGHZQMSOyQWMsgBfaynP4RO8fe+c7qWtyp95b 5J0QZGNkBpy07rzARsD6xakFNqbV5/LXoaS6UBJyys0Pz43RUKQitIKt6OiiBFt37jvf 5wWjqSumGLJD3vYF0+8UEwFg0UUEzTCsp+h5LpuZh8cYiTvGd3bRZFkTtVcTP7jfAcwK z5qFBXLqiwwJu2aW3PjBoODxsuOZ/vOlHZkAAgWbTUh49xmqbzDA8kxgUChsOcHuQXE3 5WthBMabtcQ5z60PZUMnwWqrObE9bkUzxh67ee8Sm6tzRlZapzaYwDBmDb1C/ie+6La9 yA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3bun41wkh9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Oct 2021 13:52:13 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1E00RH4CN0LF30@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 22 Oct 2021 13:52:12 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1E00F00CGVVF00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 22 Oct 2021 13:52:12 -0700 (PDT) X-Va-A: X-Va-T-CD: dfc86da510652575580ff00346bca277 X-Va-E-CD: bf1cb759b0b3f7f2bae1beb8fcd74ad2 X-Va-R-CD: 255e370300a24ec0ef482130ed03f994 X-Va-CD: 0 X-Va-ID: 20c4978e-7662-496d-82ce-e46bfee5f92d X-V-A: X-V-T-CD: dfc86da510652575580ff00346bca277 X-V-E-CD: bf1cb759b0b3f7f2bae1beb8fcd74ad2 X-V-R-CD: 255e370300a24ec0ef482130ed03f994 X-V-CD: 0 X-V-ID: 894c9014-f468-43a7-ac26-977a5fe15bf8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Received: from smtpclient.apple ([17.234.112.62]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1E00GBICMZXS00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 22 Oct 2021 13:52:12 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Christoph Paasch In-reply-to: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> Date: Fri, 22 Oct 2021 13:52:10 -0700 Cc: "IETF IPPM WG (ippm@ietf.org)" Content-transfer-encoding: quoted-printable Message-id: <47C1F585-FDA0-45C1-92C1-E760D8BE2EBF@apple.com> References: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Archived-At: Subject: Re: [ippm] Request for presentations at IETF 112 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, 22 Oct 2021 20:52:22 -0000 Hello, I would like to present draft-cpaasch-ippm-responsiveness. Thanks, Christoph > On Oct 22, 2021, at 1:48 PM, Tommy Pauly = wrote: >=20 > Hi IPPM, >=20 > At IETF 112, we=E2=80=99ll have a two-hour session on Thursday, = November 11 (https://datatracker.ietf.org/meeting/112/agenda/). >=20 > We=E2=80=99ll mainly focus on adopted documents, but please do email = the chairs or the list with requests for other topics / new work. >=20 > Best, > Tommy > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Oct 22 14:00:12 2021 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 EC3FD3A09FE for ; Fri, 22 Oct 2021 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQU3rgwe1S-G for ; Fri, 22 Oct 2021 13:58:03 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2094.outbound.protection.outlook.com [40.107.223.94]) (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 18C323A0858 for ; Fri, 22 Oct 2021 13:58:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oUNeC9JoEm2b2DQRwsq0l1lyyszgTAMb75SmM8C/K8kxw7s2ttlMXV6FwA10f3nVTk0lMTNz3/HH5eddI//JhKDNBYx9LjpQ5vJKU4flGW/hxbLFzKmG/tVA32uGtLHA99AGSnX9rvF5+noCciyXAQQj77QeO+bwzhXtwXamA7LRHkI4IhYPzyICCvuJFVxLQKsjcrz3Y03aV1QHh8eRtdu0TGXdKsLEcIspQLJB1sNfr3Gh0hEW6zpUeYOUa/uDEaMjqUWHqLcm8KTWwlssW9Zc+JJxbvgNKBjfkHYFJ9poBH3TZjBfgYPoQYQ+ORqhZi947Jbc1VVICKqnGlSzQw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wepJUTfFWvsKI7h1h6K0hVyLRZpP4RoKELK9CMbrdkc=; b=cxkdLPW3u6QA2gWa1yGh0r/stjzRTqEH+bQFoQ+R11zL5aJy1Wy0yyTbF0lmrix7Cx5kH1+JiWYX4k83cS1XL1GM1Z0B3boKkupSWPlXKJ+RVuTaAPNIAnY+5j+HOGNaddTY54cmkaRrQgn6CyqPd2UsgzjUvZwYG2h4k8GCtvSsUkVH4dHhV4hnBS8bflPv1i7JhHHby4z49HCPhYHNTEmwO4PC9IoezXLiwS/b+RKDvEYAW9DUtCcKzKpUdkD/rooFooCb2RTzKyFH+/jwNuMgLWszS0jPGLQLz/f+J0F1zKWeJ9QplJs2bK5uTA+J7zjlszop0zz41qem160tfg== 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=wepJUTfFWvsKI7h1h6K0hVyLRZpP4RoKELK9CMbrdkc=; b=fZZfO7Ho92JdpACIpKfnq9xBXoZ/6/q+maSAtjj8ymijXXEvNKSX/Y/JeuEjY+ZxCb3fcVlE3utJZUoM/v9xrzFHOg5J5Q1TL3IMWrZ2pefripcjvwBEIRJLxMYrv9Dcr4DOoazpa2hX3LF1JTv2ceDZ+66RsLmYdcfYdXT7New= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BY5PR13MB4472.namprd13.prod.outlook.com (2603:10b6:a03:1d8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.11; Fri, 22 Oct 2021 20:57:59 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5%7]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 20:57:59 +0000 From: Haoyu Song To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Request for presentations at IETF 112 Thread-Index: AQHXx4ZLEeIm+m8MB0a0HQgG8KbcTKvff9ng Date: Fri, 22 Oct 2021 20:57:58 +0000 Message-ID: References: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> In-Reply-To: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55dcb44a-5176-453b-eb74-08d9959ea12a x-ms-traffictypediagnostic: BY5PR13MB4472: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7qmICkl9KqqYL3g1XYw2B98nn62u39ObrzvIuTZFOv+cv8BzVDCZ6dl6kHFjQYzyq5GPlH57IUknnnU/0x9RDVZASieUYP+RxqhQ5Q5KiFWTYTsD6o7/gA9hveu/V4Hqn1vEiLNBZP9k5sHcjTbhJHl/REIf6MxNACZw2UzxPDNsHHfQQZa7XL4/w6JYInmSM3dEwVO0eixodNngHSYkdeYRv12V85v+pPgFDLW26mmIMAzH5ELD5OTmcwbrLtUI+40HHZQbhRku16ShWcOYL2FDD3EyCwUYKMFePWqMcxoa4bU0qx96fgGfHBNbQ0m0HgzvXBXEHoUc3VlgvMuNPK1HaVVqwcRxp3kzOKB6OcXoRGiI6VIFuFG7jitNqLNKEUm/jyuJWUQVUj7L/0Bi0Y1VtxJzDc78LseKwBhgK+iiUAB7e9gZvxSitp28bkxe+uFmxKJLoM6q1u1I7EZabL3SnLfnnfPjUcwawKsOJpswwK9aCTtS/zgJPaMlPIVHsB8xfZOEOq6DeyENRNDtSvPwRCr9wT0evVvFUqbnkKPUvXfSzOwHbVIarlfYarhW/BOvzIGC2nR5aCvubvfHiaZ59kCSZ7DOZkJbUap6K12wCkzXUCI6M8O4uVQJ8VASPiAGYC2lHF7lF3bk8oFrPtes8PD6zZLUWrDX+A4Swr8uxgaZwIFUyBjy8+i43WHyYYgiFTNfh/mT7XUGJjWgkjMjaCBaVq3zw5FXxL9wfwvnkKXfKNdIlSdipJ00Px+8pd6s9ilP1uy3lsEsa0CPZLV7T3OaXRLaT6Xm+2jssIlDB26BMIe7AjuZOj9zTExY4phy9xB8sYIZuKOx0BGZtA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(53546011)(52536014)(9686003)(316002)(110136005)(7696005)(55016002)(4744005)(76116006)(508600001)(2906002)(6506007)(66446008)(66946007)(966005)(5660300002)(64756008)(66476007)(66556008)(38100700002)(33656002)(186003)(83380400001)(8936002)(122000001)(71200400001)(44832011)(38070700005)(8676002)(86362001)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ZU/fYQfwxSW08+tl84mrL0MutLt1YJ67eAfBGd0gnBvmBSM6tZfPf/bbVjaq?= =?us-ascii?Q?G15vmj6yXxzMOreiGB4Q17+ibH2wxzO8qRXFrK3eQvmE7xBmvBr3scorS1Jv?= =?us-ascii?Q?q2Wc88XFVHQfVYkeJkBOW96JkfH3Yyed133iJgiauJGLu1xw3m6gHOkJU3kz?= =?us-ascii?Q?44mDw48w/0/GVX+Zg+/eRv43gM6AsXsXkj8kQzxR4FYoCTMhb/erd+EjS+2f?= =?us-ascii?Q?7Vr1g0wlS1o7hG3ECGAvXoNVrPgR2E40dpWV/eX5en9+kYncHPhgCDwJG1KN?= =?us-ascii?Q?YvhwNUbCa1ohIlzecd3E7Y/y1Gcdfua6fzfq4ZlPAp2djmyPss0ZrQDgKiT1?= =?us-ascii?Q?VhdB8pmqIR8SdYLkKH2me99oq4CRR/pFc6kIX8K/xBB40HQiR76ZmfjnJ5Yh?= =?us-ascii?Q?GBc7OteyralJJEctLfcuWSRM8noNBvUFjm/I9x7/z60GAn/UtpIVVpLkj/ZX?= =?us-ascii?Q?jSjholD0HTgm23Q0J07OvumrGxqlia9VcfteCyfREcN9821W6/efOoOjcmnb?= =?us-ascii?Q?M0xrau0hYadI0cCLtC2bdkbl8GDYIg9hwEhJgdI4zXiduklDa4G55Kya0RYe?= =?us-ascii?Q?F2rEHE8ag6n9xYsAMeKzNUnnwVgtXnkxtHErVyts/QzOUtZn91Wob2IPITf9?= =?us-ascii?Q?Y2/9EktiyEkc5WOBfOs1T+C3QtT4S9tdXqxELDR4A5cmwm6jiOvc/ohMf1Yr?= =?us-ascii?Q?AUbji7htj7pBCrUj5wxk0Ideb0GG1vV6wmX1BKpB47WQ1+gY0KT9258WgLEY?= =?us-ascii?Q?gL5lFparzoSIHTvkURXmeO3VtMYi3XkLPYeBBTztQCa60WSo767Y3u3O//ax?= =?us-ascii?Q?LoLw4rB3qlAIAXZIBxuZ0Bd6ycK/axb3wyh9FULFy3yKQMN1NLLLYMCmDvgW?= =?us-ascii?Q?Na9HyDFcIor95W7LwlJn0cvBusZNRPQPoAGrz5zMcH4XBxgd0yqamkxDZd6i?= =?us-ascii?Q?O7f1XmeLoHHqk4bETtBv06K6TqLA4pUiEu1ZyVLfUy/yrELcB2OK5794wfag?= =?us-ascii?Q?D/DAAmXa0MOZcKM0sWScnPBnvuL/kmX/yupT3vPkEsDAl+8yjFhCqiZwws0h?= =?us-ascii?Q?m+fP/Uc9gvH6jRcmybdRqoCbQQTtUOVjk7dcYX2QvQDVuX/Uds6ADFYp5f2N?= =?us-ascii?Q?CFJCCSOWz7SqKmOVOy76M7Bgyd0ho2SUwiKVgTnOB6qwutCX9qrqns2EQzEk?= =?us-ascii?Q?zgWxj7AePeAGI+fQlE0PFuJsZuBpGLqaDSRvzm3ZrwE2zerG63swTMkqcT9K?= =?us-ascii?Q?h2ywIRj9AhuphxcTANXOxKpeMt8FKHynkJ4BTsYCpIu1/5KQSsdH3czPtt+A?= =?us-ascii?Q?fUVBj7mSzBtlf1N9l5DKWUDq5hE2t932I7doxTL7AFazjnePJYRMPqBB5CBN?= =?us-ascii?Q?g/p8JkIeQDY3O6orH5PWFwlyX+UzyC09MwtM08mSQKNcVMYJeOHA/MLVAXh6?= =?us-ascii?Q?yfaCabba8D9OSaxK/h3AZ+LHc5y2o5VO7+jFHdqZPU6YxvrcRHa1SMmo16jy?= =?us-ascii?Q?dBIaDIaZWXLC72M=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787F7A565AC7FB953E818EA9A809BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55dcb44a-5176-453b-eb74-08d9959ea12a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 20:57:59.0215 (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: hsong@futurewei.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB4472 Archived-At: Subject: Re: [ippm] Request for presentations at IETF 112 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, 22 Oct 2021 20:58:10 -0000 --_000_BY3PR13MB4787F7A565AC7FB953E818EA9A809BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IPPM Chairs, I'm writing to request for a presentation slot in the coming IPPM WG meetin= g in IETF112 for the following draft: "Postcard-based On-Path Flow Data Te= lemetry using Packet Marking" https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/<= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-song-ippm-postcard-based-telemetry%2F&data=3D04= %7C01%7Chaoyu.song%40futurewei.com%7C6ff33ce82ccd4e5f6e8108d93bf0e7ce%7C0fe= e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637606728152877534%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C1000&sdata=3D5TztFdQRSsBePiu%2BXwV2FVkIm5Xw2R66JU%2Fp78%2FTkxo%3D&reserve= d=3D0> Thanks for the consideration. Best regards, Haoyu From: ippm On Behalf Of Tommy Pauly Sent: Friday, October 22, 2021 1:49 PM To: IETF IPPM WG (ippm@ietf.org) Subject: [ippm] Request for presentations at IETF 112 Hi IPPM, At IETF 112, we'll have a two-hour session on Thursday, November 11 (https:= //datatracker.ietf.org/meeting/112/agenda/). We'll mainly focus on adopted documents, but please do email the chairs or = the list with requests for other topics / new work. Best, Tommy --_000_BY3PR13MB4787F7A565AC7FB953E818EA9A809BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear IPPM Chairs,

     

    I’m writing to request for a presentation slot= in the coming IPPM WG meeting in IETF112 for the following draft:  &#= 8220;Postcard-based On-Path Flow Data Telemetry using Packet Marking”=

    https://datatracker.ie= tf.org/doc/draft-song-ippm-postcard-based-telemetry/

    Thanks for the consideration.

     

    Best regards,

    Haoyu

     

     

     

    From: ippm <ippm-bounces@ietf.org> O= n Behalf Of Tommy Pauly
    Sent: Friday, October 22, 2021 1:49 PM
    To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: [ippm] Request for presentations at IETF 112

     

    Hi IPPM,

     

    At IETF 112, we’ll have a two-hour session on = Thursday, November 11 (https://datatracker.ietf.org/meeting/112/agenda/= ).

     

    We’ll mainly focus on adopted documents, but p= lease do email the chairs or the list with requests for other topics / new = work.

     

    Best,

    Tommy

    --_000_BY3PR13MB4787F7A565AC7FB953E818EA9A809BY3PR13MB4787namp_-- From nobody Fri Oct 22 14:00:43 2021 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 3DAE83A0AA7 for ; Fri, 22 Oct 2021 14:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=yahoo.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 Quvil3Jlx0Y7 for ; Fri, 22 Oct 2021 14:00:27 -0700 (PDT) Received: from sonic308-15.consmr.mail.ne1.yahoo.com (sonic308-15.consmr.mail.ne1.yahoo.com [66.163.187.38]) (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 308173A0C2E for ; Fri, 22 Oct 2021 13:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634936378; bh=j2d/1tsPLHezLpFwAW3TNKd/8FCXkuTXOMx8y+PSEQ4=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Bzn4hE18IuAgehbwGGB1Z5QK9e9IgC6gJeLx1eyqnrdX8bjbA4h3Eay/nentbry2jLLgGR+QzWbmEbLYDmlSV0OIojcc5GdKyLidGijBCV+2fWQTp8IjgHQlt76ioziyG2XFoAyCdqtUW64mDNVr6JDn71YYTbIQATboOyIrcVgZhZZVkAYlLPv4YH44LaetkcK+1A9uOo6h4M2AkNf/+rkFJdQ82NpcxwDEmIxd3FpT4kfqdM+GF484RaCquQV/gVCo+czGD5K1hlKu8eWretJadjcf/hrwksdGrEeUiDcjPyDedQXVuUd9A/pubpMWKzL7oqH7JrmvAK3SYlvIRg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634936378; bh=918MSagNYljp/HFzD4p5Wfg2ukLpvaokmbxIMyzLrgG=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Hw1h1vyK8A3xjzF5vAYHqnmBCN1WIyDQb4KzxXMlc29EIqik9CqByrj6T8Nih4Sz3OXmn2xl1WNb1riGsk+kp+RgSQ2gO7xkrpb9lj6Er9KIKxWFWx62BezO5IcYJx1BAuw3OeniqVMnUFt3V+cPPTo4V+yobln7H2I6mU+sND0Z0K47nRXF8gumjwTNkE297wlKJMcKi4Ru1vThVjevSTgdCv+GVbaulHLABIPVbfED4YKqR5omlUhXAjCKrFoTj4Gpdfd3kLNTwtT2F37QW5xzbAFxOISEupbNusnGotW2z5F00CQ1TgcUnFbfKm0CEeFdQjoy1o1+ivTCFi2Ivg== X-YMail-OSG: sE8frgkVM1ncMfsNwm7._r_cFrAiCmN2.F7o.4jSlsCe13x4UllF9E70FI4kMMZ HbIu9JGX4g5BakoJmZAC6SqFG9Fsp1nN0LBRPrPA4wRpBxJ2CrXAz5ZTWgW80J7BV3Ei4gynwSGG sEft3DHFUYtGJXd2bOBXu2Vkbzsz_KRrZ0yLLM7NeZKRWSVmxkof_d1pcVV13bDHhk75MGFNzykC lVRa5338_valSRKxTvda4kt9F8TXuAbwB5DjKkKyVRZJy1kNP_0ouJOd8E0t7oEq22FmZU7Q4QJr fFX1lgQeyMwq3WYaQx1XjpJuf3MEZmg9mU.wPI_Sbq8AKVNP6V2GLFE8psjGPqd5_JSRIuPcGYDr DkDwrnBHJNFtWAjgZyzqF7WPOwTR.SNWmi6j08.cxP_xKCc4_yYRzgDH5pqVCJrOO6TvlaEReEwJ 5e75ydvYe8j6n1RvyMz3Vuw4wjhlMjFHO0mGujW0DSqPjDK1EIldsnZPzjhLzWOjBBndarlfcPwf INaRQqwxPQiF60iZv0gJ62aS23Q0VlfNXFEN48h.sMChC7Bw_wthG7HWj412RuGM117O0_I3vh.X J51qVnMWDvW_MKXnMGWAchHbq_eROdykvFSVBfo.y3OaIZtyLW0CdPQXRZG1IPuIL4Qof4sJQB7Q u99ewMLjvxy1ByrJq5eAWvrAkZpJOgBNbPQ6BM8B9mR0BcMfvu83s3OlDC3lC2DuDygiVZnvac2t viDNUPM5zpseFZFgzFGo7TG0.qm8F.zkfIAn1C_0hTWnc.iDVe16omgGlLJ9quGX8QluulDWXMIO okF_qnSHjly0ZxrZObkS1PJLQbCU66mw_xiK9lDYjGxp_rVEktBerWeF4kprYlx512TkejjM0tHU pR9_J1mMdBMTRrXEmP7GcuLenpGfapdlgwLoQQlhOGzgmBRUrB5d8JemWZ0G1EGoHVw3rG6tl1aU etqOblBnU2r9QGxI0g7e1CfRsZ8JkjLxLb3sePQwpNozIalCbJwWiRjfNLpmAjEbeMzI.4rmkAqh 5_TGU48qgV35SFTyh3hhBIsqJnGP1MN_TWmZX3_nuWct9wb.ytI7caRbsxJrDEscxwgldiadCpJ7 ng7iw1i0m1kpLfOZ.QQNzQ.Gi7nFctdihdbJ9HsNjy5uFK6aF5l1Lt4PmM6TNP9N6AAkFIfYZ_3g cCVWIImY22.iJYCPAw8PxR5ci5Xe8iEYC_7xcM.IOLIkVsJt7Qqd2nOJPha88_WaqbwCcIvzXcu1 1PNgm2oain9E6ZvDe5lRovsJJpWhOnHnP8N8uFfLUb7RkKEP2rbws8s1vnP9UPorVnkkBQldr3cR ioalgOZUnrlmM20WWMda3NCXPtaNVA..nuAbZ6Fw7GiMc2QLPko7_u2TgwmZ2tMBtbq5NEt8ph9t CXWPIR1Dd1sMqVWCYuTYw0aQYMhsaawc3QktKXXzBZ71kbHCk73OLiOTHydRqZVb96SlrSBGXZnp 6GTsy57w0DshTB4oOA0goJbZsTpbEjnHGzQrmwtrEm7pYGvnmKpX8lFn_GWEUZaobfpiqYhhQo3R SjUGAzTY4q5TVoQjU_TbthoExrCyOVltZttmzjFEPQRGMkN2XVwqT24rtRCbd0woEEdtEaH86f38 KcfyI1W_Fi9YaHv5ZmAVgmQAm5FOVSRC8mLATJZB0qZ6DX.7mDfj_ZH5ZMyNu.w9CTy4YePgXZuS nW95MyOWwo1QQT7Qw5w7.qEESnj92NnwkOVFgFDBUaoWxKzoNbknumL_AztfJ7mRBUaOGi22B0.r cIVYTScIWtU0dWt6QUUnNaCzUqjzKKPkoqKGcjdN8y8PzRXFqtKozpOu6ORCznu_VDDxmnSQmWjA KMG2a3w2q_ooGrlvSjgmoMd8sKwD9hwyp_jZnQWIGuZmHOPyBsGAqX.nIutUukld1n7dvCVdChBE u0g0Cx1yVRljnKlH6djykecsFp0KV3m9muN3Ppx0H2KLENiJUzlLeEUTs6jq7QgXt7cLbwPLCF0E 81Y_icVfy1MCNURqd1qYy5ISOagTyUM53iw5ZW.d5GzGsO9lccFkvdOS9W7EWWk_c0IoT0gUSwi7 2xnzEN9KH19zA1oYcrfkkQYCRwEgXyAaIW4qNunRVdfUo2e1YU_e2qgIkrcHxuco6ThYyUSK_KrJ XJOJQaTeAHWQhIZ2gAOHr24jOvhwqmTxfR9RNSo.rKX48t_k5UbV4LhiZHWfR8uxJTKMRTF.CbDk T X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 22 Oct 2021 20:59:38 +0000 Date: Fri, 22 Oct 2021 20:59:28 +0000 (UTC) From: Nalini J Elkins To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Message-ID: <479125853.764864.1634936368563@mail.yahoo.com> In-Reply-To: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> References: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_764863_412498525.1634936368562" X-Mailer: WebService/1.1.19198 YahooMailIosMobile Archived-At: Subject: Re: [ippm] Request for presentations at IETF 112 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, 22 Oct 2021 21:00:37 -0000 ------=_Part_764863_412498525.1634936368562 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tommy, We would like to talk about our encrypted PDMv2 draft. =C2=A0We will also s= chedule a side meeting to demo the implementation as far as we have it. Thanks!PDMv2 team=C2=A0 Sent from Smallbiz Yahoo Mail for iPhone On Friday, October 22, 2021, 4:49 PM, Tommy Pauly wrote: Hi IPPM, At IETF 112, we=E2=80=99ll have a two-hour session on Thursday, November 11= (https://datatracker.ietf.org/meeting/112/agenda/). We=E2=80=99ll mainly focus on adopted documents, but please do email the ch= airs or the list with requests for other topics / new work. Best,Tommy_______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ------=_Part_764863_412498525.1634936368562 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tommy,

    We would like to talk about our encrypted PDMv2 d= raft.  We will also schedule a side meeting to demo the implementation= as far as we have it.

    Thanks!
    PDMv2 tea= m 


    Sent from Smallbiz Yaho= o Mail for iPhone

    On Friday, Oc= tober 22, 2021, 4:49 PM, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.or= g> wrote:

    Hi IPPM,

    <= div class=3D"yiv6850325366">At IETF 112, we=E2=80=99ll have a two-hour sess= ion on Thursday, November 11 (https://datatracker.ietf.org/meeting/112/agenda/).<= /div>

    We=E2=80=99ll mainly focus on adopted documents, but = please do email the chairs or the list with requests for other topics / new= work.

    =
    Best,
    Tommy<= /div>
    _______________________________________________
    ippm ma= iling list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    <= blockquote>
    ------=_Part_764863_412498525.1634936368562-- From nobody Fri Oct 22 14:28:03 2021 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 B30BA3A0C5E; Fri, 22 Oct 2021 14:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wb0YlSlWt3E; Fri, 22 Oct 2021 14:27:50 -0700 (PDT) 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 2417A3A0C43; Fri, 22 Oct 2021 14:27:50 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MLNKkM020131; Fri, 22 Oct 2021 17:27:48 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 3bv55rr31w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 17:27:48 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19MLRkHQ002058; Fri, 22 Oct 2021 17:27:47 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19MLRfMO001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Oct 2021 17:27:41 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 3C6914005958; Fri, 22 Oct 2021 21:27:41 +0000 (GMT) Received: from GAALPA1MSGEX1AD.ITServices.sbc.com (unknown [135.50.89.99]) by zlp30486.vci.att.com (Service) with ESMTP id E24FE4005951; Fri, 22 Oct 2021 21:27:40 +0000 (GMT) Received: from GAALPA1MSGEX1BF.ITServices.sbc.com (135.50.89.107) by GAALPA1MSGEX1AD.ITServices.sbc.com (135.50.89.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Fri, 22 Oct 2021 17:27:40 -0400 Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1BF.ITServices.sbc.com (135.50.89.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Fri, 22 Oct 2021 17:27:40 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Fri, 22 Oct 2021 17:27:34 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QAQenhSFQvkwCe1knxNaNpD/eQREt4ktZ04tCjWf4XguQQwquQsKTqeSE2yBY6Q5b4doa8Rwx4yu1WX5kvceZoIED2Nppca/eBjUDEcO+rrjffA56ce2sgYTdMPhYf4dbw14QbbLRIArY+3YmS358La5h//5QF+1pK0Xfc/DSXeJ0bnbs3zhlzqZx5wW2J7ZMmt1iD0FtkstHCdJGL6/xN1qkQrP9kMFlOH2A+cyZ52Dv620ONRhcaC7VDML270nCUD2xv2MIHpbCfQJgPY+jgG6hLrwGEwTtt/F6dkGu3Ao0e/NkjxdRRdgtt0vIs+Lugg+aCyAmo9ZaAlEbgDeJw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=urh9LNhmdmmvk7am0QAmx3GRAoBIuYYRX8/aooNxyPI=; b=SHc+BoWE6rDcrwuTqpm9Fy1t8KabbGe2eo0RLRzjPGMol9l6lzfyUJFhORGW3wOSjugRdgMNv3uO1RWEVr4SzfK9/2JafgTv5VfxKkcArQOlTBaD8j+u6w3+b2bdaFdN3vt2L4c0k98GyKmYjlv4n/Pl4HHJzeSmx/JqBA0Lv5YavcydMFIOugj7mwt+lPmGPupgWN+m0Zq7KjhLHGw87TNBMIuhUzRzZDBEuTJmiJhlLWlvRJ+0FzHG4zeBHWuZh3XDNPPUrIxOJVoPhnAOpX1FQhSkN1JKBbhUhHm2M7czFtHRTgbWRecldjlI5weCMpzPL3Oj3BcXPQ41gQ2KbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=urh9LNhmdmmvk7am0QAmx3GRAoBIuYYRX8/aooNxyPI=; b=mvhRzg4vAbFTLOtn56GKxSXd85puIibHj59FQfdYgGxGelQ2tQJLUj++AiizmIu+361FwjLdlMj6T6kNq6z0BWONq2P1oEVlOc+WuLspb0wXZanRQDDT8VzRsykJIGzCX4XIv+i7R6D1K/S3S9A6gFC2aXHQmv4MGa84EhRmcPg= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB5127.namprd02.prod.outlook.com (2603:10b6:a03:6c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Fri, 22 Oct 2021 21:27:32 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%5]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 21:27:32 +0000 From: "MORTON JR., AL" To: Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Request for presentations at IETF 112 Thread-Index: AQHXx4ZWjJYs3LwLQ0Ope0hn53SSZKvfheag Date: Fri, 22 Oct 2021 21:27:32 +0000 Message-ID: References: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> In-Reply-To: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10585b0e-4359-45b3-ebf3-08d995a2c215 x-ms-traffictypediagnostic: BYAPR02MB5127: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8X/hTESQK5rSegCAeO6OZXIke4Wv4bMR4j0TCU52moVPgKcv3rhkAwQcGbALFN2SYUzcdHiCqIV1NBxxO50uDLLPf6xPpeDFy8gWxaW8W4Bc3tq+O/uZ8vHtxPcTka/hDFqsuKIRjXGUwCuF/iqvFazmCNLBEicapbdEReuNJ1RFGO39F4mIzEipnuMZgdZOMxJRZ3gpUSq7lLmM8aHBWidAvJIPeuiuUqwpLlFMX8wKpNH8JWwxngdLKu5tilaLBemyfdvl3hWoUs2BxsuZVxrSDjB6vOT1n7EYXEnIx2PRSo03d20Ywn155mQ85aGUC5Xifgoz0qg36UfQQ4ZHXwccACeiucb5+UZMBzC05uqCXchP5solYpGu4+ysEvbK/QA+FIXKndRMl8u4JgvfNVjwEkxv77NTBr0fGSCW9lBjo5QScaGO5zhgtN0wjIITBgvnZvixAiFXLeyzF7MKcRpOwfV1+NwtXl8+sBwuypUucPvFYnAPvJKW8YFAfHgTfswbuXCjHVJJI3shW7uST+aIaV/NFIyhLXcmBLljpxYHv6Yk9Qa9ZIlzauX/OweMg+58ARibytsAfNluffAGerRxMQ6y68BbcawsXJXz4inOWEoEeWBqvE/wruzaJUO8tWKbdjSBNnlY7i3YBN32EDBMeDyUNAfXJFl87ckHc+zckraGHZfNrFssmm+8huluzGY3pXPH6BRR656dtiT3xeZGZqhtzXEcYJgeg1KA3SNsMA4IKGAMX2aKlGbCc22xUDdgpttmnZhRkKIb3qFMHRxqCP7WBBUmYWZ1MQPd0Mg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(9326002)(53546011)(82960400001)(66476007)(52536014)(8936002)(6506007)(82202003)(83380400001)(166002)(26005)(2906002)(110136005)(71200400001)(33656002)(508600001)(66446008)(38070700005)(122000001)(76116006)(316002)(9686003)(5660300002)(55016002)(38100700002)(8676002)(64756008)(86362001)(66556008)(66946007)(186003)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YXpmUXNXaGdDSXVaKzR5OUZweUw3YkJndDBSckxPTjUzTlBOV1pTWE81c2Zw?= =?utf-8?B?NzVmYWh5VU11S1BnL2hFVlNZYkRjU0VmYS9haW5nZ3ZKNUdMWHFxTnZpRWF3?= =?utf-8?B?a0J3N2FqLzlhK2xPeGtDMTBOb3UrZkt0QVUwNTJaN083cHllcXhZcW1WbkRJ?= =?utf-8?B?b0JzdTRLNFkxVmpnTDY0akhuTVhqejJVN0M3bC9CSEhiV1lsWmtuekdtcUlV?= =?utf-8?B?Zy9zTWhlcU9NKzIxTnJoNVUvMzNzR09CM0RUTld3R2NzSG1RbW5LQWdaVGdV?= =?utf-8?B?ckFhamxsRVRkVVVpUVRwVUNoZTY1S001MUZXWWxpNTZoUUVWbzRod3lqZ0hi?= =?utf-8?B?Y3ZxK3dlQnlzK09lOWNmMFRFQld1a0Zqb1Y3NkZFZDE1N240K0N6WU5kVlAy?= =?utf-8?B?TWZsNlFyU2VZZTkyNTZKTXhta2lQdzB5TjI0RXdTMlF5bGRtUElUdjJDcFcr?= =?utf-8?B?VFBqZHMvTUVvcG8vb0FXU3JISmkySnVBM3VteUY2WExjRExiN2JkbEZ3OXlu?= =?utf-8?B?QmFDMDdEOXZ1WnJhZHlwNC9XREFjNXBEdlBJT3dQanhObGUrWUF6N3JyNEo5?= =?utf-8?B?SXBzSCtuV0NRK2huMHc1aEw1L3R5MndzejB4c1JQaFE0K2JHK1RwMjhnMlZz?= =?utf-8?B?Sk1mdkZZWS9NWDhZNjlHKytGb2J4OGR5dEs5ZDc1QXJpOURINHFOMHBscGlV?= =?utf-8?B?SmgzRU05U2VpZjhNdytKOC9BbXJsbXRFdkFoQVUwbFllNWI1T1Y1VGZFckZu?= =?utf-8?B?dnJlOFpWQWtTRU5FMThNQVZkYkNHNjNleW53Rk0yNk1zVzhmcFdhTmI5NVI2?= =?utf-8?B?T1JTR2NlQUZzT0hzcWRuWVJCaVJxYXB4dHZWcm1oclpjcjJrc0RGcXIvTHR1?= =?utf-8?B?OGxpN2lPRWFQQTZjVXh2QkhWcTk0YlNqYTF3eFVXS0YvTTBWdTdjd2FBc3pV?= =?utf-8?B?WjNKcGMzMDc0eVQ5bllMOThJUTZxN2pZbHVZVyt2VkpXTE9adkhSanNQMlI1?= =?utf-8?B?Y0ZlM01rVjNPeTR2dVFLRWw2cG9GZ3FsR3RmNk5odmllMzkzVkpJMTdnMWJ1?= =?utf-8?B?SERTR3AwNzlvZUFwYzd4THpFTmQyemoxWHhMRitZdlNaOUpsS3lCMkxvaCt1?= =?utf-8?B?Mk8wekxFQUlXL0Z1bFd2SzdLeWlHcXFBUUU3OUQ4ZzFPeUJHY28vMzI1anZE?= =?utf-8?B?L2hvV2tsdVlXMXMrUHluNDM2RHhXd3p3aDY4ak53OVh4bFBFZVRKc1dXZjY3?= =?utf-8?B?Uko1VjRDWi8veDZnZTFWNjZielJkUm5lU08vR0xaL1N1K0JNTjVSWnFtNzNq?= =?utf-8?B?QnYveDNIMDhTWXJYSWZzUVdiYllhM2ltWFhYTlZKeHZ6NUpsdHR3WWNvajhT?= =?utf-8?B?eks1bEFYTS91aVhTMU1DK3VvQTFDbkpsTzMzZWQ4L2t6R0lST3FZR29jVW1Z?= =?utf-8?B?NmFnbFVrWjhwU3ozdWxoZTNFWXpZK3YyaFBmWHlualZXaVIvZ2RlbE9BbzUw?= =?utf-8?B?cjJkWkFaMlB1a3ovMVhsSUZWVVdXb29QUlBqY2tBbWMwZHNvN3MzR3h4SGx1?= =?utf-8?B?UlhtMmlVczRZcW82YkU0RmNYOTdJL1F2eCtUVjlmdCtQa0lqK0FoM3N4NU1i?= =?utf-8?B?aHNTU0RBVmk5dmxsTjlDYXNKZUNEcTRkQVJpbU9oMmd4VDhPWVVoZDN3a21R?= =?utf-8?B?TWg3TFBMbXdwVTIxRXQ3VGQwWkFlT2szUnp2c04rL3BydHVYeWVhd1N6QzZm?= =?utf-8?B?WHFzckg3aFZBVUMyZXRnTzZyM3dQYWdpbFJoUUp0cGR3cVRNRldvQk05TktS?= =?utf-8?B?c1V6MkYzRmUzWHE4MzlCRGZsUjZGS3pGNHNzNWIwaUFWSVVpbnJsN1BUN1Va?= =?utf-8?B?eHRDZmpvUTdmNXVKZmozZXBSMzNxUERicVhUdUxMMkNDUnc9PQ==?= Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB78538C93DEFEB1946A39CDB8D3809SJ0PR02MB7853namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10585b0e-4359-45b3-ebf3-08d995a2c215 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 21:27:32.1957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: am2935@att.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5127 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 98E4967A1ACCE7EC01AD2C5B96BB12ABAB1B2A74E269189037F7869FD9715A982 X-Proofpoint-ORIG-GUID: Rj3NN5eOZBTjvgRctSudEjRKN-8dBqkd X-Proofpoint-GUID: Rj3NN5eOZBTjvgRctSudEjRKN-8dBqkd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-22_05,2021-10-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220120 Archived-At: Subject: Re: [ippm] Request for presentations at IETF 112 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, 22 Oct 2021 21:27:57 -0000 --_000_SJ0PR02MB78538C93DEFEB1946A39CDB8D3809SJ0PR02MB7853namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tbXksDQoNCldl4oCZdmUgaGFkIGEgZ29vZCByZXNwb25zZSB0byBteSByZXF1ZXN0IGZv ciByZXZpZXcgYW5kIGNvbW1lbnRzIG9uIHRoZQ0KDQogICAgICAgICAgIFRlc3QgUHJvdG9jb2wg Zm9yIE9uZS13YXkgSVAgQ2FwYWNpdHkgTWVhc3VyZW1lbnQNCiAgICAgICAgICAgICBkcmFmdC1t b3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtMDENCg0KVmVyc2lvbiAyIHdpbGwg YmUgc3VibWl0dGVkIGJlZm9yZSB0aGUgZGVhZGxpbmUsIGFkZHJlc3NpbmcgbWFueSBvZiB0aGUg Y29tbWVudHMgYW5kIG9wZW5pbmcgZnVydGhlciBkaXNjdXNzaW9uIG9uIG90aGVycywgc3VjaCBh cyB0aGUgc3VnZ2VzdGlvbiB0byBtZWFzdXJlIGludGVyZmFjZSBieXRlIGNvdW50cyBkdXJpbmcg dGVzdGluZyBvbiBhIGN1c3RvbWVyIGdhdGV3YXkgKHRvIGRldGVybWluZSB0aGUgYWdncmVnYXRl IG9mIGFsbCB0cmFmZmljIGluIGNhc2UgdGhlIHRlc3Qgc3RyZWFtIHNoYXJlcyB0aGUgbGluayB3 aXRoIGN1c3RvbWVyIHRyYWZmaWMpLg0KDQpTbywgSeKAmWQgbGlrZSB0byBhZGRyZXNzIGFkZXF1 YXRlIGFnZW5kYSB0aW1lIGZvciB0aGlzIGFuZCB+MyBvdGhlciBvcGVuIGlzc3Vlcy4NCg0KQWxz bywgSSB3b3VsZCBiZSBoYXBweSB0byBzcGVuZCA1IG1pbnV0ZXMgb24gbXkgcG9zaXRpb24gcGFw ZXIvSS1kcmFmdCBmb3IgdGhlIElBQiB3b3Jrc2hvcCwgd2hpY2ggc29tZSBmb2xrcyB0aG91Z2h0 IHdhcyB1c2VmdWwuDQoNCnRoYW5rcywNCkFsDQoNCg0KRnJvbTogaXBwbSA8aXBwbS1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVG9tbXkgUGF1bHkNClNlbnQ6IEZyaWRheSwgT2N0b2Jl ciAyMiwgMjAyMSA0OjQ5IFBNDQpUbzogSUVURiBJUFBNIFdHIChpcHBtQGlldGYub3JnKSA8aXBw bUBpZXRmLm9yZz4NClN1YmplY3Q6IFtpcHBtXSBSZXF1ZXN0IGZvciBwcmVzZW50YXRpb25zIGF0 IElFVEYgMTEyDQoNCkhpIElQUE0sDQoNCkF0IElFVEYgMTEyLCB3ZeKAmWxsIGhhdmUgYSB0d28t aG91ciBzZXNzaW9uIG9uIFRodXJzZGF5LCBOb3ZlbWJlciAxMSAoaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzExMi9hZ2VuZGEvPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMTIvYWdlbmRhL19fOyEhQmhk VCF6Z2lKRXYtcmVpMmxOcldVaDA5amZfLUNMTkg1TU5kSW9yczBfZnZWT0ZyNTF1c1o5VHZQS0tV YTR1WTgkPikuDQoNCldl4oCZbGwgbWFpbmx5IGZvY3VzIG9uIGFkb3B0ZWQgZG9jdW1lbnRzLCBi dXQgcGxlYXNlIGRvIGVtYWlsIHRoZSBjaGFpcnMgb3IgdGhlIGxpc3Qgd2l0aCByZXF1ZXN0cyBm b3Igb3RoZXIgdG9waWNzIC8gbmV3IHdvcmsuDQoNCkJlc3QsDQpUb21teQ0K --_000_SJ0PR02MB78538C93DEFEB1946A39CDB8D3809SJ0PR02MB7853namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDdDNzZBLjE3OUI4RDUwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRLaW5kPg0KPHc6VHJhY2tN b3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRh dGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhN TEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250 ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxh Y2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1V UzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4 U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0K PHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNuYXBUb0dyaWRJbkNlbGwvPg0KPHc6V3JhcFRl eHRXaXRoUHVuY3QvPg0KPHc6VXNlQXNpYW5CcmVha1J1bGVzLz4NCjx3OkRvbnRHcm93QXV0b2Zp dC8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5p bmcvPg0KPHc6RG9udEZsaXBNaXJyb3JJbmRlbnRzLz4NCjx3Ok92ZXJyaWRlVGFibGVTdHlsZUhw cy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJD YW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIg bTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYv Pg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVm SmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8 bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8 L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERl ZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9 ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjM3NiI+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9 Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXgg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJh bm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2Fw dGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52 ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJl ciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2Yg YXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNp Z25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJh Z3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0 bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5 IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxv d2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAo V2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i SFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3Vi amVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBs ZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBD bGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29s dW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg R3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlz dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZm ZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9u YWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2Vi IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJs ZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIg VGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlk Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRp dW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4 IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNv bG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5h bWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNl IFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1l ZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0i Q29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xv cmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJM aWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9 Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwg TGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVt IEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWlu IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUi IE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBU YWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIg TmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQg VGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikdy aWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRh YmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlk IFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRh YmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJs ZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBU YWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJs ZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUg MiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFi bGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUg NyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxl IDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1 IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0 IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi IE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBD b2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIg TmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3Qg VGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFt ZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5h bWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRh YmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9 Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1l PSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJs ZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJM aXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0i TGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUg MyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlz dCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxp c3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3Qg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0 IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO YW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRh YmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZW50aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNtYXJ0 IEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIYXNodGFnIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlVucmVzb2x2ZWQgTWVudGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTbWFy dCBMaW5rIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1h bHQ6IlBhbGF0aW5vIExpbm90eXBlIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy aWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOi01MzY4NjkxMjEgMTEwNzMwNTcyNyAzMzU1NDQzMiAwIDQxNSAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNlbnR1cnkgR290aGljIjsNCgltc28tZm9udC1jaGFy c2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi00Njk3NTAwMTcgLTEwNzM3MzI0ODUgOSAw IDUxMSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFm b3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltc28tcGFn aW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0 LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRp b246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWkt Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1s b2NrZWQ6eWVzOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LXNpemU6MTAuMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNvLWZv b3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+ PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXtt c28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTow Ow0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRp bmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCgltc28t cGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZh bDouNWluO3dvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij5IaSBUb21teSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5XZeKAmXZlIGhhZCBhIGdvb2QgcmVzcG9uc2UgdG8g bXkgcmVxdWVzdCBmb3IgcmV2aWV3IGFuZCBjb21tZW50cyBvbiB0aGUNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+VGVzdCBQcm90b2NvbCBmb3IgT25lLXdh eSBJUCBDYXBhY2l0eSBNZWFzdXJlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZHJhZnQtbW9y dG9uLWlwcG0tY2FwYWNpdHktbWV0cmljLXByb3RvY29sLTAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEz Ny40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4 LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQu OHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40 cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5WZXJzaW9uIDIgd2lsbCBiZSBzdWJt aXR0ZWQgYmVmb3JlIHRoZSBkZWFkbGluZSwgYWRkcmVzc2luZyBtYW55IG9mIHRoZSBjb21tZW50 cyBhbmQgb3BlbmluZyBmdXJ0aGVyIGRpc2N1c3Npb24gb24gb3RoZXJzLCBzdWNoIGFzIHRoZSBz dWdnZXN0aW9uIHRvIG1lYXN1cmUgaW50ZXJmYWNlDQogYnl0ZSBjb3VudHMgZHVyaW5nIHRlc3Rp bmcgb24gYSBjdXN0b21lciBnYXRld2F5ICh0byBkZXRlcm1pbmUgdGhlIGFnZ3JlZ2F0ZSBvZiBh bGwgdHJhZmZpYyBpbiBjYXNlIHRoZSB0ZXN0IHN0cmVhbSBzaGFyZXMgdGhlIGxpbmsgd2l0aCBj dXN0b21lciB0cmFmZmljKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4w cHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZw dCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRhYi1zdG9wczo0NS44 cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0 IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQg NzMyLjhwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPlNvLCBJ4oCZZCBsaWtlIHRvIGFkZHJlc3MgYWRlcXVhdGUgYWdlbmRh IHRpbWUgZm9yIHRoaXMgYW5kIH4zIG90aGVyIG9wZW4gaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZw dCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0 IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQg Mjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1 OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+QWxzbywgSSB3b3VsZCBiZSBo YXBweSB0byBzcGVuZCA1IG1pbnV0ZXMgb24gbXkgcG9zaXRpb24gcGFwZXIvSS1kcmFmdCBmb3Ig dGhlIElBQiB3b3Jrc2hvcCwgd2hpY2ggc29tZSBmb2xrcyB0aG91Z2h0IHdhcyB1c2VmdWwuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRhYi1zdG9w czo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAz NjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4 Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4 My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAz LjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij50aGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRh Yi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIw LjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEu MnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+IGlwcG0gJmx0O2lwcG0tYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9u IEJlaGFsZiBPZiA8L2I+VG9tbXkgUGF1bHk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3Rv YmVyIDIyLCAyMDIxIDQ6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgSVBQTSBXRyAoaXBwbUBp ZXRmLm9yZykgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtpcHBt XSBSZXF1ZXN0IGZvciBwcmVzZW50YXRpb25zIGF0IElFVEYgMTEyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+SGkgSVBQTSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+QXQgSUVURiAxMTIsIHdl4oCZbGwgaGF2ZSBhIHR3by1ob3VyIHNlc3Npb24g b24gVGh1cnNkYXksIE5vdmVtYmVyIDExICg8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTEyL2FnZW5kYS9fXzsh IUJoZFQhemdpSkV2LXJlaTJsTnJXVWgwOWpmXy1DTE5INU1OZElvcnMwX2Z2Vk9GcjUxdXNaOVR2 UEtLVWE0dVk4JCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzExMi9hZ2Vu ZGEvPC9hPikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+V2XigJlsbCBtYWlubHkgZm9j dXMgb24gYWRvcHRlZCBkb2N1bWVudHMsIGJ1dCBwbGVhc2UgZG8gZW1haWwgdGhlIGNoYWlycyBv ciB0aGUgbGlzdCB3aXRoIHJlcXVlc3RzIGZvciBvdGhlciB0b3BpY3MgLyBuZXcgd29yay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPlRvbW15PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SJ0PR02MB78538C93DEFEB1946A39CDB8D3809SJ0PR02MB7853namp_-- From nobody Fri Oct 22 16:19:57 2021 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 6BC563A0918; Fri, 22 Oct 2021 16:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 IPjux7pXsRXM; Fri, 22 Oct 2021 16:19:43 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E4F3A08E7; Fri, 22 Oct 2021 16:19:39 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 19MNJ45E026232; Fri, 22 Oct 2021 16:19:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=MJN1kfArMBusHaplLHvA8OwvGraRAIK5d0uskiCdiFs=; b=UkU7mWCr9C3e/7unzyS+qaGNDaVdgzzybu0QGCIw0PcMLMtTed+Z7iNPoQ81o02K04p8 jAb1BaYKlKMXOft5sH9GyQ3yHsF03CyHo8BCfyiEcV31E/m036j3PeReyTqCSvfIZOX1 1lSNrWnYto6L2DLMteIvTm0HUXHltaPyAJ3wHTsCwuY0b4Zk84SjqgUDBGr1mKKPQJpl KAvfjBPdutmosuVVDV/Qes8+XGrxqI1VIixX6cUPcj5PCcY92SxijZRdy6PgD6O/mL0W mTYKlh3Bcfg/mLiDUN0cJ7fsLT/09NNk72XvpQE+ve8nC2smg2/LQ1jPKUx0JtyDAuM9 HA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3bqwd6bave-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Oct 2021 16:19:33 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1E00DZCJGK9K80@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 22 Oct 2021 16:19:32 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1E00R00IUZ5900@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 22 Oct 2021 16:19:32 -0700 (PDT) X-Va-A: X-Va-T-CD: f531f8d8b46e434c6cc260b03cd4b544 X-Va-E-CD: 80ebf395e5bfaf9dd37d2e1677896837 X-Va-R-CD: 34a054e2b971ae162a64f30ab9c21b58 X-Va-CD: 0 X-Va-ID: c2c5686e-5e9d-4819-8986-b522256e6881 X-V-A: X-V-T-CD: f531f8d8b46e434c6cc260b03cd4b544 X-V-E-CD: 80ebf395e5bfaf9dd37d2e1677896837 X-V-R-CD: 34a054e2b971ae162a64f30ab9c21b58 X-V-CD: 0 X-V-ID: d492810b-ccf9-4761-b0f6-853426e1f1de X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Received: from smtpclient.apple ([17.11.46.46]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1E00NCSJGG5T00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 22 Oct 2021 16:19:32 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Christoph Paasch In-reply-to: Date: Fri, 22 Oct 2021 16:19:28 -0700 Cc: Erik Auerswald , ippm@ietf.org, draft-cpaasch-ippm-responsiveness@ietf.org, bloat@lists.bufferbloat.net Content-transfer-encoding: quoted-printable Message-id: References: <20210815133922.GA18118@unix-ag.uni-kl.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-22_05:2021-10-22, 2021-10-22 signatures=0 Archived-At: Subject: Re: [ippm] [Bloat] Fwd: New Version Notification for draft-cpaasch-ippm-responsiveness-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: Fri, 22 Oct 2021 23:19:56 -0000 Hello Toerless, thanks for your feedback! Please see inline: > On Sep 21, 2021, at 1:50 PM, Toerless Eckert wrote: >=20 > Dear authors >=20 > Thanks for the draft >=20 > a) Can you please update naming of the draft so people remembering RPM = will find the draft ? > Something like: >=20 > draft-cpaasch-ippm-rpm-bufferbloat-metric-00 > Round-trips Per Minute (RPM) under load - a Metric for bufferbloat. That's a good point! How does draft-cpaasch-ippm-responsiveness-rpm-00 = sound? I prefer not to have bufferbloat in the name as it is a loaded term = (there are different interpretations of it) and easily misunderstood. = Some consider bufferbloat to only be a problem on the routers/switches, = while others consider it to be an end-to-end problem. Our test = methodology measures end-to-end responsiveness and end-to-end here goes = all the way up to the HTTP/2 implementation. > b) The draft does not mention, or at least does not have a > separate section to discuss where the server is against which the = test is run. > It should have such a section. I can hink of at least two key = options, > - the server used for the service in question (e.g.: where contents = comes from), > - a server at a wll defined location in the access network provider. I see your point. I don't think the draft needs to "mandate" where one = should put those servers. But rather a discussion on where one may want = to place the server depending on what one is measuring. A WiFi AP vendor may want to deploy the server locally in his testbed. A = content-provider wants to host the server on its content-servers. And an = ISP wants to host it probably at the border of its domain. > c) I fear that b) leads to be biggest current issue with the metric: > The longer the path is, such as full path to a server, the more = useful the > metric is for the user. But the user will effectively get a = per-service metric. > To make this more fun to the authors: Imagine the appleTV server = nodes have a worse > path to a particular user than the Netflix servers. Or vice versa. >=20 > If we just use a path to some fixed point in the access provider, > then we take away the users ability to beat up their OTT services to > improve their paths.=20 >=20 > If we use only a path toward the service, it will be harder to=20 > hit on the service provider, if the service provider is bad. >=20 > So, obviously, i would like to have all three RPM: to Netflix, = AppleTV > and a well defined server in Comcast. Then i can triangulate where > my bufferbloat problem is. Yes, the location of the server has a huge impact on the resulting = number. The goal with responsiveness is to measure user-experience. If = the user uses Netflix, AppleTV and Comcast streaming, that's what the = user is interested in. If the user also uses some remote streaming = service on the other side of the ocean, that's as well the = responsiveness number the user would be interested in. > d) Worst yet, without having seen more example numbers (a reference = pointing > to some good collected RPM numbers would be excellent), my > concern is that instead of fixing bufferbloat on paths, we would = simply > encourage OTT to co-locate servers to the access providers own = measurement > point, aka: as close to the subscriber. Deploying close to the subscriber does not yet fix the = bufferbloat-problem. If the last-mile or the HTTP-implementation has = bufferbloat issues, they are still going to present a bad RPM-number. = Sure, once we have eradicated bufferbloat from the Internet, then = closeness to the subscriber will become a more driving factor. And that = would be a good problem to have :-) >=20 > e) To solve d), maybe two ideas: >=20 > - relevant to improve bufferbloat is only (lRPM - iRPM), where > lRPM would be your current RPM, e.g.: under (l)oaded condition), > and iRPM is idle RPM. This still does not take away from the > fact that a path with more queuing hops or higher queue loads > will fare worse than the shorter physcial propagation latency = path, > but it does mke the metric significantly be focussed on queueing, > and should help a lot when we do compare service that might not > have servers in the users metro area. The difficulty here is that it is near impossible to really measure = iRPM. Because, one cannot know whether the network really is idle or = not. >=20 > - lRPM/m - RPM under load per mile (roughly). > - Measure idle RTT in units of msec (iRTT) >=20 > - Measure load RTT in units of msec (lRTT) >=20 > - Just take iRTT as a measure for the path lenth. > normalizing it absolutely is not of first order > important, we are primarily interested in relative number, > and this keeps the example calculation simple. >=20 > - the RTT increase because of queueing is (lRTT - iRTT). >=20 > - (lRTT - iRTT) / iRTT is therefore something like queuing RTT > per path stretch. I think this is th relative number we want. >=20 > - RPM =3D iRTT / (lRTT - iRTT) * 1000 turns this into some=20 > number increasing with desired non-bufferbloat performance > with enough significant in non fractionals. >=20 > - Example:=20 > idle RTT: 5msec, loaded RTT: 20 msec =3D> 333 RPM > idle RTT: 10msec, loaded RTT: 20 msec =3D> 1000 RPM > idle RTT: 15msec, loaded RTT: 20 msec =3D> 3000 RPM >=20 > This nicely shows how the RPM will go up when the physcial > path itself gets longer, but the relevant load RTT stays=20 > the same. >=20 > idle RTT: 5msec, loaded RTT: 20 msec =3D> 333 RPM > idle RTT: 10msec, loaded RTT: 40 msec =3D> 333 RPM > idle RTT: 15msec, loaded RTT: 60 msec =3D> 333 RPM >=20 > This nicely shows that we can have servers at different > physical distance and get the same RPM number, when the > bufferbloat is the same, e.g.: 15 msec worth of bufferbloat > for every 5msec propagation latency segment. >=20 > f) I can see how you do NOT want the type of metric i am > proposing, because it only focusses on the bufferbloat > factor, and you may want to stick to the full experience of > the user, where unmistakingly the propagation latency can > not be ignored, but to repeat from above: >=20 > If we do not use a metric that fairly treats paths of different > propagation latencies as the same wrt. performance, i am > quite persuaded we will continue to just see big services > win out, because hey can more easily afford to get closer > to the user with their (rented/time-shared/owned) servers. >=20 > Aka: Right now RPM is a metric that will specifically=20 > make it easier for one of the big providers of sttreaming > such as that of the authors to position themselves better > against smaller services streaming from further away. The goal of the responsiveness measurement is not for it to be a = diagnostic tool that allows to find the accurate location of = bufferbloat. It is also not a tool to make some streaming service = providers look better than others and/or make one "win" against the = other. The goal really is to have an accurate representation of responsiveness = under working conditions. If the server end-point is at a very remote = location, then indeed the RPM number will be lower. And the = responsiveness measurement should reflect that, because it tries to = assess the user-experience. With the standardization of the methodology our hope is that = content-providers (small or big) would adopt this methodology so that = they can properly assess the network's quality for their users and their = services. Cheers, Christoph From nobody Fri Oct 22 16:23:38 2021 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 72E033A08DC for ; Fri, 22 Oct 2021 16:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i40mTBG5HohQ for ; Fri, 22 Oct 2021 16:23:27 -0700 (PDT) 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 875ED3A0912 for ; Fri, 22 Oct 2021 16:23:27 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MMVFjt035755; Fri, 22 Oct 2021 19:23:26 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 3bv65n1ask-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 19:23:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19MNNPck005360; Fri, 22 Oct 2021 19:23:25 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19MNNMVG005328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Oct 2021 19:23:22 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id EE5FC4013F90; Fri, 22 Oct 2021 23:23:21 +0000 (GMT) Received: from MISOUT7MSGEX2DD.ITServices.sbc.com (unknown [135.66.184.207]) by zlp27126.vci.att.com (Service) with ESMTP id CE3164013F81; Fri, 22 Oct 2021 23:23:21 +0000 (GMT) Received: from MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) by MISOUT7MSGEX2DD.ITServices.sbc.com (135.66.184.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Fri, 22 Oct 2021 19:23:21 -0400 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Fri, 22 Oct 2021 19:23:21 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Fri, 22 Oct 2021 19:23:21 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iC5+LAiB5HYYyOAXs1ZLU32qktJzH3SRPd2zJFV5P2I0aXgEAL3hEio/tiQusXU1/+7EGcgltCbTzcxPpvJAvcJyuA6v7vB3f9xCeYC4cHWAg8I3JbFybU52S2/9NVPX3OxKNrs3uhzS1OpVXeNdqz2zJSzyJJLtYXAxdtnKbZ/RXSKhvDqS6a6ayWAXhfJd3J2okH2lsChgq8Eehmr2IMkQBT4Iyw9stjPm0kytUbuvFqAFQ834MDJ2ltdKAMnX5Mm27YuyINbNpUaAiA9QsFbybbA3SXy/eWDsfMDYlED/m435lKK0PHQKxr9ROBDS03LoJiRjnphvxLhSJy+vnA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tk3RRP2CLaZ+eq1GeO2N1ds+X5v7IxjZFos7MCHWwU0=; b=KgXtacoRG60X0+BFoPZbv4aqPxoyiYzY/I8eahXUOMVu3BudUOL8w1t27c8qLPPaXr5Bg0Sr/8foM64hc/x7YJtxHMOfryYnS09ppbJ3dajP7imKvdlTrhiopdXkIXvydGLE+4mAVaeQNGmIl+AJ7eXJVbaQbKQa6o6cj7j6QQp23wsVdkdumGuffWIhjuxhrQwG6Pfu6r+FjY3xZC+ccsevW5KniFWrYAwhS5GsKRvXt97vARcQfdRyMtp4b1Xyhfz56sjFPuS3ceIIDj13cxTsfkpli/gTSbNnxS3K380uCsv9re1yIrQ6SoziNti7iiw+wGdtzRaZIwORvD4G6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tk3RRP2CLaZ+eq1GeO2N1ds+X5v7IxjZFos7MCHWwU0=; b=RNBktZynKmtI2eaty9RAG4eEwIvPmL1FZpN40eOokrDlBqTe4RFUN9SBByINnH18kaZNjGeJKI/Ad/P8G0BVMWJ7/Y38w7HQaTvCa8F6szPztB+EWwgZN/Vg8hKcgKGp9rniYpKovjUVC0XbxXr/3D7GnXpp4q/1GMYiybLjsuQ= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB5719.namprd02.prod.outlook.com (2603:10b6:a03:11e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Fri, 22 Oct 2021 23:23:14 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%5]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 23:23:14 +0000 From: "MORTON JR., AL" To: "Ruediger.Geib@telekom.de" CC: "ippm@ietf.org" Thread-Topic: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AQHXxmGb2Bs+Ikc7FEOtU5OB8puCNqvfqAVQ Date: Fri, 22 Oct 2021 23:23:14 +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: telekom.de; dkim=none (message not signed) header.d=none;telekom.de; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ab85a5a-5f97-4ce6-a601-08d995b2ebf2 x-ms-traffictypediagnostic: BYAPR02MB5719: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r5Gg7kq3B8M7EwdCB7iGV2xN3pnPuU6+OKZW/YPCf1dC2VBPGwwQUHQ3914XVyEjC2ZOoYwSxYQiYQGRFmbFacd1Pzvv4esnt2WxHlxRu7J+XKIoqkuDiy/57D0pEOzqLHdk3jyFLO7FcICi4+aX6Nnu16mJyFofeQWbBPYW5I9BqtoWMRWSScnSCnlN4abYNafGGzrnyLSQ77SHISTYjaUsdh9mNRkjoiLcpsyFdVJQhxiizDFidaqWZkzxpDt0RmBq3wH47elW7QvgL5cZ3slA4YXRR1KxxzifcehGcsVYOoCR6oaoFiCBFRruCJHOWA5mFRufq6jEaCrryvvvxCf/h3e5v3zU9Cf7lUcQzzqLajVNyAOpe/2j1/+R96U5yj5PMINZh2Mi+dRzUZOkNA3s5Sa3+M/jSRkNBLoZCE/69qW9gO+I+jVyzJe10e9C1E0CGA2b7yGwoq/rQ6ArLh4qO7vQ0DugUVJEvm6vYZB+ln0/TmMiiGeCKX52ocr0rCoK1hWIm91juiGnwMPq6HjlajZXmn1mgiTs8EP4UYj0hntoXtEN0kOdr8681kQfZ09427ZzY2PqteUmcCoCbpAq4ky1C2dPykwOjisJtU16rZ9iWKeTKeHFRmjAoiGvi/hVL+ZqncKWR+vI6/mWWoL5rDU2tTketGC5RKD/EtYdQQN39w2AerPOjiOxLpiLKUaJA0qa7GBs5Ew5lTLZRJG7aXFDo/wJFMnJJBl/lPAjxhnjMwpjVw/RH4az1iZvv2A+l0uVA886l1GUiO4beSGIrsmC8kYLimDhz1pyCZ8Udv1rkF4hq1595iTEg14sCoxN0nFSrY0qZZW4OtuQSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(82960400001)(6506007)(52536014)(8676002)(2906002)(66476007)(66574015)(8936002)(82202003)(9686003)(33656002)(4326008)(122000001)(66946007)(38070700005)(66446008)(38100700002)(508600001)(26005)(83380400001)(76116006)(66556008)(966005)(316002)(71200400001)(64756008)(55016002)(186003)(6916009)(53546011)(86362001)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?En2iXMWDwQ5IEg4hq3Y9hQkHoBD9lUBta0eTpE0lF4y+6bM0YDmz5BGKdv?= =?iso-8859-1?Q?KLuDibq2gUCcoBvZc66VYDFDFnzoy35Nzuyl7AaftYTTTpeUL4iWxxoOjT?= =?iso-8859-1?Q?A49l//ROmaAOOvI4zVZyF9+CsCY3Nc6GBDXnATwErR0l9wT9fpT0dxLOnc?= =?iso-8859-1?Q?Z96NuuszU22DoEPH/pxOKG/Iar2GfGxwVmWWg7Rwy0vTppVLsd3OUbY/QN?= =?iso-8859-1?Q?EQgAzGARGQgIGJayeKCa4OXR5Eovi7hK57i2lJb5KjUijzlRxOwETRt2lA?= =?iso-8859-1?Q?WZk5RBRM6IzaD7erBmZ0NMKY+2AHNaOv5JI1IemEX7Q3SVhFZ7M6C2bB7q?= =?iso-8859-1?Q?Ono+8gMwdAPmO/80C5DNzbmWg0lkkBDQRTkJz8dsnAYo7F06GwMMUzmrlI?= =?iso-8859-1?Q?2ioafHjUKYSmlTqMgaH0Bl9YlE2hjLXEYeMMTzRvqSOYsioVhQp2T0isIA?= =?iso-8859-1?Q?+6iWCEc8QHPmv6GjdzQorg0yD9weqEgxhy2PtE0RPHQNkvN5T8eA2ShG0t?= =?iso-8859-1?Q?RyI7e5G0Y7ZJwqs/bj8oza0m2jIu48yKl8inwAho167TBJsm/q7yNIuXLu?= =?iso-8859-1?Q?GiuX4usm5xcxKtW1SVCd6Jd1m9alfbTuc91IqNYzkSFpEsBPaXEFuTI1zC?= =?iso-8859-1?Q?rnBxtSJV7uVMUCm3/cyYxGqZq1pjhY9UbgZ7tawiJC5iY60fVx4Izeq1xi?= =?iso-8859-1?Q?/KIn/Xc49nOX+62wC7Mj+AYL/IpZCBZ/+m4TZGZfmWO6QVRJje+6gBdAch?= =?iso-8859-1?Q?fbn1JKqd8AhknbKJYV8jIEd5lb0DkU1gzebEwX/tYyoP8EscwrFM+keBqe?= =?iso-8859-1?Q?ImL3IZGZ3TGl3aDWuDn5iRzAov/PNnYdnue7BHfDP3YMi1yiqhIIRqhqU+?= =?iso-8859-1?Q?DVrnqFGYBv1a8M62T5OVuTSRW4PQVbPFia/XBMGhJIr44QdMebS3ivZHsd?= =?iso-8859-1?Q?1YPIr6/x8QCOfJOFEd25tpuXB0Sw/vJ/LFaR864EbyGNBhgIG3sMcICGas?= =?iso-8859-1?Q?q2hVsGrlEXq8m1l6O+cyw8/tOup4/MF3Gs0IHimx8q7zb8uAvN1+eD9OeM?= =?iso-8859-1?Q?u2QU/bNlr+X6T/qAowh3dYUlaxaE8CKwGesud+2z8wROpplSpyWB1DL3QM?= =?iso-8859-1?Q?oa4Qg9mJcaDGSafvDbMzESsz0wUuYpx/M6oC0eCkyHMj+J5tO5K6qoby/9?= =?iso-8859-1?Q?j7jGLXreymRH3RGNX1KTSCL9m0aeW50nEmJe5PghjmSBw4H7YcL+Dw1A3s?= =?iso-8859-1?Q?juMyNPE5bNch0UpSSZBhnI08iRXJ9Hjq8rTUT34OJRDAYQss3nPdMyXENG?= =?iso-8859-1?Q?FnY3xtpPM+g4jiNNa59HCg3kDJMcVBOCA/V0X5eENck6tb6Ga7h7IOpABh?= =?iso-8859-1?Q?9I2Dn/t7Tb?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ab85a5a-5f97-4ce6-a601-08d995b2ebf2 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 23:23:14.3686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: am2935@att.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5719 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 1E6672A254B0EEE845F4D729E3CDF4A8E87282D2C0EFD20BA30777B256FDE6352 X-Proofpoint-GUID: z74KdC3aG1SYdp49hV33bGhK5dAhpsPV X-Proofpoint-ORIG-GUID: z74KdC3aG1SYdp49hV33bGhK5dAhpsPV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-22_05,2021-10-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 impostorscore=0 clxscore=1015 adultscore=0 mlxlogscore=878 phishscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220132 Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 22 Oct 2021 23:23:35 -0000 Hi R=FCdiger,=20 Many thanks for your review and comments! Please see replies below, [acm] Al > -----Original Message----- > From: Ruediger.Geib@telekom.de > Sent: Thursday, October 21, 2021 5:54 AM > To: MORTON JR., AL > Cc: ippm@ietf.org > Subject: AW: [ippm] Questions on draft-morton-ippm-capacity-metric-protoc= ol-01 >=20 > Hi Al, >=20 > A standardized protocol to request a standardized access bandwidth measur= ement > is a generic requirement and I appreciate your initiative. As a person no= t > personally implementing software, some high level comments on the doc onl= y: >=20 > 2. Scope, Goals, and Applicability, last sentence: >=20 > "The primary application of the protocol described here is the same as > in Section 2 of [RFC7479] where:" >=20 > That's a mis-quote, isn't it? You target another RFC, don't you? [acm]=20 Yes, that's a typo it is 7497. > From numbers I guessed: > https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section-2__;Iw!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$ [acm]=20 right! >=20 > I started with a minor issue, as it points to RFC7497. The latter RFC con= tains > the following statement: > https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section-7__;Iw!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$ > "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do no= t > possess the asymmetric size generation capability with two-way testing." [acm]=20 Right, we have a different problem with TWAMP and others, described below. >=20 > Adding a brief section to draft-morton-ippm-capacity-metric-protocol > discussing why e.g. TWAMP (or a simplified version) isn't applied or rath= er > enhanced for the measurement protocol may be useful. If existing IETF IPP= M > measurement control protocols don't offer any benefits justifying their > adaption for a capacity-metric-protocol, the section will be brief. If th= ere's > pro and con, what's worth adding functionality to TWAMP and what's the "c= ost" > (in terms of work and changes) may be worth some words. Should inclusion = of a > capacity-metric-protocol to TWAMP be worth a thought, a few words on requ= ired > features and changes (a sketch on what to add) may be useful. I'm not a T= WAMP > expert, I excuse if my comment doesn't apply. [acm]=20 No problem, I thought about this before writing this draft. It comes down t= o these four points (which I will add in the Intro): Although there are several test protocol already available for support and manage active measurements, this protocol is a major departure from their operation: 1. UDP transport is used for all setup, test activation, and control messages, and for results feedback (not TCP), simplifying operations. 2. TWAMP and STAMP use the philosophy that one host is a Session- Reflector, sending test packets every time they receive a test packet. This protocol supports a one-way test with periodic status messages returned to the sender. 3. OWAMP supports one-way testing with results Fetch at the end of the test session. This protocol supports a one-way test and require= s periodic status messages returned to the sender to support the load adjustment search algorithm. 4. The security features of OWAMP and TWAMP have been described as "unusual", to the point that IESG approved their use while also asking that these methods not be used again. Further, the *WAMP approach to security is over 15 years old at this time. I concluded that any attempt to enhance OWAMP or others would be time waste= d. We have a unique use-case here. thanks, Al >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: ippm Im Auftrag von MORTON JR., AL > Gesendet: Mittwoch, 20. Oktober 2021 00:32 > An: IETF IPPM WG > Betreff: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-0= 1 >=20 > Hi IPPM, >=20 > Len Ciavattone and I am looking for some feedback on our protocol [0] des= igned > to help measure the Maximum IP-Layer Capacity Metric (which will be publi= shed > as an RFC shortly). >=20 > We are asking folks to take a look at the draft, because we are fairly su= re > you will have some questions! >=20 > One area where we know more development is required is the Modes of opera= tion, > which essentially describes how the different aspects/exchanges of the > protocol will be made secure. This is pretty-much a green-field in our > specification, so suggestions are very welcome. Section 10 currently > describes the different modes that we imagined to be useful (A through F > below), but practical aspects of any proposed solution might indicate mod= es > that should be combined, split-up, or new modes. >=20 > So, please give the draft and/or the list below a look, and let us know w= hat > you think. >=20 > thanks! > Al >=20 >=20 > [0] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra= ft- > morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$ >=20 > 3. Client-server authentication and integrity protection for > feedback messages conveying measurements is RECOMMENDED. To > accomodate different host limitations and testing circumstances, > different modes of operation are recommended: >=20 > A. Un-authenticated mode (for all phases) AND B. OPTIONAL Authenticated= set- > up only > SHA-256 HMAC time-window verification (5 min time stamp verification) (co= uld > add silent failure option) >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > C. Encrypted setup and test-activation > (currently using OpenSSL Library, so KISS, but may be too slow for test > packets) >=20 > -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D-= =3D-=3D-=3D-=3D-=3D- >=20 > D. Encrypted feedback messages >=20 > E. Integrity protection for test packets SHA-256 HMAC >=20 > F. Encrypted test packets (maybe also valuable to defeat compression on > links) >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;= !!Bhd > T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$ From nobody Sun Oct 24 16:29:21 2021 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 2307F3A085A for ; Sun, 24 Oct 2021 16:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ekTrTu_WHoD for ; Sun, 24 Oct 2021 16:29:16 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 D03EC3A085C for ; Sun, 24 Oct 2021 16:29:15 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id s1so9181852edd.3 for ; Sun, 24 Oct 2021 16:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J8AGgqBGH/O4lqb6y1ml7q/vQDLi8eNpgOconViPwCI=; b=nhjpWldQmSLttzMUPNnXo0p/ajn8xUAUjTQrrI0Z2RwgtybzMAvH/E3GP81Q6nsKoF pLDH5L9acv/1nVwXJfQOHei+0dN/ib6uaexl5KlNe9uopjagAyMWuft7p9/fb6w87QUH KAWxUxF0psPc8Pg+dnnjlWyL9MN8MbU+bWfeFuD2DtsaqpZTQNk4NUWJnDvZ6wI8k0J3 OPp9nPiF30GoLgBMkgeIggi+PPV+uoddCCXhlwBhKRNb8He8PX2PQYFyRxK8lJO11XuJ enoLFhYg+ZyNwcEmk0HUm0LXNw6ixmHueWdyqsCFtKFvEJ3DmqZLZWRAJDr2+4kEu8Ly Gx1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J8AGgqBGH/O4lqb6y1ml7q/vQDLi8eNpgOconViPwCI=; b=MiPBB0x7VlelQpuBg+6h7fb1wMHqIE3K6gYuhIowMASe+l8zySoz5UTo1fCDfSar3v +3UNq7wtH5TJatLEYTnlTBrKUMd5DdyIzdECyKfBgIWIg/8psoMwGxukX+GfPyLn7Qrr RY1V3nJaljFJqh5hFneQf4oncyz5YjEkmVmIvPRPTCf5vovHxFhuUv5CO0aRHomXHPCY OMk4gTQcPEqi0NeDRzRQX8F6OXma656Ej6l6idyWYgb52Cay9hZ6yEGP8AW0MqofWHhv eQdsO/UPUGb2h48mQ61ls7KVdJ5rHjMY3uHhhibgBYifskmimN4DJJgvSvIQb3NloQRX HRaQ== X-Gm-Message-State: AOAM532di8sudPmRCfC3q/EgwIMoPuSm+22Rls4ZjZxEeR9QPeDCRjqW qIMfr2MxAKhzP8ST9fEAVLgxRcVZIGD+lG2E/9NOAdExoII= X-Google-Smtp-Source: ABdhPJwB58c5f5Xb9BQq1mCtXOrxcCAaPGaFFLxhMeuU9GH82Sl77SvezYsHN1KzCJ5sIAoV9kfSUBqyn8UvgdB7tTw= X-Received: by 2002:a50:f087:: with SMTP id v7mr3297074edl.126.1635118153075; Sun, 24 Oct 2021 16:29:13 -0700 (PDT) MIME-Version: 1.0 References: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> In-Reply-To: <8D3F7F9A-F5B1-42E7-A66C-A4E490FBE9AB@apple.com> From: Greg Mirsky Date: Sun, 24 Oct 2021 16:29:02 -0700 Message-ID: To: Tommy Pauly Cc: "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000ae101105cf219cc7" Archived-At: Subject: Re: [ippm] Request for presentations at IETF 112 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, 24 Oct 2021 23:29:20 -0000 --000000000000ae101105cf219cc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tommy, et al. we've updated draft-mirsky-ippm-epm and ask for your consideration of our request for a presentation slot at IPPM WG meeting during IETF-112. Error Performance Measurement Presenter: Greg Mirsky Time: 10 min Regards, Greg On Fri, Oct 22, 2021 at 1:49 PM Tommy Pauly wrote: > Hi IPPM, > > At IETF 112, we=E2=80=99ll have a two-hour session on Thursday, November = 11 ( > https://datatracker.ietf.org/meeting/112/agenda/). > > We=E2=80=99ll mainly focus on adopted documents, but please do email the = chairs or > the list with requests for other topics / new work. > > Best, > Tommy > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000ae101105cf219cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tommy, et al.
    we&= #39;ve updated=C2=A0draft-mirsky-ippm-epm and ask for your consideration of= our request for a presentation slot at IPPM WG meeting during IETF-112.

    Error Performance Measurement=C2=A0 =C2=A0Presenter: Gr= eg Mirsky Time: 10 min

    Regards,
    Greg

    On Fri, Oct 22, 2021 at 1:49 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org&= gt; wrote:
    Hi IPPM,

    At IETF 11= 2, we=E2=80=99ll have a two-hour session on Thursday, November 11 (htt= ps://datatracker.ietf.org/meeting/112/agenda/).

    We=E2=80=99ll mainly focus on adopted documents, but please do email the = chairs or the list with requests for other topics / new work.
    Best,
    Tommy
    ______________________________= _________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000ae101105cf219cc7-- From nobody Sun Oct 24 18:54:12 2021 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 EB2713A0922 for ; Sun, 24 Oct 2021 18:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJjuLGtNpaI0 for ; Sun, 24 Oct 2021 18:54:06 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218503A0907 for ; Sun, 24 Oct 2021 18:54:06 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HcyYj1qB3z67bGx for ; Mon, 25 Oct 2021 09:49:29 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Mon, 25 Oct 2021 03:53:56 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 25 Oct 2021 09:53:54 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Mon, 25 Oct 2021 09:53:54 +0800 From: Tianran Zhou To: Haoyu Song , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 Thread-Index: AdfHDWLNvY93aiAGSwChY0Q0ZX5bBQAXyUagAHSKzyA= Date: Mon, 25 Oct 2021 01:53:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_b6d70edfdb184579901e9b69283cdfe7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 25 Oct 2021 01:54:11 -0000 --_000_b6d70edfdb184579901e9b69283cdfe7huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haoyu, Thanks very much for you interest and comments. This version mainly shows the idea for extension. I will add more details i= n the next version. And please see in line below for my initial thoughts. Cheers, Tianran From: Haoyu Song [mailto:haoyu.song@futurewei.com] Sent: Saturday, October 23, 2021 1:59 AM To: Tianran Zhou ; IETF IPPM WG (ippm@ietf.org) Subject: RE: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-= marking-07 Hi Tianran, I'm interested in this work but I think the draft needs to be expanded to c= larify several points 1. The meaning and usage of the flag bits need to be further explaine= d. For example, what's the true meaning of "flow direction"? ZTR> Yes, I will add more details in the next version. In brief, the "flow = direction" is used to address the requirement on setup backward direction f= low monitoring automatically. Alt-MK applied to one direction only before. = This flag is use to indicate the need to set up. 2. The use of meta info is not explained. ZTR> The meta info is used to provide some more information to help the Alt= -MK measurement. I just listed some idea in the draft, but not describe the= detailed data format. This will be added in the next version. 3. The capability description is too terse for me to catch the real i= mpact of the enhancement. For example, what's the thicker loss measurement = and more dense delay measurement? How does the new enhancement help to achi= eve the goal and how much can it help? ZTR> Yes, I will add more info later. On you specific question on the delay= enhancement, our idea is to add a timestamp taken from the head node, as t= he meta data. There are many ways to use it. For example, in this way, the = intermediate node can always compare with this timestamp to check the delay= . Thanks, Haoyu From: ippm > On Behalf = Of Tianran Zhou Sent: Thursday, October 21, 2021 11:27 PM To: IETF IPPM WG (ippm@ietf.org) > Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alterna= te-marking-07 Hi WG, There are many interests in this working group working on the alternate mar= king, RFC8321 and RFC8889. As you may have seen, we applied this method in IPv6, and the draft is in I= ESG review. https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ Based on the above draft, and the comments/suggestions we received, we prod= uced an Enhanced Alternate Marking Method. https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking= / This document extends the IPv6 Alternate Marking Option, to provide the en= hanced capabilities and allow advanced functionalities. We hope you like this idea. Any comments are welcome. Thanks, Tianran --_000_b6d70edfdb184579901e9b69283cdfe7huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Haoyu,

     

    Thanks very much for y= ou interest and comments.

    This version mainly sh= ows the idea for extension. I will add more details in the next version.

    And please see in line= below for my initial thoughts.

     

    Cheers,

    Tianran

     

    From: Haoyu Song [mailto:haoyu.song@futurewei= .com]
    Sent: Saturday, October 23, 2021 1:59 AM
    To: Tianran Zhou <zhoutianran@huawei.com>; IETF IPPM WG (ippm@= ietf.org) <ippm@ietf.org>
    Subject: RE: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alt= ernate-marking-07

     

    Hi Tianran,

     

    I’m interested in this work but I think the dr= aft needs to be expanded to clarify several points

     

    1.       The meaning and usage of the flag bits need to be f= urther explained. For example, what’s the true meaning of “flow= direction”?

    ZTR> Yes, I will ad= d more details in the next version. In brief, the “flow directionR= 21; is used to address the requirement on setup backward direction flow mon= itoring automatically. Alt-MK applied to one direction only before. This flag is use to indicate the need to set up.

     

    2.       The use of meta info is not explained.

    ZTR> The meta info = is used to provide some more information to help the Alt-MK measurement. I = just listed some idea in the draft, but not describe the detailed data form= at. This will be added in the next version.

     

    3.       The capability description is too terse for me to c= atch the real impact of the enhancement. For example, what’s the thic= ker loss measurement and more dense delay measurement? How does the new enh= ancement help to achieve the goal and how much can it help?

    ZTR> Yes, I will ad= d more info later. On you specific question on the delay enhancement, our i= dea is to add a timestamp taken from the head node, as the meta data. There= are many ways to use it. For example, in this way, the intermediate node can always compare with this timestamp = to check the delay.

     

    Thanks,

    Haoyu

     

    From: ippm <ippm-bounces@ietf.org> On Behalf Of Tianran Zhou
    Sent: Thursday, October 21, 2021 11:27 PM
    To: IETF IPPM WG (ippm@ietf.org= ) <ippm@ietf.org>
    Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-= alternate-marking-07

     

    Hi WG,

     

    There are many interests in this working group worki= ng on the alternate marking, RFC8321 and RFC8889.

    As you may have seen, we applied this method in IPv6= , and the draft is in IESG review.

    https://datatracker.ietf.org/doc/draft-= ietf-6man-ipv6-alt-mark/

     

    Based on the above draft, and the comments/suggestio= ns we received, we produced an Enhanced Alternate Marking Method.

    https:= //datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/

     

    This document extends the IPv6 Alt= ernate Marking Option,  to provide the enhanced capabilities and allow= advanced functionalities.

     

    We hope you like this idea.

    Any comments are welcome.

     

    Thanks,

    Tianran

    --_000_b6d70edfdb184579901e9b69283cdfe7huaweicom_-- From nobody Sun Oct 24 19:04:30 2021 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 F367B3A0971; Sun, 24 Oct 2021 19:04:24 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163512746495.11447.9426112830025766452@ietfa.amsl.com> Date: Sun, 24 Oct 2021 19:04:24 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-conf-state-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, 25 Oct 2021 02:04:25 -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 : Echo Request/Reply for Enabled In-situ OAM Capabilities Authors : Xiao Min Greg Mirsky Lei Bo Filename : draft-ietf-ippm-ioam-conf-state-01.txt Pages : 19 Date : 2021-10-24 Abstract: This document describes an extension to the echo request/reply mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can be used within the IOAM domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit node and IOAM decapsulating node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-conf-state-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 24 19:25:34 2021 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 C4C933A08FF for ; Sun, 24 Oct 2021 19:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac5yqyh5_3EI for ; Sun, 24 Oct 2021 19:25:27 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 9EC383A08FA for ; Sun, 24 Oct 2021 19:25:27 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id n1so9633766edd.0 for ; Sun, 24 Oct 2021 19:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OmNrgntc0RBd9A+LpjVqGBw124KKYYVTX5jgIFqjPeo=; b=USlOdr7tMVADbWmesW9o7497oSphKF1jW25J1RMtJXAKMgA3ydmuK+g0o886HWYTk+ hDxd/ChcEabhmPFxwLJ2otUuuBLvhx0VrbFsoV39RFtl/J6wtI85YmxXfN7AAX0Ms0Hf C26bgU+gNis+WzY9EGWA18QsUqw2TtVAraG3OIZC8nn2g/72jOWCPEYgj4L5Qi5w1KJh S+UTn9QRbGbMLngG97vY+rgxnrjJDsxEzoqKjmyffZRL3G8pAR6hEeUOJO3m5asC/tXf zHa3w1db7IMexSV8Y5/kfq2+nRqxzmTj0w8ULdFxWr85AMaAQ1eXkaM5NCNbkpw+Z4ts +e0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OmNrgntc0RBd9A+LpjVqGBw124KKYYVTX5jgIFqjPeo=; b=XHaDF6U/ZIht26dqYY7eav2cV3R5JCrZbYjofV8MqsgzDGsVNOcIH6NHHhojZ73xcd O45ilg2+DHVOIQ6EJ5xTooR9VHzBQy1gRzcTAKz9rgUvA1XiU5JLKhIAMjeHbtipjtcR zoqSdsD1wyk5+NNr8SeaLFMYjgeKdNZyMuawT1POnVkDmEMaeQcz8JPYVYCSYVdAChK2 uYgjodgbcnyl7YNVzIiwS3JMaqZFh8ymS3oN27pIubwWywbajSG8mqnaOdJXOEpyk58N pku2a7JcHSct9orMskuvJ3Gp0Si8/DmGUZcVz8qLBl776T53lJln9xBtjh8ii44OgVH4 dgFg== X-Gm-Message-State: AOAM532Ll+6c4wiWjhVKgdCv+NAd9mDiQhGxXC0ukW45TYooXw8Xe7dP vnchJWCA++pC1tWEvlxYtBKZLvL/u/OzJFAjWyU5RPGOXKk= X-Google-Smtp-Source: ABdhPJwLCOTsSTz7c8iFI9o2Lz8Rd5r08mWRKdRYfqvFmFk8BpYaUHwlzW2XED5H6hODP/YRMJMOwlaz8jeSpICfjLE= X-Received: by 2002:a05:6402:40cf:: with SMTP id z15mr21988330edb.138.1635128724347; Sun, 24 Oct 2021 19:25:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 24 Oct 2021 19:25:13 -0700 Message-ID: To: Tianran Zhou Cc: "IETF IPPM WG (ippm@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000c6dd0605cf241252" Archived-At: Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 25 Oct 2021 02:25:33 -0000 --000000000000c6dd0605cf241252 Content-Type: text/plain; charset="UTF-8" Hi Tianran, thank you for bringing up this work. I've read the draft and have several comments, questions. Please kindly find those below: - Based on the comments during the IESG review of draft-ietf-6man-ipv6-alt-mark, I see a value in extending FlowMonID. That might reduce the probability of a collision. - What could be the use case for the Flow direction identification flag? As the AltMark is applied to the data traffic, wouldn't it always be in the forward direction? - I'm also not clear about the use of the Measurement mode flag. I thought that the mode, hbh or e2e, is determined by the choice of appropriate IPv6 EH - Hop-by-Hop Option Header or Destination Option Header, accordingly. Am I missing something here? - Reading the draft, it was not clear how the extended header helps to lower marking intervals increasing the density of measurements. Regards, Greg On Thu, Oct 21, 2021 at 11:27 PM Tianran Zhou wrote: > Hi WG, > > > > There are many interests in this working group working on the alternate > marking, RFC8321 and RFC8889. > > As you may have seen, we applied this method in IPv6, and the draft is in > IESG review. > > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ > > > > Based on the above draft, and the comments/suggestions we received, we > produced an Enhanced Alternate Marking Method. > > > https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/ > > > > This document extends the IPv6 Alternate Marking Option, to provide the > enhanced capabilities and allow advanced functionalities. > > > > We hope you like this idea. > > Any comments are welcome. > > > > Thanks, > > Tianran > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000c6dd0605cf241252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tianran,
    thank you for bringing up= this work. I've read the draft and have several comments, questions. P= lease kindly find those below:
    • Based on the comments during the IESG review of draft-ietf-6man-ipv6-alt-m= ark, I see a value in extending FlowMonID. That might reduce the probabilit= y of a collision.
    • What could be the use = case for the Flow direction identification flag? As the AltMark is applied = to the data traffic, wouldn't it always be in the forward direction?
    • I'm also not clear about the use of th= e Measurement mode flag. I thought that the mode, hbh or e2e, is determined= by the choice of appropriate IPv6 EH - Hop-by-Hop Option Header or Destina= tion Option Header, accordingly. Am I missing something here?
    • Reading the draft, it was not clear how the extended = header helps to lower marking intervals increasing the density of measureme= nts.
    Regards,
    Greg

    On Thu, Oct 21,= 2021 at 11:27 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

    Hi WG,

    =C2=A0

    There are many interests in this working group worki= ng on the alternate marking, RFC8321 and RFC8889.

    As you may have seen, we applied this method in IPv6= , and the draft is in IESG review.

    https://datatracker.ietf.org/doc/= draft-ietf-6man-ipv6-alt-mark/

    =C2=A0

    Based on the above draft, and the comments/suggestio= ns we received, we produced an Enhanced Alternate Marking Method.

    ht= tps://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<= /a>

    =C2=A0

    This document extends the IPv6 Alt= ernate Marking Option, =C2=A0to provide the enha= nced capabilities and allow advanced functionalities.<= /p>

    =C2=A0

    We hope you like this idea.=

    Any comments are welcome.

    =C2=A0

    Thanks,

    Tianran

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --000000000000c6dd0605cf241252-- From nobody Sun Oct 24 20:25:07 2021 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 E08713A0743 for ; Sun, 24 Oct 2021 20:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnxCT459hAe4 for ; Sun, 24 Oct 2021 20:25:02 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA73F3A0744 for ; Sun, 24 Oct 2021 20:25:01 -0700 (PDT) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hd0Zk4bDRz67YVQ; Mon, 25 Oct 2021 11:20:30 +0800 (CST) Received: from kwepeml500003.china.huawei.com (7.221.188.182) 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.2308.15; Mon, 25 Oct 2021 05:24:58 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 25 Oct 2021 11:24:56 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Mon, 25 Oct 2021 11:24:56 +0800 From: Tianran Zhou To: Greg Mirsky CC: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 Thread-Index: AdfHDWLNvY93aiAGSwChY0Q0ZX5bBQB9xlOAABFlCaA= Date: Mon, 25 Oct 2021 03:24:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_f4139407001d49e8b3891ccb9eed8debhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 25 Oct 2021 03:25:07 -0000 --_000_f4139407001d49e8b3891ccb9eed8debhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdCBhbmQgcmV2aWV3 IGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBpbiBsaW5lIHdpdGggbXkgdGhvdWdodHMuDQoNCkNoZWVy cywNClRpYW5yYW4NCg0KRnJvbTogR3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjUsIDIwMjEgMTA6MjUgQU0NClRvOiBUaWFu cmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+DQpDYzogSUVURiBJUFBNIFdHIChpcHBt QGlldGYub3JnKSA8aXBwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaXBwbV0gRW5oYW5jZWQg QWx0ZXJuYXRlIE1hcmtpbmcgZHJhZnQtemhvdS1pcHBtLWVuaGFuY2VkLWFsdGVybmF0ZS1tYXJr aW5nLTA3DQoNCkhpIFRpYW5yYW4sDQp0aGFuayB5b3UgZm9yIGJyaW5naW5nIHVwIHRoaXMgd29y ay4gSSd2ZSByZWFkIHRoZSBkcmFmdCBhbmQgaGF2ZSBzZXZlcmFsIGNvbW1lbnRzLCBxdWVzdGlv bnMuIFBsZWFzZSBraW5kbHkgZmluZCB0aG9zZSBiZWxvdzoNCsK3ICBCYXNlZCBvbiB0aGUgY29t bWVudHMgZHVyaW5nIHRoZSBJRVNHIHJldmlldyBvZiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQt bWFyaywgSSBzZWUgYSB2YWx1ZSBpbiBleHRlbmRpbmcgRmxvd01vbklELiBUaGF0IG1pZ2h0IHJl ZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSBjb2xsaXNpb24uDQpaVFI+IFRoYW5rcy4gSSBhcHBy ZWNpYXRlIHlvdSBhZ3JlZSB3aXRoIHRoZSB2YWx1ZSBvbiB0aGlzLg0KwrcgIFdoYXQgY291bGQg YmUgdGhlIHVzZSBjYXNlIGZvciB0aGUgRmxvdyBkaXJlY3Rpb24gaWRlbnRpZmljYXRpb24gZmxh Zz8gQXMgdGhlIEFsdE1hcmsgaXMgYXBwbGllZCB0byB0aGUgZGF0YSB0cmFmZmljLCB3b3VsZG4n dCBpdCBhbHdheXMgYmUgaW4gdGhlIGZvcndhcmQgZGlyZWN0aW9uPw0KWlRSPiBDb3BpZWQgZnJv bSBteSByZXBseSB0byBIYW95dSwgIEkgd2lsbCBhZGQgbW9yZSBkZXRhaWxzIGluIHRoZSBuZXh0 IHZlcnNpb24uIEluIGJyaWVmLCB0aGUg4oCcZmxvdyBkaXJlY3Rpb27igJ0gaXMgdXNlZCB0byBh ZGRyZXNzIHRoZSByZXF1aXJlbWVudCBvbiBzZXR1cCBiYWNrd2FyZCBkaXJlY3Rpb24gZmxvdyBt b25pdG9yaW5nIGF1dG9tYXRpY2FsbHkuIEFsdC1NSyBhcHBsaWVkIHRvIG9uZSBkaXJlY3Rpb24g b25seSBiZWZvcmUuIFRoaXMgZmxhZyBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSBuZWVkIHRvIHNl dCB1cC4NCsK3ICBJJ20gYWxzbyBub3QgY2xlYXIgYWJvdXQgdGhlIHVzZSBvZiB0aGUgTWVhc3Vy ZW1lbnQgbW9kZSBmbGFnLiBJIHRob3VnaHQgdGhhdCB0aGUgbW9kZSwgaGJoIG9yIGUyZSwgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgY2hvaWNlIG9mIGFwcHJvcHJpYXRlIElQdjYgRUggLSBIb3AtYnkt SG9wIE9wdGlvbiBIZWFkZXIgb3IgRGVzdGluYXRpb24gT3B0aW9uIEhlYWRlciwgYWNjb3JkaW5n bHkuIEFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NClpUUj4gWW91ciBwZXJzcGVjdGl2ZSBp cyBjb3JyZWN0LiBUaGlzIGlkZWEgaXMgYmFzZWQgb24gb3VyIHByYWN0aWNlIG9uIGV4aXN0aW5n IG5ldHdvcmsuIFRoZXJlIHdlcmUgZGlzY3Vzc2lvbnMgaW4gNk1BTiBvciBzbywgYWJvdXQgdGhl IEVIIHByb2Nlc3NpbmcgY2FwYWJpbGl0eS4NCsK3ICBSZWFkaW5nIHRoZSBkcmFmdCwgaXQgd2Fz IG5vdCBjbGVhciBob3cgdGhlIGV4dGVuZGVkIGhlYWRlciBoZWxwcyB0byBsb3dlciBtYXJraW5n IGludGVydmFscyBpbmNyZWFzaW5nIHRoZSBkZW5zaXR5IG9mIG1lYXN1cmVtZW50cy4NClpUUj4g SSB3aWxsIGFkZCBtb3JlIGluZm8gbGF0ZXIuIE91ciBpZGVhIGlzIHRvIGFkZCBhIHRpbWVzdGFt cCB0YWtlbiBmcm9tIHRoZSBoZWFkIG5vZGUsIGFzIHRoZSBtZXRhIGRhdGEuIEluIHRoaXMgd2F5 LCB0aGUgaW50ZXJtZWRpYXRlIG5vZGUgY2FuIGFsd2F5cyBjb21wYXJlIHdpdGggdGhpcyB0aW1l c3RhbXAgdG8gY2hlY2sgdGhlIGRlbGF5LiBTbyBub3QgZGVwZW5kIG9uIHRoZSBkZWxheSBiaXQu DQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUaHUsIE9jdCAyMSwgMjAyMSBhdCAxMToyNyBQTSBUaWFu cmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdl aS5jb20+PiB3cm90ZToNCkhpIFdHLA0KDQpUaGVyZSBhcmUgbWFueSBpbnRlcmVzdHMgaW4gdGhp cyB3b3JraW5nIGdyb3VwIHdvcmtpbmcgb24gdGhlIGFsdGVybmF0ZSBtYXJraW5nLCBSRkM4MzIx IGFuZCBSRkM4ODg5Lg0KQXMgeW91IG1heSBoYXZlIHNlZW4sIHdlIGFwcGxpZWQgdGhpcyBtZXRo b2QgaW4gSVB2NiwgYW5kIHRoZSBkcmFmdCBpcyBpbiBJRVNHIHJldmlldy4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1tYXJrLw0KDQpC YXNlZCBvbiB0aGUgYWJvdmUgZHJhZnQsIGFuZCB0aGUgY29tbWVudHMvc3VnZ2VzdGlvbnMgd2Ug cmVjZWl2ZWQsIHdlIHByb2R1Y2VkIGFuIEVuaGFuY2VkIEFsdGVybmF0ZSBNYXJraW5nIE1ldGhv ZC4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpob3UtaXBwbS1lbmhh bmNlZC1hbHRlcm5hdGUtbWFya2luZy8NCg0KVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBJUHY2 IEFsdGVybmF0ZSBNYXJraW5nIE9wdGlvbiwgIHRvIHByb3ZpZGUgdGhlIGVuaGFuY2VkIGNhcGFi aWxpdGllcyBhbmQgYWxsb3cgYWR2YW5jZWQgZnVuY3Rpb25hbGl0aWVzLg0KDQpXZSBob3BlIHlv dSBsaWtlIHRoaXMgaWRlYS4NCkFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KVGhhbmtzLA0K VGlhbnJhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmlwcG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo= --_000_f4139407001d49e8b3891ccb9eed8debhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg OTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5 MzYxMzEwMDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NDcwNzUyNDA7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIHZlcnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdCBhbmQgcmV2aWV3IGNvbW1lbnRzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGluIGxpbmUgd2l0aCBteSB0aG91Z2h0cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjUsIDIwMjEgMTA6 MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpYW5yYW4gWmhvdSAmbHQ7emhvdXRpYW5yYW5AaHVhd2Vp LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZykgJmx0 O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gRW5oYW5j ZWQgQWx0ZXJuYXRlIE1hcmtpbmcgZHJhZnQtemhvdS1pcHBtLWVuaGFuY2VkLWFsdGVybmF0ZS1t YXJraW5nLTA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IFRpYW5yYW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhh bmsgeW91IGZvciBicmluZ2luZyB1cCB0aGlzIHdvcmsuIEkndmUgcmVhZCB0aGUgZHJhZnQgYW5k IGhhdmUgc2V2ZXJhbCBjb21tZW50cywgcXVlc3Rpb25zLiBQbGVhc2Uga2luZGx5IGZpbmQgdGhv c2UgYmVsb3c6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkJhc2VkIG9uIHRoZSBjb21t ZW50cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1t YXJrLCBJIHNlZSBhIHZhbHVlIGluIGV4dGVuZGluZyBGbG93TW9uSUQuIFRoYXQgbWlnaHQgcmVk dWNlIHRoZSBwcm9iYWJpbGl0eSBvZiBhIGNvbGxpc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5aVFImZ3Q7IFRoYW5rcy4gSSBhcHBy ZWNpYXRlIHlvdSBhZ3JlZSB3aXRoIHRoZSB2YWx1ZSBvbiB0aGlzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny4yNXB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+V2hhdCBjb3VsZCBiZSB0aGUgdXNlIGNhc2UgZm9yIHRoZSBGbG93IGRpcmVjdGlvbiBp ZGVudGlmaWNhdGlvbiBmbGFnPyBBcyB0aGUgQWx0TWFyayBpcyBhcHBsaWVkIHRvIHRoZSBkYXRh IHRyYWZmaWMsIHdvdWxkbid0IGl0IGFsd2F5cyBiZSBpbiB0aGUgZm9yd2FyZCBkaXJlY3Rpb24/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ WlRSJmd0OyBDb3BpZWQgZnJvbSBteSByZXBseSB0byBIYW95dSwgJm5ic3A7SSB3aWxsIGFkZCBt b3JlIGRldGFpbHMgaW4gdGhlIG5leHQgdmVyc2lvbi4gSW4gYnJpZWYsIHRoZSDigJxmbG93IGRp cmVjdGlvbuKAnQ0KIGlzIHVzZWQgdG8gYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnQgb24gc2V0dXAg YmFja3dhcmQgZGlyZWN0aW9uIGZsb3cgbW9uaXRvcmluZyBhdXRvbWF0aWNhbGx5LiBBbHQtTUsg YXBwbGllZCB0byBvbmUgZGlyZWN0aW9uIG9ubHkgYmVmb3JlLiBUaGlzIGZsYWcgaXMgdXNlZCB0 byBpbmRpY2F0ZSB0aGUgbmVlZCB0byBzZXQgdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjQ3LjI1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JJ20g YWxzbyBub3QgY2xlYXIgYWJvdXQgdGhlIHVzZSBvZiB0aGUgTWVhc3VyZW1lbnQgbW9kZSBmbGFn LiBJIHRob3VnaHQgdGhhdCB0aGUgbW9kZSwgaGJoIG9yIGUyZSwgaXMgZGV0ZXJtaW5lZCBieSB0 aGUgY2hvaWNlIG9mIGFwcHJvcHJpYXRlIElQdjYgRUggLSBIb3AtYnktSG9wIE9wdGlvbiBIZWFk ZXIgb3IgRGVzdGluYXRpb24gT3B0aW9uIEhlYWRlciwgYWNjb3JkaW5nbHkuIEFtIEkNCiBtaXNz aW5nIHNvbWV0aGluZyBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlpUUiZndDsgWW91ciBwZXJzcGVjdGl2ZSBpcyBjb3JyZWN0LiBU aGlzIGlkZWEgaXMgYmFzZWQgb24gb3VyIHByYWN0aWNlIG9uIGV4aXN0aW5nIG5ldHdvcmsuIFRo ZXJlIHdlcmUgZGlzY3Vzc2lvbnMNCiBpbiA2TUFOIG9yIHNvLCBhYm91dCB0aGUgRUggcHJvY2Vz c2luZyBjYXBhYmlsaXR5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJlYWRpbmcgdGhlIGRyYWZ0 LCBpdCB3YXMgbm90IGNsZWFyIGhvdyB0aGUgZXh0ZW5kZWQgaGVhZGVyIGhlbHBzIHRvIGxvd2Vy IG1hcmtpbmcgaW50ZXJ2YWxzIGluY3JlYXNpbmcgdGhlIGRlbnNpdHkgb2YgbWVhc3VyZW1lbnRz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlpUUiZndDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2lsbCBhZGQgbW9yZSBpbmZvIGxh dGVyLiBPdXIgaWRlYSBpcyB0byBhZGQgYSB0aW1lc3RhbXAgdGFrZW4gZnJvbSB0aGUgaGVhZCBu b2RlLCBhcyB0aGUgbWV0YSBkYXRhLiBJbiB0aGlzIHdheSwgdGhlIGludGVybWVkaWF0ZSBub2Rl IGNhbiBhbHdheXMgY29tcGFyZSB3aXRoIHRoaXMgdGltZXN0YW1wIHRvIGNoZWNrIHRoZSBkZWxh eS4NCiBTbyBub3QgZGVwZW5kIG9uIHRoZSBkZWxheSBiaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIE9jdCAyMSwgMjAyMSBhdCAxMToyNyBQTSBUaWFucmFuIFpob3UgJmx0OzxhIGhyZWY9Im1h aWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgV0csPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGVyZSBhcmUgbWFueSBpbnRlcmVzdHMgaW4gdGhpcyB3b3JraW5nIGdyb3VwIHdvcmtp bmcgb24gdGhlIGFsdGVybmF0ZSBtYXJraW5nLCBSRkM4MzIxIGFuZCBSRkM4ODg5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyB5b3UgbWF5IGhhdmUgc2Vlbiwgd2Ug YXBwbGllZCB0aGlzIG1ldGhvZCBpbiBJUHY2LCBhbmQgdGhlIGRyYWZ0IGlzIGluIElFU0cgcmV2 aWV3LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFy ay8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyay88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5CYXNlZCBvbiB0aGUgYWJvdmUgZHJhZnQsIGFuZCB0aGUgY29tbWVudHMvc3VnZ2VzdGlvbnMg d2UgcmVjZWl2ZWQsIHdlIHByb2R1Y2VkIGFuDQo8c3BhbiBsYW5nPSJFTiI+RW5oYW5jZWQgQWx0 ZXJuYXRlIE1hcmtpbmcgTWV0aG9kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXpob3UtaXBwbS1lbmhhbmNlZC1hbHRlcm5hdGUtbWFya2luZy8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16 aG91LWlwcG0tZW5oYW5jZWQtYWx0ZXJuYXRlLW1hcmtpbmcvPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4i PlRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgSVB2NiBBbHRlcm5hdGUgTWFya2luZyBPcHRpb24s ICZuYnNwO3RvIHByb3ZpZGUgdGhlIGVuaGFuY2VkIGNhcGFiaWxpdGllcyBhbmQgYWxsb3cgYWR2 YW5jZWQgZnVuY3Rpb25hbGl0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPldlIGhvcGUgeW91IGxpa2Ug dGhpcyBpZGVhLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4iPkFueSBjb21tZW50cyBhcmUgd2VsY29tZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTiI+VGlhbnJhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_f4139407001d49e8b3891ccb9eed8debhuaweicom_-- From nobody Sun Oct 24 22:29:59 2021 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 1D00A3A08EB for ; Sun, 24 Oct 2021 22:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwnoe9ZTkG0j for ; Sun, 24 Oct 2021 22:29:51 -0700 (PDT) Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (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 E2F593A08D9 for ; Sun, 24 Oct 2021 22:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1635139791; x=1666675791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gw2gMD58eWA8szZGCLW5qvsHbzlyh70pK/KHfhqEJlY=; b=fRXC7ASGoh0jlh/IlRYhWw7kLTm+mtiVwo53ctgWtVrG8z0S7ksrlC6Q nz145yl3v0bNChwHh9FiOIBHLaYqg3o09euN2beuCnA5i9/vR55dY+0c9 vI76wkuuYGUDzAoyNl4KSpZZsmSYJScdEd6dDlAIpJUVIQsp2vfV/7jmA 4Go+yQhQSxdrqbNyVKEEM1y1F39cuvS/8k87UxPk4ywuE5hdZoSYI9mOg Mqx87Lki4xB97TNu9iqViKAs7V88svLmCGcx80sPGrMvHlvhjwrKzIlh7 kRz+pNc9T7F5CEk9sYYItnajo5L0WbdNpY1xjXv5RaPKr9Q+dMtu+j/53 Q==; IronPort-Data: =?us-ascii?q?A9a23=3AfJkmVKxxqWUJ4wMNbih6t+cTxCrEfRIJ4+MujC/?= =?us-ascii?q?XYbTApDx23jAEmDQZXG+AOPiKYmD9eIggaYq/8EtQvZaDyIMyHQtv/xmBbZ7qR?= =?us-ascii?q?ekppDihw/iZ0xq6dqUvd2o6qZVBAjX8BJpsFCaF/k3xauKJQURUjslkeJKtUYY?= =?us-ascii?q?oBQghHWeIeA954f5Ss7ZRbrxA2LBVMCvR0T/GmPAzDXf+s9JC3sL43IrYwP9nl?= =?us-ascii?q?KyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs764JzozlKf8xprFpa?= =?us-ascii?q?klKr2aEsDRvjZOg3mZnh+AvDk20cb4HZvjuBgbpLwam8O49mNt+psxdlMupGqD?= =?us-ascii?q?ygkP6fkhOkZXhpfFmdyMMWq/ZeecSLg7ZXOlR2un3zEhq8G4FsNFYQT/+FtHWZ?= =?us-ascii?q?I3fUENHYGaRXrug4c6NpXUcF1islyPNitMI5ZpjRhyy3UF/AvRdbIRKCi2DOR5?= =?us-ascii?q?x9o7ugmIBoUT5BxheJTUSn9?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AdsPX761wV0N+5uek4g0rCAqjBRRyeYIsimQD?= =?us-ascii?q?101hICG9Lfbo9fxGzc5rtiMc1gxwZJh5o6HwBEGBKUmsjKKdkrNhTYtKOzOW+1?= =?us-ascii?q?dATbsSrbcKrAeQZhEWmtQtspuINpIOduEYAGIQsS+Y2nj7Lz9D+qj6zEnAv463?= =?us-ascii?q?oxgCLHAOGsVdBkVCe3mm+yVNNVV77PECZeKhD7981kCdkAMsH7+G7xc+Lo7+Tt?= =?us-ascii?q?vw/q4OgyRqOzcXrC21yR+44r/zFBaVmj0EVSlU/Lsk+W/Z1yTk+6SKqZiAu1rh?= =?us-ascii?q?/l6Wy64TtMrqy9NFCsDJoNMSMC/QhgGhY5kkc6GevQoyvPqk5D8R4Z3xSlYbTo?= =?us-ascii?q?NOAkHqDziISCjWqlHdOfEVmiTfIGqj8D3eSArCNWgH4oR69N9km1DimjkdVZlH?= =?us-ascii?q?odB2NiSixsVq5Fr77VHAzsmNWBdwmkWup30+1eYVknxESIMbLKRctIoF4SpuYd?= =?us-ascii?q?g99Q/Bmc0a+dNVfY3hDTdtABqnRmGcunMqzM2nX3w1EBvDSk8eutaN2zwTmHxi?= =?us-ascii?q?1UMXyMEWg39FrfsGOth5zvWBNr4tmKBFT8cQY644DOAdQdGvAmiIRR7XKmqdLV?= =?us-ascii?q?nuCalCMXPQrJz85qkz+YiRCdI15Yp3nI6EXEJTtGY0dU6rAcqS3IdT+hSIW2m5?= =?us-ascii?q?VSSF8LAV23G4gMy2eFPGC1z1dLkeqbrpnxxEOLyuZx+aAuMhP8Pe?= Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES128-SHA256; 25 Oct 2021 07:29:47 +0200 IronPort-SDR: FkYHaCdmQl25K2T+VrqT+DYF8cK2d4qQBINF3ZM78GrprEp8rphtG5iGkY1gWTWrYmZQWo6BjF tBGO8OG6NinSL+A6h0wFwToH1d5OTVKqw= X-IronPort-AV: E=Sophos;i="5.87,179,1631570400"; d="scan'208";a="398235478" X-MGA-submission: =?us-ascii?q?MDED0p9aDvhpTSYeLtD68prKDN5DZLkX5QppqP?= =?us-ascii?q?lGdSTIfXQbjRzwvYKRMRI3SqfOkhANBBrknAPrkOcHNeypGzpEqh6NBP?= =?us-ascii?q?LMBCFeh0E9+dkT+dblzJyV4c+uPzsm4+1zfOZ7tG85kmWAg0DXDEyBmD?= =?us-ascii?q?+YCsGRYptr0qxWi47pLpxGSA=3D=3D?= Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 25 Oct 2021 07:29:48 +0200 Received: from HE199745.EMEA1.cds.t-internal.com (10.169.119.53) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 25 Oct 2021 07:29:47 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199745.EMEA1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.23 via Frontend Transport; Mon, 25 Oct 2021 07:29:46 +0200 Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.169) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 25 Oct 2021 07:29:46 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mxDGTQPftkNjtneKu9E9wcMh7i1yPGVDxhS+jsFF+30aWpYpkUSq2dKi701Tog6B6MYEFRchPTJXplzc+C5nQHXFfK1oYr1MCsPgZGE5cv4o/db85gnhMe9p7JIbLuY3JNdSEhruC9/WkG50EYbHrku6WjXIR2e67xA2bzdBIyhmymU7BYPHp+Wo1Z3Ekw1YjT59hn1n6QvYMBbvlZb4icr7dCAUBTc8nCSqPdRu0c8A6Ty1KvgC26Ney1qUxiUy6CHxL3H31PvtJVsgE8BRD9nI0JUpl993rTfA+IqmBzA0kvc/V6sfx9mrrUDWDIGWwBhYtZqo6SO2EDGRWAuWig== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Gw2gMD58eWA8szZGCLW5qvsHbzlyh70pK/KHfhqEJlY=; b=eahdspTQt5Jrp6eVtYf2Bqt3EKuORdQTenlwbcWoPnUXf5hUJwGzDovqUQil/dQ2bddOwXD3dAxQOU9nKyuTFHHtEvkOSV8CDMMNIuFkP79Dmd4sI4jwwVBTnbLLH2I4HYe9XQJs0YroO/XfXKJipgba02G7KOAdFGy4swLtm7+PufGCu8Q4n2q6JwOobeUqfIfasFL3FfVYubjNXWE1f2sEWikwRYeIrjWMNAEkWnuV7JaZ7YCM/XEPQGSHosTMHmbZul/tPiyA4tLGoW4doqlNl17+ou/Up4VPYdZmFHPWjCNiv33Zh9992n5/3MuWJNgi3jbHYTLdO44JsZWvAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2c::12) by FR2P281MB0547.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:3e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.11; Mon, 25 Oct 2021 05:29:46 +0000 Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b875:2268:60fe:d12a]) by FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::b875:2268:60fe:d12a%9]) with mapi id 15.20.4649.013; Mon, 25 Oct 2021 05:29:46 +0000 From: To: CC: Thread-Topic: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 Thread-Index: AdfFK9goV64vTz3BSZKe4qsMDY7MVgBLmSNgAFBjHwAAcUzEAA== Date: Mon, 25 Oct 2021 05:29:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=telekom.de; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3759bb82-c963-47fd-7615-08d9977874d3 x-ms-traffictypediagnostic: FR2P281MB0547: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PRLX1759V/5zyU7+8AY9XnTUddPDxLAyhGYNJOrPZa5RUb6OF77pn8H5SnHY9R6aqV74T/Pksi5g5XSHJHndXgZHlHV9Y4aQpPamTTQWTJ33/jHcym5AjMh2sCfRuB8AEOfqjB2WgvTpGYur6SPCBnESifcLyiCV5X4SVMj/xe4RziyMKlw2141fBchSAN9h1lOT/CoqVJNSf2zCfW5NWbeiprD4rG7QFz8Tq/JGW+4w3k1EWAbJdTJgErMKNNUvtz/ZCvrHvgCkoKWzyebKWIolJ+aiXMHkXHKshfKIgfE1Ekku3RbN0NS5viBIsral6EPPUN3qT+5vb4OeclZJYTmpK8nH/V8NfvuFphZVg7LV+rXon//an+GAt++O+asnTWNjgraasZL27bMHYGP1j2fIIrVorw3j73+VQFk0yeOUPd9BfpPyhQAPcwnSG0HAABNBpkgE2dvz+c2jGtCJSQbnVVhW3GGyOiR1uDEvWBcP6sQv2oDVHkWiRrNQJJL2nFoXVYFe/XDdB2egfeizltiTWbr8DojJF31tnIAXC7wciBOZuJ6KSjfg2eIMM4M6QreFR5yBP+Wf/tXpksjcPq7CVrPWOgRTzeyyF+aZcz0XiWyayk3EMt5ZRuFk7Xrmhcyo+CBmVhTOvO7RDVkUMZ75ZKFZlZcMAAavsgZuQ6+YtTZDZUeG1HdysMWoeqSEA/EaWPiuF98NpAg8KkPme9elvbIKHkYvI8mB0o0nn8Trao6BNQ33cx/+ihifPnDRFaBO6RB2l8geX3ZCe4T0AsiVuQaljbRs9QVduIh3QLA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(71200400001)(4326008)(52536014)(83380400001)(508600001)(66574015)(64756008)(82960400001)(26005)(76116006)(66946007)(7696005)(6506007)(33656002)(66556008)(66446008)(53546011)(186003)(38070700005)(66476007)(55016002)(86362001)(38100700002)(316002)(8676002)(2906002)(5660300002)(122000001)(6916009)(8936002)(9686003)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?hsYyHFzxlQ3N2L05xdVtMDa5YNOSlPeHLT1ltl74wErFoY7r9G2R9ROhIa?= =?iso-8859-1?Q?4zOhiFmyq02JkO2wrGvLVV9uTX63e2aGebmQxb6SATQhKC2K6k3Iq8avTg?= =?iso-8859-1?Q?9MkcGr0FuA0M0yXdmlt6TUVIB4iafaIoSvlEpMFHs7kANtlzCLG5O3eHBs?= =?iso-8859-1?Q?q0Ywre/pAfQTJUsGE2t5HBGzf29DFf3xqtaPm2J08EI5WrlHoogNeWXjIH?= =?iso-8859-1?Q?C0jLZkvEHVl9Uv1HeK8MZSSNfdd5Q/vkQ18LRK2qY8cq/c/Gn7qXnCLA47?= =?iso-8859-1?Q?nzV74UhHhMAcf2XfqbVA6UE9HZ0WKHqkEelKnTwRBz5Xx9QiYooPcsVpo1?= =?iso-8859-1?Q?jyVxohOINt6GX88e3VpX1/seXqq9N9tkcqM9uptSKXXRELpcq82Yx4ntMX?= =?iso-8859-1?Q?mJuxsqT4HEP70LVRXvoXtZKk3HrEx/hJdS0qeZ1yaJ68Jdz1iVjFDTU6Np?= =?iso-8859-1?Q?anPgycrpZkRsT9ATCZY8cbwH0VAfwkIZUJqISOO7G3Dz/MhhptFCgIy19P?= =?iso-8859-1?Q?ym3K7Q5Ix0jSJyEEjw0y82hTUgH3GvTXLmUy7X9o7zNLFkZrSb6VX30ubJ?= =?iso-8859-1?Q?tAyez54rgQgNAHJOqSwpc1pxOG9njGxgrCyt8h5xhKn7pfVNFzrD5+h9g2?= =?iso-8859-1?Q?wAL2N3fnXGPQ5trDVQ9nwNYpiFCjyJlCRnlZfZcYSgzFIAUrkNEXX7EhWe?= =?iso-8859-1?Q?Q3c9UjitUiBkfIsyQOIDoQ7sTLdCOFL8x8elKHU4h+HfgY9AHsPT40y1Tg?= =?iso-8859-1?Q?aKVRNF4s5/hesZ77eXM1A8EiJSL7ZV1NY8DjUhXu8YoI08wQ5HxK88t4le?= =?iso-8859-1?Q?9DkZhMN/JAdbWMgdd34OgWC3asqKYkADhY+9lMS5M6A9//QG6tK4J3plJ2?= =?iso-8859-1?Q?yq7GiZEnshQRFPnumBaCTVd7DRU6CLfHjYKBQlvQVpl1CciVTuVDu6b2FZ?= =?iso-8859-1?Q?0zT0C2XSP7Pj9/n6CaLo8PPH2mAlEdsmU3R+1z3+BH/tl+0tpDhyRROZgL?= =?iso-8859-1?Q?Qe37xD6O2SLJxLUlEZKKSV3O9cNxAVs6d3jhaIZPUYO6C/L74Jd9Fyfph9?= =?iso-8859-1?Q?ras7QLORl8wU4Agmq/DnESlL1+nocowUQK6agjO5QzItGVHrW/ZaG9MRj0?= =?iso-8859-1?Q?TQa9uBmqAgZ0BkNmSWD2DU3EDjWJI0XEoQXlHOwgKixZYFqfKP9NHFWV7g?= =?iso-8859-1?Q?Y4daAarKAOa1L+qmyU69ZG9VxAIHV0yqJPKgUerVTHAHHrrZpyfYaIXcfb?= =?iso-8859-1?Q?EqDAHzXU1DlOPs4qVrKMpLbkUy3Shg6eBlnKnFVaPpnEp9jEQWFDz4tgNh?= =?iso-8859-1?Q?qmCTrZUJ5L+EPzTTPZbQg3w1Hi3On7mNHWo4beg68eLe1lQMjXeC0kwZUY?= =?iso-8859-1?Q?hLjR3SoEgHq2j/0Mhr5jX3kfkBP1y5VkWaIgZJUuVydomCWUBujhkcJfiG?= =?iso-8859-1?Q?8/+b1HgrVN4NKGEcHO6zSgBd7zTQWxKIpUdIxXkVN8P5ohbUMYTANKCJbc?= =?iso-8859-1?Q?2F1mxKO96xC5k8Q/IxETXBq02Z3NFU1SjlnBjmJDG0ro2/Rxx+58gIeEh5?= =?iso-8859-1?Q?0KdwdPQoJZRO037Yftsp0fOUj6SEsPIhhT5sZJ9qLuzv0X7nDH2y1NX7nx?= =?iso-8859-1?Q?C3mGNKK8jnUsjPpfI4UK0rMT8we7Tbc23kGK9sHRfdzBAFemOgiO4dQlnR?= =?iso-8859-1?Q?kUACChtj73J3VQ61OOo6k4kOxjZSS966d9fvLdZaTXqPYebJTWeYURbgjl?= =?iso-8859-1?Q?f6Yg=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3759bb82-c963-47fd-7615-08d9977874d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 05:29:46.0883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5aY9EANykxqOFwjIiaHkst1NMIWU1rvXz7RWP2zHdQtAwEU13f5ykgIaId47R3980tSazYXuhINPucFHpzs/oXLzxe0sHIRqgrS/wMdEgzM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0547 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 25 Oct 2021 05:29:57 -0000 Hi Al, thanks, the arguments you've added make sense to me and I think the text is= helpful for readers not accustomed with *WAMP protocols. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: MORTON JR., AL =20 Gesendet: Samstag, 23. Oktober 2021 01:23 An: Geib, R=FCdiger Cc: ippm@ietf.org Betreff: RE: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol= -01 Hi R=FCdiger,=20 Many thanks for your review and comments! Please see replies below, [acm] Al > -----Original Message----- > From: Ruediger.Geib@telekom.de > Sent: Thursday, October 21, 2021 5:54 AM > To: MORTON JR., AL > Cc: ippm@ietf.org > Subject: AW: [ippm] Questions on=20 > draft-morton-ippm-capacity-metric-protocol-01 >=20 > Hi Al, >=20 > A standardized protocol to request a standardized access bandwidth=20 > measurement is a generic requirement and I appreciate your initiative.=20 > As a person not personally implementing software, some high level comment= s on the doc only: >=20 > 2. Scope, Goals, and Applicability, last sentence: >=20 > "The primary application of the protocol described here is the same as > in Section 2 of [RFC7479] where:" >=20 > That's a mis-quote, isn't it? You target another RFC, don't you? [acm] Yes, that's a typo it is 7497. > From numbers I guessed: > https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section-2__;Iw!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$ [acm] right! >=20 > I started with a minor issue, as it points to RFC7497. The latter RFC=20 > contains the following statement: > https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section-7__;Iw!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$ > "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do=20 > not possess the asymmetric size generation capability with two-way testin= g." [acm] Right, we have a different problem with TWAMP and others, described below. >=20 > Adding a brief section to draft-morton-ippm-capacity-metric-protocol > discussing why e.g. TWAMP (or a simplified version) isn't applied or=20 > rather enhanced for the measurement protocol may be useful. If=20 > existing IETF IPPM measurement control protocols don't offer any=20 > benefits justifying their adaption for a capacity-metric-protocol, the=20 > section will be brief. If there's pro and con, what's worth adding functi= onality to TWAMP and what's the "cost" > (in terms of work and changes) may be worth some words. Should=20 > inclusion of a capacity-metric-protocol to TWAMP be worth a thought, a=20 > few words on required features and changes (a sketch on what to add)=20 > may be useful. I'm not a TWAMP expert, I excuse if my comment doesn't app= ly. [acm] No problem, I thought about this before writing this draft. It comes down t= o these four points (which I will add in the Intro): Although there are several test protocol already available for support and manage active measurements, this protocol is a major departure from their operation: 1. UDP transport is used for all setup, test activation, and control messages, and for results feedback (not TCP), simplifying operations. 2. TWAMP and STAMP use the philosophy that one host is a Session- Reflector, sending test packets every time they receive a test packet. This protocol supports a one-way test with periodic status messages returned to the sender. 3. OWAMP supports one-way testing with results Fetch at the end of the test session. This protocol supports a one-way test and require= s periodic status messages returned to the sender to support the load adjustment search algorithm. 4. The security features of OWAMP and TWAMP have been described as "unusual", to the point that IESG approved their use while also asking that these methods not be used again. Further, the *WAMP approach to security is over 15 years old at this time. I concluded that any attempt to enhance OWAMP or others would be time waste= d. We have a unique use-case here. thanks, Al >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=FCngliche Nachricht----- > Von: ippm Im Auftrag von MORTON JR., AL > Gesendet: Mittwoch, 20. Oktober 2021 00:32 > An: IETF IPPM WG > Betreff: [ippm] Questions on=20 > draft-morton-ippm-capacity-metric-protocol-01 >=20 > Hi IPPM, >=20 > Len Ciavattone and I am looking for some feedback on our protocol [0]=20 > designed to help measure the Maximum IP-Layer Capacity Metric (which=20 > will be published as an RFC shortly). >=20 > We are asking folks to take a look at the draft, because we are fairly=20 > sure you will have some questions! >=20 > One area where we know more development is required is the Modes of=20 > operation, which essentially describes how the different=20 > aspects/exchanges of the protocol will be made secure. This is=20 > pretty-much a green-field in our specification, so suggestions are=20 > very welcome. Section 10 currently describes the different modes that=20 > we imagined to be useful (A through F below), but practical aspects of=20 > any proposed solution might indicate modes that should be combined, split= -up, or new modes. >=20 > So, please give the draft and/or the list below a look, and let us=20 > know what you think. >=20 > thanks! > Al >=20 >=20 > [0]=20 > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > t- > morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i- > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$ >=20 > 3. Client-server authentication and integrity protection for > feedback messages conveying measurements is RECOMMENDED. To > accomodate different host limitations and testing circumstances, > different modes of operation are recommended: >=20 > A. Un-authenticated mode (for all phases) AND B. OPTIONAL=20 > Authenticated set- up only > SHA-256 HMAC time-window verification (5 min time stamp verification)=20 > (could add silent failure option) >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > C. Encrypted setup and test-activation (currently using OpenSSL=20 > Library, so KISS, but may be too slow for test > packets) >=20 > -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D-= =3D-=3D-=3D-=3D-=3D- >=20 > D. Encrypted feedback messages >=20 > E. Integrity protection for test packets SHA-256 HMAC >=20 > F. Encrypted test packets (maybe also valuable to defeat compression=20 > on > links) >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm > __;!!Bhd=20 > T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$ From nobody Sun Oct 24 23:11:17 2021 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 B88263A087C for ; Sun, 24 Oct 2021 23:11:15 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqw0WONPSq2r for ; Sun, 24 Oct 2021 23:11:13 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389F03A0874 for ; Sun, 24 Oct 2021 23:11:12 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 5864B338C7B537CC36A3 for ; Mon, 25 Oct 2021 14:11:08 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 19P6B1Af006850 for ; Mon, 25 Oct 2021 14:11:01 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Mon, 25 Oct 2021 14:11:00 +0800 (CST) Date: Mon, 25 Oct 2021 14:11:00 +0800 (CST) X-Zmail-TransId: 2afc61764a74e85fcc21 X-Mailer: Zmail v1.0 Message-ID: <202110251411008667788@zte.com.cn> Mime-Version: 1.0 From: To: Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 19P6B1Af006850 Archived-At: Subject: [ippm] =?utf-8?q?Updates_on=C2=A0draft-ietf-ippm-ioam-conf-state?= 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, 25 Oct 2021 06:11:16 -0000 Hi IPPM Folks, I've submitted -01 version of IOAM Capabilities Discovery (https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-01). In this new version, except for some editorial changes and clarification changes, the main updates are as the following: 1. Change the format of IOAM Capabilities Query/Response from TLV to Container. 2. Change the format of IOAM Capabilities Response contents from Sub-TLV to Object. The two main updates are to make this draft more general and applicable to ICMPv6 extensions. As to specific ICMPv6 extensions, a -00 version individual draft has already been submitted in 6MAN WG (https://datatracker.ietf.org/doc/html/draft-xiao-6man-icmpv6-ioam-conf-state-00). Much appreciate your further review and comments. Best Regards, Xiao Min From nobody Sun Oct 24 23:51:42 2021 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 7C5173A08BD for ; Sun, 24 Oct 2021 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjRL3d-0a5Y5 for ; Sun, 24 Oct 2021 23:51:35 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17833A0827 for ; Sun, 24 Oct 2021 23:51:34 -0700 (PDT) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hd5916cmZz67blg; Mon, 25 Oct 2021 14:47:01 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 25 Oct 2021 08:51:29 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 25 Oct 2021 14:51:28 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Mon, 25 Oct 2021 14:51:28 +0800 From: Tianran Zhou To: Greg Mirsky CC: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 Thread-Index: AdfHDWLNvY93aiAGSwChY0Q0ZX5bBQB9xlOAABFlCaAAB6FX4A== Date: Mon, 25 Oct 2021 06:51:28 +0000 Message-ID: References: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_e7c80c9c68994f97a3c6d30a4a0a2730huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07 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, 25 Oct 2021 06:51:40 -0000 --_000_e7c80c9c68994f97a3c6d30a4a0a2730huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KSSBhbSBzb3JyeS4gSSB3YXMgaW50ZXJydXB0ZWQsIGFuZCBzZW50IG91dCBh biBpbmNvbXBsZXRlIGVtYWlsLg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KVGlhbnJhbg0KDQpGcm9t OiBUaWFucmFuIFpob3UNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAyMSAxMToyNSBBTQ0K VG86ICdHcmVnIE1pcnNreScgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCkNjOiBJRVRGIElQUE0g V0cgKGlwcG1AaWV0Zi5vcmcpIDxpcHBtQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtpcHBtXSBF bmhhbmNlZCBBbHRlcm5hdGUgTWFya2luZyBkcmFmdC16aG91LWlwcG0tZW5oYW5jZWQtYWx0ZXJu YXRlLW1hcmtpbmctMDcNCg0KSGkgR3JlZywNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBp bnRlcmVzdCBhbmQgcmV2aWV3IGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBpbiBsaW5lIHdpdGggbXkg dGhvdWdodHMuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KRnJvbTogR3JlZyBNaXJza3kgW21haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjUsIDIwMjEg MTA6MjUgQU0NClRvOiBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRv Onpob3V0aWFucmFuQGh1YXdlaS5jb20+Pg0KQ2M6IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9y ZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4pIDxpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbaXBwbV0gRW5oYW5jZWQgQWx0ZXJuYXRlIE1hcmtpbmcgZHJh ZnQtemhvdS1pcHBtLWVuaGFuY2VkLWFsdGVybmF0ZS1tYXJraW5nLTA3DQoNCkhpIFRpYW5yYW4s DQp0aGFuayB5b3UgZm9yIGJyaW5naW5nIHVwIHRoaXMgd29yay4gSSd2ZSByZWFkIHRoZSBkcmFm dCBhbmQgaGF2ZSBzZXZlcmFsIGNvbW1lbnRzLCBxdWVzdGlvbnMuIFBsZWFzZSBraW5kbHkgZmlu ZCB0aG9zZSBiZWxvdzoNCsK3ICBCYXNlZCBvbiB0aGUgY29tbWVudHMgZHVyaW5nIHRoZSBJRVNH IHJldmlldyBvZiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyaywgSSBzZWUgYSB2YWx1ZSBp biBleHRlbmRpbmcgRmxvd01vbklELiBUaGF0IG1pZ2h0IHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkg b2YgYSBjb2xsaXNpb24uDQpaVFI+IFRoYW5rcy4gSSBhcHByZWNpYXRlIHlvdSBhZ3JlZSB3aXRo IHRoZSB2YWx1ZSBvbiB0aGlzLg0KwrcgIFdoYXQgY291bGQgYmUgdGhlIHVzZSBjYXNlIGZvciB0 aGUgRmxvdyBkaXJlY3Rpb24gaWRlbnRpZmljYXRpb24gZmxhZz8gQXMgdGhlIEFsdE1hcmsgaXMg YXBwbGllZCB0byB0aGUgZGF0YSB0cmFmZmljLCB3b3VsZG4ndCBpdCBhbHdheXMgYmUgaW4gdGhl IGZvcndhcmQgZGlyZWN0aW9uPw0KWlRSPiBDb3BpZWQgZnJvbSBteSByZXBseSB0byBIYW95dSwg IEkgd2lsbCBhZGQgbW9yZSBkZXRhaWxzIGluIHRoZSBuZXh0IHZlcnNpb24uIEluIGJyaWVmLCB0 aGUg4oCcZmxvdyBkaXJlY3Rpb27igJ0gaXMgdXNlZCB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVu dCBvbiBzZXR1cCBiYWNrd2FyZCBkaXJlY3Rpb24gZmxvdyBtb25pdG9yaW5nIGF1dG9tYXRpY2Fs bHkuIEFsdC1NSyBhcHBsaWVkIHRvIG9uZSBkaXJlY3Rpb24gb25seSBiZWZvcmUuIFRoaXMgZmxh ZyBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSBuZWVkIHRvIHNldCB1cC4NCsK3ICBJJ20gYWxzbyBu b3QgY2xlYXIgYWJvdXQgdGhlIHVzZSBvZiB0aGUgTWVhc3VyZW1lbnQgbW9kZSBmbGFnLiBJIHRo b3VnaHQgdGhhdCB0aGUgbW9kZSwgaGJoIG9yIGUyZSwgaXMgZGV0ZXJtaW5lZCBieSB0aGUgY2hv aWNlIG9mIGFwcHJvcHJpYXRlIElQdjYgRUggLSBIb3AtYnktSG9wIE9wdGlvbiBIZWFkZXIgb3Ig RGVzdGluYXRpb24gT3B0aW9uIEhlYWRlciwgYWNjb3JkaW5nbHkuIEFtIEkgbWlzc2luZyBzb21l dGhpbmcgaGVyZT8NClpUUj4gWW91ciBwZXJzcGVjdGl2ZSBpcyBjb3JyZWN0LiBUaGlzIGlkZWEg aXMgYmFzZWQgb24gb3VyIHByYWN0aWNlIG9uIGV4aXN0aW5nIG5ldHdvcmsuIFRoZXJlIHdlcmUg ZGlzY3Vzc2lvbnMgaW4gNk1BTiBvciBzbywgYWJvdXQgdGhlIEVIIHByb2Nlc3NpbmcgY2FwYWJp bGl0eS4gVGhlIHN0YW5kYXJkIGFwcHJvYWNoIGFzIHlvdSBtZW50aW9uZWQgYWJvdmUgcmVxdWly ZXMgaW1wbGVtZW50YXRpb24gYW5kIHN1cHBvcnQgb24gc2V2ZXJhbCBFSHMsIHdoaWNoIGNvdWxk IGJlIGNvbXBsZXguIFdlIGNvbnNpZGVyIGluIHNvbWUgY2FzZXMsIGltcGxlbWVudGF0aW9uIG9m IG9uZSBFSCBpcyBhcHBsaWVkLiBGb3IgZXhhbXBsZSwgaWYgd2Ugb25seSBpbXBsZW1lbnQgSGJI LCB0aGVuIGludGVybWVkaWF0ZSBub2RlcyBjb3VsZCB1c2UgdGhlIG1lYXN1cmVtZW50IG1vZGUg ZmxhZyBpbiB0aGUgZXh0ZW5zaW9uIHBhcnQgdG8gZGVjaWRlIHdoZXRoZXIgdG8gZG8gZnVydGhl ciBhY3Rpb25zLg0KwrcgIFJlYWRpbmcgdGhlIGRyYWZ0LCBpdCB3YXMgbm90IGNsZWFyIGhvdyB0 aGUgZXh0ZW5kZWQgaGVhZGVyIGhlbHBzIHRvIGxvd2VyIG1hcmtpbmcgaW50ZXJ2YWxzIGluY3Jl YXNpbmcgdGhlIGRlbnNpdHkgb2YgbWVhc3VyZW1lbnRzLg0KWlRSPiBJIHdpbGwgYWRkIG1vcmUg aW5mbyBsYXRlci4gT3VyIGlkZWEgaXMgdG8gYWRkIGEgdGltZXN0YW1wIHRha2VuIGZyb20gdGhl IGhlYWQgbm9kZSwgYXMgdGhlIG1ldGEgZGF0YS4gSW4gdGhpcyB3YXksIHRoZSBpbnRlcm1lZGlh dGUgbm9kZSBjYW4gYWx3YXlzIGNvbXBhcmUgd2l0aCB0aGlzIHRpbWVzdGFtcCB0byBjaGVjayB0 aGUgZGVsYXkuIFNvIG5vdCBkZXBlbmQgb24gdGhlIGRlbGF5IGJpdC4NClJlZ2FyZHMsDQpHcmVn DQoNCk9uIFRodSwgT2N0IDIxLCAyMDIxIGF0IDExOjI3IFBNIFRpYW5yYW4gWmhvdSA8emhvdXRp YW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0K SGkgV0csDQoNClRoZXJlIGFyZSBtYW55IGludGVyZXN0cyBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAg d29ya2luZyBvbiB0aGUgYWx0ZXJuYXRlIG1hcmtpbmcsIFJGQzgzMjEgYW5kIFJGQzg4ODkuDQpB cyB5b3UgbWF5IGhhdmUgc2Vlbiwgd2UgYXBwbGllZCB0aGlzIG1ldGhvZCBpbiBJUHY2LCBhbmQg dGhlIGRyYWZ0IGlzIGluIElFU0cgcmV2aWV3Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0LW1hcmsvDQoNCkJhc2VkIG9uIHRoZSBhYm92 ZSBkcmFmdCwgYW5kIHRoZSBjb21tZW50cy9zdWdnZXN0aW9ucyB3ZSByZWNlaXZlZCwgd2UgcHJv ZHVjZWQgYW4gRW5oYW5jZWQgQWx0ZXJuYXRlIE1hcmtpbmcgTWV0aG9kLg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pcHBtLWVuaGFuY2VkLWFsdGVybmF0ZS1t YXJraW5nLw0KDQpUaGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIElQdjYgQWx0ZXJuYXRlIE1hcmtp bmcgT3B0aW9uLCAgdG8gcHJvdmlkZSB0aGUgZW5oYW5jZWQgY2FwYWJpbGl0aWVzIGFuZCBhbGxv dyBhZHZhbmNlZCBmdW5jdGlvbmFsaXRpZXMuDQoNCldlIGhvcGUgeW91IGxpa2UgdGhpcyBpZGVh Lg0KQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpUaGFua3MsDQpUaWFucmFuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxp c3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg== --_000_e7c80c9c68994f97a3c6d30a4a0a2730huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAu MHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MzYx MzEwMDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NDcwNzUyNDA7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBz b3JyeS4gSSB3YXMgaW50ZXJydXB0ZWQsIGFuZCBzZW50IG91dCBhbiBpbmNvbXBsZXRlIGVtYWls LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gVGlhbnJhbiBaaG91DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBPY3RvYmVyIDI1LCAyMDIxIDExOjI1IEFNPGJyPg0KPGI+VG86PC9iPiAnR3JlZyBNaXJza3kn ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIElQUE0g V0cgKGlwcG1AaWV0Zi5vcmcpICZsdDtpcHBtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW2lwcG1dIEVuaGFuY2VkIEFsdGVybmF0ZSBNYXJraW5nIGRyYWZ0LXpob3UtaXBw bS1lbmhhbmNlZC1hbHRlcm5hdGUtbWFya2luZy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBH cmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIHZl cnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdCBhbmQgcmV2aWV3IGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5QbGVhc2Ugc2VlIGluIGxpbmUgd2l0aCBteSB0aG91Z2h0cy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBHcmVnIE1pcnNreSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBPY3RvYmVyIDI1LCAyMDIxIDEwOjI1IEFNPGJyPg0KPGI+VG86PC9iPiBUaWFucmFu IFpob3UgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgSVBQTSBXRyAoPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlwcG1AaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpp cHBtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlwcG1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2lwcG1dIEVuaGFu Y2VkIEFsdGVybmF0ZSBNYXJraW5nIGRyYWZ0LXpob3UtaXBwbS1lbmhhbmNlZC1hbHRlcm5hdGUt bWFya2luZy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBUaWFucmFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRo YW5rIHlvdSBmb3IgYnJpbmdpbmcgdXAgdGhpcyB3b3JrLiBJJ3ZlIHJlYWQgdGhlIGRyYWZ0IGFu ZCBoYXZlIHNldmVyYWwgY29tbWVudHMsIHF1ZXN0aW9ucy4gUGxlYXNlIGtpbmRseSBmaW5kIHRo b3NlIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjQ3LjI1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5CYXNlZCBvbiB0aGUgY29t bWVudHMgZHVyaW5nIHRoZSBJRVNHIHJldmlldyBvZiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQt bWFyaywgSSBzZWUgYSB2YWx1ZSBpbiBleHRlbmRpbmcgRmxvd01vbklELiBUaGF0IG1pZ2h0IHJl ZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSBjb2xsaXNpb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WlRSJmd0OyBUaGFua3MuIEkgYXBw cmVjaWF0ZSB5b3UgYWdyZWUgd2l0aCB0aGUgdmFsdWUgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPldoYXQgY291bGQgYmUgdGhlIHVzZSBjYXNlIGZvciB0aGUgRmxvdyBkaXJlY3Rpb24g aWRlbnRpZmljYXRpb24gZmxhZz8gQXMgdGhlIEFsdE1hcmsgaXMgYXBwbGllZCB0byB0aGUgZGF0 YSB0cmFmZmljLCB3b3VsZG4ndCBpdCBhbHdheXMgYmUgaW4gdGhlIGZvcndhcmQgZGlyZWN0aW9u PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlpUUiZndDsgQ29waWVkIGZyb20gbXkgcmVwbHkgdG8gSGFveXUsICZuYnNwO0kgd2lsbCBhZGQg bW9yZSBkZXRhaWxzIGluIHRoZSBuZXh0IHZlcnNpb24uIEluIGJyaWVmLCB0aGUg4oCcZmxvdyBk aXJlY3Rpb27igJ0NCiBpcyB1c2VkIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IG9uIHNldHVw IGJhY2t3YXJkIGRpcmVjdGlvbiBmbG93IG1vbml0b3JpbmcgYXV0b21hdGljYWxseS4gQWx0LU1L IGFwcGxpZWQgdG8gb25lIGRpcmVjdGlvbiBvbmx5IGJlZm9yZS4gVGhpcyBmbGFnIGlzIHVzZWQg dG8gaW5kaWNhdGUgdGhlIG5lZWQgdG8gc2V0IHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny4yNXB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSdt IGFsc28gbm90IGNsZWFyIGFib3V0IHRoZSB1c2Ugb2YgdGhlIE1lYXN1cmVtZW50IG1vZGUgZmxh Zy4gSSB0aG91Z2h0IHRoYXQgdGhlIG1vZGUsIGhiaCBvciBlMmUsIGlzIGRldGVybWluZWQgYnkg dGhlIGNob2ljZSBvZiBhcHByb3ByaWF0ZSBJUHY2IEVIIC0gSG9wLWJ5LUhvcCBPcHRpb24gSGVh ZGVyIG9yIERlc3RpbmF0aW9uIE9wdGlvbiBIZWFkZXIsIGFjY29yZGluZ2x5LiBBbSBJDQogbWlz c2luZyBzb21ldGhpbmcgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5aVFImZ3Q7IFlvdXIgcGVyc3BlY3RpdmUgaXMgY29ycmVjdC4g VGhpcyBpZGVhIGlzIGJhc2VkIG9uIG91ciBwcmFjdGljZSBvbiBleGlzdGluZyBuZXR3b3JrLiBU aGVyZSB3ZXJlIGRpc2N1c3Npb25zDQogaW4gNk1BTiBvciBzbywgYWJvdXQgdGhlIEVIIHByb2Nl c3NpbmcgY2FwYWJpbGl0eS4gVGhlIHN0YW5kYXJkIGFwcHJvYWNoIGFzIHlvdSBtZW50aW9uZWQg YWJvdmUgcmVxdWlyZXMgaW1wbGVtZW50YXRpb24gYW5kIHN1cHBvcnQgb24gc2V2ZXJhbCBFSHMs IHdoaWNoIGNvdWxkIGJlIGNvbXBsZXguIFdlIGNvbnNpZGVyIGluIHNvbWUgY2FzZXMsIGltcGxl bWVudGF0aW9uIG9mIG9uZSBFSCBpcyBhcHBsaWVkLiBGb3IgZXhhbXBsZSwgaWYgd2Ugb25seQ0K IGltcGxlbWVudCBIYkgsIHRoZW4gaW50ZXJtZWRpYXRlIG5vZGVzIGNvdWxkIHVzZSB0aGUgbWVh c3VyZW1lbnQgbW9kZSBmbGFnIGluIHRoZSBleHRlbnNpb24gcGFydCB0byBkZWNpZGUgd2hldGhl ciB0byBkbyBmdXJ0aGVyIGFjdGlvbnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJlYWRpbmcg dGhlIGRyYWZ0LCBpdCB3YXMgbm90IGNsZWFyIGhvdyB0aGUgZXh0ZW5kZWQgaGVhZGVyIGhlbHBz IHRvIGxvd2VyIG1hcmtpbmcgaW50ZXJ2YWxzIGluY3JlYXNpbmcgdGhlIGRlbnNpdHkgb2YgbWVh c3VyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlpUUiZndDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2lsbCBhZGQgbW9y ZSBpbmZvIGxhdGVyLiBPdXIgaWRlYSBpcyB0byBhZGQgYSB0aW1lc3RhbXAgdGFrZW4gZnJvbSB0 aGUgaGVhZCBub2RlLCBhcyB0aGUgbWV0YSBkYXRhLiBJbiB0aGlzIHdheSwgdGhlIGludGVybWVk aWF0ZSBub2RlIGNhbiBhbHdheXMgY29tcGFyZSB3aXRoIHRoaXMgdGltZXN0YW1wIHRvIGNoZWNr IHRoZSBkZWxheS4NCiBTbyBub3QgZGVwZW5kIG9uIHRoZSBkZWxheSBiaXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIE9jdCAyMSwgMjAyMSBhdCAxMToyNyBQTSBUaWFucmFuIFpob3UgJmx0Ozxh IGhyZWY9Im1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIj56aG91dGlhbnJhbkBodWF3ZWku Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpIFdHLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUg YXJlIG1hbnkgaW50ZXJlc3RzIGluIHRoaXMgd29ya2luZyBncm91cCB3b3JraW5nIG9uIHRoZSBh bHRlcm5hdGUgbWFya2luZywgUkZDODMyMSBhbmQgUkZDODg4OS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgeW91IG1heSBoYXZlIHNlZW4sIHdlIGFwcGxpZWQgdGhp cyBtZXRob2QgaW4gSVB2NiwgYW5kIHRoZSBkcmFmdCBpcyBpbiBJRVNHIHJldmlldy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0LW1hcmsvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFu LWlwdjYtYWx0LW1hcmsvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmFzZWQgb24g dGhlIGFib3ZlIGRyYWZ0LCBhbmQgdGhlIGNvbW1lbnRzL3N1Z2dlc3Rpb25zIHdlIHJlY2VpdmVk LCB3ZSBwcm9kdWNlZCBhbg0KPHNwYW4gbGFuZz0iRU4iPkVuaGFuY2VkIEFsdGVybmF0ZSBNYXJr aW5nIE1ldGhvZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpob3UtaXBw bS1lbmhhbmNlZC1hbHRlcm5hdGUtbWFya2luZy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pcHBtLWVu aGFuY2VkLWFsdGVybmF0ZS1tYXJraW5nLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj5UaGlzIGRvY3Vt ZW50IGV4dGVuZHMgdGhlIElQdjYgQWx0ZXJuYXRlIE1hcmtpbmcgT3B0aW9uLCAmbmJzcDt0byBw cm92aWRlIHRoZSBlbmhhbmNlZCBjYXBhYmlsaXRpZXMgYW5kIGFsbG93IGFkdmFuY2VkIGZ1bmN0 aW9uYWxpdGllcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj5XZSBob3BlIHlvdSBsaWtlIHRoaXMgaWRlYS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOIj5BbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4iPlRpYW5yYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQppcHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e7c80c9c68994f97a3c6d30a4a0a2730huaweicom_-- From nobody Mon Oct 25 02:07:26 2021 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 E14343A0776 for ; Mon, 25 Oct 2021 02:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ5316yGrWz8 for ; Mon, 25 Oct 2021 02:07:20 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB783A0063 for ; Mon, 25 Oct 2021 02:07:20 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 5so275625wmb.1 for ; Mon, 25 Oct 2021 02:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YVMikqPfb1L7Jb0Su3B7LHr/5z0UASkKz1hhIResRPw=; b=o49s59fvHCkEhQ6290htZcZTdnXcVU3JJR2leKJ5IvgAB6nVNrev5PC2UCiI9X9pam lqoBEjjLfTSSjYhSiKcdcTW+6sEFFsj1C//KdpmXPFMOShxBB3aCzghg2+2RkURwjHjo muAqyx5R1QmlECPKGLV+oXH4Lm6qeby6pFeBQcnlxFdYVkCGFX/b6gK2yq1TnBjnMblM YYPVu2pVY8xcziqzsxlJpyLULJ5HKc9ACq1Zo/h8vrz6vqoC2gG9zHIbrLoT3kM34J0A fAYYynqnj3jHga1+ZUQ7Chq13cbkgTcyJzAHQjSE7sPANsKXPFYznrEPLPPngiNg9S/5 Ezjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YVMikqPfb1L7Jb0Su3B7LHr/5z0UASkKz1hhIResRPw=; b=WL4dQCIrmrhYECR+M7B3U7vbxGKkJTINKl9csH2x7TQcJbzoIZ3MhwR4YhSSdrm36R 8pwz9Dxa51t+ngSFiZjxUfN560zrtdAYfKsk1ppmSRitrVvrrJDWXVSXZ4Vi1UTiNPAW DBXVfKYAnxzpbGJZqHSIbfs5gmTk5HrSIwtXHLpwljfrGRPvO4j0fBB68YemRMkhKeVk SjUVjWus049KdYXnVios9nJEo8TsyTaQxkPogXUUIJyBunADjgdEUtfUHfKU6xtimb4R eiy/FSPTgpBI/QaMpdTjy3NV5l9BkKofxrVQOYqoy0PoXx1JOPhH1pFsPvgV/jvyo8BA GaRw== X-Gm-Message-State: AOAM532ri2dcapH0K+t4q0xTXNvcWf1FpsGMlIi71XO484aG49D4ShRF DXvuAvgwuYXSr+eyaTGWjKbwFToCF+kDFMBi/xIFOBlZJ0UyvBCJ X-Google-Smtp-Source: ABdhPJzXeAb52QkzzLdYv+oZoBLGk68YZZWB/enw/8r2RBDzGhrOZzicUfCjWxLvHhJ+VrZfZYhcOG3Rs12eyBqvJa8= X-Received: by 2002:a7b:c351:: with SMTP id l17mr19161634wmj.120.1635152837537; Mon, 25 Oct 2021 02:07:17 -0700 (PDT) MIME-Version: 1.0 References: <163514707010.28291.13665614171375267957@ietfa.amsl.com> In-Reply-To: <163514707010.28291.13665614171375267957@ietfa.amsl.com> From: Tal Mizrahi Date: Mon, 25 Oct 2021 12:07:06 +0300 Message-ID: To: IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [ippm] New Draft: draft-mizrahi-ippm-marking-00 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, 25 Oct 2021 09:07:25 -0000 Hi, https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm-marking This new draft summarizes the different marking methods that have been discussed out there in the context of performance measurement. With RFC8321bis moving to Proposed Standard, we believe it is useful to summarize the different marking methods; not only the methods from RFC8321, but also other methods that have been discussed. This draft is partially based on an older (expired) draft: draft-mizrahi-ippm-multiplexed-alternate-marking. Feedback would be welcome. Thanks, Tal. ---------- Forwarded message --------- From: Date: Mon, Oct 25, 2021 at 10:31 AM Subject: New Version Notification for draft-mizrahi-ippm-marking-00.txt To: Mach Chen (Guoyi) , Giuseppe Fioccola , Greg Mirsky , Mauro Cociglio , Tal Mizrahi A new version of I-D, draft-mizrahi-ippm-marking-00.txt has been successfully submitted by Tal Mizrahi and posted to the IETF repository. Name: draft-mizrahi-ippm-marking Revision: 00 Title: Marking Methods for Performance Measurement Document date: 2021-10-25 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/archive/id/draft-mizrahi-ippm-marking-00.txt Status: https://datatracker.ietf.org/doc/draft-mizrahi-ippm-marking/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mizrahi-ippm-marking Abstract: This memo presents a summary of marking methods for performance measurements, and discusses the tradeoffs among them. These marking methods enable to measure various performance metrics such as packet loss and delay, and require a low overhead in the header of data packets, as low as one or two bits per packet, or in some cases even zero bits per packet. The target audience of this document is network protocol designers; this document is intended to help protocol designers choose the best marking method(s) based on the protocol's constraints and requirements. The IETF Secretariat From nobody Mon Oct 25 06:06:03 2021 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 CC1573A0A20; Mon, 25 Oct 2021 06:05:57 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <163516715777.31497.10557288203177433794@ietfa.amsl.com> Date: Mon, 25 Oct 2021 06:05:57 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-explicit-flow-measurements-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: Mon, 25 Oct 2021 13:05:58 -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 : Explicit Flow Measurements Techniques Authors : Mauro Cociglio Alexandre Ferrieux Giuseppe Fioccola Igor Lubashev Fabio Bulgarella Isabelle Hamchaoui Massimo Nilo Riccardo Sisto Dmitri Tikhonov Filename : draft-ietf-ippm-explicit-flow-measurements-00.txt Pages : 41 Date : 2021-10-25 Abstract: This document describes protocol independent methods called Explicit Flow Measurement Techniques that employ few marking bits, inside the header of each packet, for loss and delay measurement. The endpoints, marking the traffic, signal these metrics to intermediate observers allowing them to measure connection performance, and to locate the network segment where impairments happen. Different alternatives are considered within this document. These signaling methods apply to all protocols but they are especially valuable when applied to protocols that encrypt transport header and do not allow traditional methods for delay and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-explicit-flow-measurements-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 12:12:44 2021 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 1D3D23A0DEE for ; Mon, 25 Oct 2021 12:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYbx7hRxlXNA for ; Mon, 25 Oct 2021 12:12:33 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 77B333A0A46 for ; Mon, 25 Oct 2021 12:12:28 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id a26so3581507edy.11 for ; Mon, 25 Oct 2021 12:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yOAGGzd/2Vu0RgBZasOi+3fTZ5wmwLjroEwyuqEzu+Y=; b=qO6MXXvFOJsk3JWU0IONuQ1gdXUJJphussilBn1H8g6PZvX/bY9scsf7+b4v5/SMIc owIvjT2R8uLrxfR5LpzNVp8MGWE7D8M6CijeiNigHL+7DMItLi7lO25hNkRT82jCGvA6 jh3rCeNKEalSrTCJWHWG/N85R/H0ZU3baLFgR0atr4WhDbjCU8TsdQgQFyQhWK/L8LVp qZf5rbCBngg+ZQ0VCzGxbgploT75aE7O9VSEMVgQjyvL05+bLomEycJB5jHj7gG37+HH T9gkKYrvPFZPn1NzfN2+KA0jR/SQIuHQOOsK/8G8OKWHtVA+07bX7+R0wqWsP30ZVKfC rTug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOAGGzd/2Vu0RgBZasOi+3fTZ5wmwLjroEwyuqEzu+Y=; b=ULjus3TalHCgKfajIx06ab89jR5XSvXXrWYg3Bn7hHbaYS3QA9K1oi5UA4hTR9COIR QXwiftVGg1a8P0Naun/6jJvJKmced5prsqYX2goq0Iq5eDZxxkO4F9xgQKOyRK0WYtO4 TMy/hLaIi4KHe5jJxSKPzJ/SmCqJnengrJIHgkdwRmd6kv1D/PODDVB7FUiM4o892qUl BrpdDhP7PcGtuiCEts3Swbs8WFh2xyQ4s+yP384LIdgAxWpNubPMqz7hmRMDHQVujqA+ n2bUdFAyFHkLm3JDA1STOxmR2WKm99kCfcCEb+xGB9lVNbEmwTScE12583SkAAAYPLrx JzgA== X-Gm-Message-State: AOAM530OGURgH0inX5t0XogU9YPAf6+0zpN95IQwhYz982J1kKFUtgoz VrQ4zjZrMB92cS1ucq1V+ApNW64fmOTAwxBIX4g= X-Google-Smtp-Source: ABdhPJwK7NcZAc5nIw2JlH5z1ALK0YOTpFUZ+k3zekeFGGF6OSEzYSooF34/BYex9XQuxColl0xWAGRGce6CG+hcXxo= X-Received: by 2002:a50:a45d:: with SMTP id v29mr28972251edb.295.1635189145250; Mon, 25 Oct 2021 12:12:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 25 Oct 2021 12:12:13 -0700 Message-ID: To: "MORTON JR., AL" Cc: "Ruediger.Geib@telekom.de" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000024af9805cf3224b5" Archived-At: Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01 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, 25 Oct 2021 19:12:43 -0000 --00000000000024af9805cf3224b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Al, while evaluating the suitability of STAMP, have you considered using a new STAMP extension to query the Session-Reflector? In RFC 8792 there are several examples of using STAMP extension to retrieve information fro the Session-Reflector. Do you think that could be a viable option for the IP Maximum Capacity test? Regards, Greg On Fri, Oct 22, 2021 at 4:23 PM MORTON JR., AL wrote: > Hi R=C3=BCdiger, > > Many thanks for your review and comments! > Please see replies below, [acm] > > Al > > > -----Original Message----- > > From: Ruediger.Geib@telekom.de > > Sent: Thursday, October 21, 2021 5:54 AM > > To: MORTON JR., AL > > Cc: ippm@ietf.org > > Subject: AW: [ippm] Questions on > draft-morton-ippm-capacity-metric-protocol-01 > > > > Hi Al, > > > > A standardized protocol to request a standardized access bandwidth > measurement > > is a generic requirement and I appreciate your initiative. As a person > not > > personally implementing software, some high level comments on the doc > only: > > > > 2. Scope, Goals, and Applicability, last sentence: > > > > "The primary application of the protocol described here is the same = as > > in Section 2 of [RFC7479] where:" > > > > That's a mis-quote, isn't it? You target another RFC, don't you? > [acm] > Yes, that's a typo it is 7497. > > > From numbers I guessed: > > https://urldefense.com/v3/__https://www.rfc- > > editor.org/rfc/rfc7497.html*section-2__;Iw!!BhdT!y6i- > > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$ > [acm] > right! > > > > I started with a minor issue, as it points to RFC7497. The latter RFC > contains > > the following statement: > > https://urldefense.com/v3/__https://www.rfc- > > editor.org/rfc/rfc7497.html*section-7__;Iw!!BhdT!y6i- > > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$ > > "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do > not > > possess the asymmetric size generation capability with two-way testing.= " > [acm] > Right, we have a different problem with TWAMP and others, described below= . > > > > Adding a brief section to draft-morton-ippm-capacity-metric-protocol > > discussing why e.g. TWAMP (or a simplified version) isn't applied or > rather > > enhanced for the measurement protocol may be useful. If existing IETF > IPPM > > measurement control protocols don't offer any benefits justifying their > > adaption for a capacity-metric-protocol, the section will be brief. If > there's > > pro and con, what's worth adding functionality to TWAMP and what's the > "cost" > > (in terms of work and changes) may be worth some words. Should inclusio= n > of a > > capacity-metric-protocol to TWAMP be worth a thought, a few words on > required > > features and changes (a sketch on what to add) may be useful. I'm not a > TWAMP > > expert, I excuse if my comment doesn't apply. > [acm] > No problem, I thought about this before writing this draft. It comes down > to these four points (which I will add in the Intro): > > Although there are several test protocol already available for > support and manage active measurements, this protocol is a major > departure from their operation: > > 1. UDP transport is used for all setup, test activation, and control > messages, and for results feedback (not TCP), simplifying > operations. > > 2. TWAMP and STAMP use the philosophy that one host is a Session- > Reflector, sending test packets every time they receive a test > packet. This protocol supports a one-way test with periodic > status messages returned to the sender. > > 3. OWAMP supports one-way testing with results Fetch at the end of > the test session. This protocol supports a one-way test and > requires > periodic status messages returned to the sender to support the > load adjustment search algorithm. > > 4. The security features of OWAMP and TWAMP have been described as > "unusual", to the point that IESG approved their use while also > asking that these methods not be used again. Further, the *WAMP > approach to security is over 15 years old at this time. > > I concluded that any attempt to enhance OWAMP or others would be time > wasted. We have a unique use-case here. > > thanks, > Al > > > > > Regards, > > > > Ruediger > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: ippm Im Auftrag von MORTON JR., AL > > Gesendet: Mittwoch, 20. Oktober 2021 00:32 > > An: IETF IPPM WG > > Betreff: [ippm] Questions on > draft-morton-ippm-capacity-metric-protocol-01 > > > > Hi IPPM, > > > > Len Ciavattone and I am looking for some feedback on our protocol [0] > designed > > to help measure the Maximum IP-Layer Capacity Metric (which will be > published > > as an RFC shortly). > > > > We are asking folks to take a look at the draft, because we are fairly > sure > > you will have some questions! > > > > One area where we know more development is required is the Modes of > operation, > > which essentially describes how the different aspects/exchanges of the > > protocol will be made secure. This is pretty-much a green-field in our > > specification, so suggestions are very welcome. Section 10 currently > > describes the different modes that we imagined to be useful (A through = F > > below), but practical aspects of any proposed solution might indicate > modes > > that should be combined, split-up, or new modes. > > > > So, please give the draft and/or the list below a look, and let us know > what > > you think. > > > > thanks! > > Al > > > > > > [0] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i- > > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$ > > > > 3. Client-server authentication and integrity protection for > > feedback messages conveying measurements is RECOMMENDED. To > > accomodate different host limitations and testing circumstances, > > different modes of operation are recommended: > > > > A. Un-authenticated mode (for all phases) AND B. OPTIONAL > Authenticated set- > > up only > > SHA-256 HMAC time-window verification (5 min time stamp verification) > (could > > add silent failure option) > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > > > > C. Encrypted setup and test-activation > > (currently using OpenSSL Library, so KISS, but may be too slow for test > > packets) > > > > -=3D-=3D-=3D-=3D--=3D- Old/low-power host performance impacts -=3D= -=3D-=3D-=3D-=3D-=3D- > > > > D. Encrypted feedback messages > > > > E. Integrity protection for test packets SHA-256 HMAC > > > > F. Encrypted test packets (maybe also valuable to defeat compression o= n > > links) > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;= !!Bhd > > T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$ > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00000000000024af9805cf3224b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Al,
    while evaluating the suitability of STAMP, have= you considered using a new STAMP extension to query the Session-Reflector?= In RFC 8792 there are several examples of using STAMP extension to retriev= e information fro the Session-Reflector. Do you think that could be a viabl= e option for the IP Maximum Capacity test?

    Regards= ,
    Greg

    On Fri, Oct 22, 2021 at 4:23 PM MORTON JR., AL <acmorton@att.com> wrote:
    =
    Hi R=C3=BCdiger,

    Many thanks for your review and comments!
    Please see replies below, [acm]

    Al

    > -----Original Message-----
    > From: Ru= ediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
    > Sent: Thursday, October 21, 2021 5:54 AM
    > To: MORTON JR., AL <acmorton@att.com>
    > Cc: ippm@ietf.org
    > Subject: AW: [ippm] Questions on draft-morton-ippm-capacity-metric-pro= tocol-01
    >
    > Hi Al,
    >
    > A standardized protocol to request a standardized access bandwidth mea= surement
    > is a generic requirement and I appreciate your initiative. As a person= not
    > personally implementing software, some high level comments on the doc = only:
    >
    > 2.=C2=A0 Scope, Goals, and Applicability, last sentence:
    >
    >=C2=A0 =C2=A0 "The primary application of the protocol described h= ere is the same as
    >=C2=A0 =C2=A0 in Section 2 of [RFC7479] where:"
    >
    > That's a mis-quote, isn't it? You target another RFC, don'= t you?
    [acm]
    Yes, that's a typo it is 7497.

    > From numbers I guessed:
    >     https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section= -2__;Iw!!BhdT!y6i-
    > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$
    [acm]
    right!
    >
    > I started with a minor issue, as it points to RFC7497. The latter RFC = contains
    > the following statement:
    > https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc7497.html*section= -7__;Iw!!BhdT!y6i-
    > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$
    > "Current IETF standardized test protocols (... [RFC5357 - TWAMP].= .) do not
    > possess the asymmetric size generation capability with two-way testing= ."
    [acm]
    Right, we have a different problem with TWAMP and others, described below.<= br> >
    > Adding a brief section to draft-morton-ippm-capacity-metric-protocol > discussing why e.g. TWAMP (or a simplified version) isn't applied = or rather
    > enhanced for the measurement protocol may be useful. If existing IETF = IPPM
    > measurement control protocols don't offer any benefits justifying = their
    > adaption for a capacity-metric-protocol, the section will be brief. If= there's
    > pro and con, what's worth adding functionality to TWAMP and what&#= 39;s the "cost"
    > (in terms of work and changes) may be worth some words. Should inclusi= on of a
    > capacity-metric-protocol to TWAMP be worth a thought, a few words on r= equired
    > features and changes (a sketch on what to add) may be useful. I'm = not a TWAMP
    > expert, I excuse if my comment doesn't apply.
    [acm]
    No problem, I thought about this before writing this draft. It comes down t= o these four points (which I will add in the Intro):

    =C2=A0 =C2=A0Although there are several test protocol already available for=
    =C2=A0 =C2=A0support and manage active measurements, this protocol is a maj= or
    =C2=A0 =C2=A0departure from their operation:

    =C2=A0 =C2=A01.=C2=A0 UDP transport is used for all setup, test activation,= and control
    =C2=A0 =C2=A0 =C2=A0 =C2=A0messages, and for results feedback (not TCP), si= mplifying
    =C2=A0 =C2=A0 =C2=A0 =C2=A0operations.

    =C2=A0 =C2=A02.=C2=A0 TWAMP and STAMP use the philosophy that one host is a= Session-
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Reflector, sending test packets every time they = receive a test
    =C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 This protocol supports a one-way t= est with periodic
    =C2=A0 =C2=A0 =C2=A0 =C2=A0status messages returned to the sender.

    =C2=A0 =C2=A03.=C2=A0 OWAMP supports one-way testing with results Fetch at = the end of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0the test session.=C2=A0 This protocol supports a= one-way test and requires
    =C2=A0 =C2=A0 =C2=A0 =C2=A0periodic status messages returned to the sender = to support the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0load adjustment search algorithm.

    =C2=A0 =C2=A04.=C2=A0 The security features of OWAMP and TWAMP have been de= scribed as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"unusual", to the point that IESG appr= oved their use while also
    =C2=A0 =C2=A0 =C2=A0 =C2=A0asking that these methods not be used again.=C2= =A0 Further, the *WAMP
    =C2=A0 =C2=A0 =C2=A0 =C2=A0approach to security is over 15 years old at thi= s time.

    I concluded that any attempt to enhance OWAMP or others would be time waste= d. We have a unique use-case here.

    thanks,
    Al

    >
    > Regards,
    >
    > Ruediger
    >
    > -----Urspr=C3=BCngliche Nachricht-----
    > Von: ippm <ippm-bounces@ietf.org> Im Auftrag von MORTON JR., AL
    > Gesendet: Mittwoch, 20. Oktober 2021 00:32
    > An: IETF IPPM WG <ippm@ietf.org>
    > Betreff: [ippm] Questions on draft-morton-ippm-capacity-metric-protoco= l-01
    >
    > Hi IPPM,
    >
    > Len Ciavattone and I am looking for some feedback on our protocol [0] = designed
    > to help measure the Maximum IP-Layer Capacity Metric (which will be pu= blished
    > as an RFC shortly).
    >
    > We are asking folks to take a look at the draft, because we are fairly= sure
    > you will have some questions!
    >
    > One area where we know more development is required is the Modes of op= eration,
    > which essentially describes how the different aspects/exchanges of the=
    > protocol will be made secure. This is pretty-much a green-field in our=
    > specification, so suggestions are very welcome.=C2=A0 Section 10 curre= ntly
    > describes the different modes that we imagined to be useful (A through= F
    > below), but practical aspects of any proposed solution might indicate = modes
    > that should be combined, split-up, or new modes.
    >
    > So, please give the draft and/or the list below a look, and let us kno= w what
    > you think.
    >
    > thanks!
    > Al
    >
    >
    > [0] https://urldefense.= com/v3/__https://datatracker.ietf.org/doc/html/draft-
    > morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i-
    > TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$
    >
    >=C2=A0 =C2=A0 3.=C2=A0 Client-server authentication and integrity prote= ction for
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 feedback messages conveying measurements is= RECOMMENDED.=C2=A0 To
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 accomodate different host limitations and t= esting circumstances,
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 different modes of operation are recommende= d:
    >
    >=C2=A0 A. Un-authenticated mode (for all phases) AND=C2=A0 B. OPTIONAL = Authenticated set-
    > up only
    > SHA-256 HMAC time-window verification (5 min time stamp verification) = (could
    > add silent failure option)
    >
    >=C2=A0 =C2=A0 =C2=A0 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
    >
    >=C2=A0 C. Encrypted setup and test-activation
    > (currently using OpenSSL Library, so KISS, but may be too slow for tes= t
    > packets)
    >
    >=C2=A0 =C2=A0 =C2=A0 -=3D-=3D-=3D-=3D--=3D- Old/low-power host performa= nce impacts -=3D-=3D-=3D-=3D-=3D-=3D-
    >
    >=C2=A0 D. Encrypted feedback messages
    >
    >=C2=A0 E. Integrity protection for test packets SHA-256 HMAC
    >
    >=C2=A0 F. Encrypted test packets (maybe also valuable to defeat compres= sion on
    > links)
    >
    > _______________________________________________
    > ippm mailing list
    > ippm@ietf.org > https://urldefens= e.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
    > T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    https://www.ietf.org/mailman/listinfo/ippm
    --00000000000024af9805cf3224b5-- From nobody Mon Oct 25 13:18:13 2021 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 CA2DE3A0AFA for ; Mon, 25 Oct 2021 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecomitalia.it header.b=hhGeRDwj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=telecomitalia.onmicrosoft.com header.b=edIlDudo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS2sLFzGHC_x for ; Mon, 25 Oct 2021 13:17:59 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 F14093A0045 for ; Mon, 25 Oct 2021 13:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@telecomitalia.it; t=1635193075; x=2499106675; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=K1s1nACJBMho533YRJvYtW+fmJwWQK53ELkVFxkesos=; b=hhGeRDwj9LU2O8F3p4uzyDh/6eg/Dx+M/Q+BARVkxepDB1K/Ulq34t64KZHW3DT8 GMsN7TYMMmB4+zA8p73Px5a+0bcq1NvFT8ATYO3F6S1az3eWct9CFORhDF2RjO6K 6ZAYOlYpSlIoTbM6/b6JQ49LxoklfMxc5/NL9ty0+LKPJXWUeU0y023YXT8IY+EU MrUL8lsycJIkaWM24XUNwb5Dx8QDaXfoz7/esdRQ+Ph7xnclGQx9V6CBYnHu9t3B 0O6jO+JvolOFvMpFneZVoJCbDtnoTtM3nbl8r5K8xMLvw1ozSMggrGxGR4IwTQyx C8dvIcK477Efl0hoEolUqw==; X-AuditID: d9a9790a-5c373700000007ea-6d-617710f3ab74 Received: from TELMBXB13RM001.telecomitalia.local ( [10.14.252.75]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id DA.36.02026.3F017716; Mon, 25 Oct 2021 22:17:55 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VvWRHr6rE27gi6Y+OYVBOJGJ0sxG5UnQbDt2qg2HosAc19QLcZXIf9zT4wd65vmUdOHFrWMMczg6RUwaq2D6hpFCCUl+F5u0wiGZQANtFeX1ft1/rrvvw37ydkpvfv8BoxRL5TtW+mnk82zfeCKNxE7ONIwPmF0G1Av9AsbewFbwFVTZ9YRsIIucUHKTmoLHujyU7Sg2rXpN6pOx2ghXU7yY5Qqw1NCamYo7myNjN1Z37EpCbklvqH/E/FbCQK7EkRjsQmw0NodY+2mNl/LrfU6bvTi/G0bbM4N0T/7hckxGAIf5Uw1WEeKTJIdbTkkpZHpwfbF0awot2+NRp7hlGg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TtwtbQPsggoEhIbeppGkfZSqYvOFWAf63CKh2y36REs=; b=dlGwM45PZ/17RPAdkF812GKjOjTZtAvQLo8nbSjt6GYMzrauMzMc8iBdDWv4+AnMEKiQZv/uXzg3c81yzFunAQmrh41VpnUXk2C2V23MOSEQp+bg1jdzVKeSsPMxIeh1gRCX1Rc0AeA6I/MRpsuAv0DGgT/f6QJiH2qqqtPNCYjNw1J1Oyd0daPg8Q0c5J5woHb1Ik3cpxxAkdaDPmzoFcRrrsjxl3qHhBdamNJYfOypZxzHQWnzzzWc6JKtxz53BBsJ3zVN+iL3hPFXs1BBzMWDJAXi4MTWeSLCDUQ0lnQSZ4KxrcDhorq8uyiLOiFBvklACJaqzJuQc6I9SG0KVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telecomitalia.it; dmarc=pass action=none header.from=telecomitalia.it; dkim=pass header.d=telecomitalia.it; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecomitalia.onmicrosoft.com; s=selector1-telecomitalia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TtwtbQPsggoEhIbeppGkfZSqYvOFWAf63CKh2y36REs=; b=edIlDudoFu3eHLDNYRtCUziHZGvSL3OtUwPTwpwqnU5LQOF5SVAxQ26bFmzAibCbNehQWn0jRY0BTy8d4OVUhQUqYacKr635hJf8Pkg6fgmL3Xhv6wSJCuPHZc3DZJbromz1gVybWURqYuxWX6FhgXIj7EWMxQw4HpI9wcMW1m4= From: Cociglio Mauro To: Tommy Pauly CC: "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Request for presentations at IETF 112 Thread-Index: AdfJ3Pw/FNgBrdlqSAmoZgULUQLSaA== Date: Mon, 25 Oct 2021 20:17:52 +0000 Message-ID: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Enabled=true; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SetDate=2021-10-25T20:17:49Z; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Method=Standard; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Name=Uso Interno; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SiteId=6815f468-021c-48f2-a6b2-d65c8e979dfb; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ActionId=086a816f-acfe-491d-97e3-cc420119625a; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ContentBits=2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telecomitalia.it; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c34bff7e-152d-4c49-e365-08d997f4862a x-ms-traffictypediagnostic: DB6PR07MB4198: x-microsoft-antispam-prvs: x-ti-disclaimer: ADBanner x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZR5pIZwMhRFOmiqMn8voqBuoUfu5zSCMiZx21fd6McovShyU8o0BVy6MwGgmMGuIBqeFypKk58DefVwkO0XCUjIYNcYv7hHz9w5t4ejaXKkba0qHG6mF3Sgrh4kPVAnqQMGvE5D25s9ohoP4g6ZhfvciRuDhlzn0SE33toP9gEEtY9iOytzNQGw01y9FDvpkka4k24iH8DkkVPOjXYEt7ks45nVj7dlkD+VsQIwqRhSeVh6aKHZOJCp4xP4vJYOboMkNy+TkBKRR3d9dT1UTdDwek9nV4u+vUqIbhANQXOb2aGIBSe4iZXq4q0OSjpzCB89lgHwW0HEA9EwEyygjE4TacWf2qpG//VDfw2UHFoozo3cquD/foOiTSaNPXn/z0Pe/ShkPxxmQ5IqHv9IEoqTjXVRm2lr949PevrlZN2h0U/fJKvQBArGJLcN9jZOBLLlM1UmyksB/qv79flkNLWKc6AK1NXVDjZO8czeg/9vyFrj1OOZksv5sql0GB/NM1atHPcIiOOmBNi0h6l0wZAk3EckgZddvuqKzg42+Q25dM4iNtC6sjwkpeuyMK/GKgCxvY+j9qdBpFX8K+cjQ8xrL8ra/dWFCcVYj4iR4cqciVNeyr+h0+zwFG9I3pE3sNpvHy6qI8LUrj75iLErEkBXmq3wCJmoHVZsJdAzKscSXzl8b3B5a86PSMX/4jd5mqY6xOFUglFjpY5SssY6FANkQKXw5JqNqu+Fob7E++b/RkiECRE+GD7n9X5+GnoYo5bZy9HsVnz63+FP3JbIAVCmJcupHLVMng43RZRWY1MQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR07MB6775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(19627235002)(5660300002)(55016002)(52536014)(66476007)(66446008)(86362001)(66946007)(33656002)(38070700005)(83380400001)(122000001)(186003)(316002)(71200400001)(82960400001)(166002)(8676002)(7696005)(38100700002)(76116006)(2906002)(4326008)(9686003)(26005)(64756008)(508600001)(66556008)(8936002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?0U4iAZGPD7iuzE+BJVhR1Ak2cnHPxaYztlydOnoMbCwdKXSODAc6hn/GP/?= =?iso-8859-1?Q?rLTUrPW19M+5qfJIjZhPRCe/AISjm6wj6dxk0j9g0qm1y9fe44jiwxJ7Vj?= =?iso-8859-1?Q?DYBe3EPdzXIzyNM0v0zptr9Meyq509oBzk1iLf1UCQp2Cf+cT7/3EwYpKa?= =?iso-8859-1?Q?QRyyvWhKp2jQWAurDWmUs+2WqBdNWDkt/Ot56P6cyAuJdqUGVVwmxIVpwq?= =?iso-8859-1?Q?QIfnqFa2C+L6bWqy/a5zHMDMXspHxLfgUEGK2sHYiuXY1AeK8n563oAoH3?= =?iso-8859-1?Q?K4hlbQFxvZbxp0X0AdEmoLonIP0IsLZUL1+Yeee6Yt825A17TLEYkHo7hs?= =?iso-8859-1?Q?ceuXAvb8ulKs8yUTLzeqqY7hTpC8AmipyhK6v867AjG+49Bo+Cfvz/d1tV?= =?iso-8859-1?Q?+6Ls8ys5GmpCm+c80O4ALUfB7RbPypf7DG5wDumTCeZqrYROeLkDbPtVdB?= =?iso-8859-1?Q?o2j0jp427ugEaM5mD+Lk2cVtQDNySw7+Uli1bem/yjiUvv50vxF1yPAB/n?= =?iso-8859-1?Q?wVwtNUXH0k3IbO2WREG3vcaHK71OvY4oGTqQ0W6/QvELrL0CwpbCEhxveI?= =?iso-8859-1?Q?Yq7YCp9LYahYhsG4M1qtJb5uDmQ6T8eDnZ9T5vn384ZakKfINbOBf776vj?= =?iso-8859-1?Q?shPlIfJzdD63l+sUnIXk0GfYguTFD7VyID42aBDSI1Yq8FdaDBqseFigPi?= =?iso-8859-1?Q?hq9ILk3NgLkNJbz50/4Fy5e/CKEsJshFfXY3g6DeISl3eQBIpJash7R06d?= =?iso-8859-1?Q?R0xSlHhakJMzWuZbPOaDJ/2QUlCiVaBSykKfa3ZBoanusMyxRCb9eOL62T?= =?iso-8859-1?Q?z1arCZ4JPY6puyKtqYdZAHfhNMG+cl2b/W0RoBaNFJScc1SBSpwD8xn6P+?= =?iso-8859-1?Q?TRXEY2GwYPUssBEVVSOLo9JSGKxS0o1UiX/y+fiJrFvMmW9Zt7PQ9FAtwK?= =?iso-8859-1?Q?fwRfzeQadAjMhfL0u98bWFEExe3rPeLOKup2HqRx8mMK0gbMIRecjj69qL?= =?iso-8859-1?Q?LQ5V4pFiz/82L+AITVHPI1IORLrEqFXbDcKbEIXuaZPd01jSq8YKKiklLl?= =?iso-8859-1?Q?4fx5r2zXaEMi6wscJI5sU/6kyLzF2gY1fifdDDcN6gDf8w/hMbycFTEcJY?= =?iso-8859-1?Q?ePD2UI4KjHx2h2r4L9/sEiNpeNKsdNRd61RT5KWpnZP+ffD5EtNvwZvFfV?= =?iso-8859-1?Q?DT1xIliclkmDPdIkI1aLsSCPTlQNrfO3BsdiaAiwnHYv2rfiFr5cDBuPDx?= =?iso-8859-1?Q?26daWU29NCWo56qsS4pGh+swTeyiq2sUct0mj2Zfkdh1Is7ZG7ikfoPmgm?= =?iso-8859-1?Q?EKNVTQYvM+iQToJA7KTiz3L07gT7KFJIDpGUGdBaPsvQAvD4Dn4q2bvr4e?= =?iso-8859-1?Q?H1BsLYU2NxUEiF8ipeC5G5DO+iDwfUKQan8OKoudF3y5Bbs2E1kC23wAkb?= =?iso-8859-1?Q?V54Sp4DhP4PCrdywW7niCqToQLbcRTW6bLbAGXzbS5RITTZgFnmoNc8wzn?= =?iso-8859-1?Q?q2WYth2MeIhBaICfIN3lDf6vMG3rcHFsJC1ZzYURx+5NiXIOFeCELV2LRc?= =?iso-8859-1?Q?q9HAdnGP/ss723h9j4aKbw6WjBD0C5+dyqfGRWFnulDY+rdUvi7lNN7PNa?= =?iso-8859-1?Q?EmAXhCwqJBUsg4hurxZc0gpI0UDh3h/ZQ1IvJVDUHgCs/gvMnihc5RuRU1?= =?iso-8859-1?Q?18tzwsk2IjPGlVPONiueZuw7pR33LbTBahhUMSTpIKzgXQPNBvOcL4fXK6?= =?iso-8859-1?Q?Oo1w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DBAPR07MB67755B3ADFE4BEE4C8C10179E9839DBAPR07MB6775eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBAPR07MB6775.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c34bff7e-152d-4c49-e365-08d997f4862a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 20:17:52.6725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6815f468-021c-48f2-a6b2-d65c8e979dfb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: akcXdQUVL4EVEvy3JzC+JLUk/K9oOshXN+ZQxMtaiDg6AacaJK2o+WfxKvw3uq3fslIqMwGhLu3PKj7TuHbUJp/zWguZJ0a32Q+qbb5ddyo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4198 X-OriginatorOrg: telecomitalia.it X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEJsWRmVeSWpSXmKPExsXCxffHW/ezQHmiwbZTqhY9D94xW/RMesXs wORxYtkVVo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFik4ujgBJVOLlBQy U2yVzJQUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZJdYGlqcUm+Qm5qcXFienpmvkLCNNGM3f/msRccd6h4ue43WwPjessuRk4OCQETiRf9E9i7 GLk4hASmMknMeraUDcRhFFjGLDH1wRR2KIdVYl3La1YI5wijxNLmA0wgDovAfmaJTQ93MoIM YxMwkziz5RkbiC0iYCyx/OBxFhCbWcBIovfkdrC4sICFxI2jZ4BsDqAaK4mlNzIhyvUkrp74 DVbCIqAq8fDmArASXoEYiX8TXUHCjAKyEjMa1rBDTBSXeDH9BDvECwISS/acZ4awRSVePv7H CmLzCixkkXiwng2it1ri77UJbBA1shKX5nczQti+EqvOHGMHWSUhoCXxeYoQRDhb4vjhj1Dj JSUOH94E1aomceNNB9QqOYlVvQ9ZIGx5iWmL3kPVy0g8uLEdHIgSAufZJFpXPGaEcN4wS2zd +QOqw0Bi3rcjbBMY9WYh+WcW0B3MAvkS156pzAJ7QVDi5MwnLBAlehI3pk5hg7C1JZYtfM0M YetKzPh3iAVZfAEj+ypG0dwKA0O9ktSc1OT83MySxJzMRL3Mkk2MwFR7c2Ul1w7Gjltv9A4x MnEwHmKU4GBWEuG1+VSSKMSbklhZlVqUH19UmpNafIjRBxgfE5mlRJPzgck+ryTe0NTM1NzY yMzUwNTMEoewkjhvzoKyRCGBdGCKz05NLUgtghnHxMEp1cCkUXDq8ppwhVV/9VreRiaHl/6q D/MpnFq7pkDh8V6Jszecu5790YhcYNsbabHpQ28h3033dT4pZiqzM/fb+ZvMD/sQdvbAwwPr 9/xJ+cCr8XWuwa9fFeenZUo7uJ4oXN4cZ2UmM7f87jOTVxbsIrNOn3mpHXj0x55PHk3Mcw+1 FcTrKCpIXC850zTPIYuja/mKcy8e32GbV3e94nJqi0OqLKvYEd624+yThDaH3apfuy8/+1GU qOOsqL6YPZs3qU7jM5hfvfYiu46MKts274SM/pXf2X99d76fMXv3aRm3e5GLpzdn/1sZvrjw yDadqGn/Q2qPiU+avNs42NHl/E2TXYfC5xVP7xDqOmHWNpFRiaU4I9FQi7moOBEAZSBhHlUE AAA= Archived-At: Subject: [ippm] R: Request for presentations at IETF 112 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, 25 Oct 2021 20:18:11 -0000 --_000_DBAPR07MB67755B3ADFE4BEE4C8C10179E9839DBAPR07MB6775eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TIM - Uso Interno - Tutti i diritti riservati. Hi Tommy and all. After the WG adoption of the draft on explicit measures we would ask for a s= lot for the draft "user-devices-explicit-monitoring" (https://www.ietf.org/a= rchive/id/draft-cnbf-ippm-user-devices-explicit-monitoring-03.txt) which pre= sents a new idea about the positioning of the probes for the same measuremen= ts. The placement of the probe on the user device offers, in addition to some pr= actical advantages, the possibility for the user to choose whether or not to= mark "his" own traffic (and if so, he could observe his own performances). Thanks. Mauro Cociglio _____________________ Mauro Cociglio TIM - Telecom Italia Via G. Reiss Romoli, 274 10148 - Torino (Italy) Tel.: +390112285028 Mobile: +393357669751 _____________________ Da: ippm Per conto di Tommy Pauly Inviato: venerd=EC 22 ottobre 2021 22:49 A: IETF IPPM WG (ippm@ietf.org) Oggetto: [EXT] [ippm] Request for presentations at IETF 112 Hi IPPM, At IETF 112, we'll have a two-hour session on Thursday, November 11 (https:/= /datatracker.ietf.org/meeting/112/agenda/). We'll mainly focus on adopted documents, but please do email the chairs or t= he list with requests for other topics / new work. Best, Tommy Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_DBAPR07MB67755B3ADFE4BEE4C8C10179E9839DBAPR07MB6775eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    TIM - Uso Interno= - Tutti i diritti riservati.

    Hi Tommy and all.

    After the WG adoption of the= draft on explicit measures we would ask for a slot for the draft “use= r-devices-explicit-monitoring” (https://www.ietf.org/ar= chive/id/draft-cnbf-ippm-user-devices-explicit-monitoring-03.txt) which presents a new idea about the positioning= of the probes for the same measurements.

    The placement of the probe on th= e user device offers, in addition to some practical advantages, the possibil= ity for the user to choose whether or not to mark "his" own traffi= c (and if so, he could observe his own performances).

    Thanks.

     

    Mauro Cociglio

     

    __________= ___________

    Mauro Coci= glio

    TIM –= ; Telecom Italia

    Via G. Rei= ss Romoli, 274

    10148 - To= rino (Italy)

    Tel.: +390= 112285028

    Mobile: +3= 93357669751

    __________= ___________

     

     

     

     

    Da: ippm <ippm-bounces@ietf.org> Per conto di Tommy Pauly
    Inviato: venerd=EC 22 ottobre 2021 22:49
    A: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Oggetto: [EXT] [ippm] Request for presentations at IETF 112

     

    Hi IPPM,

     

    At IETF 112, we’ll have a= two-hour session on Thursday, November 11 (https://datatracker= .ietf.org/meeting/112/agenda/).

     

    We’ll mainly focus on adop= ted documents, but please do email the chairs or the list with requests for= other topics / new work.

     

    Best,

    Tommy


    Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

    This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

    Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
    --_000_DBAPR07MB67755B3ADFE4BEE4C8C10179E9839DBAPR07MB6775eurp_-- From nobody Mon Oct 25 13:59:05 2021 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 560533A086D for ; Mon, 25 Oct 2021 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWQegHdP__c5 for ; Mon, 25 Oct 2021 13:58:59 -0700 (PDT) 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 E541F3A0821 for ; Mon, 25 Oct 2021 13:58:46 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 19PKw2Vm048832 for ; Mon, 25 Oct 2021 16:58:46 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 3bx433r0kr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 25 Oct 2021 16:58:45 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19PKwjXb006134 for ; Mon, 25 Oct 2021 16:58:45 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19PKwh0Z006096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 25 Oct 2021 16:58:43 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 2132B4005951 for ; Mon, 25 Oct 2021 20:58:43 +0000 (GMT) Received: from GAALPA1MSGED2BA.ITServices.sbc.com (unknown [135.50.89.126]) by zlp30486.vci.att.com (Service) with ESMTP id D1E794005950 for ; Mon, 25 Oct 2021 20:58:42 +0000 (GMT) Received: from GAALPA1MSGEX1BF.ITServices.sbc.com (135.50.89.107) by GAALPA1MSGED2BA.ITServices.sbc.com (135.50.89.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Mon, 25 Oct 2021 16:58:42 -0400 Received: from GAALPA1MSGETA03.tmg.ad.att.com (144.160.249.125) by GAALPA1MSGEX1BF.ITServices.sbc.com (135.50.89.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Mon, 25 Oct 2021 16:58:36 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.176) by edgeal3.exch.att.com (144.160.249.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Mon, 25 Oct 2021 16:58:05 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CyBTOdgna6fEB26Xy+cvvsRQe06KxMYoLw3KcaPcA8VHtglg2vO2jpXROrX8kv7dySidlO8aV+cOaoyd3RKzSxmYo8XImpGdxoiwpJfGJVLWjTtP1bJu7H85tSdxfylxSdyM/8HUy8jkyyIexlKRouc2TPwK/qH9wf0ssePpqZDTaEbyNzFWlTA9WiySu3AOzT/Qvry51B1VSsJjBpFKXcj6kZeuM36Ask6+oYio9G8RwIsJEfFijXNbh4TEKBqKQlBKs9mLsvcQfPSnt2E1xTrEaVt4Fi7XHwJwWaxUEi8aCsXsmJjEqWAQrHc7YN+ZODGSGa/Vx0c3PUzmteNYeA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ODmHwNzqj5HuTCfvykNCAUVMVjB9+Btcg+BJZC/3188=; b=MVLnMGoWf9dG1DZdSrhaDN3W2mA98MSJm55eHPGRVjlX9yc2igLKu5dZdt311IGstOxjPKNYwtcZ9DC3ito+FnmZ2IfGK6Bxbc0ykmhL7kRVV1xXKoKJrhUNsR0UVNA5uupq+aNVIHJrstYjpAVXNevYjz3IjfPhApulKEjywLZ8ArxlZnLUnJ+NvpFU4TcKX7JA5EnPuF5OZiaInwUG79R+xiZd77GyKCm7NzIwSsGjdmPqIFZorZ3lUN81ECYWjdA+/+b995gMSRyQeQRunDaJnBRUewmoMMj5aKTMEOhz2NVBr41kisFD4NANSsPFgz9dpDfNlDAvYVUjRlnFMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ODmHwNzqj5HuTCfvykNCAUVMVjB9+Btcg+BJZC/3188=; b=V6iHm/eb5E/bJQU6P+x1jTCqaxZ73dwDXNSCSyNtuYA4H3wlYXXC+dNGUMj+x1/8Z3kxPrxs89nffcVCmSD7eKSE3IdWSM3qbcF1NTyiY/d+LzMCLKj0ZhJjYMEFx08PzvDNtNbuUeCJwCch2gsbBv1ixVRybUQIgGMyLCE1Xro= Received: from SJ0PR02MB7853.namprd02.prod.outlook.com (2603:10b6:a03:32e::8) by BYAPR02MB4870.namprd02.prod.outlook.com (2603:10b6:a03:43::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.20; Mon, 25 Oct 2021 20:57:38 +0000 Received: from SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56]) by SJ0PR02MB7853.namprd02.prod.outlook.com ([fe80::49a5:79a:dfde:9b56%5]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 20:57:38 +0000 From: "MORTON JR., AL" To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-morton-ippm-capacity-metric-protocol-02.txt Thread-Index: AQHXyd6G4pmoGnXPnEat54YoJXEfzKvkKcCA Date: Mon, 25 Oct 2021 20:57:38 +0000 Message-ID: References: <163519352045.15139.8618393314159037686@ietfa.amsl.com> In-Reply-To: <163519352045.15139.8618393314159037686@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9571d99c-1e17-48dd-dc5f-08d997fa1412 x-ms-traffictypediagnostic: BYAPR02MB4870: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y55N6UxkWVisTNn6RI3A4stfzpiZILfWOgkBwK393KfIsObW44F3ojO8Ou4IjMP1Q1kE+1MOvvqBj+YIRbVuSy1CWgLfNjLvJqVOAyPV9KU091/TvkvQLRfBFWm3AfcAR911+sERg0nLc9kDEdaM38YGhxPRqgmXAVZdTR4bm3dcL77BWhkMCI7QQLSG68escYGZ3QtkAl+MUPU7s+n7wql9Ys9k32J9CbwkCzvq4xXzaC49JUwx1diZbDB8KauG0UvVkUneK7eNNn/X9vqf5DB4fM+mwL7Amjo+Np7ViKIqZG6gxoQPEil5wmNsdkOOzRJUoizan3wD4lBO7l5DJA0MZX8Td914HxFaV0NuVv4D7ZWKr3P0/bOSi+HRf/wqRnoruZzOWOOsk47HTqD/A2b68qX94G5Xogc8V2dAI3RIzzjHX2Xe5A1tdfTF0VUV9HU6RKvR0M4NXYeop6Jjh+SqTaDF4RmKYpF4sld7iIHEzowcQ5kgYqkHHX+vlXFcqKiMw7b1bFHHM07tLR/8zMxVxiHaKUQ+I+Rx/4Bjwg38qeyPRI9IH5WC8mHwhejGq+kDEi+z1RPMIwfYdMgORjPH5I7lezpzMKCVwN1yOBQsU16CN7zrFFBrWlqw7vD3gZRpbV9iPtxK85s4yJz96DQ2RRXxm88J1dre814JC0WBGuXLcx9W87i/or84YcwINJqA6UWsS74jkZBHUb7gkmRmTvbqX1Oz22jHlSWUUc+yJnevjgZq3KsHOCIDep+1KwWF9iDtMROPA6+lD5j+Xymdm7TeHDiWUV8mKsCPgv/VcsIXihgEhoOmt1QAlixm x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB7853.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(26005)(52536014)(82960400001)(5660300002)(55016002)(53546011)(186003)(7696005)(71200400001)(4326008)(9686003)(2906002)(966005)(8936002)(15650500001)(66946007)(64756008)(66446008)(82202003)(38070700005)(66574015)(83380400001)(8676002)(86362001)(6916009)(508600001)(4001150100001)(122000001)(33656002)(38100700002)(66476007)(66556008)(316002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OHh2a0VzcThwdUx3aElKQVl5TEREeFJaUlUza3pGaXBCdjY3dVJxcEhVM01p?= =?utf-8?B?K0U5NmRDbEY4bDFId2ZPcFQ2SzA2cmF1VkphanNJMFg5M0dCSkF6a3dTdEMv?= =?utf-8?B?a1Z4Nlo1UTBKNE9EOWpPcjFqaFFOYnhiTFJpWnZNOGIrem1TdERBclR4Wm5t?= =?utf-8?B?cVpQamZZc0p1aU5FWm5yZUllV2xLa0FEc0w0OFhjM2pCdWVRcHpWOEhVTUlv?= =?utf-8?B?TVU1T3l6TDNMdDNJM0dGbFhxdVRuV0ZaY1dFNTd1Wjk4RmVwMXZDLzA4eU14?= =?utf-8?B?SUFjTTBmZDR4NDliOGpCV2YyVm9lbXc3VjlxR3lDYW41NzNUTUxERmFvV1Vt?= =?utf-8?B?QVFWckdSUU1uQ1FRY2pzYjE5c2RyRzZiMnFkR3ZlZlVvaE0yNDQ2S3lCQ1JG?= =?utf-8?B?MmsxcUVtWVAxbXhwbEVhOUtRUWtTVlBiMFpFZGthV1lyUFJVd0p5REFWbGZV?= =?utf-8?B?Y3VVQ0xUSW8xUWRVcmhDaGkxK0JxNmYyVVhvMEUvYUJqNzBBL090QlZ3b0ly?= =?utf-8?B?akJqS0hJMVRtY1E0WGVGaXJORXZmNDBhUERsc1B1VGZxVkxlVWZFbnV4Z1R2?= =?utf-8?B?MG50QS84V2QwdVNINDBzVEFiQlRwREtIcWZpczNMeXh5Vm4vUzFOdGFORXFy?= =?utf-8?B?UW1aYkhZbmx3VTliZkQ4V3d1a24yMHU1eXc4Wkh3YXpDNkF3a203L09wUEtI?= =?utf-8?B?QkcvYmNNbnJYN091R3h5SWg5MnQzelAzUFJhOUd3UEY1SHppUExROU81VjEz?= =?utf-8?B?a3RvaXhOVVNpZmdpSFBRaERRaWtSZEZEbFcyM05lc1NIdzY5ckQzaFR0VXdo?= =?utf-8?B?d2NnZ2pjeW96bkFINXJnRGt2UE9nQWExS2t6dEFNMUUxYkRXRDF2Ump0UTBE?= =?utf-8?B?Mll4cGIvR0RsbVZtZERRY1JwSGIxZS9wZ0VkdmJ6RUFCR0xlVkk0SzVPZDhE?= =?utf-8?B?ZXRMRWI4b01RUTRsNE5JaWRsOGJYTmdhOUx5U2tFM2F5bmJUSURjZVJXcW5w?= =?utf-8?B?UHh6cjlDSThjRnFZOTBlQkdmeFJ4T0xaRXdvbXVnV29LQkV4OVFWRGx5c24r?= =?utf-8?B?WXhYT3BtTTg3aUUxUEtYb3RFVFFLQ3RIYUJBUStyT3czaGdWNzh2eVltQm9l?= =?utf-8?B?MjluZlYzY0w5Zjh1bm03YS9jWnRoZVJVd3pFa3VIOWhCeTJ3VE91Q3lZWW9G?= =?utf-8?B?VmluZkJReUJid295eHY3WEVoVHdReGQyWElTbU1NbHg2NElKbFlFK3ZWUXBJ?= =?utf-8?B?a2lOYStVMDh6dXlXL3lSNE1PQkdXamF4d3lPU2FIeGJPQjAzRnlFa3cva0Zw?= =?utf-8?B?a2FIRm9zUWRWUE1nTTBxdkNJNHp0NFl0cHpCOUYyZEV2K3gzZGxpTmpKVnps?= =?utf-8?B?VStpUzZuRzl5alVFT1BwaUFHb1EwZFVZV2M0UG1UYzU5NmVJZzJROXJabU83?= =?utf-8?B?ZDBSWEV5UFZoZjVaSVlwRGRpbWs3R2ZmZWFHVEhGdU1KYnlDMW11WWs3ZWNG?= =?utf-8?B?OGs0NGx0S0h2bEoxZ2xJd010bEduR0hHS2RKV0xqdlMydTZzNnhJZm1pYzRy?= =?utf-8?B?bTcyUzVwbDdzL3c0V2dBS2tEd1YwNzB1ZTdGL0NiTWpQZVhJeDVoNEIrbE9n?= =?utf-8?B?ZEp1czlLYlQ4RUNURzhIWGdvTUUzLzFSYmFmYm5zL3VkVEowYTlsRUVVa0hy?= =?utf-8?B?ZjcvYk0xWjR1L2ZNTkRuaDBVejJ6TmVTTkxuN1VnUkIvS1Q3eExSVGtkWG5I?= =?utf-8?B?d3VTcjdoSzU3NlVzb09CSTNiMkRobi82L0x6WGdJTUZqT0RLZU5JZVZWTXhL?= =?utf-8?B?dEZDZkw0MUo2bWt4ZU5ZNktXWUMwcFVweFhWTUJSTFd3bHV1WG5JOFNORGZk?= =?utf-8?B?SjArd2JSb1ZxNTR2K3VMRFIwSytaUFd2TDhiZGd4S2VnWWlSbm9uSFREUksw?= =?utf-8?B?ZXNYaXBieG9neTN3UTh3Y0VsQlI0aHFVYkQwVStwR2JFOERraDFtRTdHRlZH?= =?utf-8?B?MVdMYVlQZTV3U3ZpTS9nY2JZakpmd3B1dnZtNTg1Vk0waG0yWDk4dXlDNEJM?= =?utf-8?B?Q0xvSXphN3BSQ0FUV01aUHpsSlZubXhmd0VaUT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7853.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9571d99c-1e17-48dd-dc5f-08d997fa1412 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 20:57:38.3476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SV4C4riyItXTKKgPTYgCuFCGveEb5g+Pa1No2WlvK6jhf60t+tOLwrM8rjkRMeT+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4870 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 430F60D6D9B38A8D4BBA608C9FEC7EE05E4D2983F01D9B030E5170EC0619AD1C2 X-Proofpoint-ORIG-GUID: jHiyhAt57kglafOd0kc1md-moO-WtCvO X-Proofpoint-GUID: jHiyhAt57kglafOd0kc1md-moO-WtCvO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-25_07,2021-10-25_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 mlxscore=0 phishscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110250120 Archived-At: Subject: [ippm] FW: New Version Notification for draft-morton-ippm-capacity-metric-protocol-02.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: Mon, 25 Oct 2021 20:59:04 -0000 SGkgSVBQTSwNCg0KVGhhbmtzIHRvIGNvbW1lbnRzIGFuZCBtYW55IGdvb2Qgc3VnZ2VzdGlvbnMg ZnJvbToNCiANCkxpbmNvbG4gTGF2b2llLCANCkNhbiBEZXNlbSosIA0KUsO8ZGlnZXIgR2VpYiwg YW5kIA0KR3JlZyBNaXJza3kqKiwgDQoNCndlIGhhdmUgcHVibGlzaGVkIHRoZSAwMiB2ZXJzaW9u IG9mIHRoZSBjYXBhY2l0eSBtZWFzdXJlbWVudCBwcm90b2NvbC4gIFdlIGFyZSBjb250aW51aW5n IHRvIHN0cml2ZSBmb3IgcHJvdG9jb2wgc2ltcGxpY2l0eSB3aGlsZSB3ZSBzdXBwbHkgcmljaCBt ZWFzdXJlbWVudHMgb2YgSVAtTGF5ZXIgQ2FwYWNpdHksIExhdGVuY3ksIFJlb3JkZXJpbmcsIGFu ZCBSZXBsaWNhdGlvbjogYWxsIGluIG9uZSBtZWFzdXJlbWVudCBzdHJlYW0gYW5kIHJlc3VsdHMg ZmVlZGJhY2sgc3lzdGVtLiANCg0KSW4gZnV0dXJlIHZlcnNpb25zLCB3ZSB3aWxsIGRlc2NyaWJl IG5ldyBmZWF0dXJlcyBvZiB0aGUgcHJvdG9jb2wgdG8gYWRkcmVzcyB0aGUgb3BlbiBpc3N1ZXMg dGhhdCBjYW4gYmUgZWFzaWx5IGxvY2F0ZWQgYnkgc2VhcmNoaW5nIGZvciB0aGUgIkBAQEAiIHN0 cmluZyBpbiB0aGUgZHJhZnQuIFRoZXJlIGFyZSA2IG9mIHRoZXNlIG9wZW4gaXNzdWVzIHRoYXQg d2Ugd291bGQgbGlrZSB0byBkaXNjdXNzIGZ1cnRoZXIgKGFsdGhvdWdoIEkgdGhpbmsgb25lIG9m IHRoZSBpc3N1ZXMgY2FuIGJlIGNsb3NlZCkuDQoNCldlIGxvb2sgZm9yd2FyZCB0byBmdXJ0aGVy IHJldmlldyBhbmQgZGlzY3Vzc2lvbnMsIG9uLWxpc3QgYW5kIGF0IHRoZSBtZWV0aW5ncyENCg0K VGhlIEludGVybmV0LURyYWZ0IGFubm91bmNlbWVudCBpcyBiZWxvdy4NCg0KTWFueSB0aGFua3Ms DQpBbCBhbmQgTGVuDQoNCiogQ2FuIHByb25vdW5jZXMgaGlzIGZpcnN0IG5hbWUgIkphbiIsIHdp dGggYSBoYXJkICJKIiBhcyBpbiAiamFtIi4gDQoNCioqIEdyZWcsIEkgaGFkIGEgZmV3IG1pbnV0 ZXMgdG8gYmVnaW4gdG8gdGhpbmsgYWJvdXQgeW91ciBjb21tZW50IG9uIFJGQyA4OTcyIChTVEFN UCBvcHRpb25hbCBleHRlbnNpb25zKSBiZWZvcmUgc3VibWlzc2lvbiAtIGFkZGluZyBhIGJpdCBt b3JlIGluIHRoZSBpbnRybywgYnV0IG5lZWQgdG8gaW52ZXN0aWdhdGUgZnVydGhlci4gDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAy NSwgMjAyMSA0OjI1IFBNDQo+IFRvOiBBbCBNb3J0b24gPGFjbUByZXNlYXJjaC5hdHQuY29tPjsg Q0lBVkFUVE9ORSwgTEVOIDxsYzk4OTJAYXR0LmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtDQo+IHBy b3RvY29sLTAyLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tb3J0 b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtMDIudHh0DQo+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQWwgTW9ydG9uIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYg cmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRy aWMtcHJvdG9jb2wNCj4gUmV2aXNpb246CTAyDQo+IFRpdGxlOgkJVGVzdCBQcm90b2NvbCBmb3Ig T25lLXdheSBJUCBDYXBhY2l0eSBNZWFzdXJlbWVudA0KPiBEb2N1bWVudCBkYXRlOgkyMDIxLTEw LTI1DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMzANCj4gVVJM Og0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJj aGl2ZS9pZC9kcmFmdC1tb3J0b24taXBwbS1jYXBhY2l0eS1tZXRyaWMtcHJvdG9jb2wtDQo+IDAy LnR4dF9fOyEhQmhkVCF6RjNXUTNNN0RSZE1kMlVzWGRCU1BVa3gwbjRrZDI4UFlaMTZMYXhCdElN d1BfWVB6dkhiNnVrUTFWRFV4Rw0KPiBNJA0KDQpTdGF0dXM6DQo+IGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb3J0b24t DQo+IGlwcG0tY2FwYWNpdHktbWV0cmljLQ0KPiBwcm90b2NvbC9fXzshIUJoZFQhekYzV1EzTTdE UmRNZDJVc1hkQlNQVWt4MG40a2QyOFBZWjE2TGF4QnRJTXdQX1lQenZIYjZ1a1F3NFcNCj4gc081 QSQNCj4gSHRtbGl6ZWQ6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1vcnRvbi1pcHBtLWNhcGFjaXR5LW1l dHJpYy1wcm90b2NvbF9fOyEhQmhkVCF6RjNXUTNNN0RSZE1kMlVzWGRCU1BVa3gwbjRrZDI4UFla MTZMYXhCdElNd1BfWVB6dkhiNnVrUVhUU0IzNEkkDQo+IERpZmY6DQo+IGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbW9y dG9uLWlwcG0tY2FwYWNpdHktbWV0cmljLXByb3RvY29sLTAyX187ISFCaGRUIXpGM1dRM003RFJk TWQyVXNYZEJTUFVreDBuNGtkMjhQWVoxNkxheEJ0SU13UF9ZUHp2SGI2dWtRdFZrdmNtOCQNCj4g DQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIG1lbW8gYWRkcmVzc2VzIHRoZSBwcm9ibGVtIG9mIHBy b3RvY29sIHN1cHBvcnQgZm9yIG1lYXN1cmluZw0KPiAgICBOZXR3b3JrIENhcGFjaXR5IG1ldHJp Y3MgaW4gUkZDIHh4eHg6IGRyYWZ0LWlldGYtaXBwbS1jYXBhY2l0eS0NCj4gICAgbWV0cmljLW1l dGhvZCwgd2hlcmUgdGhlIG1ldGhvZCBkZXBsb3lzIGEgZmVlZGJhY2sgY2hhbm5lbCBmcm9tIHRo ZQ0KPiAgICByZWNlaXZlciB0byBjb250cm9sIHRoZSBzZW5kZXIncyB0cmFuc21pc3Npb24gcmF0 ZSBpbiBuZWFyLXJlYWwtdGltZS4NCj4gICAgSXQgc3VwcGxpZXMgYSBzaW1wbGUgcHJvdG9jb2wg dG8gcGVyZm9ybSB0aGUgbWVhc3VyZW1lbnRzLg0KPiANCj4gICAgU2VlIFNlY3Rpb24gMTA6IFRo ZSBhdXRob3JzIHNlZWsgZmVlZGJhY2sgdG8gZGV0ZXJtaW5lIHdoYXQNCj4gICAgYWRkaXRpb25h bCBmZWF0dXJlcyB3aWxsIGJlIG5lY2Vzc2FyeSBmb3IgYW4gSUVURiBTdGFuZGFyZHMgVHJhY2sN Cj4gICAgUHJvdG9jb2wsIGJleW9uZCB3aGF0IGlzIHByZXNlbnQgaW4gdGhlIHJ1bm5pbmcgY29k ZSBhdmFpbGFibGUgbm93Lg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cj4gDQoNCg== From nobody Wed Oct 27 09:32:02 2021 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 16E4E3A0BF9 for ; Wed, 27 Oct 2021 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 5IaX4bvpIEeP for ; Wed, 27 Oct 2021 09:31:56 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.rno.apple.com [17.179.253.33]) (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 642AD3A0BF3 for ; Wed, 27 Oct 2021 09:31:56 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19RGRYkI008824 for ; Wed, 27 Oct 2021 09:31:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=AEdI/AdT2C3OEIgdRG9cTVryGYuHnSwRTmG7J00eRT4=; b=O+EiE3cjEmBrxhXtDdMg5jhFNmN1+ADCsGIt92nReBN0cjMUUHG38PzNTGk35KLjJQqK rX+KGbnS7VSI/PuE4RrRIY4ZoNzF+QUAJ7D4XD8IlMMk+5me7tIUUwdhxieQ0mnTXOpm cwE2eWqqB/mr83AHat6+A/L3BQF8hwZ6srE1H7DBDewbN0zjTISNJUTXh8MeQFh8rP8F 6TXoaTZng3aaYezhAb0qzkYI5EwAlWJjGJ9La6a82rHnlPoY6rms6MtRrRsyYg2h6RMX rcUwm6OjE1/hu2GGQtLE8uz85AS1XaZWDsLPUj2RkaFeKg2/InNeIA1ZICvzYAn89yEb qA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3bx4efx8j1-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 27 Oct 2021 09:31:56 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1N00U3X9X75XK0@rn-mailsvcp-mta-lapp02.rno.apple.com> for ippm@ietf.org; Wed, 27 Oct 2021 09:31:55 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1N00V009JJM000@rn-mailsvcp-mmp-lapp03.rno.apple.com> for ippm@ietf.org; Wed, 27 Oct 2021 09:31:55 -0700 (PDT) X-Va-A: X-Va-T-CD: de279c0840622e930446fe69a11c94de X-Va-E-CD: 78a19cf0e2ea71e8d6ce1460fa61c8bf X-Va-R-CD: 6f0ad4a33eff139adc8fdb4347c3bf62 X-Va-CD: 0 X-Va-ID: a50fc73f-d127-4213-9954-aa6e16ab1b5c X-V-A: X-V-T-CD: de279c0840622e930446fe69a11c94de X-V-E-CD: 78a19cf0e2ea71e8d6ce1460fa61c8bf X-V-R-CD: 6f0ad4a33eff139adc8fdb4347c3bf62 X-V-CD: 0 X-V-ID: 0ea002a7-8350-4c9a-8e7a-5f8253d1506f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-27_04:2021-10-26, 2021-10-27 signatures=0 Received: from smtpclient.apple (unknown [17.230.169.122]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1N00WE99X6TD00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for ippm@ietf.org; Wed, 27 Oct 2021 09:31:55 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_1D3F88D8-717F-4686-9A59-89404313C3C3" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Message-id: Date: Wed, 27 Oct 2021 09:31:54 -0700 To: "IETF IPPM WG (ippm@ietf.org)" X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-27_05:2021-10-26, 2021-10-27 signatures=0 Archived-At: Subject: [ippm] IETF 112 Agenda 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, 27 Oct 2021 16:32:01 -0000 --Apple-Mail=_1D3F88D8-717F-4686-9A59-89404313C3C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello IPPM, We=E2=80=99ve posted our initial agenda for IPPM=E2=80=99s meeting at = IETF 112: = https://datatracker.ietf.org/meeting/112/materials/agenda-112-ippm-00.html= = If you=E2=80=99re a document author, please check the agenda for your = slot. We=E2=80=99d like slides uploaded by Tuesday, November 9. You can = upload those as PDF documents here: = https://datatracker.ietf.org/meeting/112/session/ippm = . Note that you = need to sign into Datatracker to upload. We=E2=80=99ll spend the first hour+ on adopted documents, followed by 30 = minutes on proposed work that has received recent list discussion. For the remainder of the talks, we=E2=80=99re trying out a new variant = of lightning talks (which we switched to be =E2=80=9Celevator pitches=E2=80= =9D in the agenda). We=E2=80=99d like each draft being presented to be = limited to a single slide that summarizes the document and pitches to = the group why it=E2=80=99s something people might be interested in also = working on. We don=E2=80=99t want detailed explanations of the drafts, = but conversation starters that can engage the group. Best, Tommy, Marcus, & Ian= --Apple-Mail=_1D3F88D8-717F-4686-9A59-89404313C3C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= IPPM,

    We=E2=80=99ve = posted our initial agenda for IPPM=E2=80=99s meeting at IETF = 112:

    https://datatracker.ietf.org/meeting/112/materials/agenda-112-i= ppm-00.html

    If you=E2=80=99re a document author, please check the agenda = for your slot. We=E2=80=99d like slides uploaded by Tuesday, November 9. = You can upload those as PDF documents = here: https://datatracker.ietf.org/meeting/112/session/ippm. = Note that you need to sign into Datatracker to upload.

    We=E2=80=99ll spend the = first hour+ on adopted documents, followed by 30 minutes on proposed = work that has received recent list discussion.

    For the remainder of the talks, we=E2=80=99= re trying out a new variant of lightning talks (which we switched to be = =E2=80=9Celevator pitches=E2=80=9D in the agenda). We=E2=80=99d like = each draft being presented to be limited to a single slide that = summarizes the document and pitches to the group why it=E2=80=99s = something people might be interested in also working on. We don=E2=80=99t = want detailed explanations of the drafts, but conversation starters that = can engage the group.

    Best,
    Tommy, Marcus, & = Ian
    = --Apple-Mail=_1D3F88D8-717F-4686-9A59-89404313C3C3--