From nobody Mon May 2 09:32:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3D12D586 for ; Mon, 2 May 2016 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9yJM6B8dFyH for ; Mon, 2 May 2016 09:31:57 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98A612D581 for ; Mon, 2 May 2016 09:31:56 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id r184so76889090qkc.1 for ; Mon, 02 May 2016 09:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=x/D6urV9ZXBi3theapQl5muwQy3zf5Gn6lJZZirU02c=; b=UVxrK46P5M0FIoMqpdBkbkZ7zSME3+M0b48b3OlX0WKu7belMntHAQOJyGBZ6R26/g CZmbTyRGM/N0sRPWg9uvxsmd5fJAJ50IjNvSOnQUg3yHD4T5Tih6uMBycnjyCTYEedi+ 4pk+YG0qNoVRCyfpVjmONRjINNH9rYcfTIQNzeBKrSJM+qdI0FT4emZUIdULkPio+EkI jk9d04RNLxOQWGd9K95gYRuUHsPjEBE/UmPhbE9oGBUYh/diWsQMoOaAYBYirrWKv6B9 me2bllw6BB+wmLWg3M0rdcOwBDMjaZgcdxRDT2NI3irJVadTRGOn3kefsNJ+kgUi06uZ 99rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x/D6urV9ZXBi3theapQl5muwQy3zf5Gn6lJZZirU02c=; b=VnXufXNoLeZ73meQ18ysIeZHLtaxhuoatGS7gBI/IJskPDHSQC756+lYpMK+6GQMyT YwxGGAaxZUPy5OLoBPEOAJpnK1J99+QyrQJakLWV+nLqmei/PsMlp1ZrosqmI4xgMOs6 bHPIh76DFzRUjg1rZc4NlBsYDQkTWYI3inTOaaPdoR+ItctHQdEPSC6tKw2VwetTl1vh vMtsbPIbdvNbalGIXLzzYcQwWYis6+ywavlR8EyF5V5w/Qyh+tpjiYq3GMadtj3Bl+VC JCXvJRn2QG0cDRBTx70Bx+F1kNMpmTmsSXLuGDvdgAS+wLXd65W+v2keAyCADqF7Ivjb 1QUg== X-Gm-Message-State: AOPr4FVOTB+0HcTVCgAf+3Y6zVMPf2w4d99b0sNfWrTJaQLRjgcrmYdAunZbFM0bUq5PKOBI1/YGN7pF/tLNDZhr X-Received: by 10.55.168.195 with SMTP id r186mr35129244qke.24.1462206715563; Mon, 02 May 2016 09:31:55 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 02 May 2016 16:31:46 +0000 Message-ID: To: IETF Security Directorate , draft-ietf-aqm-pie.all@ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a114d3280df16710531de87c6 Archived-At: Subject: [secdir] SecDir review of draft-ietf-aqm-pie X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:31:59 -0000 --001a114d3280df16710531de87c6 Content-Type: text/plain; charset=UTF-8 Be ye not afraid... I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-aqm-pie-06 - PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Summary: LGTM, Security AD attention not required. Details: No major issues, some nits. Feel free to integrate or ignore. Notes: >5 authors. Many of the authors are experienced, so they probably already know the RFC Ed might make sad face at you. Comments in [O]riginal, [P]roposed, [R]eason. Abstract Bufferbloat is a phenomenon where excess buffers in the network cause [O] phenomenon where excess [P] phenomenon in which excess [R] grammar high latency and jitter. As more and more interactive applications [SNIP] There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. [O] jitter; and hence [P] jitter, and hence [R] grammar [SNIP] The design does not require per-packet timestamp, so it incurs very small overhead and is [O] require per-packet timestamp, [P] require per-packet timestamps, [R] grammar [O] incurs very small overhead [P] incurs very little overhead [R] word choice 1. Introduction The explosion of smart phones, tablets and video traffic in the Internet brings about a unique set of challenges for congestion control. To avoid packet drops, many service providers or data center operators require vendors to put in as much buffer as possible. With rapid decrease in memory chip prices, these requests are easily [O] With rapid decrease in memory chip price, [P] Because of the rapid decrease in memory chip prices, accommodated to keep customers happy. While this solution succeeds in assuring low packet loss and high TCP throughput, it suffers from a major downside. The TCP protocol continuously increases its sending rate and causes network buffers to fill up. TCP cuts its rate only when it receives a packet drop or mark that is interpreted as a congestion signal. However, drops and marks usually occur when network buffers are full or almost full. As a result, excess buffers, initially designed to avoid packet drops, would lead to highly elevated queueing latency and jitter. It is a delicate balancing act to design a queue management scheme that not only allows short-term burst to smoothly pass, but also controls the average latency in the presence of long-running greedy flows. [O] It is a delicate balancing act to design a queue management scheme that not only allows short-term burst to smoothly pass, but also controls the average latency in the presence of long-running greedy flows. [P] Designing a queue management scheme that allows short-term bursts to pass smoothly as well as controlling the average latency in the presence of long-running greedy flows is a delicate balancing act. [R] readability [SNIP] New algorithms are beginning to emerge to control queueing latency directly to address the bufferbloat problem [CoDel]. Along these lines, PIE also aims to keep the benefits of RED: such as easy [O] the benefits of RED: such as easy [P] the benefits of RED, including easy [R] readability and grammar implementation and scalability to high speeds. Similar to RED, PIE randomly drops an incoming packet at the onset of the congestion. The congestion detection, however, is based on the queueing latency instead of the queue length like RED. [SNIP] In October 2013, CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandated that cable modems implement a specific variant of the PIE design as the active queue management algorithm. In addition to cable specific improvements, the PIE design in DOCSIS 3.1 [DOCSIS-PIE] has improved the original design in several areas, including de- randomization of coin tosses and enhanced burst protection. This draft separates the PIE design into the basic elements that are MUST to be implemented and optional SHOULD/MAY enhancement elements. [O] that are MUST to be implemented [R] This is awkward, but maybe should be left as is? Or delete "are"? 4. The Basic PIE Scheme As illustrated in Fig. 1, PIE conceptually comprises three simple MUST [O] PIE conceptually comprises three simple [P] PIE is comprised of three simple [R] I think this is what is meant -- PIE is made of three MUST components, not PIE makes those three components? components: a) random dropping at enqueueing; b) periodic drop probability update; c) latency calculation. [SNIP] 5.2 Departure Rate Estimation One way to calculate latency is to obtain the departure rate. The draining rate of a queue in the network often varies either because other queues are sharing the same link, or the link capacity fluctuates. [O] because other queues are sharing the same link, or the link capacity fluctuates. [P] because other queues are sharing the link or because the link capacity fluctuates. [R] clarity 9. Security Considerations This document describes an active queue management algorithm based on implementations in Cisco products. This algorithm introduces no specific security exposures. 10. IANA Considerations There are no actions for IANA. -- END -- --001a114d3280df16710531de87c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Be= =C2=A0ye=C2=A0not=C2=A0afraid...
I ha= ve reviewed this document as part of the security directorate's<= br style=3D"color:rgb(33,33,33);font-size:13px">ongoing effort to review all IETF documents being p= rocessed by the
IESG.=C2=A0 These comments w= ere written primarily for the benefit of the
security area directors.=C2=A0 Document editors and WG chairs should treat=
these comments just like any other last cal= l comments.

Version reviewed:=C2=A0= draft-ietf-aqm-pie-06=C2=A0-=C2=A0PIE: A Lightweight Control Scheme To Ad= dress the
Bufferbloat Problem

Summary:
LGTM, Security AD attention= =C2=A0not<= span style=3D"color:rgb(33,33,33);font-size:13px">=C2=A0required.

Details:
No major issues, some nits. Feel free to i= ntegrate or ignore.

Notes:=C2=A0
>5 auth= ors. Many of the authors are=C2=A0experienced, so they probably already kno= w the RFC Ed might make sad face at you.

Comments in [O]riginal, [P]roposed, [R]eason.<= /div>


Abstract

B= ufferbloat is a phenomenon where excess buffers in the network cause
<= div>[O] phenomenon where excess
[P] phenomenon in which excess
[R] grammar
high latency and jitter. As more and more int= eractive applications

[SN= IP]=C2=A0

There is a pressing need to design
intelligent queue management schemes that can control laten= cy and
jitter; and hence provide desirable quality of service to = users.
[O] jitter; and hence
[P] jitter, and hence
[R] grammar

[SNIP]=C2=A0
The design does not
require per-packet tim= estamp, so it incurs very small overhead and is
[O] require per-p= acket timestamp,
[P] require per-packet timestamps,
[R]= grammar
[O] incurs very small overhead
[P] incurs very= little overhead
[R] word choice



1. Introduction

The explosi= on of smart phones, tablets and video traffic in the
Internet bri= ngs about a unique set of challenges for congestion
control. To a= void packet drops, many service providers or data center
operator= s require vendors to put in as much buffer as possible. With
rapi= d decrease in memory chip prices, these requests are easily
[O] W= ith rapid decrease in memory chip price,
[P] Because of the rapid= decrease in memory chip prices,
accommodated to keep customers h= appy. While this solution succeeds in
assuring low packet loss an= d high TCP throughput, it suffers from a
major downside. The TCP = protocol continuously increases its sending
rate and causes netwo= rk buffers to fill up. TCP cuts its rate only
when it receives a = packet drop or mark that is interpreted as a
congestion signal. H= owever, drops and marks usually occur when
network buffers are fu= ll or almost full. As a result, excess buffers,
initially designe= d to avoid packet drops, would lead to highly
elevated queueing l= atency and jitter. It is a delicate balancing act
to design a que= ue management scheme that not only allows short-term
burst to smo= othly pass, but also controls the average latency in the
presence= of long-running greedy flows.
[O] It is a delicate balancing act= to design a queue management scheme that not only allows short-term burst = to smoothly pass, but also controls the average latency in the presence of = long-running greedy flows.
[P] Designing a queue management schem= e that allows short-term bursts to pass smoothly as well as controlling the= average latency in the presence of long-running greedy flows is a delicate= balancing act.
[R] readability

[SNIP]=C2=A0

New algorithms a= re beginning to emerge to control queueing latency
directly to ad= dress the bufferbloat problem [CoDel]. Along these
lines, PIE als= o aims to keep the benefits of RED: such as easy
[O] the benefits= of RED: such as easy
[P] the benefits of RED, including easy
[R] readability and grammar
implementation and scalability= to high speeds. Similar to RED, PIE
randomly drops an incoming p= acket at the onset of the congestion. The
congestion detection, h= owever, is based on the queueing latency
instead of the queue len= gth like RED.=C2=A0

[SNIP= ]=C2=A0

In October 2013, CableLabs' DOCSIS= 3.1 specification [DOCSIS_3.1]
mandated that cable modems implem= ent a specific variant of the PIE
design as the active queue mana= gement algorithm. In addition to cable
specific improvements, the= PIE design in DOCSIS 3.1 [DOCSIS-PIE] has
improved the original = design in several areas, including de-
randomization of coin toss= es and enhanced burst protection.

This draft separ= ates the PIE design into the basic elements that are
MUST to be i= mplemented and optional SHOULD/MAY enhancement elements.
[O] that= are MUST to be implemented
[R] This is awkward, but maybe should= be left as is? Or delete "are"?



4. The Basic PIE Scheme

As = illustrated in Fig. 1, PIE conceptually comprises three simple MUST
[O] PIE conceptually comprises three simple
[P] PIE is compris= ed of three simple
[R] I think this is what is meant -- PIE is ma= de of three MUST components, not PIE makes those three components?

components: a) random dropping at enqueueing; b) periodic = drop
probability update; c) latency calculation.=C2=A0

[SNIP]=C2=A0


5.2 Departure Rate Estimation

One way to ca= lculate latency is to obtain the departure rate. The
draining rat= e of a queue in the network often varies either because
other que= ues are sharing the same link, or the link capacity fluctuates.
[= O] because other queues are sharing the same link, or the link capacity flu= ctuates.
[P] because other queues are sharing the link or because= the link capacity fluctuates.
[R] clarity



9. Security Considerations

<= /div>
This document describes an active queue management algorithm base= d
on implementations in Cisco products. This algorithm introduces= no
specific security exposures.


10. IANA Considerations

There are no actio= ns for IANA.


-- END --
--001a114d3280df16710531de87c6-- From nobody Mon May 2 15:27:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1CF12D64A; Mon, 2 May 2016 15:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqWUZnHzJXaT; Mon, 2 May 2016 15:26:59 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.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 1C56812D191; Mon, 2 May 2016 15:26:58 -0700 (PDT) X-AuditID: 12074422-913ff7000000760a-82-5727d4310f12 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 28.EC.30218.134D7275; Mon, 2 May 2016 18:26:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u42MQvnN008011; Mon, 2 May 2016 18:26:57 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u42MQtFa016856; Mon, 2 May 2016 18:26:56 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netconf-yang-library.all@ietf.org Date: Mon, 02 May 2016 18:26:55 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixG6nomt4RT3c4M8xK4v223+YLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGX8Xn+TveAsc8WJhumsDYxfmboYOTkkBEwk Fl2/x9zFyMUhJNDGJPFjxzZWCGcDo8SMuS0sEM5rRom/GyezgLSwCUhLHL+8C6xdRCBSYt3H nawgtrCAvcS7+W8YQWwWAVWJlxeWMIPYvAK6EjNmPAPr5RHglPg09Qo7RFxQ4uTMJ2BxZgEt iRv/XjJNYOSZhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJNjOCQ cVHawTjxn9chRgEORiUeXo90tXAh1sSy4srcQ4ySHExKorxxK9XDhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwXjoDlONNSaysSi3Kh0lJc7AoifMGRR4LExJITyxJzU5NLUgtgsnKcHAoSfD+ vwTUKFiUmp5akZaZU4KQZuLgBBnOAzR8CUgNb3FBYm5xZjpE/hSjLseCH7fXMgmx5OXnpUqJ 854FKRIAKcoozYObA451IcZ9rxjFgd4S5r0IUsUDTBNwk14BLWECWpK9XhVkSUkiQkqqgbFR 7ORT51kr4t4yTZ4tPjt7v07+a+btFf7GNR28dRM+eC+3FRfRcxV5YqH8PDXDe1X155RLGctz W0pWtProP9/tuNpt9n/d8m/K1brrWb/ts+4RbO68wH06myt+WefabKnbBQFhnAuCLlab35U1 d59TLq3Eve5LZr35fZ2cVX/sLQKirsx+osRSnJFoqMVcVJwIAOjsOArQAgAA Archived-At: Subject: [secdir] secdir re-review of draft-ietf-netconf-yang-library-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:27:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready The current revision of this document adequately addresses the comments I made during a prior review. From nobody Mon May 2 20:52:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCC712D531; Mon, 2 May 2016 20:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAJV1jLMBjv3; Mon, 2 May 2016 20:51:59 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 E631512B018; Mon, 2 May 2016 20:51:58 -0700 (PDT) X-AuditID: 1209190d-fefff700000076cb-9d-5728205dfabd Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3C.24.30411.D5028275; Mon, 2 May 2016 23:51:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u433pvOJ025265; Mon, 2 May 2016 23:51:57 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u433pt9v011767; Mon, 2 May 2016 23:51:56 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-drmp.all@ietf.org Date: Mon, 02 May 2016 23:51:55 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixCmqrRuroBFusGuVgcX/ba9YLWb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGX8aNvCXLCMraKp9zNjA+NE1i5GTg4JAROJ Y3vfs3UxcnEICbQxSbx5/IcZwtnAKPG46wlU5jWjxPOH/UwgLWwC0hLHL+8Csjk4RARcJQ6+ VwMJCwsYSjTfb2UHsVkEVCUOdi5nBrF5BXQlOhvWMYLYPAKcEr/+TmCDiAtKnJz5hAXEZhbQ krjx7yXTBEaeWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgO GEneHYz/7nodYhTgYFTi4V3wQD1ciDWxrLgy9xCjJAeTkiivxF2gEF9SfkplRmJxRnxRaU5q 8SFGCQ5mJRHeY3wa4UK8KYmVValF+TApaQ4WJXHemJtHw4QE0hNLUrNTUwtSi2CyMhwcShK8 x+WAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGXwCp4S0uSMwtzkyHyJ9i1OVY8OP2WiYhlrz8vFQp cd5bIEUCIEUZpXlwc8CRLsS47xWjONBbwrxx8kBVPMAkATfpFdASJqAl2etVQZaUJCKkpBoY L9dxPl9cnXaaLSdoR4PI7SWJf/p4n9Y+85BZplLi3ie7PH52kWT4bx2xie0x0/Q4G8x4P8dE lCYv0Hj5ZPFPEc5TpfK8MyQmFee8tNCSst91IPjvxvrVRiw+cUxvZQ4dVNRf8HjW1v1M6ivv NwgX19jMaH7wbMucmU9rclpDXOxX/VXnS2BXYinOSDTUYi4qTgQAudol7s8CAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-dime-drmp-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:52:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits The security considerations section of this document seems substantial. I approve of including a treatment of the lack of end-to-end security in the protocol. This is a topic to which authors of other documents should pay more attention. Editorial: Page headers say "DOIC" instead of something like "DRMP"; is this intentional? Section 11.3 title "End-to End-Security Issues" should probably be "End-to-End Security Issues". From nobody Tue May 3 23:17:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086DF12B042 for ; Tue, 3 May 2016 23:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvsVckOJUV8i for ; Tue, 3 May 2016 23:16:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 29BF212B065 for ; Tue, 3 May 2016 23:16:48 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u446GjC4003645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 May 2016 06:16:46 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u446GjhX011787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 06:16:45 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u446GiEE017684; Wed, 4 May 2016 06:16:45 GMT Received: from [10.159.77.32] (/10.159.77.32) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 May 2016 23:16:44 -0700 References: <56908353.5050200@oracle.com> To: secdir@ietf.org From: Shawn M Emery X-Forwarded-Message-Id: <56908353.5050200@oracle.com> Message-ID: <5729944D.4040403@oracle.com> Date: Wed, 4 May 2016 00:18:53 -0600 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56908353.5050200@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: draft-ietf-bfd-seamless-base.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-bfd-seamless-base-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 06:17:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a version of Bidirectional Forwarding Detection (BFD) that allows for better efficiencies in provisioning and path monitoring of network node infrastructure. The security considerations section does exist and asserts that the security considerations that pertains to the base BFD protocol, RFC 5880, also applies to this protocol. The section continues with guidance on authenticating data, replay, and DoS avoidance, specific to this protocol. I agree with most of the recommendations outlined and assertions presented in this section. 5880 is forthcoming with the various vulnerabilities/limitations of the base protocol. However, the draft does not cover the case where an attacker impersonates the SBFDInitiator, but does cover the SBFDReflector scenario. General comments: None. Editorial comments: s/Once above setup/Once the above setup/ s/it can quickly/can quickly/ s/and IS-IS will advertises/and IS-IS advertises/ s/then response S-BFD/then a response S-BFD/ s/allocated a same/allocated the same/ s/Remainder of this/The remainder of this/ s/for above suggestions/for the suggestions above/ s/that discriminator/that the discriminator/ s/for a same/for the same/ s/is to have following/has the following/ ... I stopped after this. Please have someone review the rest of the draft for grammar. It will be hard to read w/o these updates. Shawn. -- From nobody Wed May 4 01:42:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25712D09C; Wed, 4 May 2016 01:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] 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 i2jGtVdJp1ox; Wed, 4 May 2016 01:42:46 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id A143712B00A; Wed, 4 May 2016 01:42:44 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC6B4E30081; Wed, 4 May 2016 10:42:43 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 68AC8E3007F; Wed, 4 May 2016 10:42:43 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 4 May 2016 10:42:43 +0200 To: Donald Eastlake , "iesg@ietf.org" , References: From: Thomas Morin Organization: Orange Message-ID: <5729B602.2040004@orange.com> Date: Wed, 4 May 2016 10:42:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000401080700080505030005" Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 08:42:48 -0000 --------------000401080700080505030005 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Donald, 2016-04-27, Donald Eastlake: > > The feature specified in this document is aimed at limiting one type > of denial of service, or at least at interference to some users by > others: denial or interference due to excessive control plane traffic > due to a high rate of multicast group membership change. Still, it > makes me a bit queasy that the document has not one word, even by > reference, about security for the setting or changing of the > parameters used at a node in the damping algorithm. The document does not introduce a new way of controlling parameters on a router; so in this regard it does not introduces a new security issue. But of course, I agree letting an attacker control configuration can lead to much havoc ; again, nothing specific to these specs. > I suppose it is reasonable that it doesn't talk about how any of the > control messages involved are protected or authenticated since the > document is just about suppressing such messages... Yes, precisely. > The Security Considerations section has a reasonable discussion of how > and to what extent the mechanisms specified provide the services claimed. > > Page 15, Section 9 (Security Considerations), 1st paragraph starting > on this page: There are a number of things wrong with the following > sentence: > > Note well that the two > mechanism may interact: state for which Prune has been requested may > still remain taken into account for some time if damping has been > triggered and hence result in otherwise acceptable new state from > being successfully created. > I would guess it should be "result in preventing otherwise" or should > end with "state not being successfully created". Here is a suggested > replacement: > > The two mechanisms may interact as follows: if damping has > been triggered, state for which Prune has been requested may remain > and still be taken into account for some timeresulting in an > otherwise acceptable new state notbeing created. Your replacement text is much better, and will be incorporated in next revision. Thanks. > *Editorial:* > > This document is very heavy with acronymic jargon with no expansion or > definition in this document. However, most of it is defined in other > RFCs that are referenced. > > Although I am willing to accept that it is just a matter of style, > this document has lots of extra words that add nothing but verbosity. > Things that could be completely dropped with no loss, like starting a > sentence with "Additionally, it is worth nothing that ...". If it > wasn't worth noting, it presumably wouldn't be in the document. Your style suggestions are appreciated. In some cases, I'd keep the original formulation (see below), but I'd take your suggestions in others. > > Page 4, Section 3, 3rd paragraph: "...this technique will allow to > meet the goals..." -> "...this technique will meet the goals..." > Ok. > Page 12, Section 7.2: "More specifically it is RECOMMENDED to > complement the existing ... (e.g. MRIB states): ..." -> "Complementing > the existing ... (e.g. MRIB states) is RECOMMENDED: ..." > Done. > Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean? Corrected already based on OPS review. That should be 'dimensioning'. > Also "...state churn to go beyond what..." -> "...state churn going > beyond what..." Ok. > > Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not > capitalized, this word sounds quite mandatory to me but it is not used > in a mandatory requirement context... I suggest "shall rely upon" -> > "relies on". > Ok. > Page 15, near the top: "should rely upon already" -> "should use already" Ok. > Finally, while I understand that others have a different opinion, I > find it objectionable that not a single first page author is willing > to list a telephone number of any sort in the Authors' Addresses > section. To my mind, this sort of corner cutting does not speak well > for the document. I'm honestly surprised that someone finds these phone numbers in IETF specs ! If someone wants to contacts authors of a spec, he's much more likely to succeed with email, not only because it can talk to all of them at the same time. I have a reasonable filter on my email for spam/commercial sollicitations, but not on my phone lines; this is a strong obstacle to providing phone numbers in the wild. Emails can also be slightly more stable than phone numbers. Last, if voice can end up being useful for some exchange, I think it is likely that time will have to be coordinated in advance via email -- the actual phone number to use can be provided at this time, and may end up being the more convenient phone number among a few possible ones, a confcall bridge or a login on video chat system... So we aren't "cutting corners". I think it simply reflects the reality that this is an obsolete practice. In fact, I would suggest removing the postal address as well. Thanks for your comments, -Thomas --------------000401080700080505030005 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Donald,

2016-04-27, Donald Eastlake:

The feature specified in this document is aimed at limiting one type of denial of service, or at least at interference to some users by others: denial or interference due to excessive control plane traffic due to a high rate of multicast group membership change. Still, it makes me a bit queasy that the document has not one word, even by reference, about security for the setting or changing of the parameters used at a node in the damping algorithm.

The document does not introduce a new way of controlling parameters on a router; so in this regard it does not introduces a new security issue.
But of course, I agree letting an attacker control configuration can lead to much havoc ; again, nothing specific to these specs.

I suppose it is reasonable that it doesn't talk about how any of the control messages involved are protected or authenticated since the document is just about suppressing such messages...

Yes, precisely.


The Security Considerations section has a reasonable discussion of how and to what extent the mechanisms specified provide the services claimed.

Page 15, Section 9 (Security Considerations), 1st paragraph starting on this page: There are a number of things wrong with the following sentence:

          Note well that the two
   mechanism may interact: state for which Prune has been requested may
   still remain taken into account for some time if damping has been
   triggered and hence result in otherwise acceptable new state from
   being successfully created.

          

          
I would guess it should be "result in preventing
            otherwise" or should end with "state not being successfully
            created". Here is a suggested replacement:

          


          

          

            
          The two mechanisms may interact as follows: if damping has

            
   been triggered, state for which Prune has been requested may remain

            
   and still be taken into account for some time resulting in an

            
   otherwise acceptable new state not being created.

          

        

      

    

    

    Your replacement text is much better, and will be incorporated in
    next revision.

    Thanks.

    

    

    

      
Editorial:
        

          


            This document is very heavy with acronymic jargon with no
            expansion or definition in this document. However, most of
            it is defined in other RFCs that are referenced.

        

        


        

        
Although I am willing to accept that it is just a matter of
          style, this document has lots of extra words that add nothing
          but verbosity. Things that could be completely dropped with no
          loss, like starting a sentence with "Additionally, it is worth
          nothing that ...". If it wasn't worth noting, it presumably
          wouldn't be in the document.

      

    

    

    Your style suggestions are appreciated. 

    In some cases, I'd keep the original formulation (see below), but
    I'd take your suggestions in others.

    

    

      

        


        

        
Page 4, Section 3, 3rd paragraph: "...this technique will
          allow to meet the goals..." -> "...this technique will meet
          the goals..."

        


        

      

    

    

    Ok.

    

    

    

      

        
Page 12, Section 7.2: "More specifically it is RECOMMENDED
          to complement the existing ... (e.g. MRIB states): ..." ->
          "Complementing the existing ... (e.g. MRIB states) is
          RECOMMENDED: ..."

        


        

      

    

    

    Done.

    

    

    

      

        
Page 13, Section 7.3, 2nd paragraph: What does
          "dimentioning" mean? 

      

    

    

    Corrected already based on OPS review.  That should be
    'dimensioning'.

    

    

      

        
Also "...state churn to go beyond what..." -> "...state
          churn going beyond what..."

      

    

    

    Ok.

    

    

    

      

        


        

        
Page 14, Section 9, 3rd paragraph: The word "shall" is
          used. While not capitalized, this word sounds quite mandatory
          to me but it is not used in a mandatory requirement context...
          I suggest "shall rely upon" -> "relies on".

        


        

      

    

    

    Ok.

    

    

      

        
Page 15, near the top: "should rely upon already" ->
          "should use already"

        

      

    

    

    Ok.

    

    

    

      

        
Finally, while I understand that others have a different
          opinion, I find it objectionable that not a single first page
          author is willing to list a telephone number of any sort in
          the Authors' Addresses section. To my mind, this sort of
          corner cutting does not speak well for the document.

      

    

    

    I'm honestly surprised that someone finds these phone numbers in
    IETF specs !

    

    If someone wants to contacts authors of a spec, he's much more
    likely to succeed with email, not only because it can talk to all of
    them at the same time.

    I have a reasonable filter on my email for spam/commercial
    sollicitations, but not on my phone lines; this is a strong obstacle
    to providing phone numbers in the wild.

    Emails can also be slightly more stable than phone numbers. 

    Last, if voice can end up being useful for some exchange, I think it
    is likely that time will have to be coordinated in advance via email
    -- the actual phone number to use can be provided at this time, and
    may end up being the more convenient phone number among a few
    possible ones, a confcall bridge or a login on video chat system...

    

    So we aren't "cutting corners".

    I think it simply reflects the reality that this is an obsolete
    practice.

    In fact, I would suggest removing the postal address as well.

    

    Thanks for your comments,

    

    -Thomas

    

  


--------------000401080700080505030005--


From nobody Wed May  4 10:28:10 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0391D12D72A for ; Wed,  4 May 2016 10:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prss2LUpU9jl for ; Wed,  4 May 2016 10:28:07 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C65412D77B for ; Wed,  4 May 2016 10:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3569; q=dns/txt; s=iport; t=1462382887; x=1463592487; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dI/5Dw2DnFy3a9UplUyhGFMWSuqbXG+xP88HkQalNsA=; b=c1pWC7eA43eMxlxaquLUv80I0DGBwwojIl6xpdvxuf/DiZ20/+EN7W3q pVUtsrTml6gS5BcaIyXCkGs6pZyDt0qJCheCQTybDq6pTrg1GcgKUhbrO IQS+D3YeGcJeFtOf+RXJCm6UZFndYtEIlh2As232S6ed81xrs1IinIMJC M=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAgAJMCpX/4MNJK1egziBUAa5Yw6Bd?= =?us-ascii?q?oYQAoE3OBQBAQEBAQEBZSeEQQEBAQMBeQULAgEIGC4yJQIEDgUOiBQIvUwBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQENCIYggXaCV4dqgi4FmBkBgyeBZ4kJgWiETYMph?= =?us-ascii?q?TWPMwEeAUODa2yHPX8BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,578,1454976000";  d="asc'?scan'208";a="103693177"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 17:28:06 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u44HS5YX011619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 17:28:06 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 13:28:05 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 4 May 2016 13:28:05 -0400
From: "Carlos Pignataro (cpignata)" 
To: Shawn M Emery 
Thread-Topic: Review of draft-ietf-bfd-seamless-base-09
Thread-Index: AQHRpcyaOBkyOQUqSUukdtw7hgg2c5+pTBUA
Date: Wed, 4 May 2016 17:28:05 +0000
Message-ID: <66BCC017-7C31-4B98-AA00-BFA19F72505E@cisco.com>
References: <56908353.5050200@oracle.com> <5729944D.4040403@oracle.com>
In-Reply-To: <5729944D.4040403@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.49.250]
Content-Type: multipart/signed; boundary="Apple-Mail=_AED0665B-1D64-45B0-AD9D-9F814B47B2CA"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-bfd-seamless-base.all@tools.ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] Review of draft-ietf-bfd-seamless-base-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 04 May 2016 17:28:09 -0000

--Apple-Mail=_AED0665B-1D64-45B0-AD9D-9F814B47B2CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thanks Shawn for taking the time to read and review, and catching all =
those Editorials as part of the SecDir Review.

All fixed, =97 I am sure the RFC Editor will fix all the remaining ones, =
and the ones you might have missed.

=97 Carlos.

> On May 4, 2016, at 2:18 AM, Shawn M Emery  =
wrote:
>=20
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the =
IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>=20
> This draft specifies a version of Bidirectional Forwarding Detection =
(BFD) that
> allows for better efficiencies in provisioning and path monitoring of =
network
> node infrastructure.
>=20
> The security considerations section does exist and asserts that the =
security
> considerations that pertains to the base BFD protocol, RFC 5880, also =
applies
> to this protocol.  The section continues with guidance on =
authenticating data,
> replay, and DoS avoidance, specific to this protocol.  I agree with =
most of the
> recommendations outlined and assertions presented in this section.  =
5880 is
> forthcoming with the various vulnerabilities/limitations of the base =
protocol.
> However, the draft does not cover the case where an attacker =
impersonates the
> SBFDInitiator, but does cover the SBFDReflector scenario.
>=20
> General comments:
>=20
> None.
>=20
> Editorial comments:
>=20
> s/Once above setup/Once the above setup/
> s/it can quickly/can quickly/
> s/and IS-IS will advertises/and IS-IS advertises/
> s/then response S-BFD/then a response S-BFD/
> s/allocated a same/allocated the same/
> s/Remainder of this/The remainder of this/
> s/for above suggestions/for the suggestions above/
> s/that discriminator/that the discriminator/
> s/for a same/for the same/
> s/is to have following/has the following/
> ... I stopped after this.  Please have someone review the rest of the =
draft for
> grammar.  It will be hard to read w/o these updates.
>=20
> Shawn.
> --
>=20


--Apple-Mail=_AED0665B-1D64-45B0-AD9D-9F814B47B2CA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBCAAGBQJXKjEkAAoJEIXgpQGOZny9z0EQAKq6ruR6nHKztmsG/XpJoin2
bQZXNKEUyh0aFErYCDxym4J83LtpV3mYCXscuka9osBLYfHwO+dhdI0PDR/tj198
4Tr45OInLW+bWZdbBV+JkJdKK63+WPjVIlDJige97nydE8L1BuoHim57IrNKkffr
y3JgWdUciZYxk5+yyhg9PbfYo3qAYPdfsJT0SXqnn9cDBHn2ZYuAkWyXrRTMpXfA
zNMk1hggcGZQEWLUu6nbAbn/HM3QcveJ3/VGovwHXJPeS5eO/2jLUq0ukGkyR6l+
wCyOceqLpJilTarT2P99Z+f56ee9wXewB8UnTbV5u/MNaUBni207d1fcvV8eYeAl
dokSsXdL3k6XrDRO2p+a3vNQKdsMbEoxJNiUe4TYaFRj5YEkZ2lqOfBDEGL/cYWV
UzzWigshJZRNW3mIndh0CFlSZ9Skog+DW564sVHZy/FCzGPUIlNo0p7UisqV5PiX
18UUHNz3f60AWtcm/+t+EcVl6WVRRmO5d8RLaovHxqBnII7P4+xa+r0SX1ye/8uh
GGcFxh1hxoNFo26cl0pOryrQAOr7FYeHP5N0wPgw4vsGIoeU2877qEkh6/jCcZNZ
knxQIFEAsTJbPSRmaTyExg8NevMpKhF5EGTii9VPUb/KD2tI/grZ2HczWOCyMuy3
zid+je318evz7EGvCqYc
=xH4l
-----END PGP SIGNATURE-----

--Apple-Mail=_AED0665B-1D64-45B0-AD9D-9F814B47B2CA--


From nobody Thu May  5 00:24:37 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D69412B03B; Thu,  5 May 2016 00:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_isuExteTDn; Thu,  5 May 2016 00:24:31 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8406F12D10E; Thu,  5 May 2016 00:24:28 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id n129so9145179wmn.1; Thu, 05 May 2016 00:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=xf+4OfetbAPrKWQ6zVKUsGG+RRvjgw9B+fLUA4juyHo=; b=JUsJOt8cWA8SIVUSrxu+a3axOFX1S1JZ2+dKPQT3TMwVMPoJRhk7JSrhUYxd2Vfs5B hYoPayH2MhRGQeyovIGEkH1PXRMGowOCIJ5pWaBSri0KVyR33Na5HIRJhSVUsseyBxuB IcqkGdczSh21mZAvEFQNmYB49A/rVwXRaW3J3H+5rJ4svadTkOZNXol51IaeIvDg+nMM OjXkM1n7ed1ohKqvJ7WvtMqVa0d0WVpeQcIMKQet08rTbYhpHe57VHH92DHF0WnoCIam geCLQ2YKq1VIGenylL1QSJxwKrrPKgZMZWe7bsXlcVIkI5hCFBuB+5R5608TuRSp6DMX hs5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=xf+4OfetbAPrKWQ6zVKUsGG+RRvjgw9B+fLUA4juyHo=; b=D64Ktcq3p/1fLzhgA+741fEOCv2ga+hHP6/11KE9FQWLczmRtRDLgBJIqdPGMHeyai J1KQI2Vm7w+eEwcDu3eU4mvsSOVW2t+ZfmaYIozo+gur0iRl44TB8KN4P34kqJVd7qV/ 5t9SZMer1EameS/+nt5ChDCI4c2jCKg6XSQHYUnWUkF5TE0GsWAlarvE8xSNoTmKRB1s VJyvxiC2fGjRdAc8yDQWxSTm85Q2iSkz/hI5vPqN9lsFc7+yxs3lBTOXay53Etb1Ic36 MLxdpYQA5qMCiAvd6hHzcXktSI/Sy7ie/dMe8RTv0Uk2rSuJNxT8uTn92s/Ton29qt+4 xSnQ==
X-Gm-Message-State: AOPr4FWqfztE/FAIQaEEN7jbE9oK8nZbYihZnGg2Qtl37Q4tpln5VmEMhXcqwocIZsTdOQ==
X-Received: by 10.28.211.136 with SMTP id k130mr1654083wmg.81.1462433067048; Thu, 05 May 2016 00:24:27 -0700 (PDT)
Received: from [192.168.4.111] ([199.203.248.154]) by smtp.gmail.com with ESMTPSA id cf6sm8237730wjc.12.2016.05.05.00.24.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 May 2016 00:24:26 -0700 (PDT)
From: Yoav Nir 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Thu, 5 May 2016 10:24:24 +0300
To: secdir , The IESG , draft-ietf-rtgwg-bgp-routing-large-dc.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 May 2016 07:24:33 -0000

Hi.

I have reviewed this document as part of the security directorate's  =
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the =
security area directors.  Document editors and WG chairs should treat  =
these comments just like any other last call comments.

Summary: Almost Ready

This document is an Informational discussion of packet routing within =
data centers. It describes existing practice with using layer-2 =
protocols such as STP or TRILL, hybrid setups, and layer-3 routing =
protocols, mostly IGPs. It finally recommends replacing these with EBGP =
and a Clos structure. The document is very clear and quite an =
interesting read.

The document does not deal with security questions such as what kind of =
damage a rogue node can do, and that is fine. That is not the subject of =
this document.=20

My one issue is with the Security Considerations section. Section 9 =
defers to the BGP RFCs (4271 and 4272) for the security considerations. =
This is a common pattern and it's usually fine, but in this case it is =
missing something. RFC 4271 requires the use of TCP-MD5 (RFC 2385) for =
authenticating the BGP connections between routers. RFC 4271 also =
mentions (but does not solve) the problem of key management. ISTM that =
in a large-scale and dynamically scalable data center, the problem of =
key management should be addressed. It might also be nice to use =
something less antiquated than TCP-MD5.=20

Now it's possible to decide that all elements within the data center are =
trusted and under the administrator's control, and that therefore no =
authentication is necessary as long as BGP is somehow blocked from =
outside the DC to internal nodes. But if these assumptions exist, I =
believe they should be stated.

Yoav=


From nobody Thu May  5 07:59:08 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD46D12DB42 for ; Thu,  5 May 2016 07:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 BDJWQwemzdBu for ; Thu,  5 May 2016 07:59:03 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 5099812DBF5 for ; Thu,  5 May 2016 07:52:22 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u45EqHFJ022913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 May 2016 17:52:17 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u45EqHxh004113; Thu, 5 May 2016 17:52:17 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22315.24097.510389.326004@fireball.acr.fi>
Date: Thu, 5 May 2016 17:52:17 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 May 2016 14:59:06 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Rich Salz is next in the rotation.

For telechat 2016-05-05

Reviewer                 LC end     Draft
Daniel Kahn Gillmor    T 2016-04-12 draft-ietf-bfd-seamless-ip-04
Chris Inacio           T 2016-04-26 draft-ietf-ospf-sbfd-discriminator-04
Ben Laurie             T 2016-04-29 draft-ietf-idr-add-paths-13
Matthew Miller         T 2016-04-15 draft-ietf-sidr-as-migration-05
Eric Osterweil         T 2016-01-05 draft-campbell-art-rfc5727-update-03
Yaron Sheffer          T 2016-03-09 draft-ietf-v6ops-host-addr-availability-06
Dacheng Zhang          T 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04


For telechat 2016-05-19

Sandy Murphy           T 2016-05-12 draft-ietf-netmod-rfc6020bis-11
Magnus Nystrom         T 2016-05-09 draft-ietf-sidr-rpsl-sig-10


For telechat 2016-06-02

Vincent Roca           T 2016-05-16 draft-ietf-manet-rfc6779bis-05

Last calls and special requests:

Alan DeKok               2016-04-30 draft-bradner-rfc3979bis-08
Daniel Kahn Gillmor    E 2016-02-01 draft-ietf-rtcweb-security-08
Hilarie Orman            2016-05-10 draft-ietf-teas-interconnected-te-info-exchange-04
Eric Osterweil           2016-05-26 draft-hardie-rfc6455-iana-clarification-
Radia Perlman            2016-05-12 draft-ietf-dime-e2e-sec-req-04
Hannes Tschofenig        2015-12-28 draft-ietf-hip-rfc5204-bis-07
Hannes Tschofenig      E None       draft-ietf-ntp-network-time-security-13
Hannes Tschofenig      E None       draft-ietf-ntp-cms-for-nts-message-06
Hannes Tschofenig      E None       draft-ietf-ntp-using-nts-for-ntp-04
Brian Weis             E 2016-02-01 draft-ietf-cdni-uri-signing-07
-- 
kivinen@iki.fi


From nobody Thu May  5 21:57:29 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1C12D0A6; Thu,  5 May 2016 21:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mckm49n6XCic; Thu,  5 May 2016 21:57:21 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF512B04E; Thu,  5 May 2016 21:57:21 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 507) id 786A3540B7D; Fri,  6 May 2016 00:57:20 -0400 (EDT)
Date: Fri, 6 May 2016 00:57:20 -0400
From: Jon Mitchell 
To: Yoav Nir 
Message-ID: <20160506045719.GA17263@puck.nether.net>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: draft-ietf-rtgwg-bgp-routing-large-dc.all@ietf.org, The IESG , secdir 
Subject: Re: [secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 May 2016 04:57:23 -0000

On 05/05/16 10:24 +0300, Yoav Nir wrote:

> The document does not deal with security questions such as what kind of damage a rogue node can do, and that is fine. That is not the subject of this document. 

Ack, and agreed.

> 
> My one issue is with the Security Considerations section. Section 9 defers to the BGP RFCs (4271 and 4272) for the security considerations. This is a common pattern and it's usually fine, but in this case it is missing something. RFC 4271 requires the use of TCP-MD5 (RFC 2385) for authenticating the BGP connections between routers. RFC 4271 also mentions (but does not solve) the problem of key management. ISTM that in a large-scale and dynamically scalable data center, the problem of key management should be addressed. It might also be nice to use something less antiquated than TCP-MD5. 

Since this a document describing what is possible to do in a real
design, I will try to avoid talking about something less antiquated than
TCP-MD5 since such things do not exist widely in implementations.  :-)

> 
> Now it's possible to decide that all elements within the data center are trusted and under the administrator's control, and that therefore no authentication is necessary as long as BGP is somehow blocked from outside the DC to internal nodes. But if these assumptions exist, I believe they should be stated.

Agreed and this is the reality of the matter.  We will update the
section to mention that MD5 may not be practical given key management
issues and that perimeter controls (ACLs) may be a more feasible option
in the design.  Expect a revision shortly (may wait a bit for AD/other
directorate feedback).

Thanks,

Jon


From nobody Sun May  8 23:49:09 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C55112B05F; Sun,  8 May 2016 23:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 mUaJiiZD7EZW; Sun,  8 May 2016 23:49:07 -0700 (PDT)
Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3CF12B024; Sun,  8 May 2016 23:49:07 -0700 (PDT)
Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1azf06-0000vf-3S; Mon, 09 May 2016 00:49:06 -0600
Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1azf04-0005hf-PL; Mon, 09 May 2016 00:49:05 -0600
Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u496lRM8032183; Mon, 9 May 2016 00:47:27 -0600
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u496lR3i032182; Mon, 9 May 2016 00:47:27 -0600
Date: Mon, 9 May 2016 00:47:27 -0600
Message-Id: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
From: "Hilarie Orman" 
To: iesg@ietf.org, secdir@ietf.org
X-XM-AID: U2FsdGVkX19qaJhu+Q53lhkDoYxuEQWv
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country: 
X-Spam-Timing: total 897 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 5 (0.6%), b_tie_ro: 3.7 (0.4%), parse: 1.18 (0.1%), extract_message_metadata: 6 (0.7%), get_uri_detail_list: 2.9 (0.3%), tests_pri_-1000: 3.7 (0.4%), tests_pri_-950: 1.69 (0.2%), tests_pri_-900: 0.96 (0.1%), tests_pri_-400: 28 (3.1%), check_bayes: 26 (2.9%), b_tokenize: 6 (0.7%), b_tok_get_all: 9 (1.0%), b_comp_prob: 3.5 (0.4%), b_tok_touch_all: 4.0 (0.4%), b_finish: 0.96 (0.1%), tests_pri_0: 842 (93.9%), check_dkim_signature: 0.45 (0.1%), check_dkim_adsp: 442 (49.2%), tests_pri_500: 5 (0.6%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: 
Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org
Subject: [secdir] Security review of draft-ietf-teas-interconnected-te-info-exchange-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Hilarie Orman 
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 May 2016 06:49:09 -0000

Problem Statement and Architecture for Information Exchange
Between Interconnected Traffic Engineered Networks
draft-ietf-teas-interconnected-te-info-exchange-05.txt

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

The document includes the problem statement:
    A mechanism is required that allows TE-path computation in one
    domain to make informed choices about the TE-capabilities and exit
    points from the domain when signaling an end-to-end TE path that
    will extend across multiple domains. [TE is "traffic engineering".]

The document describes, in general terms, the need for exchanging
information about reachability between domains without revealing
the totality of routing information.  To this end, the document
anticipates the use of abstracted reachability information.  The
information suggests that a path might exist, but it is not a
guarantee of reachability.

The numerous examples definitely motivate the need for exchange of
"meta routing information" (my term), but my concern is about the
privacy of the information.  In fact, one reason for using abstracted
information may be to obscure the details because they are sensitive:

In section 3.2 "Confidentiality", 

   ... an operator of a domain may desire to keep confidential the
   details about its internal network topology and loading.  This
   information could be construed as commercially sensitive.

also 4.1.1

   While abstraction uses available TE information, it is subject to
   policy and management choices.  Thus, not all potential
   connectivity will be advertised to each client.  The filters may
   depend on commercial relationships, the risk of disclosing
   confidential information, and concerns about what use is made of
   the connectivity that is offered.

>From a security viewpoint, I wonder if the architecture should have
sensitivity labels for abstracted reachability information.  Although
one domain may be willing to share some partly redacted reachability
information with another domain with which it has a limited trust
relationship, the first domain might want the second domain to
refrain from disclosing that information to other domains.  Perhaps
the first domain might offer two records with different abstraction
levels, and the most abstracted one would be "shareable" while the
lesser abstraction would be "private."

I found the notion of situational address interpretation
disconcerting.  In "4.5.  Addressing Considerations", we learn that
"one address may mean one thing in the client network, yet the same
address may have a different meaning in the abstraction layer network
or the server network" and "human operators may well become confused."
Should addresses have labels that define the domain of interpretation?

The notion of some kind of anticipatory information being generated
and dispersed to neighboring networks was confusing.  Section 4.3
"Considerations for Dynamic Abstraction" discusses "fluidity".  The
second sentence is an impenetrable run-on word sequence.  However, it
is followed by something that is asserted to be more significant ---
it is apparently "stability".  Some wordsmithing for clarification
would be helpful.

Nits
----
1.1.9.  Abstraction Layer Network
   ... networks and one or more client network (should be networks)

3.2, last sentence
"understanding that less information that is made available the more"
should be "that the less ..."

3.5, last sentence
 "Thus, while the data shared in reduced," should be "is reduced"

Hilarie


From nobody Sun May  8 23:55:36 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC6812B024; Sun,  8 May 2016 23:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkJJpOJudyfA; Sun,  8 May 2016 23:55:31 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 C4C4312B04E; Sun,  8 May 2016 23:55:31 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id x201so200405367oif.3; Sun, 08 May 2016 23:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=KyM45i+Eb2FSm5XtRJuZWpGXRyY0Lr465kpByBAvI2w=; b=CadWH41nxrj712chemp1NSZYxpSRTe0wsGEKbKzj1iMmzq9D2YgZdI4TZWgOhIQLB1 qPX2s8Qdo1iOmpD8LXebRsLUG8rw9squYYB6OaClr4B1aRw0BmoBog3WYlJVQTbx8szX RMF28kcq0xOIs+A8sD7Ho2078JJdC19n7yk6KqywZESSAD1FUyVIknOugPrY2u5GaaKk y+WS0vgMnhSFlMYkJayEulW9LVHVJN6Fy9O89ZBnQe438tpXQt5madf2Z+b9O58+n7wW +U8ACWaPk1D2AAW+al6w+7K5SKp7mZX2pD8EcnI2BcpK4RAgPiqOunWkua6K9oMYhYX0 v65Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=KyM45i+Eb2FSm5XtRJuZWpGXRyY0Lr465kpByBAvI2w=; b=gHrEn+X3YEtXWOurTtLy6P4JCzLimne4cv2anwj7+JIAeElo2oog3TFpg/vh9CA6D2 v2yzbGXSS8AxBnZJD547E8ENE4O/hXyu9aKbvBvPtIUUmdwyl7QHE0Pylw8XDja8PVQH 3GDhvlaAfWkrGkX25sTujqaPco2wSpRI+L6212w7oPwumb7GNGl+KGdBCIx5kI9pAlOV AUN9+iNf8+PgE2O1Cx2q2qfNvyCN7p6sNLNOES6H9by9cq5OluYSKtXy7EF9ueONDjeB 1QV6oe2gEdLdagd1Coa4Q2RBF08Wwg2U0nu8+WhhpZz0ILNC7SB1cRYkCHhDslY36/DT 4DYQ==
X-Gm-Message-State: AOPr4FUCLlXoVyirZDlBjTmH9H4TKO6QRvO3jmGybPTX5Sq+gnvnRXVb6o8envDHC8DexbkZAGkkgJ8k870w1g==
MIME-Version: 1.0
X-Received: by 10.157.18.143 with SMTP id g15mr13813097otg.125.1462776931121;  Sun, 08 May 2016 23:55:31 -0700 (PDT)
Received: by 10.202.108.137 with HTTP; Sun, 8 May 2016 23:55:31 -0700 (PDT)
Date: Sun, 8 May 2016 23:55:31 -0700
Message-ID: 
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= 
To: "secdir@ietf.org" , draft-ietf-sidr-rpsl-sig.all@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c03cec45d806e0532634b22
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 May 2016 06:55:34 -0000

--94eb2c03cec45d806e0532634b22
Content-Type: text/plain; charset=UTF-8

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes a mechanism for digitally signing Routing Policy
Specification Language (RPSL) objects. The digital signatures are intended
to ensure authenticity and integrity protection of such objects when they
are transferred to and from resource databases.

- The signature scheme is a little unusual in that the signature attribute
lists the names of the attributes that are part of the signature rather
than just including those attributes (and their values) as part of the
signature attribute itself; I assume this is due to a need to preserve
established RPSL object syntax but it doesn't seem required for this
application which essentially is a transport format. The cost here is, of
course, the need to duplicate the names of the signed attributes in the
signed RPSL object (once for the regular attribute value and once for the
value in the signature attribute).
- There is an expectation that relying parties fetch the signer's
certificate based on a URL in the signature attribute. This may be a
dangerous practice, since the URL needs to be contacted before the
signature can be validated. A malicious party may insert a URL that will
lead to an attack. I suggest this be noted in the Security Considerations
section with some suggested best practice, e.g., only https and careful
parsing of the retrieved resource.
- The Signature Method field - how are new algorithms identified? Is there
no need for protocol action / IANA action to register new algorithm for use
with this memo?
-- As for the canonicalization, this is an inherently complicated field. It
does not, for example, seem as if the memo describes how to canonicalize
multi-valued attributes. The ordering of such values may well be
implementation-dependent post object parsing and thus, the canonicalization
should cover how to order sets or sequences of values.
- The last paragraph of the Security Considerations brings up an important
point but provides no guidance to an implementer how to handle this case /
detect the situation. Preferably some advice should be given here.

Editorial / questions:

Section 1:
- "This means when downloading a Routing Policy Specification Language
(RPSL) object stored in this database, one can reasonably safely claim that
the object is authentic, but for an imported object one cannot." Two
points: First part of sentence likely misses a "that." Secondly, what's
referred to with "this" database?
- "A maintainer of such signed database objects MUST possess a relevant
resource certificate, which shows him/her as the legitimate holder of an
Internet number resource." Why does a maintainer of objects need to possess
a resource certificate? I think the party generating signed database
objects need such a certificate, but not necessarily all maintainers?

Section 2:
- "When verifying the signature of an object, the verifier has to check
whether the signature itself is valid, and whether all the specified
attributes are referenced in the signature." What "specified" attributes?
- It would be very helpful with a full example, not just an outline as in
2.3.
- Section 2.4 talks about multiple signatures. I believe this is the only
place where this is done, and it is also confusing given that earlier text
stated that each attribute (and the signature is an attribute too), must be
present "at most once"?

Section 5:
- The certificate shouldn't be used for more than one verification - was
the intent to say that the private key associated with the public key
present in the certificate shouldn't be used to sign more than one RPSL
object? It seems difficult to state that a certificate can be used for
verification only once - multiple relying parties may verify it, for
example (note: I am not too familiar with RFC 6487 so may be missing
something here).

-- Magnus

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


I have reviewed this document a=
s part of the security directorate's ongoing effort to review all IETF =
documents being processed by the IESG. These comments were written primaril=
y for the benefit of the

security area directors. Document editors and WG chairs should treat these =
comments just like any other last call comments.

This document describes a mechanism for digitally signing Rou=
ting Policy Specification Language (RPSL) objects. The digital signatures a=
re intended to ensure authenticity and integrity protection of such objects=
 when they are transferred to and from resource databases.

- The signature scheme is a little unusual in that =
the signature attribute lists the names of the attributes that are part of =
the signature rather than just including those attributes (and their values=
) as part of the signature attribute itself; I assume this is due to a need=
 to preserve established RPSL object syntax but it doesn't seem require=
d for this application which essentially is a transport format. The cost he=
re is, of course, the need to duplicate the names of the signed attributes =
in the signed RPSL object (once for the regular attribute value and once fo=
r the value in the signature attribute).
- There is an expectation that relying parties fetch the signer's cer=
tificate based on a URL in the signature attribute. This may be a dangerous=
 practice, since the URL needs to be contacted before the signature can be =
validated. A malicious party may insert a URL that will lead to an attack. =
I suggest this be noted in the Security Considerations section with some su=
ggested best practice, e.g., only https and careful parsing of the retrieve=
d resource.
- The Signature Method fiel=
d - how are new algorithms identified? Is there no need for protocol action=
 / IANA action to register new algorithm for use with this memo?
<=
div class=3D"gmail_extra">-- As for the canonicalization, this is an inhere=
ntly complicated field. It does not, for example, seem as if the memo descr=
ibes how to canonicalize multi-valued attributes. The ordering of such valu=
es may well be implementation-dependent post object parsing and thus, the c=
anonicalization should cover how to order sets or sequences of values.
<=
/div>
- The last paragraph of the Security Consid=
erations brings up an important point but provides no guidance to an implem=
enter how to handle this case / detect the situation. Preferably some advic=
e should be given here.

Editorial /=
 questions:

Section 1:
- "This means when downloading a   Ro=
uting Policy Specification Language (RPSL) object stored in this   database=
, one can reasonably safely claim that the object is   authentic, but for a=
n imported object one cannot." Two points: First part of sentence like=
ly misses a "that." Secondly, what's referred to with "t=
his" database?
- "A maintainer   of such signed database objec=
ts MUST possess a relevant resource   certificate, which shows him/her as t=
he legitimate holder of an   Internet number resource." Why does a mai=
ntainer of objects need to possess a resource certificate? I think the part=
y generating signed database objects need such a certificate, but not neces=
sarily all maintainers?

Section 2:
- "When verifying the sig=
nature of an object, the verifier has to check   whether the signature itse=
lf is valid, and whether all the specified   attributes are referenced in t=
he signature." What "specified" attributes?
- It would be very helpful with a full example, not jus=
t an outline as in 2.3.
- Section 2.4 t=
alks about multiple signatures. I believe this is the only place where this=
 is done, and it is also confusing given that earlier text stated that each=
 attribute (and the signature is an attribute too), must be present "a=
t most once"?

Section 5:
- The certificate shouldn't be used for =
more than one verification - was the intent to say that the private key ass=
ociated with the public key present in the certificate shouldn't be use=
d to sign more than one RPSL object? It seems difficult to state that a cer=
tificate can be used for verification only once - multiple relying parties =
may verify it, for example (note: I am not too familiar with RFC 6487 so ma=
y be missing something here).

-- Magnus




--94eb2c03cec45d806e0532634b22--


From nobody Mon May  9 07:43:19 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B129B12D1E8; Mon,  9 May 2016 07:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqy9vxgZ_CzI; Mon,  9 May 2016 07:43:16 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E849912D1E7; Mon,  9 May 2016 07:43:15 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u49EhDCJ023313; Mon, 9 May 2016 15:43:13 +0100
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u49EhCpA023291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 May 2016 15:43:12 +0100
From: "Adrian Farrel" 
To: "'Hilarie Orman'" , , 
References: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
In-Reply-To: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
Date: Mon, 9 May 2016 15:43:08 +0100
Message-ID: <019701d1aa01$1b5c0640$521412c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQM0Aofw9Q+SCYGjpwhgTv6Z5CXs/Zzr9ckQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22312.000
X-TM-AS-Result: No--16.300-10.0-31-10
X-imss-scan-details: No--16.300-10.0-31-10
X-TMASE-MatchedRID: dL10VBB8yoenykMun0J1wvHkpkyUphL9aSjMyOl1TBnfUZT83lbkEM1S TvaVrDRw9k7ejKn/NFBDHMqEWJcg8Oyt+a9Mtf+e7DzBuedLDxtDGFvBeB2nXJBLkWHr+GTPxlv mHoRzlcrYOJK6UUeDpq8XLD5qB/Bi/kfqE9cRF+aRxwsFDaw1reiY+s2L3xQELO3j+XDwlkPy0h CIU6EV9u8CS9vvFOCxT8D3oVABNiFAFYb6xVW8k6lXXrpOy3q0BWSwVcXsRGWTMTaQzhvoeindB wYVY7dc5Iv7L+NLrJ6iBTvAIT2eAW1yv+64My/eJhFEQZiq2ZQznot5HSrON+qLmFCMpwfU4CUa wQn11ToNgVgOes3NEao0q1fOt8o7qE3fTaEfMDGr17gY+g3e8ZWr6iSXWtgPN15VVRl9DpEbYyS B54LRMbT1+1Gumyg9SRR+Y/NZqWIXXEXrP7ee7QxXJkG8Mv0f1kqyrcMalqXqpu20wiek6B/pZ3 bffunhZfaj0Ej/gOLD/5kXiyVFlslOV51nCIAz7BI2Kjvg8mh4nU6KtjDMA6QMmuFqyUK6o8WMk QWv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSkj80Za3RRg8GpDr4Ib28DoIKwYGzWnDwTtFee2 MU8oNI+28w5m5IDud0xX2Ii4JpA=
Archived-At: 
Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-teas-interconnected-te-info-exchange-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 May 2016 14:43:19 -0000

Hilarie, thanks!

> In section 3.2 "Confidentiality",
> 
>    ... an operator of a domain may desire to keep confidential the
>    details about its internal network topology and loading.  This
>    information could be construed as commercially sensitive.
> 
> also 4.1.1
> 
>    While abstraction uses available TE information, it is subject to
>    policy and management choices.  Thus, not all potential
>    connectivity will be advertised to each client.  The filters may
>    depend on commercial relationships, the risk of disclosing
>    confidential information, and concerns about what use is made of
>    the connectivity that is offered.
> 
> >From a security viewpoint, I wonder if the architecture should have
> sensitivity labels for abstracted reachability information.  Although
> one domain may be willing to share some partly redacted reachability
> information with another domain with which it has a limited trust
> relationship, the first domain might want the second domain to
> refrain from disclosing that information to other domains.  Perhaps
> the first domain might offer two records with different abstraction
> levels, and the most abstracted one would be "shareable" while the
> lesser abstraction would be "private."

While I understand the idea you are suggesting, I wonder how well it works in a
commercial world. You are suggesting that Company A might share information with
Company B on the condition that that information is not passed on to Company C.
Now, that could certainly be agreed between  A and B, and the data could be
flagged accordingly, but A will have no way of knowing whether the information
has been shared with C. Practically, the only way A can control what is shared
with C is to take direct responsibility for that interaction.

But this goes further. If we assume that the default position is that B must not
share any information from A into C then we have exactly the same problem.

Thus (I suggest) the only safe way for A to behave is to assume that any and all
of the information it shares with any party may be subsequently shared with any
other party.

But part of the value of abstraction is that it helps to hide the details of
reality. That is, the information shared by A can have only sparse relationship
to the network it actually operates. No-one can tell whether the existence of an
abstract link from x to y with bandwidth Z means that there is exactly that
bandwidth available on a single physical link, or many multiples of that
bandwidth available on a collection of LSPs that could be set up some time in
the future. Conversely, the absence of an abstract link from x to y may mean
nothing more than "I don't fancy letting you do that today".

> I found the notion of situational address interpretation
> disconcerting.  In "4.5.  Addressing Considerations", we  learn that
> "one address may mean one thing in the client network, yet the same
> address may have a different meaning in the abstraction layer network
> or the server network" and "human operators may well become confused."
> Should addresses have labels that define the domain of interpretation?

They do! The context is provided by IGP instance, AS, area, or level.

This is business as usual. Address spaces are re-used. Operators (and your home)
use private address spaces that are used by devices in other networks.

And, if you tried to manage a single network consisting of public addresses, the
addresses of the operators' nodes and links, and the addresses of a number of
homes and enterprises, "human operators would become confused."

> The notion of some kind of anticipatory information being generated
> and dispersed to neighboring networks was confusing.  Section 4.3
> "Considerations for Dynamic Abstraction" discusses "fluidity".  The
> second sentence is an impenetrable run-on word sequence.  However, it
> is followed by something that is asserted to be more significant ---
> it is apparently "stability".  Some wordsmithing for clarification
> would be helpful.

OK. Thanks for identifying that porridge. I'll rework the text.

> Nits
> ----
> 1.1.9.  Abstraction Layer Network
>    ... networks and one or more client network (should be networks)

Ah. Interesting catch.
Actually should be

   between one or more server
   network and one or more client network

:-)

> 3.2, last sentence
> "understanding that less information that is made available the more"
> should be "that the less ..."

Ack

> 3.5, last sentence
>  "Thus, while the data shared in reduced," should be "is reduced"

Ack

Once again, thanks.

Adrian


From nobody Tue May 10 12:12:06 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC612D616; Tue, 10 May 2016 12:12:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ld07tb8biN0; Tue, 10 May 2016 12:12:03 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E42612D85A; Tue, 10 May 2016 12:12:02 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id k142so32076896oib.1; Tue, 10 May 2016 12:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYkS62+QkwCcXEEw4O17mCPxkcmiaui538XFF04QV8M=; b=lc4FsQxcBKlXRrxBHJxf2PdkntQnVkN3EPRqIskAcyMhDowrgRnrbQ5dnufVPWKRAP vIJWYOCTS5cYsxzB2fsKQ27lBcK83UoRjT4MGXOWdIr3Xa7/QFsyTSet8+aHCJy4G8je xnmyLBXNdi+cabe0zwYikiAANb9iBr4BuUXzeqqXzg2jKlZLeeI7cpmmKrijuxqYMwrC INgvDhwZUauTLSmkSF0qBurI1CmlJiYZPfHDa/CfR0wqhMjhFC3sguMQWx5mq1t0YtDg 9VuWflYxT7CEaAvO+fxqqQISEJEKm4DHR0vmQIaEJYdVL56aCNBXopFyofcf/pLINSLM 62NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYkS62+QkwCcXEEw4O17mCPxkcmiaui538XFF04QV8M=; b=eoGrk8rleqVxq3bWBZkIboyWG8dx+VOLu/bbB5JwZHkgjRL6QFbEbfRgx3ywo4VTc3 2+ZE0UP+U8caSDY9243HyXr298oO52zeNgUukOoK3zkTXr41xl0NhNyMbklxMc2XQjDv vZO46xop9YTfmEQeceNJA9Eqku2Py4qgEMwxEuTLFPVmcOnaZ3jLYN2dyltw4s9DTaa9 4oNqCgBz2WYKkqt4vUTqIBI6CX7aQiYoBX6hvhC4T3kGMjiuG+Hhbs4mH/htjrK06arO QZUyU878DvnxOWMUdwPh6nI1rzgIbTO2sARaKCVzZFc/B7D27jpHjltfc2/elzuq4bhV cYzw==
X-Gm-Message-State: AOPr4FUyuYxsbUeTUjQ4kcwLCrsItKL67bXswKCPhNMoaKFSfFxrxQVpINItXPLX6g9tzJGda4UFDUuZ9trbAA==
X-Received: by 10.202.228.2 with SMTP id b2mr18617676oih.81.1462907522204; Tue, 10 May 2016 12:12:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.22.216 with HTTP; Tue, 10 May 2016 12:11:47 -0700 (PDT)
In-Reply-To: <5729B602.2040004@orange.com>
References:  <5729B602.2040004@orange.com>
From: Donald Eastlake 
Date: Tue, 10 May 2016 15:11:47 -0400
Message-ID: 
To: Thomas Morin 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-bess-multicast-damping.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 May 2016 19:12:05 -0000

Hi,

Thanks for the changes. This resolves my technical and editorial comments.

I also have one response at the end below which is unlikely to be of
interest to most people.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Wed, May 4, 2016 at 4:42 AM, Thomas Morin  wrote:
> Hi Donald,
>
> 2016-04-27, Donald Eastlake:
>
>
> The feature specified in this document is aimed at limiting one type of
> denial of service, or at least at interference to some users by others:
> denial or interference due to excessive control plane traffic due to a high
> rate of multicast group membership change. Still, it makes me a bit queasy
> that the document has not one word, even by reference, about security for
> the setting or changing of the parameters used at a node in the damping
> algorithm.
>
>
> The document does not introduce a new way of controlling parameters on a
> router; so in this regard it does not introduces a new security issue.
> But of course, I agree letting an attacker control configuration can lead to
> much havoc ; again, nothing specific to these specs.
>
> I suppose it is reasonable that it doesn't talk about how any of the control
> messages involved are protected or authenticated since the document is just
> about suppressing such messages...
>
>
> Yes, precisely.
>
>
> The Security Considerations section has a reasonable discussion of how and
> to what extent the mechanisms specified provide the services claimed.
>
>
> Page 15, Section 9 (Security Considerations), 1st paragraph starting on this
> page: There are a number of things wrong with the following sentence:
>
>           Note well that the two
>    mechanism may interact: state for which Prune has been requested may
>    still remain taken into account for some time if damping has been
>    triggered and hence result in otherwise acceptable new state from
>    being successfully created.
>
> I would guess it should be "result in preventing otherwise" or should end
> with "state not being successfully created". Here is a suggested
> replacement:
>
>           The two mechanisms may interact as follows: if damping has
>
>    been triggered, state for which Prune has been requested may remain
>
>    and still be taken into account for some time resulting in an
>
>    otherwise acceptable new state not being created.
>
>
> Your replacement text is much better, and will be incorporated in next
> revision.
> Thanks.
>
>
> Editorial:
>
> This document is very heavy with acronymic jargon with no expansion or
> definition in this document. However, most of it is defined in other RFCs
> that are referenced.
>
> Although I am willing to accept that it is just a matter of style, this
> document has lots of extra words that add nothing but verbosity. Things that
> could be completely dropped with no loss, like starting a sentence with
> "Additionally, it is worth nothing that ...". If it wasn't worth noting, it
> presumably wouldn't be in the document.
>
>
> Your style suggestions are appreciated.
> In some cases, I'd keep the original formulation (see below), but I'd take
> your suggestions in others.
>
>
> Page 4, Section 3, 3rd paragraph: "...this technique will allow to meet the
> goals..." -> "...this technique will meet the goals..."
>
>
> Ok.
>
>
> Page 12, Section 7.2: "More specifically it is RECOMMENDED to complement the
> existing ... (e.g. MRIB states): ..." -> "Complementing the existing ...
> (e.g. MRIB states) is RECOMMENDED: ..."
>
>
> Done.
>
>
> Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean?
>
>
> Corrected already based on OPS review.  That should be 'dimensioning'.
>
> Also "...state churn to go beyond what..." -> "...state churn going beyond
> what..."
>
>
> Ok.
>
>
>
> Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not
> capitalized, this word sounds quite mandatory to me but it is not used in a
> mandatory requirement context... I suggest "shall rely upon" -> "relies on".
>
>
> Ok.
>
> Page 15, near the top: "should rely upon already" -> "should use already"
>
>
> Ok.
>
>
> Finally, while I understand that others have a different opinion, I find it
> objectionable that not a single first page author is willing to list a
> telephone number of any sort in the Authors' Addresses section. To my mind,
> this sort of corner cutting does not speak well for the document.
>
>
> I'm honestly surprised that someone finds these phone numbers in IETF specs
> !

I am not going to engage in a conversation about this but I will respond once.

> If someone wants to contacts authors of a spec, he's much more likely to
> succeed with email, not only because it can talk to all of them at the same
> time.

I agree it is convenient to have email addresses if you with to
shotgun a query to all the authors. I have not suggested leaving out
email addresses.

> I have a reasonable filter on my email for spam/commercial sollicitations,
> but not on my phone lines; this is a strong obstacle to providing phone
> numbers in the wild.

Most IETF participants can easily list a main number for a sponsor
which is, in effect, filtered. In any case, experience show this is
not a problem.

> Emails can also be slightly more stable than phone numbers.

Any of the three types of pointers can, in some cases, be much more
stable than the other two. Direct pointers for an individual can
change asynchronously from those via a sponsor. Of the three types of
information, any one could, in a particular case change more rapidly
than the others. It is more robust to list all three.

> Last, if voice can end up being useful for some exchange, I think it is
> likely that time will have to be coordinated in advance via email -- the
> actual phone number to use can be provided at this time, and may end up
> being the more convenient phone number among a few possible ones, a confcall
> bridge or a login on video chat system...

You seem to keep falsely implying I asked for email addresses to be
left out. I didn't.

> So we aren't "cutting corners".
> I think it simply reflects the reality that this is an obsolete practice.
> In fact, I would suggest removing the postal address as well.

Sure you are. You are trying to get by with the minimal author address
information you can get away with. It's not hard to include a bit
more. So when I see this, I wonder what other corners have been cut.

But, not to worry, I'm pretty sure you will find your opinion on this
being backed up by the IAB and IESG.

> Thanks for your comments,
> -Thomas


From nobody Wed May 11 06:33:45 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDE312DADD; Wed, 11 May 2016 06:33:43 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Mp_z6Hy7VJA4; Wed, 11 May 2016 06:33:37 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96B312DAD2; Wed, 11 May 2016 06:33:35 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A52418812B; Wed, 11 May 2016 06:33:35 -0700 (PDT)
Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 31A8D328081A; Wed, 11 May 2016 06:33:35 -0700 (PDT)
To: =?UTF-8?Q?Magnus_Nystr=c3=b6m?= , "secdir@ietf.org" , draft-ietf-sidr-rpsl-sig.all@ietf.org
References: 
From: Brian Haberman 
Message-ID: <573334A9.2050300@innovationslab.net>
Date: Wed, 11 May 2016 09:33:29 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nq7PvN3va2Nj199j78n1nUTMRVti6tNpO"
Archived-At: 
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2016 13:33:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nq7PvN3va2Nj199j78n1nUTMRVti6tNpO
Content-Type: multipart/mixed; boundary="stnXrUEeketgDNxIhHcVBWavGTkiKDrEE"
From: Brian Haberman 
To: =?UTF-8?Q?Magnus_Nystr=c3=b6m?= ,
 "secdir@ietf.org" , draft-ietf-sidr-rpsl-sig.all@ietf.org
Message-ID: <573334A9.2050300@innovationslab.net>
Subject: Re: Secdir review of draft-ietf-sidr-rpsl-sig-10
References: 
In-Reply-To: 

--stnXrUEeketgDNxIhHcVBWavGTkiKDrEE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Magnus,
    Thanks for the review and comments. Responses are in-line...

On 5/9/16 2:55 AM, Magnus Nystr=C3=B6m wrote:
> I have reviewed this document as part of the security directorate's ong=
oing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat th=
ese
> comments just like any other last call comments.
>=20
> This document describes a mechanism for digitally signing Routing Polic=
y
> Specification Language (RPSL) objects. The digital signatures are inten=
ded
> to ensure authenticity and integrity protection of such objects when th=
ey
> are transferred to and from resource databases.
>=20
> - The signature scheme is a little unusual in that the signature attrib=
ute
> lists the names of the attributes that are part of the signature rather=

> than just including those attributes (and their values) as part of the
> signature attribute itself; I assume this is due to a need to preserve
> established RPSL object syntax but it doesn't seem required for this
> application which essentially is a transport format. The cost here is, =
of
> course, the need to duplicate the names of the signed attributes in the=

> signed RPSL object (once for the regular attribute value and once for t=
he
> value in the signature attribute).

As noted in Section 2, this approach is similar to the one taken by
DKIM. It is designed to allow backwards compatibility with systems that
have not been upgraded to recognize the new signature attribute.

> - There is an expectation that relying parties fetch the signer's
> certificate based on a URL in the signature attribute. This may be a
> dangerous practice, since the URL needs to be contacted before the
> signature can be validated. A malicious party may insert a URL that wil=
l
> lead to an attack. I suggest this be noted in the Security Consideratio=
ns
> section with some suggested best practice, e.g., only https and careful=

> parsing of the retrieved resource.

It is unclear to the authors what "careful parsing" means here and
HTTPS-only in the context of RPKI-hosted certificates creates other
complications that may exceed the benefits.

I would suggest that we add a pointer to Section 7 of RFC 6487 to the
Security Considerations section of this draft. That portion of 6487
describes the certificate validation methodology for these certificates.

> - The Signature Method field - how are new algorithms identified? Is th=
ere
> no need for protocol action / IANA action to register new algorithm for=
 use
> with this memo?

We don't think so. This approach follows the approach of RFC 4055.

> -- As for the canonicalization, this is an inherently complicated field=
=2E It
> does not, for example, seem as if the memo describes how to canonicaliz=
e
> multi-valued attributes. The ordering of such values may well be
> implementation-dependent post object parsing and thus, the canonicaliza=
tion
> should cover how to order sets or sequences of values.

In my experience, RPSL servers do not modify the order of sets or
sequences when importing/exporting objects. The necessary
canonicalization text for such objects is mentioned in point #5 of
section 3.1.

If you think it would help, we could add something along the lines of
"The ordering of multi-valued attributes in c14n must preserve the
original ordering in the object" to point #5 in 3.1.

> - The last paragraph of the Security Considerations brings up an import=
ant
> point but provides no guidance to an implementer how to handle this cas=
e /
> detect the situation. Preferably some advice should be given here.

An entity is free to sign whatever attributes it wants. So, it is up to
the consumer to decide what attributes he/she cares about. Given that we
can add a sentence to the Security Considerations section saying that
consumers of signed RPSL objects may validate signed resource attributes
if methods exist to do so.

>=20
> Editorial / questions:
>=20
> Section 1:
> - "This means when downloading a Routing Policy Specification Language
> (RPSL) object stored in this database, one can reasonably safely claim =
that
> the object is authentic, but for an imported object one cannot." Two
> points: First part of sentence likely misses a "that." Secondly, what's=

> referred to with "this" database?

Would the following be more clear?

OLD:

This means when downloading a Routing Policy Specification Language
(RPSL) object stored in this database, one can reasonably safely claim
that the object is authentic, but for an imported object one cannot.

NEW:

This means that when a Routing Policy Specification Language (RPSL)
object is downloaded from a database, the consumer can reasonably claim
that the object is authentic if it was locally created, but cannot make
the same claim for an object imported from a different database.

> - "A maintainer of such signed database objects MUST possess a relevant=

> resource certificate, which shows him/her as the legitimate holder of a=
n
> Internet number resource." Why does a maintainer of objects need to pos=
sess
> a resource certificate? I think the party generating signed database
> objects need such a certificate, but not necessarily all maintainers?

Agreed that "a maintainer" can be changed to "the creator".

>=20
> Section 2:
> - "When verifying the signature of an object, the verifier has to check=

> whether the signature itself is valid, and whether all the specified
> attributes are referenced in the signature." What "specified" attribute=
s?

The list of signed attributes is identified by the "a" field in the
signature. The attributes listed in "a" need to be in the object.

> - It would be very helpful with a full example, not just an outline as =
in
> 2.3.

I will try and generate one.

> - Section 2.4 talks about multiple signatures. I believe this is the on=
ly
> place where this is done, and it is also confusing given that earlier t=
ext
> stated that each attribute (and the signature is an attribute too), mus=
t be
> present "at most once"?

This will be applicable when text removed in an earlier version is
restored that allows for multiple signatures.

>=20
> Section 5:
> - The certificate shouldn't be used for more than one verification - wa=
s
> the intent to say that the private key associated with the public key
> present in the certificate shouldn't be used to sign more than one RPSL=

> object? It seems difficult to state that a certificate can be used for
> verification only once - multiple relying parties may verify it, for
> example (note: I am not too familiar with RFC 6487 so may be missing
> something here).

Correct. This should be signature generation.

Thanks for the feedback.

Regards,
Brian



--stnXrUEeketgDNxIhHcVBWavGTkiKDrEE--

--nq7PvN3va2Nj199j78n1nUTMRVti6tNpO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXMzSuAAoJEBOZRqCi7goq+OoH/jWF72dNdVNbzT6d+829lLY1
Qd+ml6hqCGX4ia2cpU784qhL6mDLDLrk5MgU/ifXOcDUuiU1s5Ys1NIV4GOn2mDb
BZGJbhavkbsj+KmzmZy2JxXVyC3DukUjz7pKwP5GjCMskHkGM7Hj7gZFcSq10wOH
w76BWKbaSoJvULVSjnNSmQppw3jF2AXB2zQb6oocCqrRa0i5ITa3UvCnXjmTiIKo
vM+NEzF+pRY941/S4QLD+uENMbIhbQ8wtQCNz6WMcSkCdmXJt2Pa1GMxB41OxsTK
7jAPS5wgTlETOG/y7l2LcgRh24evGICErpM9ewotm9igtmLyDutGbuhgCsx/C/k=
=sTgV
-----END PGP SIGNATURE-----

--nq7PvN3va2Nj199j78n1nUTMRVti6tNpO--


From nobody Wed May 11 14:28:53 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D419F12D5DE for ; Wed, 11 May 2016 14:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 KjCKoXKvOfXI for ; Wed, 11 May 2016 14:28:49 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9636512D5E4 for ; Wed, 11 May 2016 14:28:45 -0700 (PDT)
Received: from mail-lb0-f181.google.com ([209.85.217.181]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0McRue-1bIH5n1hq4-00HgvK for ; Wed, 11 May 2016 23:28:43 +0200
Received: by mail-lb0-f181.google.com with SMTP id n11so1913865lbh.1 for ; Wed, 11 May 2016 14:28:43 -0700 (PDT)
X-Gm-Message-State: AOPr4FVpwqdKWqYzcuvEa6yOm2Tkk4yQTCdpJDtv21Jv2AC1qNa8BFWxIbBsTFdDw9mG1klcfSMmmNfyM5abfA==
MIME-Version: 1.0
X-Received: by 10.112.170.201 with SMTP id ao9mr2272933lbc.38.1463002122734; Wed, 11 May 2016 14:28:42 -0700 (PDT)
Received: by 10.112.74.135 with HTTP; Wed, 11 May 2016 14:28:42 -0700 (PDT)
Date: Wed, 11 May 2016 14:28:42 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
From: Bodo Moeller 
To: secdir 
Content-Type: multipart/alternative; boundary=001a11c36bdcd4db62053297b973
X-Provags-ID: V03:K0:G/jB6Z3t9snbKbFPJ9b8RjNFi7DA12P/oK8f6iYF4lt9rw4gBop vb/LeIuYOVA5Bg4+nZCqKmuiwsZ0F5tW7TFxtmnr15A1VhcWmbs5NlIXMl6OuMQi5NQkYza DeEy9PfBNCiNuPdMQINLX7K3G1sIiUNhlb6O/xvchKCN+PsbRx2IcK15HHyYqPYL5cDz7Di Pmjn6FXWsWqSNgaXq4jYg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aQvABFK1ZHc=:k+ObKoiMhpbJDJfzjL1oXD 67x9i7ocNQAx47BSlKaI0akhDsbstToP54uV1UoofxBjVpBmO7i3fiB0N0DE8qJvFMZee7bA9 awpZNcNMF2DHE/lfg/j6XbA8yI2g2owY8tIqDL/x9OkErf/iARsrk3Qpv+1RZvFag0Y8tbX1P TGIiYmSmuqZLtUOOLUNXtJbeua8qvWTeWCied3rP3nXurvvKXI3vyJRLhSPLr/Ot1Mae9F4hr Jvdf4ksYhlgIqxlS4I5z0fhRSYDMbIggzf50G4RgEoB8WpYsU4fe2+Vbu3+KEH7WbsSUFUtr1 79/qNN2LiZvhi0C3cxFdR8iauoPl8e9s8/RgpfdVU5KqSE12mpvdH/zuWXIeSwJeVs8TvOqSC lnR7vg97KotZirE21QYNhLdTPo0FrOUOtigtuUu+B9YmCm83ZTm0yG7N6nYo7qhP13ZzLaVIz DqagMuGJL8Z5cGPKHzagknv1KRKhEqy2w5lc5Z+nuSFGxEe+65y7dTT2n+FZ0J6dlf4UIc1Eo VwM0tcB/dAOEiUigSAa+W/mTwBLZVnAmZM0D5gKFru+E/TyD7ndE3HU67L9opOkUsOOUeqNQk xJ5+aRW36lCnUNHF5IvX4sqHEMECaV1ztvSb16z5Gk20Vr2R9IYXArRibpRj/wNmOs85N499L XhFT/I10kaYlu3jQvDJG88sz6r3hg5Aty0Jtk0O/PKeqdUkfXu6TzL73vrzVBXlY3LAAy8dK3 nVZjcQPjMSWWy607
Archived-At: 
Cc: Nagendra Modadugu , Adam Langley 
Subject: Re: [secdir] Secdir review of draft-ietf-tls-falsestart-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2016 21:28:51 -0000

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

Charlie,

thanks for your comments.

Some nits:



Section 3 talks about determining whether a TLS server is "false start
> compatible". I believe any server that correctly implements TLS (i.e.,
> following the specification) would be false start compatible. That does not
> imply that all would be, and it would be useful to do some testing to see
> whether most implementations in fact are. Publishing this as an
> experimental RFC is likely to encourage such an effort.


I'm truly not sure about this. By the TLS specification, servers wouldn't
have to expect early handshake messages, so arguably server behavior in
their presence is left unspecified -- however, I'd certainly not be
surprised if all server implementations that aren't false start compatible
are indeed strictly broken (I see no good reasons for TLS servers to *not*
tolerate handshake messages that arrive early).

In any case, I think the concept of a TLS server being "false start
compatible" is useful, so don't think I'd want to make a change to the
document there.

Section 2 paragraph 1 says that TLS requires two full protocol rounds
> before the handshake is complete. While technically this is true, it
> overstates the benefit of this enhancement because TLS rides atop TCP which
> has its own protocol round before it starts carrying application payloads.
> So this enhancement reduces that TLS startup time from three round trips to
> two rather than the more dramatic two to one.


I don't really agree that draft-ietf-tls-falsestart-01 overstates the
benefit, it's just that the round-trip time added by TCP is mostly an
orthogonal issue: RFC7413 (TCP Fast Open) addresses it. I'll discuss that
point and mention that RFC in draft-ietf-tls-falsestart-02.

Bodo

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


Charlie,

thanks for your com=
ments.

Some nits:=C2=A0
=C2=A0
Section 3 talks about determining whether a TLS se=
rver is "false start compatible". I believe any server that corre=
ctly implements TLS (i.e., following the specification) would be false star=
t compatible. That does not imply that all would be, and it would be useful=
 to do some testing to see whether most implementations in fact are. Publis=
hing this as an experimental RFC is likely to encourage such an effort.=C2=
=A0

I'm truly not sure about this. By t=
he TLS specification, servers wouldn't have to expect early handshake m=
essages, so arguably server behavior in their presence is left unspecified =
-- however, I'd certainly not be surprised if all server implementation=
s that aren't false start compatible are indeed strictly broken (I see =
no good reasons for TLS servers to *not* tolerate handshake messages that a=
rrive early).

In any case, I think the concept of =
a TLS server being "false start compatible" is useful, so don'=
;t think I'd want to make a change to the document there.
Section 2 paragraph 1 says that TLS requires two fu=
ll protocol rounds before the handshake is complete. While technically this=
 is true, it overstates the benefit of this enhancement because TLS rides a=
top TCP which has its own protocol round before it starts carrying applicat=
ion payloads. So this enhancement reduces that TLS startup time from three =
round trips to two rather than the more dramatic two to one.

I don't really agree that draft-ietf-tls-falsestart-0=
1 overstates the benefit, it's just that the round-trip time added by T=
CP is mostly an orthogonal issue: RFC7413 (TCP Fast Open) addresses it. I&#=
39;ll discuss that point and mention that RFC in draft-ietf-tls-falsestart-=
02.

Bodo



--001a11c36bdcd4db62053297b973--


From nobody Wed May 11 14:35:37 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DBD12D1A8; Wed, 11 May 2016 14:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 D4byt-wsZeWk; Wed, 11 May 2016 14:35:33 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B27C12D141; Wed, 11 May 2016 14:35:33 -0700 (PDT)
Received: from mail-lf0-f44.google.com ([209.85.215.44]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MEwBu-1ap3Kj0SNu-00G0I7; Wed, 11 May 2016 23:35:31 +0200
Received: by mail-lf0-f44.google.com with SMTP id j8so61328925lfd.2; Wed, 11 May 2016 14:35:30 -0700 (PDT)
X-Gm-Message-State: AOPr4FV/PLqKUkfAJFuEAwq9o/qJ69atRj4S9++PpnrNMDLpTk8xEsLcGyixiOY9XhnSJYZRzPwWMNj6lEfWeg==
MIME-Version: 1.0
X-Received: by 10.25.206.130 with SMTP id e124mr2637948lfg.41.1463002530148; Wed, 11 May 2016 14:35:30 -0700 (PDT)
Received: by 10.112.74.135 with HTTP; Wed, 11 May 2016 14:35:30 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 11 May 2016 14:35:30 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
From: Bodo Moeller 
To: Charlie Kaufman 
Content-Type: multipart/alternative; boundary=001a11411f9e1d7d08053297d2dc
X-Provags-ID: V03:K0:TzpqV+gK8JmZJaj+M14nkhlEwbVudOgxgZubbaoGeEsuPKGczIK b8Y/MCtLm7xVL8QXb+4zKPyGQs8gWNJIyk7MEn7EFMLrrCf/VWz2IuSiDshlnnde3JLlFVp K6grpto+x6xkHXqnIiRkXNZomdU5i6h1S4ZrZbIzDvCCLVCYjiJ5s4KTr4GqlxMOiFq+act 14Wrm+tciljWdXHByT+iA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:SnX0lT5JKwM=:AqYbUg2/3iKgnqdHtdMBQ8 Y/bfipnXaD64/1jL8RhGIkeYUy06u42XPUU1HYblrdGN6GuoYSMMCRM7rmAeINJhVdFjdZ2aJ Sm4NP7/nL8ieWZe0mcf9oRG8v+FraS+4vchPkEN2IVcJ/76az3PVQ2I8quGBUc4Kiq8cSTDoB VqL72Uoy309ZzaOQOFluPIa3t3dYTU1H5LLuZTST1x9KEShEf6kV5hB1xOQPxQe3OoRR+cUWI 48Z8JnE1tp80a5EfX8kxU7qrVkOBVbPvR85xkiDM+JoxOHf6OgtOhld06UNfvjC/ZtxQWx0Ps 0Mpl4uNIzVexC4jA3A6gBVkDa/1z2d7RuMalbfFUH9onErGWB6/eZdu3z9oPec8XF0Yjm4o3Q 1sJYeEtSUDKX3or6tMfOCSXK9UHaVv7/is7PJtBTn3ueuDAkPNJn96KfDucYqdApb0Y5lYdK3 fQ0YIvYJoeKwfpZbySXdTsKxlnX2fYvSTWy6Hfla2W0/TZDtGrkiUGZpTCfFHuW1bSpy4pRar BxeEYOIU2wsxz0NrVV1FpXTBGhMRnx/v/Zu0R1vX5LAWFZVvIuyoAjH0KzehHEPgmlPPfKxZi 4XzQNcUyi0ou/IUBUz0ICWEZK6VlELc/Ck4Fa2XjyC5F9usDRky6yqN4Cyh8JUDdWMW9aleeY tZT8T+AASHAK2ouDQ7GcT+a7wo3a8RE3wd3M/T2mjyHVU+sMoTY6mwTTfeR80tSK+HCwm/Izt LQ4kaEfytDcCuRxV
Archived-At: 
Cc: "draft-ietf-tls-falsestart.all@tools.ietf.org" , The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-tls-falsestart-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2016 21:35:35 -0000

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

Charlie,

thanks for your comments.

Some nits:



Section 3 talks about determining whether a TLS server is "false start
> compatible". I believe any server that correctly implements TLS (i.e.,
> following the specification) would be false start compatible. That does not
> imply that all would be, and it would be useful to do some testing to see
> whether most implementations in fact are. Publishing this as an
> experimental RFC is likely to encourage such an effort.


I'm truly not sure about this. By the TLS specification, servers wouldn't
have to expect early handshake messages, so arguably server behavior in
their presence is left unspecified -- however, I'd certainly not be
surprised if all server implementations that aren't false start compatible
are indeed strictly broken (I see no good reasons for TLS servers to *not*
tolerate handshake messages that arrive early).

In any case, I think the concept of a TLS server being "false start
compatible" is useful, so don't think I'd want to make a change to the
document there.

Section 2 paragraph 1 says that TLS requires two full protocol rounds
> before the handshake is complete. While technically this is true, it
> overstates the benefit of this enhancement because TLS rides atop TCP which
> has its own protocol round before it starts carrying application payloads.
> So this enhancement reduces that TLS startup time from three round trips to
> two rather than the more dramatic two to one.


I don't really agree that draft-ietf-tls-falsestart-01 overstates the
benefit, it's just that the round-trip time added by TCP is mostly an
orthogonal issue: RFC7413 (TCP Fast Open) addresses it. I'll discuss that
point and mention that RFC in draft-ietf-tls-falsestart-02.

Bodo


[Sorry if this is the second copy of this message that you receive, I
realized I'd previously dropped some of the CC recipients.]

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


Charlie,
<=
br>
thanks for your comments.

Some nits:=C2=A0
=C2=A0
Section 3 talks about determining whether a TLS server i=
s "false start compatible". I believe any server that correctly i=
mplements TLS (i.e., following the specification) would be false start comp=
atible. That does not imply that all would be, and it would be useful to do=
 some testing to see whether most implementations in fact are. Publishing t=
his as an experimental RFC is likely to encourage such an effort.=C2=A0

I'm truly not sure about this. By the TLS specification, server=
s wouldn't have to expect early handshake messages, so arguably server =
behavior in their presence is left unspecified -- however, I'd certainl=
y not be surprised if all server implementations that aren't false star=
t compatible are indeed strictly broken (I see no good reasons for TLS serv=
ers to *not* tolerate handshake messages that arrive early).

In any cas=
e, I think the concept of a TLS server being "false start compatible&q=
uot; is useful, so don't think I'd want to make a change to the doc=
ument there.

Section 2 paragraph 1 says that TLS requires two full pr=
otocol rounds before the handshake is complete. While technically this is t=
rue, it overstates the benefit of this enhancement because TLS rides atop T=
CP which has its own protocol round before it starts carrying application p=
ayloads. So this enhancement reduces that TLS startup time from three round=
 trips to two rather than the more dramatic two to one.

I don=
9;t really agree that draft-ietf-tls-falsestart-01 overstates the benefit, =
it's just that the round-trip time added by TCP is mostly an orthogonal=
 issue: RFC7413 (TCP Fast Open) addresses it. I'll discuss that point a=
nd mention that RFC in draft-ietf-tls-falsestart-02.

Bodo


[Sorry if this is the second copy of this =
message that you receive, I realized I'd previously dropped some of the=
 CC recipients.]



--001a11411f9e1d7d08053297d2dc--


From nobody Thu May 12 05:53:59 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9208A12D66D for ; Thu, 12 May 2016 05:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 6OCT7LIOmDnJ for ; Thu, 12 May 2016 05:53:56 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 22B1812D65D for ; Thu, 12 May 2016 05:53:55 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4CCrpVI015704 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 May 2016 15:53:51 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4CCrpG5025199; Thu, 12 May 2016 15:53:51 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22324.31967.251866.218602@fireball.acr.fi>
Date: Thu, 12 May 2016 15:53:51 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2016 12:53:58 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Zach Shelby is next in the rotation.

For telechat 2016-05-19

Reviewer                 LC end     Draft
Sandy Murphy           T 2016-05-12 draft-ietf-netmod-rfc6020bis-11


For telechat 2016-06-02

Eric Osterweil         T 2016-05-26 draft-hardie-rfc6455-iana-clarification-02
Vincent Roca           T 2016-05-16 draft-ietf-manet-rfc6779bis-05
Rich Salz              T 2016-05-23 draft-ietf-clue-data-model-schema-13

Last calls and special requests:

Alan DeKok               2016-04-30 draft-bradner-rfc3979bis-08
Daniel Kahn Gillmor    E 2016-02-01 draft-ietf-rtcweb-security-08
Radia Perlman            2016-05-12 draft-ietf-dime-e2e-sec-req-04
Yaron Sheffer            2016-05-23 draft-ietf-dhc-topo-conf-07
Rifaat Shekh-Yusef       2016-05-24 draft-ietf-mmusic-msid-13
Hannes Tschofenig        2015-12-28 draft-ietf-hip-rfc5204-bis-07
Hannes Tschofenig      E None       draft-ietf-ntp-network-time-security-13
Hannes Tschofenig      E None       draft-ietf-ntp-cms-for-nts-message-06
Hannes Tschofenig      E None       draft-ietf-ntp-using-nts-for-ntp-04
Brian Weis             E 2016-02-01 draft-ietf-cdni-uri-signing-07
-- 
kivinen@iki.fi


From nobody Fri May 13 07:38:39 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC8D12D530; Fri, 13 May 2016 07:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GrO1_pA-edj; Fri, 13 May 2016 07:38:31 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7392F12D531; Fri, 13 May 2016 07:38:30 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id f66so139601217vkh.2; Fri, 13 May 2016 07:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=Er1NBV1wsegQCZhv1kMvuyE5Y+mYQACHnOqGtaSBcUk=; b=kYfENZHVi0eJzRycXq3wn92HrJAkznxrO+VJsOc8gaXPmeWbdQ1uMjoiYh0YgI7ARh TNe3wHotYXgFtLBf/NVEjcYHWKDEF3Duqddavf+jU/0Dip9q2YWfJrVjRUBAI9cB6lkE 1EAwXozwRi3CDKNWbIwt7MuXDeOQp4pBCSDJVPw+UcDZStdzpxoMfLp41U0iy0UErv+Z UkVToHRXfzt5R+nU7VBQLwPkbKI5GqbxE59YQUUVKG1/VakL0niz52sKs93X0V3LsJHp VMJTZyEw3o3HyTX+LYAJk9Z79kG0weS781x1leoQyZaHkwbwWxznF0TwYfOwx0kbuk08 kSoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Er1NBV1wsegQCZhv1kMvuyE5Y+mYQACHnOqGtaSBcUk=; b=DuZxKE9HfJRvhMpFlAXQ6mndR0e9RWMhfzjARU3IKJW5a/dnNcvAjWfPuXQYF+1Yef HuVCPlvZhVT/MFAmNGqxVxEVyoJRYSHRjZgJl2M/Ig1s08/p2pv1VC+1RQvO1eC1jPIZ QNL5Ed2ICR12hoDf5wmXVBmknE4EJ2z9hMGCnPugWmHXADljJh1J8BsqkpmqMVIWi66d yIz85pXUvJ8PJZWdvPY/Lz1GE0JzdWlM3IwnnmqnRViKzOaKeP1iHXsh1qAR3rfmzqQo SEiJHR1wagMEs7Gr/EXVxcqTgq7AkqxCkIneBK8xsF2n6JWQEg5eF5cv4L9H/Y+mLC2y 5M6Q==
X-Gm-Message-State: AOPr4FV68p13hCp8GyfdzKAP8VrvJLFDogl1E9a2RlSfkGt/cJIIAMtObP2DnF+NEYw3yC7uOWVvj/qi4BJeJA==
MIME-Version: 1.0
X-Received: by 10.31.99.133 with SMTP id x127mr6620404vkb.146.1463150309933; Fri, 13 May 2016 07:38:29 -0700 (PDT)
Received: by 10.176.7.101 with HTTP; Fri, 13 May 2016 07:38:29 -0700 (PDT)
Date: Fri, 13 May 2016 10:38:29 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: The IESG , secdir@ietf.org, draft-ietf-mmusic-msid-13.all@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c07ccfc7a0c020532ba3a14
Archived-At: 
Subject: [secdir]  SecDir review of draft-ietf-mmusic-msid-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 May 2016 14:38:33 -0000

--94eb2c07ccfc7a0c020532ba3a14
Content-Type: text/plain; charset=UTF-8

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: *Ready*

This is a Standard Track document that defines an RTP media streams
grouping mechanism in SDP.

The Security Consideration section clearly describes the potential attacks
introduced by this new mechanism, and points out the general issue of SDP
modification by untrusted entities, and potential issue with the buffering
required by mechanism suggested by the draft.

Regards,
 Rifaat

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


I have reviewed this document as part of the security=
 directorate's
ongoing effort to review all IETF documents be=
ing processed by the
IESG.=C2=A0 These comments were written prim=
arily for the benefit of the
security area directors.=C2=A0 Docum=
ent editors and WG chairs should treat
these comments just like a=
ny other last call comments.

Summary: Ready=


This is a Standard Track document that defines an=
 RTP media streams
grouping mechanism in SDP.

The Security Consideration section clearly describes the potential at=
tacks=C2=A0
introduced by this new mechanism, and points out the =
general issue of SDP=C2=A0
modification by untrusted entities, an=
d potential issue with the buffering=C2=A0
required by mechanism =
suggested by the draft.

Regards,
=C2=A0R=
ifaat



--94eb2c07ccfc7a0c020532ba3a14--


From nobody Fri May 13 08:47:59 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50512D581; Fri, 13 May 2016 08:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf1MiiXXhauK; Fri, 13 May 2016 08:47:55 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3A012B060; Fri, 13 May 2016 08:47:53 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id v145so176457720oie.0; Fri, 13 May 2016 08:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sSB5U8l3SBzwIN+O+phYveqTcnTYGbVJyZofpHUEBEw=; b=FbquK8oQswM7qKXywNfVRqMpcDCq8PXX0NBfwFCe7AlzCofLoJIkXNUtRIwETWYg0v 4UUiLIrbIhhMNhMTlgomAp8/Z7i0ON6pIKFurQvX75pCUq6ge7X4b0i+525ng1u7MFCI sHk9BFzFcXEcHZUQhmhhPYfSv7xGUFM6zRaFIHOSMfGr3+Kpk6DBsbn/YL1ObeYespQp mbmGVV9vHw/MinqMFecoT+reMIdIV9mNdFnd4Q3G3XzC3BUxikT4njISj/82qHYJJ22S qCP/U8JV+Pbllkpzlm6o8M//uZ3sn2Innvy8ndRURBwUSIh1ljzPeu74DgJ0SvacXMPe kd2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sSB5U8l3SBzwIN+O+phYveqTcnTYGbVJyZofpHUEBEw=; b=Hrx34BGmsucdnTQr9nbXKtLIX8uDijveUb56Vhx0z3T1ghQhtjC2ZfsS/91OufmVSN c+EEzy1nE13ZUZJsUwqLzPNHKPmVAVG/dpQw4Ko+9ymnuVunF9YdQncBTQ7n6Gy1uVDc e7AX6LQEaFKTVcsFFxtvPDnO3DKJ56Ad2H6MP0VmcglvMgF6IvHTRx64CCFA9L8GonZF SWiYGtvrdGLa6I2SEkhc3ISraQO0Lb24S8pv+vt1EBAFxuWS/22PXAAkyzEYaWIxet0B 5bX7P05zN/bvhaNwlA5bGDmLRfRE+vu/UsRsxPeudBbxx0WvntJ/Qmx17mAfh4WYK0El sMLQ==
X-Gm-Message-State: AOPr4FVqNE5eKK23oOp5+PYiFcxH0e47iSDngQtSmNQhhgDunzv+GlW7z8+xitM63oqvZ04xC53T71ednW5gug==
MIME-Version: 1.0
X-Received: by 10.202.240.215 with SMTP id o206mr8301301oih.132.1463154472783;  Fri, 13 May 2016 08:47:52 -0700 (PDT)
Received: by 10.202.108.137 with HTTP; Fri, 13 May 2016 08:47:52 -0700 (PDT)
In-Reply-To: <573334A9.2050300@innovationslab.net>
References:  <573334A9.2050300@innovationslab.net>
Date: Fri, 13 May 2016 08:47:52 -0700
Message-ID: 
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= 
To: Brian Haberman 
Content-Type: multipart/alternative; boundary=94eb2c09204e9a197b0532bb32d9
Archived-At: 
Cc: draft-ietf-sidr-rpsl-sig.all@ietf.org, "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 May 2016 15:47:57 -0000

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

Thanks Brian,

On Wed, May 11, 2016 at 6:33 AM, Brian Haberman 
wrote:

> Hi Magnus,
>     Thanks for the review and comments. Responses are in-line...
>
> On 5/9/16 2:55 AM, Magnus Nystr=C3=B6m wrote:
> > I have reviewed this document as part of the security directorate's
> ongoing
> > effort to review all IETF documents being processed by the IESG. These
> > comments were written primarily for the benefit of the
> > security area directors. Document editors and WG chairs should treat
> these
> > comments just like any other last call comments.
> >
> > This document describes a mechanism for digitally signing Routing Polic=
y
> > Specification Language (RPSL) objects. The digital signatures are
> intended
> > to ensure authenticity and integrity protection of such objects when th=
ey
> > are transferred to and from resource databases.
> >
> > - The signature scheme is a little unusual in that the signature
> attribute
> > lists the names of the attributes that are part of the signature rather
> > than just including those attributes (and their values) as part of the
> > signature attribute itself; I assume this is due to a need to preserve
> > established RPSL object syntax but it doesn't seem required for this
> > application which essentially is a transport format. The cost here is, =
of
> > course, the need to duplicate the names of the signed attributes in the
> > signed RPSL object (once for the regular attribute value and once for t=
he
> > value in the signature attribute).
>
> As noted in Section 2, this approach is similar to the one taken by
> DKIM. It is designed to allow backwards compatibility with systems that
> have not been upgraded to recognize the new signature attribute.
>
> > - There is an expectation that relying parties fetch the signer's
> > certificate based on a URL in the signature attribute. This may be a
> > dangerous practice, since the URL needs to be contacted before the
> > signature can be validated. A malicious party may insert a URL that wil=
l
> > lead to an attack. I suggest this be noted in the Security Consideratio=
ns
> > section with some suggested best practice, e.g., only https and careful
> > parsing of the retrieved resource.
>
> It is unclear to the authors what "careful parsing" means here and
> HTTPS-only in the context of RPKI-hosted certificates creates other
> complications that may exceed the benefits.
>

Well, it seems to me that the ability to get agents to contact an
unverified URL is a potential risk and I would recommend some discussion
around this in the Sec Cons section..

>
> I would suggest that we add a pointer to Section 7 of RFC 6487 to the
> Security Considerations section of this draft. That portion of 6487
> describes the certificate validation methodology for these certificates.
>
> > - The Signature Method field - how are new algorithms identified? Is
> there
> > no need for protocol action / IANA action to register new algorithm for
> use
> > with this memo?
>
> We don't think so. This approach follows the approach of RFC 4055.
>
> > -- As for the canonicalization, this is an inherently complicated field=
.
> It
> > does not, for example, seem as if the memo describes how to canonicaliz=
e
> > multi-valued attributes. The ordering of such values may well be
> > implementation-dependent post object parsing and thus, the
> canonicalization
> > should cover how to order sets or sequences of values.
>
> In my experience, RPSL servers do not modify the order of sets or
> sequences when importing/exporting objects. The necessary
> canonicalization text for such objects is mentioned in point #5 of
> section 3.1.
>
> If you think it would help, we could add something along the lines of
> "The ordering of multi-valued attributes in c14n must preserve the
> original ordering in the object" to point #5 in 3.1.
>
> I would suggest this, since in general canonicalization should allow to
first parse a received message and then later do verification with a
successful result without relying on implicit expectations on behavior.

> - The last paragraph of the Security Considerations brings up an importan=
t
> > point but provides no guidance to an implementer how to handle this cas=
e
> /
> > detect the situation. Preferably some advice should be given here.
>
> An entity is free to sign whatever attributes it wants. So, it is up to
> the consumer to decide what attributes he/she cares about. Given that we
> can add a sentence to the Security Considerations section saying that
> consumers of signed RPSL objects may validate signed resource attributes
> if methods exist to do so.
>
> Yes, that may be helpful.


> >
> > Editorial / questions:
> >
> > Section 1:
> > - "This means when downloading a Routing Policy Specification Language
> > (RPSL) object stored in this database, one can reasonably safely claim
> that
> > the object is authentic, but for an imported object one cannot." Two
> > points: First part of sentence likely misses a "that." Secondly, what's
> > referred to with "this" database?
>
> Would the following be more clear?
>
> OLD:
>
> This means when downloading a Routing Policy Specification Language
> (RPSL) object stored in this database, one can reasonably safely claim
> that the object is authentic, but for an imported object one cannot.
>
> NEW:
>
> This means that when a Routing Policy Specification Language (RPSL)
> object is downloaded from a database, the consumer can reasonably claim
> that the object is authentic if it was locally created, but cannot make
> the same claim for an object imported from a different database.
>

Much better, thanks.

>
> > - "A maintainer of such signed database objects MUST possess a relevant
> > resource certificate, which shows him/her as the legitimate holder of a=
n
> > Internet number resource." Why does a maintainer of objects need to
> possess
> > a resource certificate? I think the party generating signed database
> > objects need such a certificate, but not necessarily all maintainers?
>
> Agreed that "a maintainer" can be changed to "the creator".
>
> >
> > Section 2:
> > - "When verifying the signature of an object, the verifier has to check
> > whether the signature itself is valid, and whether all the specified
> > attributes are referenced in the signature." What "specified" attribute=
s?
>
> The list of signed attributes is identified by the "a" field in the
> signature. The attributes listed in "a" need to be in the object.
>

I would suggest "all the attributes specified in the "a' field".

>
> > - It would be very helpful with a full example, not just an outline as =
in
> > 2.3.
>
> I will try and generate one.
>
> > - Section 2.4 talks about multiple signatures. I believe this is the on=
ly
> > place where this is done, and it is also confusing given that earlier
> text
> > stated that each attribute (and the signature is an attribute too), mus=
t
> be
> > present "at most once"?
>
> This will be applicable when text removed in an earlier version is
> restored that allows for multiple signatures.
>

Is that intended to be restored before publication? If not, suggest
removing.

>
> >
> > Section 5:
> > - The certificate shouldn't be used for more than one verification - wa=
s
> > the intent to say that the private key associated with the public key
> > present in the certificate shouldn't be used to sign more than one RPSL
> > object? It seems difficult to state that a certificate can be used for
> > verification only once - multiple relying parties may verify it, for
> > example (note: I am not too familiar with RFC 6487 so may be missing
> > something here).
>
> Correct. This should be signature generation.
>
> Thanks for the feedback.
>
> Thanks


> Regards,
> Brian
>
>
>


--=20
-- Magnus

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


Thanks Brian,

On Wed, May 11, 2016 at 6:33 AM, Brian Haberman <=
brian@innovationslab.net> wrote:
Hi Magnus,

=C2=A0 =C2=A0 Thanks for the review and comments. Responses are in-line...<=
br>


On 5/9/16 2:55 AM, Magnus Nystr=C3=B6m wrote:

> I have reviewed this document as part of the security directorate'=
s ongoing

> effort to review all IETF documents being processed by the IESG. These=


> comments were written primarily for the benefit of the

> security area directors. Document editors and WG chairs should treat t=
hese

> comments just like any other last call comments.

>

> This document describes a mechanism for digitally signing Routing Poli=
cy

> Specification Language (RPSL) objects. The digital signatures are inte=
nded

> to ensure authenticity and integrity protection of such objects when t=
hey

> are transferred to and from resource databases.

>

> - The signature scheme is a little unusual in that the signature attri=
bute

> lists the names of the attributes that are part of the signature rathe=
r

> than just including those attributes (and their values) as part of the=


> signature attribute itself; I assume this is due to a need to preserve=


> established RPSL object syntax but it doesn't seem required for th=
is

> application which essentially is a transport format. The cost here is,=
 of

> course, the need to duplicate the names of the signed attributes in th=
e

> signed RPSL object (once for the regular attribute value and once for =
the

> value in the signature attribute).



As noted in Section 2, this approach is similar to the one taken by<=
br>
DKIM. It is designed to allow backwards compatibility with systems that

have not been upgraded to recognize the new signature attribute.



> - There is an expectation that relying parties fetch the signer's<=
br>
> certificate based on a URL in the signature attribute. This may be a
> dangerous practice, since the URL needs to be contacted before the

> signature can be validated. A malicious party may insert a URL that wi=
ll

> lead to an attack. I suggest this be noted in the Security Considerati=
ons

> section with some suggested best practice, e.g., only https and carefu=
l

> parsing of the retrieved resource.



It is unclear to the authors what "careful parsing" means =
here and

HTTPS-only in the context of RPKI-hosted certificates creates other

complications that may exceed the benefits.

=

Well, it seems to me that the ability to get agents to contact an unve=
rified URL is a potential risk and I would recommend some discussion around=
 this in the Sec Cons section.. 



I would suggest that we add a pointer to Section 7 of RFC 6487 to the

Security Considerations section of this draft. That portion of 6487

describes the certificate validation methodology for these certificates.


> - The Signature Method field - how are new algorithms identified? Is t=
here

> no need for protocol action / IANA action to register new algorithm fo=
r use

> with this memo?



We don't think so. This approach follows the approach of RFC 405=
5.



> -- As for the canonicalization, this is an inherently complicated fiel=
d. It

> does not, for example, seem as if the memo describes how to canonicali=
ze

> multi-valued attributes. The ordering of such values may well be

> implementation-dependent post object parsing and thus, the canonicaliz=
ation

> should cover how to order sets or sequences of values.



In my experience, RPSL servers do not modify the order of sets or
sequences when importing/exporting objects. The necessary

canonicalization text for such objects is mentioned in point #5 of

section 3.1.



If you think it would help, we could add something along the lines of

"The ordering of multi-valued attributes in c14n must preserve the

original ordering in the object" to point #5 in 3.1.


I would suggest this, since i=
n general canonicalization should allow to first parse a received message a=
nd then later do verification with a successful result without relying on i=
mplicit expectations on behavior.


> - The last paragraph of the Security Considerations brings up an impor=
tant

> point but provides no guidance to an implementer how to handle this ca=
se /

> detect the situation. Preferably some advice should be given here.



An entity is free to sign whatever attributes it wants. So, it is up=
 to

the consumer to decide what attributes he/she cares about. Given that we
can add a sentence to the Security Considerations section saying that

consumers of signed RPSL objects may validate signed resource attributes
if methods exist to do so.


Yes, that may be helpful.
=
=C2=A0

>

> Editorial / questions:

>

> Section 1:

> - "This means when downloading a Routing Policy Specification Lan=
guage

> (RPSL) object stored in this database, one can reasonably safely claim=
 that

> the object is authentic, but for an imported object one cannot." =
Two

> points: First part of sentence likely misses a "that." Secon=
dly, what's

> referred to with "this" database?



Would the following be more clear?



OLD:



This means when downloading a Routing Policy Specification Language

(RPSL) object stored in this database, one can reasonably safely claim

that the object is authentic, but for an imported object one cannot.



NEW:



This means that when a Routing Policy Specification Language (RPSL)

object is downloaded from a database, the consumer can reasonably claim

that the object is authentic if it was locally created, but cannot make

the same claim for an object imported from a different database.

Much better, thanks. 



> - "A maintainer of such signed database objects MUST possess a re=
levant

> resource certificate, which shows him/her as the legitimate holder of =
an

> Internet number resource." Why does a maintainer of objects need =
to possess

> a resource certificate? I think the party generating signed database
> objects need such a certificate, but not necessarily all maintainers?<=
br>


Agreed that "a maintainer" can be changed to "the cre=
ator".



>

> Section 2:

> - "When verifying the signature of an object, the verifier has to=
 check

> whether the signature itself is valid, and whether all the specified
> attributes are referenced in the signature." What "specified=
" attributes?



The list of signed attributes is identified by the "a" fie=
ld in the

signature. The attributes listed in "a" need to be in the object.=


I would suggest "all the attribut=
es specified in the "a' field". 



> - It would be very helpful with a full example, not just an outline as=
 in

> 2.3.



I will try and generate one.



> - Section 2.4 talks about multiple signatures. I believe this is the o=
nly

> place where this is done, and it is also confusing given that earlier =
text

> stated that each attribute (and the signature is an attribute too), mu=
st be

> present "at most once"?



This will be applicable when text removed in an earlier version is
restored that allows for multiple signatures.

Is that intended to be restored before publication? If not, suggest =
removing. 



>

> Section 5:

> - The certificate shouldn't be used for more than one verification=
 - was

> the intent to say that the private key associated with the public key<=
br>
> present in the certificate shouldn't be used to sign more than one=
 RPSL

> object? It seems difficult to state that a certificate can be used for=


> verification only once - multiple relying parties may verify it, for
> example (note: I am not too familiar with RFC 6487 so may be missing
> something here).



Correct. This should be signature generation.



Thanks for the feedback.


Thanks
=C2=A0

Regards,

Brian









-- 
-- Magnus




--94eb2c09204e9a197b0532bb32d9--


From nobody Mon May 16 05:08:01 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC012D55C; Mon, 16 May 2016 05:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORgEO2GV00EH; Mon, 16 May 2016 05:07:53 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CD012D174; Mon, 16 May 2016 05:07:53 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id s184so209749562vkb.3; Mon, 16 May 2016 05:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ba5PQ+wmyMRhn7kIB8P/lUeh6yaaxiwndDAxsFbqQ6I=; b=uVCqJt4zYUQBWqk6rc4Pm9MFYzjb2RlPVAR5izPw8jfvdNOfAAYabrdVINT8cjAsAv jVBw36XqW2BS5UBi1eTXL5oZsVqSrTSOoASe8/cQMddStUeV+SroQpv496TfBv11on0c r0HKI/5J3mavjOykw6vaol3LJfMz3cJQHv8RhIEDItk+3v21D300DGEg6cZ+TkwvCMkw HhQWgAOCGiiTIMYgvZoJv+LLtO32lD+l0emycJNa08cdhJUiZvcZRQgKpzBcwXx35Og1 h+B0YJcnr8LWLKbzELXBLUJBvUGb/PEGD6+JPQ3KBxrBcmpysnKKZuGDtr5Hf5iG/QiQ nNkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ba5PQ+wmyMRhn7kIB8P/lUeh6yaaxiwndDAxsFbqQ6I=; b=fgKw8OItldJKmb1NAbl832E5DEUtN737ug9m6Ag86tgGeqf619KP3TWt5UDi0fXEd1 gPxrz6fyV3ayKcsbcFkJ+FB2x/kRpdm/QsnEWdEXCZijdjeNGpC8/F/cvkWVMUDoXCSn Q4LyuWaWKEKUwqQzxy61lHOi20MH6K9MuCTA7Oa2B4j7/BFSh6gzqpD1K8kSqQy/rUKh BLHUF3e8xHxuRcozCynDwka2qEc4r5E3ma9+l/DMeMbMHV8O0SbBWZ7Wryn9P/vxf1Hh zCA6dUFVtKRkrviFqnqIcOnnsV623W70J04/+6R6r9u+nJ3Wl9wp6vmncRA6FdMYfYv6 Hg1g==
X-Gm-Message-State: AOPr4FXwCYB5vj51UIw46zO8Ns7zaNjAo3kqvNwImzM7mcLDXq4pHvfz6/+J3JFUN6JMDLMnmPr4rQujVeUO8A==
MIME-Version: 1.0
X-Received: by 10.176.0.202 with SMTP id 68mr6422172uaj.33.1463400472688; Mon, 16 May 2016 05:07:52 -0700 (PDT)
Received: by 10.176.7.101 with HTTP; Mon, 16 May 2016 05:07:52 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 16 May 2016 08:07:52 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: draft-ietf-mmusic-msid.all@ietf.org
Content-Type: multipart/alternative; boundary=001a113e070656c0130532f479e6
Archived-At: 
Cc: The IESG , secdir@ietf.org
Subject: [secdir] Fwd:  SecDir review of draft-ietf-mmusic-msid-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 12:07:55 -0000

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

Re-sending because the original message bounced back (complaining about
draft-ietf-mmusic-msid-13.all@ietf.org email).

Regards,
 Rifaat



---------- Forwarded message ----------
From: Rifaat Shekh-Yusef 
Date: Fri, May 13, 2016 at 10:38 AM
Subject: [secdir] SecDir review of draft-ietf-mmusic-msid-13
To: The IESG , secdir@ietf.org,
draft-ietf-mmusic-msid-13.all@ietf.org


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: *Ready*

This is a Standard Track document that defines an RTP media streams
grouping mechanism in SDP.

The Security Consideration section clearly describes the potential attacks
introduced by this new mechanism, and points out the general issue of SDP
modification by untrusted entities, and potential issue with the buffering
required by mechanism suggested by the draft.

Regards,
 Rifaat

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


Re-sending because the original message bounced back =
(complaining about draft-ietf-mmusic-msid-13.all@ietf.org email).

Regards,
=C2=A0Rifaat



<=
div class=3D"gmail_quote">---------- Forwarded message ----------
From: =
Rifaat Shekh-Yusef <=
rifaat.ietf@gmail.com>
Date: Fri, May 13, 2016 at 10:38 AM
Subject: [secdir] SecDir revie=
w of draft-ietf-mmusic-msid-13
To: The IESG <iesg@ietf.org>, secdir@i=
etf.org, draf=
t-ietf-mmusic-msid-13.all@ietf.org


I h=
ave reviewed this document as part of the security directorate's
<=
div>ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of =
the
security area directors.=C2=A0 Document editors and WG chairs=
 should treat
these comments just like any other last call commen=
ts.

Summary: Ready

This is a Standard Track document that defines an RTP media streams
<=
div>grouping mechanism in SDP.

The Security Consid=
eration section clearly describes the potential attacks=C2=A0
int=
roduced by this new mechanism, and points out the general issue of SDP=C2=
=A0
modification by untrusted entities, and potential issue with =
the buffering=C2=A0
required by mechanism suggested by the draft.=


Regards,
=C2=A0Rifaat






--001a113e070656c0130532f479e6--


From nobody Tue May 17 01:31:16 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537CC12B048; Tue, 17 May 2016 01:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBYCtvSPmIeD; Tue, 17 May 2016 01:31:08 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) by ietfa.amsl.com (Postfix) with ESMTP id BBC6012B00C; Tue, 17 May 2016 01:31:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400";  d="scan'208";a="3480013"
X-IPAS-Result: A2EyAgDQ1TpX/wYBeApdHAGDGoFTBrlvAQ2BdoYRAoE0OBQBAQEBAQEBA2InhEMBAQEDeRACAQUDDRUdBzIUEQIEAQ0FCIgnwxYBAQEBAQEEAQEBAQEBASCKcoRBgymCLgEEjheFGYR5jwSBBIRPgx4MhTePQh4BAUKDbDwyAYcGAX4BAQE
From: Kuhn Nicolas 
To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-aqm-eval-guidelines.all@tools.ietf.org" 
Thread-Topic: Secdir review of draft-ietf-aqm-eval-guidelines-11
Thread-Index: AQHRoIyZ3aFSg9THzUGEGUMXQuD6up+860sg
Date: Tue, 17 May 2016 08:31:05 +0000
Message-ID: 
References: <22304.47475.765923.579337@fireball.acr.fi>
In-Reply-To: <22304.47475.765923.579337@fireball.acr.fi>
Accept-Language: en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22326.006
x-tm-as-result: No--37.596500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Mirja Kuehlewind \(IETF\)" 
Subject: Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 08:31:10 -0000

Dear Tero,=20

Thanks a lot for your review. If you believe that your proposed changes on =
the references format should deserve changes in the document and a new ID, =
please let us know, we would try to integrate them ASAP.=20

Kind regards,

The authors.

-----Message d'origine-----
De=A0: Tero Kivinen [mailto:kivinen@iki.fi]=20
Envoy=E9=A0: mercredi 27 avril 2016 15:07
=C0=A0: iesg@ietf.org; secdir@ietf.org; draft-ietf-aqm-eval-guidelines.all@=
tools.ietf.org
Objet=A0: Secdir review of draft-ietf-aqm-eval-guidelines-11

I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.

Summary: ready with nits.

This document describes various criteria for doing characterizations of act=
ive queue management schemes. As this is not really a protocol document the=
re is not that much of security issues that could raise from here. The secu=
rity considerations section says

   Some security considerations for AQM are identified in [RFC7567].This
   document, by itself, presents no new privacy nor security issues.

and I agree with that.

As for nits, the document uses very heavily references in a format where it=
 makes document very hard to read. The references are used in such way, tha=
t if they are removed or hidden, the whole document comes completely unread=
able. I think the references should only provide extra information, and the=
 document should be readable even if you remove everything between [], but =
in this case the text comes like
this:

   An AQM scheme SHOULD adhere to the recommendations outlined in
   [], and SHOULD NOT provide undue advantage to flows with
   smaller packets [].

Also references style (i.e. whether it is [RFCxxxx] or [1]) should not affe=
ct the document readability, but in this case it makes things very hard to =
read when text is like:

   [1] separately describes the AQM algorithm implemented in a
   router from the scheduling of packets sent by the router.

When you are reading the document and you do not remember what [1] (or
[RFC7567]) actually is it forces you to go and check the reference section =
to see what this document is.

It would be better if the text would be expanded so that the actual text is=
 readable even if you remove all references, i.e. the first example would c=
ome:

   An AQM scheme SHOULD adhere to the recommendations outlined in Byte
   and Packet Congestion Notification document [RFC7141], and SHOULD
   NOT provide undue advantage to flows with smaller packets.

(I have no idea why the second reference was there at all, it might be usef=
ul if it provided section talking about that, but as the whole document is =
"IETF Recommendations Regarding Active Queue Management", I do not think it=
 relates only to the smaller packets.
--
kivinen@iki.fi


From nobody Tue May 17 03:53:44 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89E12D787; Tue, 17 May 2016 03:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MAie3VhAsz9; Tue, 17 May 2016 03:53:32 -0700 (PDT)
Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) by ietfa.amsl.com (Postfix) with ESMTP id B896212D761; Tue, 17 May 2016 03:53:28 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.26,324,1459814400"; d="pdf'?scan'208"; a="3402563"
X-IPAS-Result: A2E5AwC39jpX/wIBeApcHAGDGoFTBqxljQgOgXYohWkCgTM4FAEBAQEBAQEDYieEQwEBAQNFNBACAQUDDRUdBwIYGBQRAgQBDQUIBoghw2gBAQEBAQEBAQIBAQEBAQETDopyhBERAR6DKYIuBY4XhRmCIoJXgyqLWoEEhE+DHgyFN49CHgFDg2w8MgGGUDYBfgEBAQ
From: Kuhn Nicolas 
To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-aqm-eval-guidelines.all@tools.ietf.org" 
Thread-Topic: Secdir review of draft-ietf-aqm-eval-guidelines-11
Thread-Index: AQHRoIyZ3aFSg9THzUGEGUMXQuD6up+860sggAAoC5A=
Date: Tue, 17 May 2016 10:53:25 +0000
Message-ID: 
References: <22304.47475.765923.579337@fireball.acr.fi> 
Accept-Language: en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22326.006
x-tm-as-result: No--42.441600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/mixed; boundary="_002_F3B0A07CFD358240926B78A680E166FF8DAF35TWMBXP03cnesnetad_"
MIME-Version: 1.0
Archived-At: 
Cc: "Mirja Kuehlewind \(IETF\)" 
Subject: Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 10:53:42 -0000

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

Hi again,=20

FYI, attached to this email is what could be a new ID for the document.=20

Kind regards,

Nicolas



-----Message d'origine-----
De=A0: Kuhn Nicolas=20
Envoy=E9=A0: mardi 17 mai 2016 10:31
=C0=A0: 'Tero Kivinen'; iesg@ietf.org; secdir@ietf.org; draft-ietf-aqm-eval=
-guidelines.all@tools.ietf.org
Cc=A0: 'Mirja Kuehlewind (IETF)'
Objet=A0: RE: Secdir review of draft-ietf-aqm-eval-guidelines-11

Dear Tero,=20

Thanks a lot for your review. If you believe that your proposed changes on =
the references format should deserve changes in the document and a new ID, =
please let us know, we would try to integrate them ASAP.=20

Kind regards,

The authors.

-----Message d'origine-----
De=A0: Tero Kivinen [mailto:kivinen@iki.fi] Envoy=E9=A0: mercredi 27 avril =
2016 15:07 =C0=A0: iesg@ietf.org; secdir@ietf.org; draft-ietf-aqm-eval-guid=
elines.all@tools.ietf.org
Objet=A0: Secdir review of draft-ietf-aqm-eval-guidelines-11

I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.

Summary: ready with nits.

This document describes various criteria for doing characterizations of act=
ive queue management schemes. As this is not really a protocol document the=
re is not that much of security issues that could raise from here. The secu=
rity considerations section says

   Some security considerations for AQM are identified in [RFC7567].This
   document, by itself, presents no new privacy nor security issues.

and I agree with that.

As for nits, the document uses very heavily references in a format where it=
 makes document very hard to read. The references are used in such way, tha=
t if they are removed or hidden, the whole document comes completely unread=
able. I think the references should only provide extra information, and the=
 document should be readable even if you remove everything between [], but =
in this case the text comes like
this:

   An AQM scheme SHOULD adhere to the recommendations outlined in
   [], and SHOULD NOT provide undue advantage to flows with
   smaller packets [].

Also references style (i.e. whether it is [RFCxxxx] or [1]) should not affe=
ct the document readability, but in this case it makes things very hard to =
read when text is like:

   [1] separately describes the AQM algorithm implemented in a
   router from the scheduling of packets sent by the router.

When you are reading the document and you do not remember what [1] (or
[RFC7567]) actually is it forces you to go and check the reference section =
to see what this document is.

It would be better if the text would be expanded so that the actual text is=
 readable even if you remove all references, i.e. the first example would c=
ome:

   An AQM scheme SHOULD adhere to the recommendations outlined in Byte
   and Packet Congestion Notification document [RFC7141], and SHOULD
   NOT provide undue advantage to flows with smaller packets.

(I have no idea why the second reference was there at all, it might be usef=
ul if it provided section talking about that, but as the whole document is =
"IETF Recommendations Regarding Active Queue Management", I do not think it=
 relates only to the smaller packets.
--
kivinen@iki.fi

--_002_F3B0A07CFD358240926B78A680E166FF8DAF35TWMBXP03cnesnetad_
Content-Type: application/pdf; name="draft-ietf-aqm-eval-guidelines-12.pdf"
Content-Description: draft-ietf-aqm-eval-guidelines-12.pdf
Content-Disposition: attachment;
	filename="draft-ietf-aqm-eval-guidelines-12.pdf"; size=58484;
	creation-date="Tue, 17 May 2016 10:53:05 GMT";
	modification-date="Tue, 17 May 2016 10:53:05 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nKVWTVPjRhC9+1d07WWhCsvYVBZ2byx4U1TA4UN7inMYSW1pYDQjZkYG59fn
zVg2NjhLkpUPVknq7tev32vpkQ6TIR2GX/ef173B7TGVrndIZe+xN4w3qfvLa/qa4oETGo4onfWW
MUMaHdHx0WdK697ehfZsNXsa61JqZit1SalwD/TN2JzpR8ckod/aSh/QuEj20/ve8IjSy5eU/XMr
Zv6HGbrjbDK+O6CUFecGkC17UWre/7jMpQsuyHnhW/eFLvTM2Fp4abRQ/5jwOqGJ8MKKe9HBQ67x
cyMtI8fEzLnO2NLw5IBGh8NP7wOULjd0t3Ceaxdy/Zuudh6Bs0oUXMs1rv+X6LuWc7ZO+gWZGf3u
lPkpXOvjPKFb8197vJN1qwTdsmNh84ouRWas8MYu6PTuZ3FdiQUNj5eTQq4g3MvdGU9vruiswthz
KFD+FVVCv7ayYAVth6Y6ie6ILYJY+5L9rC8e6z7PheqX69D+cITo0acYfZo5H2p0jX3XtdCihEiV
sCVT1s5mmAxJTd4UYvHREdzwZOyDo0rMmUpMTpOVjvEACXKKn7awYaAN2yh0DQ9K51p2CVFageAd
tygXmjImURQQuAOSbNGBc6ZmCo+HpKe5R2m6abll0BpA16w9TffA3HSfas4roaWrD8g0S4upBfro
csGcmdRLVp+krwC9EfkDlofLKy5aFXZHOEVJ10IGwtFMSEuPKIh7K7WnlXRUmLyNxQt2uZUZupgL
K02LbqwM8xMB96pbhK9QvBqwi51h8svKLnkZ1F1cGuF+LHnFtdmE8GpR4Yprs1p6DwIxvFmrFHrW
a7Jjz77irVk11sylW+H4enZNxyckdLE8/byBBg9vV3QkLLJCGIG4FSExD6rQrtW8VXpjTU/3Lsbp
t+k+RDIxHrqqhCeDLJZKa9rGUQ0XCeUMFRLqlVnruePiLQDxmptOfKQQG+DlrbVhduunulRdW2AS
5Svvmy+DQYFFHOzywDYJ9kqMLQfRbW7Q5Rm8z1IM2IAIe8oiCkSgtWfsn6hwJ5+pNtpX22YP8wgE
wCNtA0BcHJDlRok8nCGJyZxR7KNzOt426PBIsDKUlzWDjYuoF7ihgQAaiNVHM7eO38J3qIWNwNBQ
lwQvsCBwFUojKpdxZFx3pTE9HcI+hNEEKaJGGZydfNgiapeKnyRUy/FVR/Dpm3ddNOGZaRZWlpUP
apFrWC+Xp3s59kF8NwZhUWpb5yONQZnwpAuCx3bUXs4kaAPa185YO1y0vjI2aOgU2GKBQIljO+ci
edvROnDpyHvOfWBpw1vRHmtcWLCXXAq1Vf36xZe3rLApoHAkiVHnq9F2fU/3Oq36kI75RacK5GjH
fYktAEIwCsZyBx5QG0AELUF3yPPLKFZefhDBtEIlm6+X7uPj3W+PP66xlGn4JzKO094Nfn8Dt8fV
omVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagoxMDczCmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGgg
MTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydl01z4jgQhu/8ir7tTBWw2ASS
HCcJk9paMsUk3tPWHhRZNpq1JUeSIeTXT7eMg0gyi71QBYU/Hr/9qrvVPMFkHMGE3vtvXg5+vz+H
3A4mkA+eBpE/CfsvXsJVghdcQBRDkg2aeyKIp3B+fgFJOfj0h3LCKOFGN4ZlDprXl+93cL1mhnE8
KV+Yk1rBbS1TUUglLASvO7aDeBLNPyc/BtNLSJaDT3i0qh8LyZv7dAZuLS2kmtelUG4MsCoEswKM
2EixxbMCf7Sn7effBtG0BXFmRFYXxW4IzNKVO0iF5UY+Ctjp2oCR+dpZYCpFnHVGcnqoha10azpS
Ce6QSCyn3wm51qnAj7LSih4N4tn5oFPIjC6PL4eyti1KKl7UeOuDLKtCZhJvuHq4gaXkQmEsDjmk
t5Wa4g3wILw0OBsL9KTVtBaQGATDUuSsgJXRG2l9BBQSRg8VHUqRQSHp2sGWGcOU2+ET9pSj5xDy
Y11jvDyee2sT9liQDAweE6BxnUgRmoIpYXRaN2ph3PMNMD1aQWIS9V4gUqrc6ysYPpTvfIwle5al
fGlP5VqnFUYZEmd7dcSK8cCtZoV9l1hdtB6zpl7XUy2N8KkHS6bymuWiY6TzgHVGugptLTO7/+Na
y6L4FiodOT0S5I6gnLZ9iADnr7pi7/3XQm+BY5oXwi+qk6XoRjxmxS3LOmYc1FUPErEuAhZ5v2L8
X+GAXOvtV8g6e8OyO8XXRqu2dZ1iXQasmc+vtznYXVfImuOBZZDqP6TDhtrZr2gSsM7xwI20vLbW
d9Wm0LFdpWKkswwehdsKoY5K61BLBxb5fisU9nUOVjhcw0wbEBtW1Kxpnad1Ra+6pj6/El3pQufN
Q5V2e1CnGEMW5ddVnWXokZUv3aowZE0D1tS3d5XjpkB+cU1dreiaZwcW5dadwM6b+hCH9IMqctjs
klhUzEiL4Q7bFHxA6Xb4KgXgga+x+RXU4cigxfW3XuUcnb2yzrzdgZzeFoWs2FtUNq0PPWp7TYm7
c920xM6sxm5vBoZJ1liMuhTdDIdoFvhFNIpzJQzmZskUF757NUaf8u49i+K8EVWhdz6kAHVa1zyI
MWgzlJ7NFs0POYaZj3vufuw5wZo1G62gcYMu9/NK58w4Zs0/YgVJd4rVtnjSlOBoYSuN3R1HEad5
95I5ZhHNt4br1SgzEreyYof9RqVY211ZF8E6Eu1XPB8vdUPLcDeSSjqJo9RhYQJM+9pKleI+1iO0
jyXF/yUpldTKKOV6aOq9EwaaZl7PlzzHwdfKjd8e9qvZyXqILgMWlfRfimZo7G69accsKp0lihq5
NVNwhR7AIssI9Q76EStudy9K9XtdY90lRlaQ0PjxlUn8B2M7zkgHFtF8O8Wy3fyiaPuwYj9Nct9Q
aV53GGX31YSYdsJZ7OfmP+u1GgL2GVaMwxRZPFc4q1r4pjeifESzoouh//v1JpX+XtEQG/+DxEUy
+I7vn+sLZcdlbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjExMTIKZW5kb2JqCjE3IDAgb2JqCjw8
L0xlbmd0aCAxOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK2XQXfiNhDH73yK
uW3yHqHYbIAcSUK7vG5SQmgvSQ7CFqBGlrySTJZ++v4l24SQ5BWS4gMgWz/9ZzSaGf+gdiuitr+q
7yRr/DLp0cI22rRo/GhE4SZVX0lG51M80Kcopum8Uc6JKO5Qr9enadY4GinHjeLu5NKwuaPyM7i5
ooslMyzBTfEPc0Ir+q0QKZdCcUtbnyu2prgddY+nfzc6ZzT93jgK491Wp4W73BmRWHKa+IrJgjlO
bslpMp3SnAksbEFrvXFRHB1/aUSdmtjD0HlhrKPBzGqTB0lvznzvKomlul4r8uq0Eyt2OGmXFWNg
whOdZVylPCXHrbMHsOKK1cefW8dmQgq3PlBRzepsdPU/beM267M2PrNKmtd2yedCiaBNz0NcJFot
APYj3/mKy7c0U/x1h+W1XQmZbk/fV9cuq4zaVBTZobTXrK8Y/MbZar2N2pN1usM6xeBfzKyFWux6
Sr7nqfdY3S0WWzEh2UyCyHKW+MDbU1c/+GqMLJFxpAmyXFls5sojmErJbiKZKSbXVuycdIq7Feus
1CN0YWmKNDQXCY2NngvJ38kOr3X1NrrOQmzVnEz83DMW3mb52DoXJ6kwPPHeZpJchT6IFbVbdFVI
J058cr1NuPIGH3ImKe5vdIG2c7gPtfEFKw6H0SESLIHl46tK1x5ta7H/xYqgaZTlkiNHuHJuopGx
P6gr+h9tjF4lsFTYpLB2Py7FZ7WN4PyRc8OcNnShlTNahnAfFE6fuEL5Q7UnK9A+aeML1uds7LRr
G3GwYVoiC/uBurHDQhIcJI9KP0meLkJk7Hmmn1l1rY1OW6XLxQzONgdydlhIgqPB9cADLRobE9y/
f0XzrLpuR2hObnlSGJ/sPsTbYqEJmPA5N1wl+2a/91iB5uPrWpsMelZ8G/0Blo+vkZp/jEaduj7i
qCyxfV9okKYGHeDhdlLH16G4G7rDKKjCQUyLkKLrVZKg8abgBUebqlgZfXR/hAx8f0x3k18veqfd
3gOxjYyqsiZoie2L9hP5z/qTPTc6oyL8LJTisNzillyTZGbBQyIoVBYWS2lWzOEf3/1WkkSWGw1N
6LeftHkMj7M8lyIpDz/ySnAuBPhWEHXdoN74gsHkQiO8lpmtUEsGzoxzTDI61xbLiTJz5wwpd82Z
sU3KfPpVGpUYEidYDuqHzMh1RUHSL8savDIZXt4fN+n8+5/DZlA29mBTFT3/nrDwapIy50lU/Puj
8chPwcMVL9OGEyol/Cz9UbhEY3J3Pbr4hleE+KGkjoZ0Nx5cY6TzEHaOFlx5Q5tevuUV6tliYmEn
ART+ZQX/6Ak3grEo88pmosxxdTqGcKcTLSvS/dH0YowND95Wa9KYaHwVV9bb5x0YHgeQOUp5LvUa
i261WBWoMh0FcYlQ8i815U4HJSzTBaILjWzKHPNDa3rkPK+3pdrzVsWa+imb3quMFLLowHg9wejC
+egJvRQMxqKW7FIXaHRn3kuncYjO34ulahJ38Fhr+81s+DNH02Jx+Fc8m4Ee9ZvhVY1efu7G3oTO
A4jDaeMG178bLHMcZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iagoxMTY1CmVuZG9iagoyMiAwIG9i
ago8PC9MZW5ndGggMjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxtVsty20YQ
vPMrpnyxVUXKopxYztGyZcUVO+UHq3SwfVgCA2AjYBfaB2n669Ozu+BDCXWgJCxmenp6evaBLs6X
dCE/5bsaZs+/XFHrZxfUzh5my/SQylc10PUKB17R8pJWzSy/s6TLF3R19YpWw+zZexPYGQ6Lt041
gfLn9eeP9KZTTlV4qH+poK2h26hr7rVhT0efj2pHlxfLl2erf2Yv/qDVh9kz/LdXrmViY2PbUbCk
qsoOg61VYAodk++sCwsEH2gdmwZJTEuOH6J2PLAJ/vzs6Wz5YgoneHzV4ZEnpQdSAYfrWMlb+X2y
VRVHZardnJSpJYnjxrqcjk29QEAJFewCfxEqUbtzoq92YLKNnPJMqm+t06Eb/JyMDWrd7+jLzds5
dWojT72lNbMpobbCx470MPYJNNekDXmJCEK31t0jzUZX7JHoT7vlDbt5wjPagPNa9SXSmg03OviC
RHKWenNmYEmJUbXq9S8k8tpU+Zz2JYjjEaTiWRCUFH1UPeCFiPbWiNwIp5cv95xOzGlwSmO387pS
PW1sHzMlAw/W7aSkbaerDoceIkc8cuQ54MRJi9IzRALjPoD3GjXfdYDsR1b30iiEVPJXpRtdlVgI
Hrp9BbWtohA5pyePu/oE5eEfXooThtRgoxEQBE0p+v5sYOUj0pZQCLzeBQAC2lFV9xz89zO8CeUI
xJSXM4i9YOjJoH7qIU6aLKE8CH+c/vTgASaKfo+Stzqge14CT82xEWqHrBS1vV2D6EKvBzqWHtgm
CFuYOnRrDf1Iv1OpG6V7SJH3pSFSg7f8hDz6+f+hEuCEGcCpHbV6g3j7d0usAdO7UYBhoc0UI+iB
T4VynaKtewvuvl1fY9iXPwSwnK6s8ZhaFjFKL3js7U6anQ0gmkEZ1aauHKSS4aHiXN/kQLRYpL8P
htCpiZYk/qnFaMJ+bkieCubU6S6aOh1I/0gYpCplMJBcJ01+SMCOGPIHxcCj1tpkt0MLO1q9+SQU
P0foaBz7EeWCR2p6u/V4o8I8emQSf4GxlEjH/rKCuqEdH/sgL2DyRZDogXWgpsr96WGLEM/CM8IH
JCiB1Dj2GErB48lHmUGfLGAhBdKAoPiuteifz9vzOaYXdoMvOJOdlyitGkDmnDhU388SJAa81jGL
mvNsyxCSAicVYMKn0ZDJw/DuVBfseczzyWmOk7+IBDC1btE6VfPh0FOIcnQWLg2C8AsEPExcs2gx
MZzWgkGY6NG3La/hLW7yzNeVkFGsIitJIh8sT6QPLD6bqZQDNMHZPr0jEkp9SGNSc+7W3psL66di
F3JK2s8p7cdDWonyKXkJfcV417GXDHeZI7rFiI9oBHbVidrvbmE8WzSuwmhD6dmgVQ2h+jxEEzmZ
kf9OzvHM6NOZkQ1WHFWakW1AtuXdbRpR5e+FVsSdzCygCuVq/UswH+/V5I2yaFI7Jnzgs0Kmgk00
eApojl9C3oziq6gk+gD0UBCsTjak+IvmsBN/sFA+5LxXFKLXOsl7GpVpBQgpouJM28k9pD3cQwTz
FEqZvPUKvxBFobdM0Vr3OoCh4+E7+HN2rnIorSoj7MwxHyx3CdIiO8lS63SLkbk9kJmQTVMb6P3N
6p34Eeh8tHRB+P6S8fjmoMqWmGrxPKJ0edg4O0gtJ8LyBw0Cb1lyJLNACIP1l6ovIb99effm6veX
Vz+KAaC5ZYXnOUJtspAerbkEV64HtbPjiEzPB5XVPlpwuksPJ2UVtNSwwp0jmYssnv3KOQacRfe4
6UdLaS275YieJD8FPqUX1jCdCiFtudTyY3Ed3HxP0DEImWdUKBeVdMXiPAPZaB9dSQCg71EL0mvR
e5/4OUaQW3Qi4T7KFWA36aLOWodR+YoNpsKKm/e8UTjc7C8qJzwV05eFc5hgt8lV4c0+lgKdqAlz
Ml0hTRzWQlUjW7TDlCZ5iBrl4g8F/RU7I0sBxZwfX+hvfo64hHv6G1eCFGL5ap5u+HT6+fYJ9kS/
/UDEm9XsM37+BdL3LrFlbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjE1MDUKZW5kb2JqCjI3IDAg
b2JqCjw8L0xlbmd0aCAyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1WwXLb
NhC96yv2VntGZi1nEru5JU2ayTTJJKlmcqh7AMmliJgEGACULH993oKgSCnOTHut5BnJhPCw+97b
XXyjy2xFl/JOn0W7+PXzNW384pI2i2+LVVyk9FG09HKNH9zQ6orW1WLYs6KrJ3R9fUPrdnH21gR2
hsPFK6eqQMPrxaf39HutnCqwqB9U0NbQm16X3GjDnmav92pPV5erZ+frr4snv9H63eJsla0yos9c
9oU2Gwo1U6MCm2JPypTUqnvd6odxaWNt2fXh/JfF1bO4HaBrPA9OlXxhq4pyDjtmQ+4/I66ejIja
kzbBaeN1oZpmT0jkjksKllgVdczYFzW3HBHx8zvex9WtanoQYDbAi0jBU8eusq5VpmBkusavjO8d
x9O9qjjsqeSusfuWTSBbAVNOWMrmBJNzrbba9o58bfumxANS3jP+cLwhRVvltCBhuy/Y4D/rcdqX
mg1v2SWcznqv84aX5G3Ti1CebL+pgwSvdEsqUG5DPScpESSZJpRWm3ExEZtNgqyyK5z7xqrGSzCh
BjulLXpJLu1fz59BqMK2+FZ6pLFBuE4XINyHo1xIbRT0CLSrNRRQ5kgwEaRzFumpZkZRkoPLJRVI
FY50EnTMsLOIPGjVjNRMKpEcFZVN8iCQSaFscNxmMnjNTQcCE9C3XgG32h8hAmEyjbiLUCttZGj0
ZjSsSLJMQCPxSYuhriSq8Kjh8dTj+c4OASaQA82dw7KBHcEoNjfwT8dF8JPhSDUb63SoW2DBCAce
E9RIISy3w7rYKoaC54HvAzzVizKe8t5BKJV767oYdKE6VeiwHzP7vF5TpTQ6icf5Dql73WgWouDD
qgEPQxURes3Oujs5o9TRr0fZzUSA3yyV2hc9MFsOtYWhgNYbhOzDyJvUie39mH3CQS3ZQotTaAcC
ou7NWJYSh2y3EHSISoAmOWNEvR+Ts4YH43PsCjb/ioP0FiGiijVwxBR9MyHNktB+8lF0lUIBuCB2
3NXICYwrksh1hSKRELDDWJSKQbhwQoiaQM8S1XCRkLC/odsznSFUSc/CVFFvk9JV9PLVxwuvH5B/
3lcVu9tzfAkDqULGFNbAyfPTyAuciYrr/dAmUdKdQo/z4hKYbV6gI+nx6NhPrWS2jCdOxXsKpaYK
jztPM8xOhoIWG7TwBMuqP7SW4nRU/aTHHDUYZfb/osloByd3g9zigVEzWBwijV4zo3DRlcqVA+/7
SOnb1+s/spMW6ec9MhzM77jB2SjtWQIy3xiTq4jez3lWtKlvnfTi/01bOL0S+CN7ljaWSckV/o00
iaXkUW57E30GfykXdIHSdEfaz4bzyLREN856JBKsbTzLZHgL+7AqT6pjZOq4RmSAuxB/ehhGw+gB
93L/sOkGk3RA3xjtLlsOweI+sdXOGolwmeaj9gkEuvg43ePQwHc0w+wwhx9nqbCioQi5P9wYki+i
LY6Jip4eLZL9HDU5bfTFBWiFoScnTi6+PRstc3N5la1W9OXdiw9+SaUK6kJ8ihyiP3oxbO6sKvPp
dpK84W/Ph9vWHXN32q1SL1giF9O3uZRo9cONwKFPYkX6D3q61Ej0zZjqPM5Xuqr+YrdF2xRf2Vaj
E5c/eBIj/bFrUTRGwAgRd/i+bUGDtAQAV7Zp7M4/B9KzpxHpz742S2Lpzdn8av36vtNgmD5AvJjR
6mYZ79p0/Pr7o9owPf0HiK/Xi094fweOhgxkZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoxMjg4
CmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz
dHJlYW0KeJydVsty2zgQvOsrpnxZucpWTHljO8rJr826IvkVuba2Ih8gcChiAxI0AEpmvn5nAOph
ybmEOhAigJ6Z7saQL3DUS+CIf+1dFp0Pj6cwc50jmHVeOkmYhPYmC7gY04IzSPowzjpxTwL9Yzg9
PYNx0enelB5tif7wyorMQ7zOH0ZwmQsrJE2qn8IrU8KXWqWoVYkONq6RaKB/lJzsj//rHH+C8bDT
pacGYJwjVBYdlh7kNtZsjVVZM6c/IKA05SG+5qJ2Xs1x/49OcrzEo0sr58Fk4CSWwirjwBvIUVcg
6JH1QpWwyNHnaEGUoQTlCJM2lbohtBZnip4SAZ/TotSa6pB2aph0F8rnlMTF1f2hUz8xhWmdZWgn
+wc08iC0M+BEhhR2DZZipU3zmdBwsyZJ2GHDFKF2hEWpSlNUwiI4nKMVmhNc4xAJlXG0BUIaKGQO
hkvp0Zr+yW/QOukmk33ggEzB1NRlyEJs00o5eSVrLSzgXOg6AnljtEOqmnZNun1C4pKW1WTGwpw1
qN02FUXIy5CpXr0jXtBRei7kkVlk8ogAjZKgV0FICk9abUpEUrta+TYWs4vlXFlTBvygtCKKaELZ
FXnEnda0eTsnTH+bRc5bUTFlGkVszbpNIu8QpcSQbWuwWKYqZ0s38pwAV6FUmZKbBX1eZ6z80rUW
X2plOSzT02KsSqVFrVyBI63NgkKtcYgZ98aSHF15B86TpsKmbbEbzCS94x7AYwzLaTkYinJWi9mS
UWbtBzawMDZ1sDd6+jbeO4h3uL0L48frh6ebx+srHn/7+3w4XA3iijfM0cTd07Bdy6M1yuXdaHR9
exWBRuf/0o29uHd3P765uz0f7rEJfL5yTWpkHbzBivlw8Fg3SyIzQ8KRF5y0akp/aOfjX5fQT5JP
8J1GPHh+Q8SfRMQXbZwTdtk5yDSiqrSSgbZDrYpgT09dk9QcsJ2bCrlBtY+ibqnBKGcudlsaiVqX
SyRR0BkNHS4Vng8HA5WOJnfcS04YhENxLrlTwkONNVInLsUscDDp0go+/XpmLPWTAlRR6aBpLH+n
C1hTs2fbQ+6QukJ0ljVFiORkjmmt2c6UYSXkD2QzcbRpwyvW1otYvWgXi7Frs1RQYGHoScYdgevj
CsjUJI4Irbgi+A9roELYHxywMkR7E5ctU4MMha+j1qJsotiZkJuZrpH4WYFB7NOPJ6fPO4xS1x/A
BTlsoVLqv1eo6bV2b01ay0B/uyy+EljsKm8ceUHD3GgyHpfI1dlm3ZwEvARdDPcCJmGb9DAde4zz
xr7TpmI8MFLWFfWXZrDjktAbVgBB23bXwXa4AoWr20XThjozZ9Yq+avI/CYckBCvqqiLnXQOlq07
SLlcFVPcjv4m44LYnb6b9LtZbrwnf5HuzT/J0QDGl/e0TXlFutA7aEbe435OnTE1iyACuYU+jTZQ
Tj4GlK91Xh4Av/B0b/Pr5vq1ombo4NbMsZhS7cnZQfjcgbfX93vqknDyTIjX484D/f4HNsf5imVu
ZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTEzMgplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4
IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVZNb+M2EL37V8ytDmA7sVMkaYAe
utkkWLS722TdU5wDI1EWG4lU+GHH++v7hqRiObtAZcCWxeGbj/dmqBc6mc3phD/5t2hHx/fntHaj
E1qPXkbzuEj5p2jpwxIGFzRf0LIapT1zWpzS+fkFLdvR+JP20mrppx+tqDyl64+7z3RVCysKLKrv
wiuj6TaoUjZKS0eD67PY0eJkfna0/Hd0+hst/xqN8dQQNcJLXewuyWg53cIKm/FtKupE8Sy9I1FY
4xz1EeC5r92MaFkrd/TLaH7ao+EqZaW0inG4oLDZW6FdZ6yHo520QwO48LXsA5jgj/DAy0iuFk1D
2nh6klQYXQUnS9oqX5PQJLquUUVKOAFvlNxmyD1Ixp7hyeJskPTamLIL/rK/IeVSZHAhXAxLh/YJ
sEB84jw63AcEHl2oVr5PvDJ2K2yJ/d7E/YWxVhYesM4rnSJtlQ6op94lzMY44Nl9uFbGcrXKewA9
3N9cLc5+PX/8Ifxvd/fLy+jFvQRhJVmDOlVBF+xmlgFheP/1ny8fk6U1QZeHNguQeK3LqTdTibUW
3lXh8u7BQlKESnWx0oUmlqGzphPrlFk0mZCDDEWTlXhQor3BRhWyhwSR5MBpUU/gvlShnYqikM5l
AwHvL0EGpdc5rB4ntLAnswEtkS3pt8Y+k2xkKzWLtjF6HZdYrrPUK66osdxn2MKBlWVAOGyX/WTP
TzvOb6NKfuTUWovG9dQ6FIWloTMQPwOuXUNrkisDua6ZdqMn9AR1MeOqRT+hbjqa97prg2OBZ6AC
XFahaXaM4NDGCC83GpxG4hCVdDFDhsmUxdbBntCUGQk9E/sFET9JqMkiPaG9qna0Gs9XR5lKJN+3
4lsbrsaL1dFbiV5V2w8WGPVhMy+r8WnGgWhLOTVVxb62UsYUHZ5vTa/FdylwYTGftLEtsDccyktQ
NnOHXnqXGTr+rUh9XsI5FkqkWNqKoXL5Yb1n+7B5vpl2X7VGOe4zxfEOwuOG4rnDAyy5kpDZjvyu
Y/gDWSP1qlIFROOFanqw2CVpVDBwaYrAmYHKTz73EYg2yU9OS0vWvWA/BhEKF7DMIzCPyco0jdmy
GnP4qa2L2kAO+dlA2HlwWjTEBsTvpxKm+KvvQbHWhMSuK6QWVhnwKmfr2SRjZVnQBhO/Z3/PtzqY
xNMGYoklS1XJED2yWx2hAnw8RaJQhyyEMjIuRVHnPAacLWZzbLpB6oi97RoZg80TOCkLtfnJMuND
CGg7HD5cgaFIkpvoNp0Xe0bR21NIzNK2TkJO6E59j5Dx9JKz5PfHw4xt+7R5B1MBGpwJ9m00cPlU
lJrjQy/Eb0DnoFjsfftnKJFiwMmEcQkJNHAEtSGKq2yo8rCreMbEnjloAo6jH6CY2setwKzM5/tk
n+RPSlgqPsUwkfBG8fx2ug2wOriOeBxCZ6CFXV+MQRPmCZBTrGXT8TR9G1ZxQv1vQ5eyAzvsx7xj
ZjYQQ9TK1T6TJWeyGt9cLTGuEANaQvj9Ob1nFzaQKM+2wVzvNZ+lksxX41s2dLkp3eXBjIEnenCP
9DvdOHr4sPPykY6xh27xT/ljx38v0n1ajfOWX/QA8GeocWrgNUs0s+EL3PVrByocfcGZF99M5heT
+EZHh9fD32It6fwRiNfL0R0+/wEecGhvZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iagoxMjQ0CmVu
ZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl
YW0KeJyNVk1z2zYQvetX7K3JjKSYUmor7qm1k9ZTJ3VitZeMDxC4pBCRAA2AZpRf3weA1Ifl6ZQ6
UAIXD2/fvl3qkc6mGZ2FT3+X9ejNlwsq3eiMytHjKIsPqb/Jmn5bImBB2YyWxSjtyWg2p4uLBS3r
0asb7dlq9pNrKwpP6fr180e6WgsrJB6qH8Iro+n3VuVcKc2ODq6PYkuzs+z89fLbaP6OlrejV1i9
KcivlaOavVWS8K11nJM3xE+iaoVnPGdq2BbG1kJLJlNQxyvyVmhXsHXj1z+NsvkAqHwAcW1ZsvMJ
yQpAWJJGOxCzEdCrmkkz5ykkN52ujMhJVBXgAlCIMqtvLL3Dd+Gxv26MS3wCgUaUPCbh+gTEBvnW
xjI51ghTegBiW7vAGplZ4u/IRXFIBKga+x07p3T5X7R6JBZy3XOaYml2HpOeTWdTog+V6ch5YT21
TcTpNy0BW5w8DCLtDlyx75h1XLD82EI5WiOxVVhENv5I4cKaOobKCnl4EjqPP5HdExKMx7jAPlao
RkFy4cU0MRG1aSNeQIImjZAbRnhuTdMg6dUWeNFWNfwCSGVaV2GxKJB10l4oH/QKOppBmry1Ya1b
K0gUosKZO4/EbLTxiRznkczedZ1pqwHINSxVoSSMsKXCyBalS8oYHBgNHuyFUwB5/emeKmM2bePG
tLy6CzHa9UhBl/v7W5ytc7cO9jgq2hwk7mL2gHDDpoMVklDCSNnCNHpiTetht+i18EDVkC4Jwjqf
eDPB7ahOhz1Ts3Cthb7wsWXJCpU6YNPbxIeWsXT/x19/317vGzCS2fs2giSrJCAYO2hvNB+db4rk
sM70OrvLoxNN6rHmIOOo7+XziQArreDh6EztUZYhm6Pj9iaImkS6NeJ741VGl5PQigcnBXCwVGGy
IfW+BMHiJviYRb6dwDGQwEnWAnYLZqi2v7yUR0SBZLtuCvOGZeshUTyT3eULLdeZ51mk2H3iQ7an
9TqRLjoDW9JQSe3k4BRo1ldz0Ke33P7gtB+eFlS0WsZB3ldQt/UKVcYv7PK7lh363hsvhqG5Dx2i
3FCCUFJVrn3sQ3BEVgq8ctgG2lElVgYcjN3uxqYLbMexGLu+xmAt968XkT8pmSZy8u6pw6DJmuUm
jfAAxXDstqeH8Y0yWRS/MTqPQyVJ2gn3vCy923PqFPyJwY0V4YwWq6qv6dcvH65m54uzh+kLLDbM
TTwN4y/og/lypNE46nkQEJU3enJq8qbCePK8275jFgn8/Pbtw6lV/oc7x73KKJSoXPBSVYVmp1I0
z96xwSV9fx70T5T3H3NzF+ZugRkaCc3PsywSyrKLCPBnu9Zjgsiimh7+QXj/vVGAoU/miaOLssU4
/mOg4+vrHV68tHgA5Pvl6DM+/wJcBNRlZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iagoxMDQ3CmVu
ZG9iago0NyAwIG9iago8PC9MZW5ndGggNDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl
YW0KeJyNVl1z2jgUfedX3OlLkxmgQNokfcym6cduv8s+7CR5ELZsa2NLjiRD6a/vuZIMhnZnlrQD
A/LRveece6RHmk3nNOO/9J41o2dfL6h0oxmVo8fRPPxI6S1r6I8lFlzSfEHLYhSfmdPijC4uLmnZ
jE7eaS+tln7yyorCU3xdfflA15WwIsOP6ofwymh606lc1kpLR4PXB7GlxWx+frr8d3T2kpbvRyeL
6fMp0WeRPUhPtXGO3FZnlTU6QZ0+HS3Ow1IAfNKSSiNqMgUJHbYWdWms8lVDypE3VMm65XexNiqn
sjYrUQNjftZjHOEzVFGbDTZGE0qXJGhlvK+lltkDrbqikJawblOprCJfSd4WiIxlWmmFR5N3J7df
X18vzmYv78f86eLF+cX93SlaW+KBJ7ksrZRPeK82tDrhVhPIcUEr6TdS6lTVt7ef/n7/Cl+ScE7i
Xz6mDfpF/3n4YDqfgFJt1OkcJWdGO4hgA+j0gMb3v+GZRGPQfNy0gVDY8bET2qtCyZxWW3JyDbQj
MmtVVr7eUq6YJ6k9NdJblUGLSnjKROs7Kwc/C9fKzDumgut1opGpfOVcJ+n27dW3b4vZ7PIe5L01
G950TEqTlaKebIytc2whHFAb4LmAklVGZRKYCSrWAAo6rEYjqmmNi120bFSVwUMHBDmaTEhOyynY
rSQwbYIqYOJJaQXecpRRGNsk3+ikZbAtPIAauZaBecRaqFqs6r5DY0kbj75e4xOvbTvLhTEZLFx2
NEZjeLE0JgeNOlc5nHbYn4rdR5P/ImhobJzIYmOHHa1pjU2DFWrq7Y8ueFHsyVHepWEIQwkVtA9u
xp49u4K9Sh2I7RU8UEl+x3SoJJIZNid/NV8N8yUUYVfKW2G31OcNivKVo9s/r/6BM87vD938bpcF
LqtgCqZFrkXdga8c5XEboaxaFZIAh/IeSOq1QgGhvPGBp5VnBCzCkLVGYQIAgCmLjnamGYCsw+Pk
OkSDcFRA7x0biL8HbOy8iRYLU5UJ8DVoHxUm+/Rjz/ZcyyhKzwhG3VedY8sW/DwrCV11qIwHaafK
gJrF9AUUewP/tLuI4DQq4zdUCd4UO+ayCO4W0U66a1YceQVBB0cQEYkCUngjFaZ1zxXGYSNsjoeh
cJhEYy3mG5gOvMW+FctYiEzCjEqjDaG3ERut+/1sWHQgtGuUZ+FCoJ4/v7jvbRfKVNHa8rFToDZK
wvsihHskJ33XQiKZB9/FHKtjjPHB4Dg74pNRaswklZhYlmnnwqQKl89ptTmK0A8HUyV1PvFmgrcd
uxi0NdKFmyXRtiBF7c6bymxoI+vDKD3ycMMA3CFTwiMbXACkGuEVgCBMSCOdyXjO7MIhpGP+u6rQ
Ldtyr1eOPGjRxrNG2Icw/wYbbPfh0B8qqa5dSvL3hdxIe+SZlImM68KqPkfD2j5dWJ293s6FsIM5
VKN+9KSCAsxCn427wPq/hFzleTCLqOvt+JDdnijMI0zEUGDj5jsjwRHXiCJ2LxA/Gj7+Evzdyc31
x7tT6pkSrO0u+bAXMpiHMqad0d6aGqatxZarKXGCjHfP9jwo7bwU+f7k6vVgBhpUl3eZPB7LRPEh
fVzMPoczBB7bN+mOAm5+NQNnJNb0N6Y+Mwei7Sl7ikzFER6yCbc6N7iB9Y7VQwFjjYOm0qwmUf9D
tph0KAX0N1zKYFKGN5y0JWewi7chSHM4oMsYkf09obdy3ztcwYdeHx0gdt++iXe9g+mU3324vcSW
MUZ8rPPSBrp6/MdJWeEuNDz+O6/qdMBxbS8WAeyvroIRJJcwHV6O4b8QaR8x9kHp+eU43Jbp8HX7
WZSSXt4D8WY5+oK/nzjC7WBlbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjEzODIKZW5kb2JqCjUy
IDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W
TXMTORC9+1f0DVJlG9ssSdiqPQAJC5WEj2DgABzkGY0topEGfdgxv35fazSTcSq7tc4h/pBev379
unt+0Ww6pxn/5f9FPXpyfUJrP5rRevRrNE8/Uv5X1PRyiQOnNF/Qshq1d+a0eEonJ6e0rEeP35og
nZFhcuZEFah9vfh4Ra82wokCP6rfIihr6O+oSqmVkZ4Gryuxp8Vsfny0/Dl6+pyWl6PH+Ha5UZ5q
GZwqyG9s1CWtJAntLdlVEAApqXLyV5Qm6D2V0SmzJmFI3jaIWOPro0ej+dMOT3gKG0namvUElGpa
W1s2MRDCOKnlVphAlXXkgxTlfuKDCJJ8IY1wynqyRu8BmKBMSTVIGxvIyEJ6jyPg4GSlZRFoY3cp
ljLB2TIWKXdbMTnI0oEUIQqNW6pu8D6zU+aGYlC6U6xLK5CgQjrOmzg9WwIwIwUkOyV6rSND8jWP
0AlvK3SE2APBbM0/eAlphY9Osk4+A3FOpWwk0mPCOOeoAjfrmJ0w/5HUmHwsNhA5Q6VEtNgDQVvv
waGMkoJFddgsQkM8BRbQu7DOxYbhxlR1OZh1BlpB7J0qw8bT98ens8V0Pqevly/e+e9HY9pIsd0D
wKylT3xQRqk9owYnjG+sCx0h5vIIpeaqOtklsDq4jrdITkObAukqX09xe3GcLLSYHkPkS1w3xT5Z
4KcKyCXjL7l67Y/jFB+frZGTXdIU0bOXx+y3UvkiQpWS6/Tt+vWrxfHJ8x/TA78C0Ek+LJiWl8ZH
NiHrLUrYnvPI7VHleC2hMdeqS9vJxqHaJvvrkNEWts1+YQjY8EbiYGcS8qKWGafSdvdn+vJDOkVn
CeFLh4DifDj78v2IvHRbVHsntUazaooociFggAzE2T7743T+YyBtlg++mwQ7YftlJSFPoWMJvMLW
DchzHq0vkx9/Rh+Y1IFwmAiReybl2PuyTUit2XqNs9y0g0PJLbXCd9Zkoq1EXGe+ef8KrHBlnbTb
Vu9Oe65XISJXdtVNi4HKqHbHjoHvg0JEOV1PwbnYwKH6rgtkVWGwwPPTVqqHmzDdqyXt0rRs58pA
1b4T7lt43KWJAYak+gHB5vKD4cs+xABH92SoPGUGhZM8cURHC5MKgLUwhTzopBOkcdb2QDrZwqAI
pZzYqkKssJPSHFDN43rQbh3B7PC2mwKvDS9bZXigHfBmI2A/6DQND1yTUwFUYOYJprRF5Pk45l+t
K9l2tmveRAptaIKq9tmEaRr/nywOzf9VhQ0ir4UrPUdgIvlgWxrFPV+qlFP+vd9jB1nw0sIh4fb9
eksrABmkRXd9/ur91dX5u7PzswQkbh5cBJiiQKijDqrRstUDB5VRdazpermEU/EJb9DxXZovEtWX
KO1bjpWhfFzzdIX0D8XjxabxOeSQF3RLLTAi4IKvLdo9Q9mYmv1uSaCsvAV2LN/FX/MZQr9Ra54O
ee/xVLsg4diihY1OrHvr7jbScMwsTM2+Fw06suFulf1MzebqLZ1NAmn8dODFFDDHO1yjfAEPRzvr
brB+GgGuRf9chLVTHOAMxOn2/NXnT0t2MfsOu5S3OMJIgbF296iTtOec+rmfKD7JQrAEPEJF6oHC
YSUDD0PF8d270eHHAye3F5TnyfXpzfvPl2dpmstbcNf7fkM8wNlPW1P3ZHpr9yvy3/2YcWG8tO+A
OMk47YLCI4HH1b6ADZJRK9i01ZynaZa9kiKAGE8Iu8UAGAxlVKDcQY0n3laB3/STPo9NlDqRYDgV
vNRVh9pd7UgNZly2Pq1BzaWHu3sJZiJ3tp/Puj7JGQOOG4w9cfwstfVF3ODJCHkLPR0+Np/fNoqT
e4clVK9wbX46Ts/RdPD69gGuR5wfQDxfjj7i7x9jPPUdZW5kc3RyZWFtCmVuZG9iago1MyAwIG9i
agoxNDA1CmVuZG9iago1NyAwIG9iago8PC9MZW5ndGggNTggMCBSL0ZpbHRlciAvRmxhdGVEZWNv
ZGU+PgpzdHJlYW0KeJxdVctyGzcQvPMrpnwJWSXSWiq2FN8S6xFVbCe2mPJB1AHCDncRYYEVHhSZ
r08Di6WpkAeSi0FPz3TP8JlOFxWdpnf5lN3k7bdzavzklJrJ86TKh1Q+ZEe/rRBwQdWSVpvJcKei
5Rmdn1/QqptMb01gZzjML53YBBpev379TB9b4YTEofpXBGUN3URVs1aGPR29Pos9LU+r97PVP5Oz
X2j1aTLF02tnO2IhW7IbCi17Js/Bp18dCx8dd2yCP0lnJGMXNXJsmWo2XoX97KdJdTZibaKRmcB6
+vHyej0rkCQtYmt2XAMzOCU93f3+59+fLukxHXZ9DFwviG5zOCAT2NElL9kIpywpE5yto0Rh9d6I
Tkmh9Z62wu2VaahHH5CAnT8pIIG73jqhibdWx8ytcBqJSBt1TUJ7m8g0bNiJgc21dbkxBWokMXRi
Y7W2Lylp40TfUofmHt//kKN2c7FTnnxrX3yBeY4c0zUIhCvraWhFIMSkcLHF5YapZzfvhXziUMKU
Id6h6iRLwemUUV3s6NtqtZ4NnPZDtvS1sbZGV1HFldaq92iYcD96TT5CcDFyqjkIpfEYee6/3365
g01+fvhAb74zBfHEgz+UqdVW1RHdvF8sFg/koinfDkjWgL2FTCckTJ2omDFp5lXNufdKQwZOvIKS
Sedgoyu6jNWhElQ31+oJRm5RDS0v6UZE75UwVCsP9R4HQXMHeddrocxQfWbgFwVroPiCx9qGon2d
UFKbPRt4DE+djU0Lnpl3Eol/qHQoT5BUTmpeFNAVwKxTGBAxekuU0jBHjnuHeQKVV7aGW5FdMvwS
XphNpvQ/AkPeMoA13OaOIHpng5VWL94QGEDxwYJ4DHmgNMYgZCopA6aBYqrRBwCnmnCynlbr2Tgi
LQ/p3hbTUHCi5rndbHJeQQ3mPcloGva5zCSZsxr8ZCuM8l2BuuNh/N8N6q+nS+wAeP/YkvlkNHru
cyk2DTE6TaKAHZZJGViw2mzgF21Ffch0sVgmmZfv8wo6g99v0gQiDEss9rkA3godsz6jjLlpvkAc
a0TB9lbbZj+YSkJMDHX0RYKjNfl67x2Wwbgkxn1pHdB7OzTe2MEmfpBYeQk780gq2cJGnHkfu36I
yyxadAs0IEEHXdKMZsksljF4vyq/QgNWYwkpySElos7eVTnsj9iaE8JuEXpx/P9wtesV2NIXu+Xu
EbapLk7yHwa9et3/lZSrqgdAXq0mX/H+DyBaPQdlbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjky
OQplbmRvYmoKNjIgMCBvYmoKPDwvTGVuZ3RoIDYzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K
c3RyZWFtCnicrVZNc9owEL37V+ytMBCKyTRJk1NISafThGkIh2RKD0KWQY2RiCVDyfjHdy38gY3B
zrSCGZD99u3u2/Var9Dt2NCNPvEvXVgfR+cwU1YXZtarZZubEP/QBfTHCLgAuwdj19ra2NA7hfPz
CxgvrMY3oZkvmD754hNXw3ZdP9zDzZz4hOJN/kY0lwK+BtxhHhdMwc66Jxvode2z5vi3dfoZxndW
A6+2TpLVgporM0Gj5gfLPk3IQsWEw3wF12FdstBnlPFVZNQPkew/xdQ720+wHmMRn09Qo/Yup0A9
opRdmWURHycY5n1U0xTwCQ08DoadW0+ubWyyA6rllIHR4CY1yGgS6NZZ6jUXQsnfGF+kCd9JE5bT
/Gs0mTZPsQitEppWmTZPsN+KmbJhCU2yL+meRj7AFBhBW2m1WmaT7RPYLkHe6UgG+MzDXaJfvB8V
YIcJCv1X3FcTmOmTXQ6hHHaEoB+47iN/Y2HpvgbBpNFXiJ800xJnV2qSxIb4jSuxLU2xEuHBUqac
Yfq37IluHWmpYwQHWio/WoZhFU0RXzGKDtJUjaJhcRRlNOWjaFhjFMEuTcnFmqOokqbeKHp3NJk2
z/lyJsXP13hXm+ejo+jYKumb7K24v275LPAZ2JcwlkvpydkGiHBASG0OFSqOIoEBV0BgxgQeOyjo
xGQ9Zz67jLESIDkQrLmeg8NdF28LDWkvpkcXpTlV+PDyDuu0k/u5dy+upS9d7jGFDzclAqYMuNC+
dALKnKtcfuhazxlovuBiBtIFRugcXJQUqAw8J7LNwkncYvQCHInnpghe9G6slSa+NsooTHrS3HNr
HCX5xQGbaKlcLDFPBivicxkoEMFiigMbg4uY1VWmmuHAA9xLpHKm0RvDuLEsUQpLZJ00pGAnazzX
4XGPbNroZkko15ttWDGZIQeCRTPVIhpZiIbrbRKmGhL6bVDoJxKLwFRq7SGWvqALlLEohIlsyvSa
oVy+ee0ofA9FfKOt67NPBv49mIs2MNTL6+z22uDPkvuo8lCumNHAvmibs2m+JX/+IDNstd4vZByM
rQf8/AWVP2vDZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago4MDAKZW5kb2JqCjY3IDAgb2JqCjw8
L0xlbmd0aCA2OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nIVWTXPbNhC961fs
LfaMpVr21Hbrkz/S1pM4TWxlOp3EBwhciohJgAZAK/Kv71uQFCXbSamDJBL7dvHe2wUfaH8ypX35
dN+6Gv1yc0yLMNqnxehhNE0PqfvSFZ3PsOCEpgc0y0dtzJQODun4+IRm1Wjnykb2luP40qs8Unud
fbqmi0J5pfHQPKlonKU/G5NxaSwH2riu1YoO9qdHu7Nvo8PfaPZ+tIO7jigWTJEDAOj2r78/v78k
7WwAhKe5iwUFzVZ54wK5nFRYVRVHbzQpm+2+GU0Peyhcw0NExpIt63tCJfeBjEUSXyWQOUKXJovF
hOjKklaBcRtgHcxGEgneSyVqVStt4opy7yoKbFFgoOjIs2bzKH9MoMIsCvYDVCyUTeHOchs5LEds
B3OalmxnHTB6Aqj27hG8BFLYQsC6JkVHbMfYhewsZarZt0K0NwYgUatijZJMqGiJQlmFFPNsx0NK
flRlo6LktD8CArWKKucZe1OlCREogWNTnyLi4GhDaln5g0xh7xUjhNhkq3R/bsbPxc4MqJR9qpIi
PJmL7ByXzJbOxB10Tl93Mre0KZHcaGr5+XWXlgbG+gk3GdelW3FGwiKUW+fCv3IF28yGWq/P/t2w
TpaZtqZyNfhYDYSmzNvJ5izq9SkHLGRLDbBOHlq/stJDV7xC24Bg7CMemAUETMtMBQ9H8UXmXU21
K41e9b6RopBydvGRzi7eDSAIuecYEoEG3z1I62uYLXe+UlbzZEvuszIWrlkIzUa8jmRusaIKY8C6
mOKwK7DkOS/xiwDaiJTtSsNhb0vx1CHIXfIABmDtqko0oSZALtMWtXS+zGRfCGjK1AyhmxcCFSrI
kzibc5ZIjWhvsM1ryYCF1lAZPzSJvKEThKcOB/1Yu6DKQF+uxpcT42M+Nlr7xTjqWtbfiVOSNJg7
4CIKUA0GVIxspawOCbeTjP3GMDYiFahgLm5OW9ssAbWKWkEXXLE0co8DNmq4AnZKrPcLxHOKLC/B
U1s0AAeEDeEOJweo+bzJc9gpmKe+Q2aJ/SfuzTJPK5ABGoNqYU5ByCbZvgC+3UuGQXPIQ4wDbOCF
nutBPMaBoVJtWaPj6fbDrkHSvfVY7zfcT2VJJitaIPlVKr8A93Qzm/W+2FAXJxlccj/56f6SKzq/
9y2yYfi2JWCTDiQzFSOBs1IudFAYdABJYi4NLLdtMNFtQ7FXfLXdUVe5DJKatUmjbtBIavBwKuZE
tjUPrj/fzuhbgxGQr16clxlHZcq2XzrKKvUdDVPRQ8MNr6EhXho8Gffw3bq+nV7yJl2OicwDb2/C
S+YwTOAVo3uTdVMfLEHEucMpBpYQgm3nyvieqyCDsR/0osgmXYLzT2FK3ma2c3rYLDLV3eX0XKnO
JAGydUBKexfCmtGw1SiHIOXCWfGYHAwQNnpXhrWhwFzmdANLxLXq0KmxtnWzZzlXpJJuxTOkLbFU
uXAebVyF52fc8zP2Vl4HlM/SIH+J+nvXW4HH8or2f3nlEAkJ6gMvb9h2B9gtTgj6cvPHxa9HJ9M7
oUXeEhHyrinQ+eh2VU423/7efq/hzkAf3CNXc5A/PdlLr4O0dX35qBZM08M7IL6djT7h8x/cgXiE
ZW5kc3RyZWFtCmVuZG9iago2OCAwIG9iagoxMjEwCmVuZG9iago3MiAwIG9iago8PC9MZW5ndGgg
NzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1Vk1T20gQvftX9C1QZRtsspDs
jRB2Qy0GEpzaSoUcxjMteRZZo8yM7Di/fl+PJGwFYqqQPR/dr1+/7tZ3Oh5P6Fj+2qdeDY4+nVEe
BseUD74PJmmT2ode0bs5DryhyZTm2aC5M6HpCZ2dvaH5anBwVUb2JcfRe6+ySM3n/OOMLpbKK41N
+1NF60r6u7aGC1tyoL3PTG1pejw5PZz/Nzh5S/PrwQFWHWzkuecQ7JpJuzLnkIzga/SuCH+SooUK
PBKDLxygzPnDV4PJSWcRn7i0gbSKnDu/JXyfX9zRRb2wmr5ejd6PLcdsFHW1GmlZ/DaGgenpHqRr
4BnFpSrpHbzRZQYnkR4Ort9dPhz+BmVJ2N3b+xVUh/cVgq2LGMiWFFaqKNgjwNJsrIlLmDFHzhP4
A112VYFYSrZaKyHihPImhZQQ9lZsDFxkQ9osGTtIjC1zIdDFWHDJ+nFnaWPhzsbxK6Kvn/66OJ2+
PfvW4+E2LgEtelWGSsJ/IWyQXNLt3fzq9ub8+voLLZh4rYoa1BvE16NAGWPl8pjoE2su455pBAtX
lXfRaTGrPFPpIq1wDFeSMUTLLfrMFYXbSGiBtRwIQ5GBnKCgHplcRgHkFVbbuN3L7ms4n3FcOuMK
l2+H8sNbjetJyA58exuSvTulHznSvf3J+HWvl2zqIrFZmn5qLy9u9j1M+j5ayOdIadDeVok/4GOl
lxRFXYFjXdH9h9vP1++FQcNR2QIxR0dKAk167vlM97C9kIoQ0Did8umanGE7AMZc6kAVobUTmu2A
my0qz8IRspWoS9fIZlQyGzadgecgG4StjeCyuJGEgRiC4kz6sYYfSUwy0pgGMO3qwtBKUgSlklFR
tVbUGhbVouB+LcpdyKJyAWHscbRTGdj0rAq0hwzJ38LNCvlqxLCl2fmXHnG9q4kxXkNjI+PRfkoR
TV2kJhZQ7aFGilSgMoymQ/l/MmzR3s5uLudD4qgfDsf7KGE1QNtQkdupeOHqsskmIVXRavjwraUW
jYgiOkif43MCWvKQCi7BoFd5I47EoyRup5hdqiQbTcXsou86T1UvkPZi+yLrr8dThIRakOILwu+q
KRI8Vag9y3qLXtAZp2tZAgMc0hWBxKUZRTfC4+k6uhV6WZ0vO+nWIcXRg9hlpxGkV4ZHLstwOm4Y
CUJywME2RZc7Z6o6Smu4b9oACfKrrlt2DUe8vQxpmNa/11xjvEAIxRPWh4PSeWnOXf2iLRVwAsAI
ouF8bTU6TcUe6UNfkEV0EcwHSGGNCSh9lyMy15qACFAU0q3lOFpAewOnlmptIdl0Ag29Ntsuf08z
IJOKaS3ZNIpVIXJSgAyzCPxf9HwEAaFE0QrUGCxSi1h4nI+HQFxx67vXTFlFZDV0sA0ttslzV8tH
XYU/HCbCAlO+m/DKrG3obIFpjIZgJYwXaB1SV1K4+0h1tEX7zjBMx4GtNZTmX7OIqkYPloqumpZs
UGlHK+UfZfRFi4mk0zD9Jd9d4/04G4WKtc0w/Xt8fXAboasRwV4dzj7fz0WelbfwYp8kIG8hqd/w
j4Z+FJBbBPZrLD8X17M67vNmXOoNyq4Eb1PBbWJoo7Yt0Z0eZc4u+sXcVqMBqbbU/JuL0oO6k6mD
/KgaGT/NgEYWneuX+9Ef0+T1n3pZStfDOBnvv9pd/qisKOjGrXm1QO4nb4bpXY96n6936Fw0eS2v
GZfzwUf8/Q9+DW37ZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iagoxMjg3CmVuZG9iago3NyAwIG9i
ago8PC9MZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1Vk1vGzcQ
vetXDHKJDUiuZLdJ2pu/WgSt08RWD0XdA8UdSay55IbkSnZ+fd9wd6VdWZEBCwI5b94M3xvyK03P
ZjSVv/Zbl6Mf7t/TKo6mtBp9Hc3yIrVfuqSrOTZ8oNk5zZejJmZG5xf0/v0Hmpejk48ucXCcJjdB
LRM1n8svd3S9VkFpLJpvKhnv6LfaFGyN40i9z516ofPp7N3p/L/Rxc80/2N08uPZxRnRtS8rFYxb
ZbSo11xyPH07On+XNyF0vjaRCq/rkl2iwNqvnPkG+LRWCf84Mq32SUtkWjDVkQta+gCo2UUHpY8l
Oxtk6y2QY2AkL3BNJH6qlTIuJlr4tKaKA1KUymkm5YpBroIr618yZ60Sr3wwyEX00ZEqCiO9GoM9
aousc+cKTsrYSGu/RUrkSB6IgqX02vAGOWipTOjKiIjxywHjxQupjTeFlKg5AM+1EJVJS2Vtv1o5
gBkYfe5VsYdu4/roce1rWxxtB46BVuwgA43t7IDh2xPCvkFjYl2WWP6GaOPooS1+JmLoJ7u7/HuQ
CRQpVqzN0uiWG/S49eGJ2G1M8E56DZK1XpOCYlRS6IHoNo7R05K7/fjJSctRLHFqr+qkNaKRU5WM
2MeT+HjaFLLlwMTPYgR08oVS7XYaEwhfJVN2NgBbKIQDVXWofOQ4bqW6UbaW8v56mEt9hYnaYr34
vgwXbD3OE0IszHIJEpDUBh3kZHhf79eaa55YdisIc6GAOOx6C/Z4ws8o/f72BmWBZA6DXCbwjzhH
ArtGtHuv/Q3bMX3+ePt4enZEFvwsBfbIae9S8JaenF9EcIteG1igoK0Bt92+FioypJeMFnP8Ckb8
rMrK8pi2a2O5MRpyi8EaKqKoA94tVJ99zAEM63QEVSYkfewIimo7IGoaMJm0WEj5NtKbg+XAmbvm
N7QB4cznyLakworTm3GLJXkgPVGM7NmJK4p/u8WO9lpt+PtNGoNCrG0SHNjnddMrb2AD9PJBhNGt
6zxUBQlB/cPTyokMWUUDSfsNB+v9k5xV7n6pnvIs2Y2Fg3E5HM73t9d/3t3dfrp5yFUtvbV+mysO
XnNRg3r2cTPHBvqsjg4hUEtbZpfherR/GZCQIfYA61kV9m3Y91h0YCApo7M14y80x3SVld1AG1CR
j9qKyNrTOYLZruzb3/VTJkXbaco3ThMaW3oLxvEaH8D4gISyMd80/cw9IOOqOjXDg4Jyq1bf2gc0
tfIuj/x+lQduGnKKuC5DVt3rCibw/SWGw+uBIifQw2kCxpnH48lVF3J8mMh0zzuvsn2teWL70gOD
K4fCJwivyI3uephbEA/921ith9T6uF1oOFFbhog/G7e3uHctVq/6jVru+ycK45QG7u1GeTeBZ9Pp
3VUOyjl6QLNp2Qj/CiPQ2sNK+8cm7wZuTnN3B8uHJVlztUj1uIY6i7c/J03gK7yyltcKHzl/FuWD
FagEtW1s7rStY45DouOeHFR2CdWOyeBy7J4GVR6RaoHhYeR+zbaF/zGClcW5R7kIpGU9lAOzyp1Y
R9GOPIXyCA84oMT58NtbvF/Q7g0aZUTuDkSrSmmTXiBRzDW1Yrqfz/Pdj2B52MLvv9drJ+8B+O+s
/2C9fa6MjKtPGInlAoc9+zDOL1gafP75LLCzn/4F4u189AV//wM3xrQ0ZW5kc3RyZWFtCmVuZG9i
ago3OCAwIG9iagoxMjQ4CmVuZG9iago4MiAwIG9iago8PC9MZW5ndGggODMgMCBSL0ZpbHRlciAv
RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVk132zYQvOtX7K32e4os2vFH25NrO01eEseJldfXxj5A
5FJCQwIMAEpxfn1nQZCikhwqH2Sb4GB2dnaALzSfZTSXn/Sd15OjD+e08pM5rSZfJll8SOkrr+mP
BRZcUHZMi3LSvZPR8Qmdn1/Qop4cvDKBneHw7NqpMlD3uXz/lq7WyqkcD/U3FbQ19GerC660YU+j
z1v1RMfz7Oxw8e/k5FdavJkc4L/HM6Lc1o1yTHbDjhQ5ZVb4oyRtmjbgqSn1qnUR2/9GYc1Ym9u2
KmjJh79MspMeTD5eh7ZbSts1G1lOnoPgASk4WxE2UzWDsMdTFUiVJef4AtaA0nCuS51jh7XaaOsI
X0yFxlLHJgCyVibo3GNF2HLaKGytSDIGytdcs0eVl55qvAlmXJBaotgp3b26ATBotEab1R4xOwLp
iX9puQUJriBlZC7vqp+yKp2tscZ6HuG0HltrQ1f2mitQemXIt/l6pNlUyvDc0ybDeCPYTugdndiv
4n81DNu8gHz8VdVNxdMfYaIIG6yLrDpM0XJADcqt0MCu7LjFvjTjzfDk+Cza4fnsZCbmuuamsk+i
fNpQe2sSgLi3r/Ttx/sFytwVp1ZKGy/77gCcFpurTjXp23rfgEMD0QkDVfVGhyd6OLiHv2QyLmYn
D4dTUm2wz1LPdw+z44dDsi5x0yKX7NrNVG5BZbQ2ezjcK/Y5Sr1T+WcI5fU31KNMIeKs2McXjA3i
5wjWV29GAlANcWP54F2gyGjHEd52rSumFRsWrc1qr+7RRl6vjKo8ffrw4uo8e549fmeA0RQKuu+1
TKSub+/JMYzugz9y7BvwYdhycXVH93/f+qPLq9coDrbxtaqqKS3hOLRBO6qs95SrvjzPcBJXT6Ik
4il6SjVNlUSghl1pHeYl59lPxEgoMW2wjkWcpVY+zsNWucJ3DIY6lk9UONs0ohzeqmmrw7rnIivh
isbZpVrqSlwxGA3jVYnFXQ8FOi/tVuhPkzpmlCqJovbUmlKhbrxfqKDEcoVEx65HP+JeY+GgT1w+
RbHQRNvWw3xkpeCt9miUiFzDNhsVOpZBfYaExQYRo+Jo9kjCcaQelAiYXl/rEFkM1Xc0psmbEuDo
cFsFTHWCao1XJY9mrjNya9asqrBOwI11Qf5/BMKjliaMgsWD4yz4wez3L999fHONWuJZIqVJ4DBa
gj2LdHzYNsghVnTsdmYfnN0VkrBu3y2kvRsMD+gW7VgpbFBWdut/aolkn4h6enb+2OWydQXH1vJG
VQhnNLxMPtg5IEF9Z8vdVsMmMsI7+bvO06UcBS8kPJmyBIXxEaNL8MlBEjsfkeRkq6w0Ew8K6apM
5Gir4RBKSOPw+H0IzNP5HPYIyBNJ/Gz3p4y6ZNsGExt1TTBIUyfnWSI2DA1GMh1Vwizy2MvD0ygj
klh1gRk53lzd9jETDQYc0VNVK4tkX9e+b+YQvnTzVeylA06nPuL2zHA7ylXkM3ZAiKPQLSMa8B1D
CW3sYnEclNJbUzRWw+SJ1dgDQIp/n2RnF48y7RAAI4ArmBKV0s2lig0YnWN9bA07wtWM9cgF3DmQ
lbjBba37vMdEoAorx70NcklIzevnCakGQos4KyomoeFSw7M4nDvLix+EsG+bOJvSnT2z9gX+dfPm
H1wCT6XC8ek7GiLZTpLI4S4DnsMxYStYo3c850p4ytjeXC0eDubx6Ox+x9GI6hAhUdrIWC4+3bTG
OyGoPgPS2Wns4ut2babEouZsfGFF6zVsiRZvuF5iYLKLabzB0t7n052MeHb2CMSbxeQ9fv4D8pSw
R2VuZHN0cmVhbQplbmRvYmoKODMgMCBvYmoKMTM0OAplbmRvYmoKODcgMCBvYmoKPDwvTGVuZ3Ro
IDg4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicbVbLdhM5EN37K2o34Rw7xAmJ
YZkxYeAMCYSYxRzIQt2ttgXqVkcPJ+bruaWHH2Hshd0tqapu1a1beqCT4ymd8Df/1t3o5ZcZLd3o
hJajh9E0LlL+qTv6e4ENr2l6Sot2lM5M6fSMZrPXtOhGRx96L20v/eStFa2n9Lm8vab5SlhRY1H9
El6Znv4JqpFa9dLR3udabOj0ZHrxYvFjdPaGFh9HR3hbi0FUWtLd+09fP74lJz0Jml9NOmF/Emxd
zW8mZc8g6p/SO1I9+RUerXSyr+WLv0bTs2LPtFiu1aBk76k2/VI6jukYm04vyqYPbTTgsSabiMHV
K9lJRNOTC8NgrGfP9O3Lu/ns/GJ2P94dsI6uv94tDrw2ytXBORJ9Q410tVWVjCeKMYQFe8dEd4gu
LjlJy12e4BgG2RQOBoeovCG5FjoInywN0rbGdoKPmz/if1R+xd6zEX40IWHgTKp+6SKEDXISdENC
O7Pv6iGI3qt2w3uyDcX1hgf2JnsUAEYiiF0qXx1fAFIkBgjApY9x3CGZTeD92dQlgTePBhVt5FoB
QAcuwDWDmrTaPJKx8X+tBbL4EGRgZwnUQaLd1jQgLI3Fji6mCn8kbFjF79QvlFJaL8AUMQxa1ZGY
Dm5yRNER8s6ZBJ1bVY9Jq075mFjLSU9LveuUczg85hjhabBmjbKVJDmjE+krIJSyBxXaFnkD+7Jh
YoAuguFwUICuw/4YQbaypdkhTRdMoD3AIBdHx/UGs38YVEhvSHXoC8+9wouybybeTGSkwi5ve+w5
joatxLMcbw0C1mCc0JHbWz7v2NBK4VSltPIbzoJomv3QgKkCj5tUsmJzW6HoUhW02TgnTXDLgGnO
c2Rjur78j+TToLlwjysZa8rWGkQ3sKPBoJjAXGzF6rLfFVJf9EFYiXLwdtkzl7CO2jUy/f8jx4ed
2Bjqjc/5OFhh2Ewa97wfnwvQ/5HUxUZppGzGjBpwTG69eieffAKJy9iSJrE34YGYrATV0hkEoGzU
zjoXBITw1ugYWu6fkm4c21CkXkzA+LnHvXCLyz+87YWUtyrvpG4jKVXU5GciUEiQTAL9JVD3xZB8
Et2gM/+yVdSadaG2ktvPhWoS43UHxM9CjY07vSwkgGsp6lWRx52FMZt4aexe+7AI7o5mW7mHHldG
pyzGuCGV412Mjjq1XHm8CXCFUr67nczNW6lLL7//dPUBc+78nkn3TqyNvWVL9O3y5uojFl5hmCgu
VhOghFH9trIlyqyKU6rPc6IWjjG4QdaKBcXV0GMcceRWBUjma5NYmsUvG4oESqZ2qS6lZrKbHjqy
knpIsxVtFEu8q3sVWNQqbQSAVxgscX5wn1lTBcyIAGpbMOwR3UJrBCdBS9TBoE0AaktG0LRRUYuz
JjDVeFKVmtU4kR4U92IduiiljKDFE3Oo8LpoQq5tnnN7LHF7rX7O/ljO4zj+bI03tdFFRm7yeGKm
sYKmMYXkyJRRJBiRt2oZbBE5gQ4RzvBgPBQA0ZnQR0Apa6ib4JGPfFXO2CpNlXg/qYJ1PikDOdNt
u0z5kAbWeDs489gB/bzsm9zxKSAq0ca4tLDLw7Il5Vob1WSFjKnDW6uWS8mAqg3gtEHrEnLsOJOt
dOIJk/FXuoaAGD8peAyCfNmDCBLLdyNsQ9o4N6kE83Ax/1wm4KHiHkyGJNamBajtdSfGA3SO8XJF
F3tj+CDV8yx6pZz0/Qhuv7+IA/Vk9ubsvtQqznZY7kNXAZ9pYef8NNr5N6ww3PneqY/376tXT4PC
/YduzFrGQ9PX43iBpYPPt89iKWk6u4fFq8XoFt/film/6WVuZHN0cmVhbQplbmRvYmoKODggMCBv
YmoKMTM2NQplbmRvYmoKOTIgMCBvYmoKPDwvTGVuZ3RoIDkzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVj
b2RlPj4Kc3RyZWFtCnicjVZNc9s2EL3rV+zkUntGUi25ttz25LhJx9M4TRy1nk7sA0QuRdQQSAOg
ZOXX9y1IiqI/2lIHaYTF29237+3wgY7GEzqST/OdrAbfX89o6QdHtBw8DCbxkJqvZEVv5wg4o8mU
5tmgvjOh6THNZmc0Xw0OLm1gZzmMfnEqC1Q/55+v6CJXTiU41N9U0IWlXyudstGWPe09V2pL06PJ
6eH878HxjzT/MDjAv6osjU7iPT8mml98Iu1J0UYgtpRyaYotpxScsr4sXEDQZaBMG+OpKg+/G0yO
d1hrpY1aGKZFlWXsEGCDNkDzbFN2NQgOtF3iz0Vl7ikzxQbJQi6pgSY4jhPWa5YyvF5aZej2oFTJ
PQdKXVHeHlLIVUBYWiWICjnHBILqVGBpI+cGyyi3lMx5W9Qw/s71Mu/9TUWSVKWyyXZIyqZy4jgr
HMuvBuuh4kqSgBm1RZZzS5xlOtFsQ5yET3Je1cV4KqpArBxITAq7ZC8UN0B1V6i8iITjaxE5kXJ6
SUCg8AaA4AozxvXpacv2xyKQMoaQrCy0DR4sFa43UDBVeQGTLJXnmiqFEjOj1ggust4AEYa2/lRO
c9jisJmbpyVbFmop1UKW9JsY5T3YRxTGKjTQJtdJ3rS4QvG2kCFBmtJhR8Ku/dsDda8QZUeOoS3r
MfQoCN+AfL1+fzE7OZ3doRFU22HK4KUZ7XqTJ+WJH0uGGdIavQGat+ql9wJf60dhuIa9p73sOLBC
wy4z1GB80cAk4BvIb9RyiTtduW9uD8UWVkoCy4kCMcM9RXhUyfdgocWp5/l83v0Jz3MtN5NIWumK
NTyJWXTuBq1xCLUHSnYQ7AoaZpkKGkEFvfkCoyw8/IQ4WmPMReV308MhXA3U0WhvzGFb1kNupNB0
cHsQPdvFicL2Rtx2KEkUtDmEkjuahw1KxyMI7Fo/GU/qVTTKoESbwkJ1drkmh68c13tkp3FtddBo
dq+sjbZpsWlFEelN2AoRlLMpI6O8VqYSMeXYTDWJrbGjmGvaY/4eubtidquyKUs2BYkNsRgNahkZ
NJwORfj7bh21G0uvdJBzofQjb67ZFlFmw7o/lHT5vLOb2BnmcnkDs3gODRpqPaZ6eWII7QL2lKqA
Dcxhw2xb+s7j5mu2r6O3KPx32YMtX6hn1+QLs95pvUpycWJvQmLPJ+oXj50c/3B2RxwSujr/K1oN
RUmEh8jh874h3kO2GEHeh+747u7VW37pVAmRsk+cXsC42vYm9qWx1nQ8w9XKpJK7XXXpE0FO/01z
nQ9eFZ1/UXUJpomk2M3pf2hPpapstNdrorXvSj/W/SMp1gkcG+cV192TGiVJs7lB0uXNc5LDfpHg
clN0i6CGvPrjy7xHVyumXnGvCOunXsLiRX88s0fji2e2+Lkhdh/m/9zbs9ONGCZapVe9gDp5Q2v8
U79YIMc3bsmLNmpdBd3RqvJBePHB6SSYbVMcnt0rBzJ2mJEZn7fqQ11dTJcYKKcnsazfqtwOYRh4
Zbz/dvfusdTYpXgrWPNqAYzJ2TC+7lHv+fpJLRlnd0B8Nx98xucfERZr8mVuZHN0cmVhbQplbmRv
YmoKOTMgMCBvYmoKMTE3MAplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIg
L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczVbBbts4EL37Kwa9JAEcN3bQOD26SVsEW7dp1sViUfdA
SyOJG4pUSCpu9uv3kZJiKU282NvKBwky+fhm3psZ3dHJZEon4dfek3L0+mZOuRudUD66G03jn9Te
kpLerbDgnKYzWmWjZs+UZqc0n5/TqhwdXmnPVrM/vrQi89Rci69LuiiEFQn+lH8LL42mj7VMWUnN
jnrXUjzQ7GR6drT6a3T6llafRod4uyqYvBXaldK5sNlk5PFO41FUlZJJxDxWspSeU8qU2VJZO0/O
C+spk9b5o4PR9LRDFDqNCM+hvogYwRwhMLZhJRAD1l4WhXBkWSQFXjjPIn0IMJ4n2Dw76+h8MJbC
opaCY3IJa2GlcePIKbeiKihll1i5AZTU9DsnMZGzyZwSU6t0EOAGe1izFZFJB58o4Vw8BPJkMqH1
4XPMQ3YQVRvfMyvWR5NGlcSUleLIw8uS96SwBVtdXDeJiZQDzZKFqy2nvYy8mcyAv8hzy1DmvpWp
MpDSsU7ZdmCFdI+ZooJV5cgz0mxxN8T3QtVIABU4T+joQwclwDNI4uMiMUjb04MQjfCEU0pjEVaP
UQFAQU7qXHGI6jizElvUQ8ut2Y8w/mDolsHodLDbD9u7A4I3BBUyL3CQ1AlIQfkMzEw8uBMAhtGp
sCnVlYmH1kmC/Vmthv7FqtfYKQj5bajrx70tVMrDU1rEWr+EuT7kST4ZB8MlYZ/JWqTE6BypDmvw
6K1RjrbSF7RIU+kR4vFVF9GyVl62hsD7y5ZDC7Q+XFwtL9dHVFnkAOt4HEIQNkcMi6suquVly9lF
8y261CvwOG6hFODT8UsFOY7mu6g38H20YAw0C2ZJhRfwot8y64F+OCcUg+WEgW3pHY7+4oNePS/8
morWZq7FWi7+JKGcCXbHCofONzR8vwVkStzjGZUknimAF/vBwMa/9IZBPxhU2iki+qZxThWI/S9q
TSFo6jMKRoZ2YPrZeG7WZQKu6optByVDPypZ+yg9el0oCwI+iGEetGZqNhMG1dbY2xaEm40Oq4+t
qbuDXhWQ61VfZCdzDTlDTVQiuWWPdAgE0Mn9/ebDxfzN2fwHlRhnUXiFBTED2FxKmBt3X0eO41DP
RXNWkBaZ6yzY5E8zp036UlH58FA/0Su08tCQDQBk4J+OmzHSAuW7WVtZUxnHzfDbGowGhVJAKe0m
ztCXocvH+bkTP0FG4afacTqQ/q7mmmlTSxVaFQhdDYduZ303DCDU4voQZU3bIlALbgiEgleDHVAE
wnf9bDd2N8Z7BUsnt6h7fQtWEENC1baOKWqIwz7FEr6ZPPHwro856XyciqLpJrGNPO0i1A3Hb5fX
vfaBd53s/Sayp318DKXrntbuf6raVhbHIJ/+uy4y64zVWQppEBvFw3I0dMtcxaV9dcJnW2BVx4Da
BrcvmVFhQaX86THXQ1774zEm5DkDu84we1V5zH5mTTnE6YsVDhFdGfUGxf4JgVlU6+45yinuBaq1
SVWbpMfPxn7rimwGbhEPbNdHzcz5zFu6YW0icyC9mcWk/1YXqH60DxHyubve/6wk4kKzu+dyA/Tp
+Th+FdPg+n4tcqbp2x9AfL8afcXvH4Yk46xlbmRzdHJlYW0KZW5kb2JqCjk4IDAgb2JqCjEyMDEK
ZW5kb2JqCjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K
c3RyZWFtCniclVZdc9NIEHz3r5i3JFWOiQ0koe4pX3DUJQESUVdXIQ9raSQtSLtidxVjfv31rGTF
AkLdOZWyLO3OTPf09OorHczmdCB//XdaT57dHFHhJwdUTL5O5vEh9V9pTacJFhzTfEFJPun2zGnx
nI6OjimpJ7tvTWBnOOyfO5UH6j4nH67orFROpXiov6ugraE3rc640oY9bX2u1JoWB/PDveTz5Pkr
Si4nu7gbShUoOGV8rQNlKihaclgxG/JsMnZ0Qspk5Dhl/YCfpzNk9WSbxnrOKNi9ncn8+WM4plw7
H8inbJTTdhrvORWYbB6vP56/l4x5rlPypW2rjIwNSEuFY6xziNiXZuKGpQ2hYsPpF0pVo1Id1tNY
VL8bO0tdlCgubilVlfe5+ki/CAAUr60jVmlJYd10xXVFdRUXTjUlZexTp5ec9ZG0oVtOI8uL2RGl
m/wFogvGbIaFi8NIx8vZC2S5ZO/3Y12nDFou8ty6nvFGrjqW+/BJqf3AHJVcNR4MEz+oqhUGS7sC
8Nh1n5Zcg1ggCHHR5enFqBWpNQUySqm4DM5Wvuv2jmPfVtgEML5WVQXilqBzpbNQCq/PQAwEpNYb
0DU4C4RAPuCxchklZ+87skd3dPBc5VNalSIfyFKbgtTPTVhpJNJhtkN0d/P67HDx6uh+JujZMSn8
NzawCVpVlAN23lYD/ZCHivz7LotQIVIAegqclkZ/baF7CZLaeokhyOjuzbvrN5D+i/s/Bmn9nmeE
Dp2eJAx/0x71pDxWVeNsNwNP1FBj4JaCxXu9rHhLGTK45EFOxVShTfsVRkumwJBqmkqncY5xFzPJ
HbXXvLphYymv7Go8caKknJ3/r8P7LiJDzP3caayqNm3+WTC9yDxdnfxDqvJW8OCZh784aJ3o9kcQ
faynoFxenJ+eJF3Xj+dH9xGPH0CMMPShnkbyt8gfXa6xQtrnOcSOBeUKXEYJy64+UKEgeOkwAKGR
fSkYhkYm+oGrtQR5SbWPqeDMd8nNyXUUzoa3PpR0+jd0DaKePsXcSAuDEfUGud2bR2FtHMM/5U+P
mvg/LnUIaDe2RZbE6YYSDVN5rTROGu8F7eFsjhVXFgzFVvYMnGy70I7fZsPrwgAyfdp90IoyTAn4
dnRxdo2RcF/8pz2qWx9GFbvOiKV5PzgjgbtoWyq2Sih84M2zFA6kjYZThM1UwoN+1Zoac6mM9nUk
VGWfUUHMJ5HEpoSXWefAj/OdctbCSbQ4Z4sJ40bymuiFshm/9oPdF/01Cp52kySiSzEmeYyffawH
GA33nQMEqBO9/kWZyNS5LWfdEYdWhtaZkRP7GEYtdYWDTAKNjwSIeBNO1sGLWkH2NtAATaTMOIhY
IoJrBUjYprxH1+Oux3iesBDs90UD0ybKxmu60TxFw3lWzKaUO1t3c4SYi4MDXH3aG0s+EQB+jdEN
bh1BsqvjWGY6hxFEt9XS3IBDxONNAXmHhMKmbf1IQcK/Hw6d2FlVj94dbv989/HyfDyIg7oebT3v
xT9ki+800aZEbtieaZ+2XpwfHt7VOTpQpsOZJ9tE0XAssft4hJbgG9IVPFEzckzEUxyZvTzp+tcr
ow/Ue58V6+uXRZbxzgYDbJSLr2JYZqO7x7xiwdGZu2wbVSNnd9ZGcm3WdkYB6rd7LlUNpzBsCDpx
yL7FkwDYcCXNPXwZW/FXW5opQSuqmm2/fl58azQGmK4RpV6ipPnxNL6P0uhz914VjPv3iHiRTD7g
718tC6GNZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBvYmoKMTMxMAplbmRvYmoKMTA3IDAgb2JqCjw8
L0xlbmd0aCAxMDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVk1TGzkQvftX
dOWyocoh2ISPTU4EyC4VDAk4p0ClxEx7RotGGiQNjvPr97VmBmZS1NbaB9uj1uvXr59afqCd7Rnt
yLv7zKrJ26sDKsJkh4rJw2SWFqn7yCr6uETAIc3mtFxN2j0zmu/SwcEhLavJ6zMb2VuOb068WkVq
X0dfF3RcKq8yLOpfKmpn6a9G52y05UCD10JtaL4z299a/jPZ/ZOW55PXeApU7/Im07YgZRNeyEqu
mCrEZ6oJTLFkauxKaaQPge44rplterwybh2mW39MZrs9Ij9iTa/S8tVyGUh5JhCyUWfKbBMtSx2o
dlGeKDNEvv778tv5CRIAUKC0feQQdaEi56QCrdmYbazN91Oy/e054K44c1XFNkdMRHjoNi8l/+nx
5WJxenFyekLR1c64YkPInnNU2mCDtvRJFw0Yzrb7fQ4lKNMgaV8D9QyntHKeWGUl+cZOKa5dK0Eq
MtePqDMfqaFtdCksA17hvOYAzsftjw2d0bp0oU3S6xqkFk9H6EfecfKcsX7Ew4/PGsE6O9UYTNA0
uL2E1iEBc4gWSteYXNB021CvbMH0fa8KH/b2gX+Lhcw0AfGpdX1rKvVTV01FohQnVXqtPNeekTWG
p0duRYoCaBqjoSqsed/BfL/6dDx/d3h4O2ir2Bq0o2zrO5F3Mi++XS+p92RQsGnmQDgk3+MrzGxG
+isjoseyeo+vJm0r2LIfYGa9BAGHwIAeEN8YFJyTdbbXra4N/Ct5sFZp2b48/kIXvL5i27lg5M1d
6LXg6HUGIf7DUwO7uibWTdJNxbZUsKpYBRg0F4u9p5vXs5uthJE1VWNA6JFJoZmq4FHhhXM5wETE
/qDSyrtqYJdpH/QDz36cAfuas6TkfHvvZusDHsxvtjp+L6f8P2nOph3EKNuL6Xa72rwI/Vv825dQ
ZNO7blNPqVbZPdyTe1cLED+f2e4MbjqkIQFkHnTvAL372PgQ6eguOF9LULfplYzIirNSWR2qQJZl
7rjefImJEyZw20PDjdjqF2NyiAesdHLUptRq5T1GBybwneSEIzGJ0XmVyWRzefLqGiaGP1JZtcS2
ZYZXg5N0sLd/cDsqYyYmdOiYGpRwNJrzkmylMu6To5OdgomWMhiXqAL0H5XXrgkj/h7udFbG0ElP
zFko4Klyvu9FaC2h2hQpI0ZEYyKGS8epZo82VcqCSM1WmYhJ+TRXMuexoXY2lwTtpSPHFcFJD+4H
ZZ+vhBmEMlT0OIPKBhxZyAieX17M9Mzp6e6RE2okH3Aqhh7X50chDVDpDaZ9ImDTcUCISKpyl7wy
nmZytNUdsOJGAgdt7TVPDHGyOI0Ko3yB6dy6x7AtYjmeaaBQsvBPGkuc0MSdrzYo8LKd5NIGmDSf
ko5y5+mqdj4qG5Pnnq6DoRUeGp3dmw3deeCFltxGyK1WOsNFLRdJ5/OnPB2Qw1ff5VPQVd33N8rv
xzGVmDJIYLuYMnVIPYlRum5IP7mGMIiirk3b/yD2aWfP850Z8EfEM4BQOP4etRqLBEm/wTwfeq+9
4zzjN6MQcefePOn+uSlx4cupkNqfX6c/aw1adIFDX92Bxuxwmv5n0ej1/YuMpvnsFoiny8lXvP8F
p448BmVuZHN0cmVhbQplbmRvYmoKMTA4IDAgb2JqCjEyMTMKZW5kb2JqCjExMiAwIG9iago8PC9M
ZW5ndGggMTEzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicvVZdb9s2FH33r7hv
SxDbsx20ybqnOE0HY8uQZmrzsOyBlq8kLhKpkJRdF/rxO5Qoy1qKoUWB0UgsiJfn3nPuB/1Ms+mc
Zv4TvuNi9OP9BaV2NKN09DyaN5sUvuKClhEMLmm+oCgZtWfmtDini4tLiorRyUo5Nord5K0RiaN2
Xb2/petMGBFjU34WTmpFv1Ryw7lUbOlo3Yo9LWbz16fR36Pznyj6bXQSAGycccGkqzRz5DStjVQp
rStjnaVKbdhQrJUzOqf1ntYiFypuLLTLTn8Yzc87MGFLjnFmMqHHk/njKT1XXHlLhAPvtpRPiEkY
pkIqWcjPvCGhNjBewLhkk2hTAJyB6vFKViJ3EmewQVql2oMlud5ZkopAubCkEypF/MSONkaX/4Kf
Amnx+kBWHfN1mXBUCKkc/izZTBvXROxjzBsnVsPOsDfyni0c8YCxjyJjaJUkUMlHGWRDVMIYufXH
2vDslCiCrdM5G08ST4FnfyaYQjBw30D9UrceVFWs4eHIJLhuAh4HoF0m44wkzkuDTOR7Qhk8QWVk
1Rt79iJPtZEuKxDPrTast2zGSIPfDDBBoAI5k0WZ41k5EpSwcBXUDcWQe24etRCfZFEVZKE4Igwg
Io65dPDdshu3esdw1JIjPdBOx3FVQpY9QUS8DyhxZQy8gwlbJwvhAQdVFVRFnOgBr88RZhuQClDt
BmJps9ukwFNcM/FW5JXHPqqXi+kC2Pcc6wL8N15EhGAD2LsmSihtYxSpkXrcbMPp7Yc/ogMgZXp3
UD4UuKUd5A8c+1JKtI+q0RQNnsiYUlaoFM84MRryctOKVz6ZyC5LJI6WbwYVrokeeH1AaBytHuaz
n0PY2F96Cfa0xYzQABYF26Pda62sE0j3Ujq69wweT66X92jPD2/vOtxpb38FkVWao0CRTlGWuYyb
ITTJ0YBt9vMniq7vmrbFhMD8iJ9SozFXBvR9gnr0ntE7mfqaW1BpGAqg8L2cWy95ZVFONkwH/7aj
3VRak4f1UONe0TW7HbPqRfVzqFd1GMPZ5FvX2cBtfY0wa4pCeNG+ZPrvVQeFazq4HwRx9uLNsefD
yfqjz3LtSwJ5XD3gunk8rQkJrVEHITFdWL3XBrie9P/Dql+8Oex0Xlet61kIAFdYy8c/1Qd6s5dM
v8fn6mt8zr+g7vf4XLUO/k+eH+krfH6B51G1fEMV9fX/YnVN+aabJl3nddOwG5NXpHhHO9RfKVKm
jd6pXIsNrpAq3xAmDa5c/Jrhtn/R4tumrbsDgy46HMbUTXAh2wzzmuhG4Mo7eGiB1/6hKLX1nb4n
TIOcBQb/qxkQXy0axF+rTI2J/W0wPeZ286nE5Wnpd1yMzZ07vxw3P5yGEvx5590tFn8B8SYavcfn
H4BSwE9lbmRzdHJlYW0KZW5kb2JqCjExMyAwIG9iagoxMDQ1CmVuZG9iagoxMTcgMCBvYmoKPDwv
TGVuZ3RoIDExOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nH1Wy3LjNhC86yvm
FrtKZiy5Yjt721eSrezbSqVS2RwgcCjChgAaACVrvz49ICmJthPqQBUJNHpmenp4T+fFjM7l19/1
evLj1ytaxck5rSb3k1l+Sf1Nr+nVAguuaTanRTXp9sxofkFXV9e0WE9O3rnEwXE6exNUlai7Xn75
QK9rFZTGS/NdJeMd/dqakq1xHOno+qB2ND+fXZ4ubicXP9Pi/eQET/3ylnWKpFxJqWaK5juTr4iV
rvuXFGvf2pKWTCqRZRUTze5eFXRJi9efT3+YzC4GtAZMrGVL2juHrWAT6ea3T3+8fyPbV+w4qMQ4
ylPpt8561R3b05gCTXDy6c+C1Wpj3Ap0yTiTjMpvVxxz4FvjgEqREw7ooZDgRuk7TrHAk/nlQPUX
H/ogK2EQEbpmp4LxcZoprYJqaio56mCWoGwc3XQsaF5c4VjkZBT8KMBqgFdNY43OhSlQBE7B6Eix
lVeR2JVnyZ/h1tO12O30bkq3JqGkU6osItJ+3VjOZyezZvrw8q/RcUUXD2j3MFpFVB+hVUGt9wtl
P54t2xDTjjZQiacENVVGC5ktWyv3I5jaG531sOXlfmmjhJqb9nkrOSlj9xIygZqA5y7lA3skFRjS
qaQwObsJJeNwXJNrBHGT1NJYk3ay67qYScZ8MptjpIWoVFWMCMALQpAeiLpmxGkilSagSnZHge0g
NQOBxyPoQ81aV3KgjQo7UZVvcpbwD6IqTae4oVTDon0Wgq+M5TgEiOgr2+rUdgjo1K0Pd0dIEp9x
ks7njtFqCFAOQmjQQc6UhOeYyyiRBF4rCFGCsdyz76pwgOphtiahb1PGkP1ZkqrsFqFv+EGKiD+p
deAy7o6PPfuSNxBAZocN4G1YIvjfhJXcQM94OMo0pFfBpXw4ZDRLuWs/KhU0j53W79aQzr4Zp8RJ
d/IevOFBSTO8GPH10MUgZBTiyBMsb1jECf3VZlUjX2UbhHHD6o6QoSCCz8k/kBXEqjo7LCken/au
K06n9K5FVFZh2Vpp2xxTQK3kKOnRbsV9yy33tR4dl4u+z5xkK9ui1m2j4Aey2ydhnxHiC2CJMWQD
xWLVJweXRAlexgeIvT/QIGMGZVT7HIyoVZ13CCKHA9IY5GkOpBO1grvKGrWBCWRVilY6DW9EnVLk
bydcrIppJh3jDr6iYOl2+jgLeG/cHQTSND6k426D6A/kTVVFDhvSVsX47XRM7M+ac6Kyy6iwwjCA
HBLkLvagyPk09A+7jQneieC6ij1nEU9MBm0oTZikEcVZBD1424cLFEmXcMcQxsxVe29ftlWFJYei
SqZg48gG5hwUKz6+qMXEvG5zG8BkGh/3JrM6THawQPAcs10DRQYjygi2B6px7G+DqT9tDrTM0NIj
ZYz9eQ56XxmzCNRKcVagDMw+eugIfdT5zWOPFO+wwGX5ihgGWjAyo5wf98LRvDyzZm3EwvGZkedg
LJ7M7R5vPLuHbMkEj/89wp/5MJnuP4RW3pdNmwD10zxz+72tnbgRKVscf1e9fWgwciIysOH1Etme
XU/zhxaNrr8/qxXje+4fIL5dTL7g9y9VjkPGZW5kc3RyZWFtCmVuZG9iagoxMTggMCBvYmoKMTE4
MAplbmRvYmoKMTIyIDAgb2JqCjw8L0xlbmd0aCAxMjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+
PgpzdHJlYW0KeJytVcFu20YQvesr5lLUDiSalBLbKdBDG7ttEFuOLQU5xEmwIkfixiSX3uXKVr6+
b5akLQlBiwKVDrJnZ2fevHkze09xlFAs3+43LQdHNye0coOYVoP7QRIOqftJS/p9DodTSsY0Xw7a
OwmNJ3RyckrzcnDwtmrYVtyMzqxaNtR+fru+pDe5sirFof6uGm0q+tPrjAtdsaOtz6Xa0DhOjg/n
3waT1zS/GBzAapbU5ExrZbXxjpaFeXDkcuOLjBZMqS99oRrOIqI/jKUZpyHFaTSOXpGqssOfB8mk
D7Z9eixxNzT76+rDxRnpKjW2NhahQj7LzheNg51qtqM6V45poZx2CCihlKMHLooI/46P+/gfc7a8
ZhtCVCbkkgJ0yYQIxI91oVPdFBsquZJjziRFk4e4z0CdX7gW67C9HZNrlAWgpTVlCF8aCUGqKGj+
5n1HTK7WDJNllW06oPg7zZEGd7Sl1FQrdgGYWhudqSplCtVtVSL0JCD0jJe60k9VIOnW9QsUWnQ5
3koJDIZWT50d7vsX4u9IWSG3Br9AD1iLjTjuFF9b8w3F47BW6R03lFlTk7RmiAIzUsEwapQu6N6z
Z3oAt2luEBJsugbVd8AAW1VBhA4klByFHgW0tDBNU3DF6R1pkRSQIXYJxGhd1be5lo4F2Y4KXWpB
9UR3RMVX2xZaGOcCxB69lJwi94K7SOg9inaSAyzQ0ldpz+y0jVH5cgHtwLDwxd1zmqHomGbDLpC4
Ol/2LVng8EFnTT4C8xgh5M982oQ7QSfqUZdwX/jlEtGd/s59JDCQb+ESrQfCkRFShwXwzu8jmkiu
T5dXNzfjOI4//7KjeVBAv2KLnBzTC5p+GdMRzb6MuwxTHM1gn13fzG8PkiNxuz3sDHR7gMu3h53v
fE9B5B3vcdsYykSTrT3TUpEMwbPMdoTUSg7F+KYd9szIVGKUdB22BqyqkbpBBLhJtcU+waBhKFxP
UsnKeauhih8JmlZ6Dagb40VoKk19ACouper6u9W351Kwq9Y65RG2hVN7szeGTC81FtxOXS1HItWU
K1mHnb6Ep0yo4bUqvMTOzcOu7MMSwPKAk9plSK/yBqgwVWixLMEyVIoNvtRptwXFAo7KXUQ0GnVy
6bA9TakMufGQH56WnyLp676022Vl+d5r22LHjtLg84kqlLlP9ZCmXwXDUMYVZFa7OmwPobebqw/T
M2grjuLJ8YtZqy+hdSK0cqYxDP8/sTu0/guR+xieqdwisV9APZWv/iOV/aMiQX5IJf8Dk7xH5GnS
EZnEL4PbO5/jaWJ5f6LtR/z8sQYOR1Oz5oAzOR2GV512Pp/eqxXT+OVnhDyfD67x/Ru/J6yJZW5k
c3RyZWFtCmVuZG9iagoxMjMgMCBvYmoKMTAxNAplbmRvYmoKMTI3IDAgb2JqCjw8L0xlbmd0aCAx
MjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9VtFuGzcQfL+v2JdCdiGpOtmx
HRd9cOu0MWo7iaO0KOqi4PFWOtZ3pEzypLhfnyGPsiRbQQMUyOlBOnE5u5ydIXlPo2FOo/BJ37LJ
vrs5ppnLRjTL7rM8DlL6kg39OEHACeVjmkyzbk5O4wM6Pj6hSZPtXWjPVrMfnFsx9dQ9Z++u6KdK
WCExqP4VXhlNv7Sq5FppdrTxXIkHGo/yo/3JP9nBS5pcZnsnw/HwcEj0msXigaTRM3YBYb+XjY9i
BOZNKuXISdbCKkNSaCqYWscleUO8EHUrPFNlloShUI+TFTdMllGUQxDQ8oMVmtLSNErPyGMVUyUR
5trah3+UpupJITQY0FzIO/ZUWjMni1QOeAFJWNPqkvJvhiiRSbdNwZbMlIq2vqNpbZYO4Petsl2p
QlaKF0we60kQG4lqDNV9uv47ltAnrNlXrE+3qEij9APdvPlwfU63e+hufvjt+9v9gBjofAE6fxP2
IS4RZT1NkTJ/TVIXIUfruvwuMLRRVNnaVGqqjD/OoaSGtcdKLnSk67HS/s41xQwQ21IhWJNISLWw
M9ANrIGTouYhxUZNTY3ehKTzSjhMayDMIqI66BbdOu1G6IIGCapRdbmj6tFgPHLfr6IRTg2Xqm2e
hyac8WhwuDkjTHmmuQR+OBocbcSSmAml+yvxQXnOkNHDtUBC+4822i8WQtWiqLE0AREr//Alza+4
npNcW7pTQaA9yKDgSiyiBdbdD7WIUsyjLqjA61KVvgogYU2J9nVfHawDvxgPtoT2nZgCkOVpzdLH
ZPwR+QMrpQqkRNn8rgY/K2K9UNboDslBekzKB7+g5jIhoY6SnZppYM7ZA2KxXYGx8KNsg5+B0bS1
6LJMMeBaWSWcFUluuL0lwSNxDgfpRbJLi+6EH3GL6HRaGO9r1izvHjsAAv2SWW8RqA2Kpd6NacE4
XfYio6vXm95K3maB107/rYUkwMgu25BwSeNue/cwRK/WUflph7UqLCVJ9ZFfGgrbwLat1jXv9teZ
C/sFetfMa+5I+IzdUtndJvjcdziXRlfF3H3eaXkcX8OkwCcOS67Z6ZdnlIz/NyWuMtZ/NUrwR/NF
pCAQ/G0G/wcvwbCQcdDf1dkfcLIxmCXS7Lg+Fa4DoKOjhEo1naLgYGfYnpaV8NtHBLzqYQ1sFQWE
jAMuqpdwoVgae9dzOGfDnrE2/O1eMGJQ8+OWstqOcbsAY3Nrylb6232ASHZOBfyNQ0PGWkNDK6Nk
9EtEjOUnpCereP/6zYfL87AdrooFP0hWmGDrMpD0Mo9L+rWtQB/uBaIebt5yICcc+I6usch4IchP
+vHaQ1vPn28FvDN+8RcQX02yd/h8AojmCpllbmRzdHJlYW0KZW5kb2JqCjEyOCAwIG9iagoxMDE2
CmVuZG9iagoxMzIgMCBvYmoKPDwvTGVuZ3RoIDEzMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+
CnN0cmVhbQp4nG1Wy3LbNhTd6yvuLvaMpFj21HanK+fRJtM4TWJl0am7gEBIRAMCNACKUb++5wIE
RTmVFn4QuI9zzzmXT3SxXNEFf4efspm9/HJDuzC7oN3sabZKD2n4IRt6tcaBW1pd0no7y3dWdHlF
Nze3tG5mZ+9tVN6quHjjxTZS/tx9vqfXtfBC4qH+V0TtLP3W6UoZbVWgyedeHOjyYnV9vv5ndvUz
rT/MzvDfda0oqoDbdH/3J4mq0hxDGHMgtRemExEH+FDvqFGWH6qKglRWeO3C+YvZ6qoEezwLtfNx
gWgNCVuRcXaX/5KiFVLHA+1xLZUZHs/nVHVe2x2ffek8YnEUbaXpKv73+vUnCsb1ixCFj9TWIqgl
Tl1el4z3zivyShgdopa0NZ2MKJkvjxlbERm5kBrcKJLIDYC8qpap/5MWJljI2rmAxh1X5HzrPGNx
TDZiQL2ONR7shK8Czg99SNc0mMZYE353W9qg115XuKAtoa+oFm67AMILbjEqWVtn3E6rcNopD6pk
zC2EGDggg/RR9V+Udcjl+oAeY68UoiuLNumO4T1p0iup9B6PXjECji9w0yIEFUKatm4AXuTwlRfa
Mp7cPRLa9By8G7rcqFrstfPzzJIBvq8Pa+6/FRiPRp2t8lvnG2GlymjFmrFN8V27GGJFoU3izcO7
P75+eEOtd3tMigQq3mJgfLtysmMeEuJxSu35WOuCMEOUSgfZhcA1T9Ny3Eq1xh3S9aG6iud7WgxX
sRxivep8wFSguK2WcwqdrAETMiqAG3EbQ3xQMg33Znk5R9jOVCRMYFRHIhTCcbL/RRmqOCQh7JFc
bIw60jcjXtBO9YhNAB8Lo4Z5TOhyu7zCYD/BFhrF40CtAbLecziGAbTbaJP/EuYAKg3hmWSoNnpn
yIieuoCaN3wsOY3OZbdeN6gXdiCgKjzuay3rocojy5461XFP8CJYD+4OkU0S3rs0zY4ZinJs0nt8
ln6sS3qUL4Vh/H68Uig4AQNSqVWjRoEPYxgj5zFlp4GuFMSA6Nq2HWym4AZhJ2KwDapSCpiAeT/L
8wLC6CJfHmthnJn5I9aFUncTi51PYgRqAJPoolvEzqpjGUN+pprzLOjRYRpIE2y1k4EmdCCBbdJL
JCyM3vlv3HxOG9ilM41HvZTDOLSDgJlXBpCYMP9B/n6MqOxee2dZTLDy5YRBx2ryQABhaSuNjD1O
P6WWQpYKhIC9IVDC2NtxzM980IN0fBrFQN7Z63PXU/ogM0OrvuOMTlTjpyoN74SlONh0JurWTLjn
XMtUF5HtnhW6PwE1aowLdIRHE72PZW8ldcCpeCdNOuIw2aIgpum82RwDG3WcmAWDh1L6WiXdH9Kp
7Fu4jlBjta3D9NMKaF3kzTw64GSOglcw67e8PvA6rLMuymbkEJMrQe9AzsKOxzPjQhr829cfF9D9
NwD+eI6ydLLYrXdN6gpcrV01DNSqbHbWFXREBQyDwmuF5koY1WERoL2DFY2WoQg4lhkzbtFJZ/I0
yppgWIZZnZKD6yjbIDzfIhshv+28A1cgHH5dguLxvtKnl4Uc7fRVoFaYJG/64pJTg5m6CWs9+fmp
f5SJwsjz1oNSR6s8CZCZzJQIibJ4m6t+YcyzT8GGC4oAFByjHlYBeIdVl+I9V900Aeb96/h+NfG3
xE0m2Gg7Vd7jI0ADhqNTliRjPafITHXeQOfC6tDAcJgwsFNlDEp5SPZzunlqZVhyU3svW2cKVHlT
GQAfvOhI+8HjXh4XfRjM4Qj8sMmy0Jg/1z+lkf/e1XZOUIjgIo+ft99bjX1PH+ECzQahVrfz9CZN
J5+/PomdosvrvxHx7Xr2Gd//AKxOANNlbmRzdHJlYW0KZW5kb2JqCjEzMyAwIG9iagoxMzgzCmVu
ZG9iagoxMzcgMCBvYmoKPDwvTGVuZ3RoIDEzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0
cmVhbQp4nH1VwVLjOBC95yv6tlAVAgk1BIYTBHaLmg2bgQxbU8seFLsda5AtI8kJ7NfvkyzHMbO1
zsFJJL3u9/p165VORmM68Z/4TorB8cOU1nZwQuvB62AcFim+koKul9hwTuMJLbNBc2ZMk1OaTs9p
WQwO7krHpmR3dGNE5qh5rr7OaZYLIxIsyn+Ek7qk32qZspIlW9p75uKdJifjs8Plj8HpBS1/Hxxc
jIiehJG6trQEaiYTWhidScX28JfB5CzswtllLi1ZTgJ8ZfQGASytuzhOk7CWLb7lTBWbTJtClAmT
zkiUPk8Ajk9bQGBU2gpF2EebmIKLKVQxBbJ1kgN3t7CVLqdUZhkbLh0APZSoKiWTwNwS0FbyKJWm
yRUB4tlRx+diNAbvlm8h3yJQQzLh0qdDCbJeMdWWU8+ON0LVwjHlehsJYW/OBZNhqN9I0OPougiU
IDlpnSzXXpAdhX7yke7nnvSa6LpWL7ScLTxiaXEyJoylP3nVxun+fNJ3i+7XDNBOINa1dPTgKTwf
zK4fng/p283i58NXqaic3DD5GmuyDvQK5B13PH2oFcihUFGswDIFs9QLnLPlfY883M7+mM9v72/6
KkHbNx+BSThSLKwLHsq0UnrrBfPLleLPaIcPtfVEL+kspua1qMQakVK9LZUWKZi2FkrZCXgqJVnS
YzTydDR5PrwELOTAK8LsBHjyAlzSJ1pF/UHqqnwnjfQMuBYrWcbKJbpWKRSIEJ0OsEpKNo/L0Mlw
Viv1jhSTuoADIFWv3L/CwfBTvjPiMKixNqKC9dkmRq76LCaj6X78Ttk1l2xQ7zQ0WQBNFLrUO7Dt
CowFdkYmXa9xmR45fYRXJKMAUSbvQ/ohHYZMYJShNF4BlCXk4CT6YH713XM0XGnT53UxmiDS9X82
ZowClzqjFQqYvLDr0rm5fwTia83W2WPDtoK0bIehHR6/39vjq9kXS5C1R90WQqkhChe8JA0pbRuX
Wt6gLiiALBCqsdpeE8Zs9gZY4+RuLjSTqymB2x+LW6kU5awqrLSjKYxE7+FtzsE1Ppz0TNO6ObUb
j+00kWWCjrMcJmlbAp89Aq/ESirp3kMFQ3uBBcT23R2F+9lNbn+sDXeNO//2uPTl6lwCQivtB6zv
Hlm++Er3VK0r//eQup7K0LY9M542s/X/Wj82fdsjJDBDYF78RusGEIUaqeAzL1d3KwC0bBKNMG3U
c/hr0uXfmswilbtYpQSSNq1URMO3Po1YrR5+ixUoBAjuEUOIro12EUYfbknuDf39jHdAuH1Cpwhl
9Uf9e2p/5ILFs09h8Uudl0Ni3B5qtH/D375V2G7pXm+4WEHa8fkwXPnUe/5aYEjSZPo3EG+Xg6/4
/AvOzbseZW5kc3RyZWFtCmVuZG9iagoxMzggMCBvYmoKMTAyNwplbmRvYmoKMTQyIDAgb2JqCjw8
L0xlbmd0aCAxNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9Vk1z2zYQvetX
7C322HIteRq77SlOnI6nsaexNdND0wNMLkU0IEADoGR19OP7FvywqCihDiKJ3bdvv/lM52czOpdf
959Vk58eLmkZJue0nDxPZumQur+sousFBK5oNqdFMWl1ZjS/oMvLK1pUk6NbG9lbjtMPXhWR2uvd
5zt6XyqvMhzq/1TUztLvjc7ZaMuBdq47taH5+ezt8eLfycUvtPg0OZqdn+F9Y6KeCtBjxlZ57Y7f
TOZve4GZiLioVwkbR0fAWnhlQ+18DORq9jiyS2pszp5iyZQ5G70z5IpEkF8go9lmnE65KDiLQJpd
JCPAg2AlNGrzqmycqwMUVCTP8I/cCvC5hrZnGynqikOmDAcwvI0dMy0qECicZ9KVcFQiLDC1d7UL
nCdSISsZAKQgF5gtRUdP3KGEqJ5AZV3K+5I3SSrn2rgN1AE1sK2dthKFAncRtLQyHQb8WHJICVEG
96Qs9TmkWsUStBcIB27lpUDsqAS9tMqEDuvLkXEBVjzdvL+fVsp/RcC/HIOWDhL6wrsqeVVxLF0O
r0xwZBlk4ZZ1fXRUjhgGNhvSwkSiutaxTGnJN1ZVOku+yHPscyxxiy5zps1GB5XC0uXqbFQxczj2
gaPSUHC2TflKmaYtzvBaZAJzMu2vE/rh9SoI0VHxbANL5QV6t/0+jKhvPWesV63oQfvbw8rbA/aP
vuF20oKMEE/a19+qbB9cgwzQJwLp/uFu9+Fhu68iCe75jB/uXco+7asc5nKQ2PcSsd1/OBSIIQXX
2+nuNYLaS8H14RT84Nq33JXcntRHvWzQrRe/0gLtbtxyQxgGqQxfR91eFS5KzI3+HWXo1CemJrTt
0xUvU+nWVKqVNNzuBNF2VI6Bn5s06zB9pMHEsLZ5kwHNAMZmGww0PEs7nI6Ol87lddN3WKVedNXP
dGXzvitznrqiAMO45nY+Bbxfu26exM7rDqX2OEaz57AyxAaN25i8d/KM9vxBT7eEdD/wh2oVHkO1
hrKHEWpBVfwbBDbkZATLcCjEXnIgDFOx08BpwJryyfzHlKCdHJySjjLLUS6uqqS4JBWvkzWpkqJK
A21nbBpesWmDapvqCTKYZoVxa0DXnOlC73r1yCkJdIWZNQcpySyypwwGZMBWlVlfyegeJkzy/1oC
1rvZQXmGadk04PukbZu08UhP3MJ3IvAXD0Cdx1J6FasgCRN/MNq9jOdRQnc92BnCsrRvK+wnAMWW
S+ZCKiycHVzpj02WcQhFY7pFJ6r9Bkcmcg1m0UjtShUnejqGhAuxUQvokWlYu0etOv8VyCsNK6nD
0nZCkPO1LFcUQHBFlPt+k49AhrXUbrmsVFaHKm2aGsGSzEmXdBbeDOWmavWkjY5aVj2CatBSHWJb
Jq0Cmm0jHOQP61LSk74Ahpob2IBmleiiSrC7feyZaZ+4ofV0Jrn4eZ7C8UdTosux8pU52x1TNy81
IhroHp81qVBnV6fp+2w8zf7+Uy2Z5lf/APFmMfmM3/+VoQiLZW5kc3RyZWFtCmVuZG9iagoxNDMg
MCBvYmoKMTEzMQplbmRvYmoKMTQ3IDAgb2JqCjw8L0xlbmd0aCAxNDggMCBSL0ZpbHRlciAvRmxh
dGVEZWNvZGU+PgpzdHJlYW0KeJxtVsty20YQvPMrpnSJVEXSolyW7NwcP2JXYitW6JPlwwoYABst
dqF9kKK/Pj2LB0nLZEkEwd2e7pmeWTzQ+XJF5/IePot29uzmiuowO6d69jBb5R9p+Cha+mONBS9p
dUHratbvWdHFc7q6eknrdnb60Ub2luPirVdVpP71+ssnetMorwr8qH+oqJ2lP5Mu2WjLgQ5en9SO
Ls5Xl2fr/2bPX9H679npANB517mgTKB/P1x//fut3NgAgrrAqXSLwuG6cp5iw1S4tjMcOe8MRcMt
z89+m62ej4iNrhuDv6htTTVb8CpIy6aWbcwMF6HjQle4r+QqBnJVBu/xACdAIRUNFtBJCX6LqLQ5
oU1YDt8bVuXJnLTtEvbfnvKyXs6pSN4jCj0kTog/ICEbajfPN5kM2zo2t2fzLCX1jAKANs5suJyT
ZS57ubplH+bEsVgOSOtGB2rYdIGiI+TIRl3tgBRAQoXgCq0itm91bPaiJRMiDykbtWWhhGIp6pSP
ukhGeUIly63y+MFTcFXM1yVvdMHLITjK5AaQShXaaAhAoUsdipBClqK8SxYcGo0E3mtcIr09SqBC
WWIVtNlNae465+NIkNS0FUutiyL94jJXd7VaXoDHDSNz0FVCqMRNQeIOcL801OSJLHYst/Z5tXE1
nBAbFcGcj7zUk8ZHJ9FQVyE3hCRd5a+N22aYO27URiNxhUumxNeBEKog3YE7u6xxSud7rOVHJUWa
owzZHajUIruF7lTAnicV8/yQtJc8Hjut95jYNTuSKu/a43AfqwFpfxfF9LDxjlql0RoatYtS440y
CZyw0JKOuWR3TNHrjVYGxtsr6/2VIX9OKLz1U/zDyEOLhxHKllBVRGpZ2extDrA/rJU3HYu8Pa32
qft9VIVmCRG30DAljxs8EKTVspTRYVOlIDWwDTrqDe9lybIOZLS4apwMxwwGcoPbx+EEAw1qB6QP
h6Moz5chmo47AUZe91NMRB9FGUAOY/WdP+Ud0+FoDKhOnO9lBAyJdNXPtRqptFw0yurQ9kNgT3zs
Nem0646RQYh742z0zmTDv07RLWKyw3zDwhWWfnLQlWkOEa8tj8m703UNGdQkXxrO7Xfz7q20lXG7
bKCtCs9QDY3eRIeqFgPeH3XiYeYg2WVioqVwsE6fncUiN2Opq0rmWRTv6pwhsB3bUQJPIUKunDpk
gtWqaDTDEaoouIvqzkABzpFK9201AGHYITzgpJVNKmKaCIlY8Y4BCoaQJA0H59b5+0O6qixHx7mD
o+0REqVdbOF8bomJbd+XAbCqlD2dc35AQDqgpFX2qIYyDu3u0GNIh9H3bHIS0QV8mItt4wKPQVRV
SXDwOqpDMRjBqG3WNfRS8ns/g/y7R8xfSYYyRiDCYZyBMkbVCHbAQdI/JcuN9rs9xb8U2N+ePT1A
MA1zscXGyQZV9V2+rykIfbX8KCd9P1L3EwCuStMQ2sqQeJJt6e/AUTrICyEj1XlNrbZoS0M2tXfs
9432C015qf7BIVd52gDT74Jwhq5+xmIY35MaB/4uRG6FFAgcTwpUsVcHOUrkveetYDwJPUC16p6n
6TdgtA6wEnpReY3TDZaQekpmAYUy9BHk5vQUc5fqY3ed5APb1M7jeaOdjtvP1+vxoKJ+UIhcZCHK
+ZGPSFvpOvlxXuz9dZA2FFTOefQRaCJBgcPyhOjbzfs3Vy8ur77nMowPMkkO9zzCL19krL9SY+XR
CfSWh4+hsGY+Pz+7DedCrF7O83MpHb2+/aNqpotX34H4bj37gvf//Sy2oWVuZHN0cmVhbQplbmRv
YmoKMTQ4IDAgb2JqCjEzMzYKZW5kb2JqCjE1MiAwIG9iago8PC9MZW5ndGggMTUzIDAgUi9GaWx0
ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVVNc9s2FLzrV7xb7BlZsaRM7B7TJG09jZsmVk5J
DxD4KCIFARofstVf38UHZSrupdRoRFLgvn27+8B7ulws6TJ96q/sZy8/X9HOzy5pN7ufLfOfVH9k
Tz9vsOCalivatLPyzJJWa7q6uqZNPzu7MYGd4XDxzok2UDnefLqlt51wQuJP9Y8Iyhr6NaqGtTLs
aXLcigOtLpevzzffZ+ufaPNhdoa7/DhYz2SNPlDo0ukAtJ4B53FDBJLWBGc1Lph6IZ310g5KptLn
L2bL9Yi05U7slXXko+xIeLqPHJnARCRox76zupnX25rNLnTT+xzkAoCr1yPgm6ZRqR+h9WGey3vR
cjiQbUmY3LqXHfdMylOjHMuAJhzqBW4oWFLBnzD0QWyVVkCIpmFHe+EOyuzIDuygHM7Qa6npj12M
iwJUb5UEYIIanG2VhsDCNNTqKEMsCDDowbq/J0jzhNKwl05twUuZCnEHvsmt6wXRx/9ikCqj18Am
V+nYSM4ypM4Nc+MrElp13Atlcoeaa3tYCjsngA8KDseQMdLz1FpXIcRRayQi5QwnIRowArubNpec
BMPxfYTgdUmpN5L5oWp2zhx599EH8qzbC9GIIYCHZO9Tp0f4CrQXOkLg7YG4H7TNJogY7EUtGlh2
RiFNfhKb5WqxAuPPLG3fM2g1SIaX0XtwqcA3hqzLAtnCHKpB3xKpF8mrVA5P5+x7zJITRUAsOwkU
XIOEvUjGFM0F+YGlQlCIzV45axLOvOjnLGZNaE93v3388uFdpTNGI0v0P4bvOHDz0UM0AbImqPaA
i8MzsB9cQ/s1+cn3CvJkXDI+EYi6QSnkFkDsQ30SbdhR2oLOe9is0mhWqMmA9tgCjA2IGShgPDGn
o5WcxnRCtUw6KkWdao3zNlF6BAMpOwTVCz2nLWItddq+wM1bQHWJqGPh0Rxm4nRrQaJRBVKI9IVU
rXpEVCaCpVlRx9hmUgpbG4dK6ikExczEpsrBTbbiO5KOIDC2NnDqWA/TtD10nBggMLn02OZIoKQ/
bWxiGLSSeayhANZjTVAyauGmEXvW37MdkhNk3hpTb0+lvp35b+fFwockyTj/+nDSZrIq7xhF9PFd
k65zI0N06U1S/IMPdXxvv9xtoM2YdSiUXGqmI7tG0t5aI3WcDOkvahdB5hVp5YMvu79kI5yyZdMt
htRIJwXKNvDqKoP+HjuTXinI6WL6Enz/OGC5pz/snvstaC+v5/mtSCfH1z/Fjml9+Rcg329mn/D5
FyZ0jsllbmRzdHJlYW0KZW5kb2JqCjE1MyAwIG9iago5NDkKZW5kb2JqCjE1NyAwIG9iago8PC9M
ZW5ndGggMTU4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVfbcuI4EH3nK/pt
kxrwYAiXzBvXTCaQMODM1tZmH4QtbA2y5OhChi0+flvmMhC2tobaUBEPtiz5+HSrT3fzDGXPh7L7
ba5hWvg4bkCsC2WIC88FP1+EzSVMoR3ghib4FQhmhfU7PlSq0Gg0IUgLF7fCUCWoKXUVmRlYj9bX
IXQSokiIi+xvYpgUcGNZRDkTVMPeGJIlVMp+/TL4XqheQzAoXODTD6X/PT5c/lbwq1vA1SSkgigm
4XisJjT08DKmz5YpmlJh/mUXrBDwDbm9MdQqPwh0uHP1CzMJ9Dr3W+Zw5dVgNXycBDClEDEdWq1p
BGwG2maZVAYnZ7DvmNQkTGhkMQpiR6oOqz4lmk0ZZ2YJxwTPQipQRGhnNIyUNDKUfBeRq5q3dth/
jy2rFQSdUWmmGBURX4LGC1U7p9dQY3uBt7UulEKjEpQzbx+qFceKas0W9BBoDVU5BepRIFLmFl+D
OajqKVCDdu81nT2oqwOo1h/HSGc5wbG0IoJAsQwCllLoE4Y5SOucVf0UX70lq7ZV2kBrqqXK8ojf
91XjvVhNDNnI6ziMmydG+zeilihdxzqmOreR0wVF/ayg6VW82q/H1RaKLAjjZMpxJ8lIiDzXUPVf
hxphoUkpJhoNBMNC/zTYQbloDxKmYfL54XHQfZVfzhai3xx1qzFIyWzGQpdqZozntW91fWqS2WCk
7MfrPXB9mGTQznGv8zAc9u67ve4xVJuVIqxxeUYmHMwGeQNVeR85Dy03rOSahmMnYCuCtN6D1W2a
8bwZWLcvHanNHivfsRppaiNZCmVE98IrU3KB3M5TUR8yLKhGKuQjjJL80FcVxyqwwilrQ+j+IReP
Wjc3b19SfzZt69FnsVUUrj7BxKYpqhzkDEyCdWhzhGuV4hOmtqyclzViVeo5ln+FAmmFcyFfOI3i
3bL7SC7lF6nmkBCNhlEBGVGGEe4K8K6ZmS7zb/askhkl7vTSFN1ilgddoc3rGjOYHDCNCexP+i6V
5PAo2BgnWF1MoqSNkxxwjN1L6Ly77Xu3tHY9xYAYKsIlPF2Mb4Pe06ULh+8oOHxw2wlKVb/RKJef
Lr09c13TkR8nm1o82q2pQyKcFUTMNRgJE+eUeWKIKkLLa+OsTWKylHNZhH4+m1NcGrtbTDS6CF3v
wNqO5JxRVWor+SKKcIMbXeFMXNkqwhec3lBjlvjiyN1LbnRKcGOAs88Ss7SIShtqX6SKqcC+oAh3
uHrH+HzOitBx95YTY0VMivA7TgfEoj90mHAS05x5x7GqVXJWdzZBCGqAcG9f9r0fGYaFhnu5oOkU
z8hvFvO/CYfZ4c8RgkLV/wsRe0HhK/7+AcvONw5lbmRzdHJlYW0KZW5kb2JqCjE1OCAwIG9iagox
MDEyCmVuZG9iagoxNjIgMCBvYmoKPDwvTGVuZ3RoIDE2MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k
ZT4+CnN0cmVhbQp4nKVWTXPiOBC98yu6ctmkynyYMAG2traKQJJhJmRI8NZubSYHxW7b2tgSkWUY
8uv3yUA2BHLZMQdbUqv1XvfrFs/UavjUcr/NO8xrzbsuJUWtRUntueZXi7R5hTmdBzDokd+mIK6t
9/jUPqVut0dBXjseK8tGsa2PjIgtrZ/B7YSGqTAixKJ8EVZqRVeljDiTigt680zEitot/+wk+Kd2
2qfgunbsZrWxWnl01yCaCnxc4WP2JJVi49EIg0CkloSKaILBn5y9ZBRrQxFbITOO3NLJLzX/dOtx
KQummDl6FOETAY5NZUGRDsuclW3Atn1W2fpncDge3AxoqFUByKaCX8DC+QnctpxzTVKFWRmBjdJk
+LnkwpLV1Vbn7tjvOswclkba1WFnM50zFVuTcMekouMCKQwTppWVsQQxqej+7nLY/XTWfWg4NDs0
t4Q8elyRtAVnsUdzwwXmKqSKlxjLhQhXGJr/TpdFAQpvA9ED/juO2bAKuYKMKR+TN9rkALngd8s4
/35cHzUk27huw3leD8tHGT7sIHzz3KXMHo0bHv1VenSN92fh0Qzvv2WeMw5RSP0A44skYWPXNuvM
vnfVoFmYchyzYmfr0dHwj/PxsIripUBqrrVK6iNZWAG4dMN2qc1TceTt+4qckuvvSNRbPn0/dntc
BuZGJwhq8f3Eoy9ClcKsVfwmfK/BMPAjw9AkzhsvRPZhPD6LFRdO3hC+3nwMVGR4+coc0aHLTK8i
R1DnOYQcDKf7HC5wTrmuu1kpLR95W1p7cHaY7XvaoVpmFc/OO57QY6vbP31AserCcgZLwD0KjFBF
DmE5GCgAa3RGU6OtDnUGRLNgRF3vQ3VcDglOEYZvYzSkht/t9LrNzVHYzHPL+SMb8vs9/0Aaf0ut
nf/abC6Xy4aJwzpH0mrT0CZpShXrJubg6Pd9Km3f74PKuRFR1W6cII++8ooQo2hdlyWaCWQA46Kq
eRXJUFj+kAragzTsCpOuecEZdFfxc0d5INDvHoDR6fUAY5BlueuAE6C4yvRi3QDXYriG6iHnlF+A
8EKl+JYq2SjiIJJv2I89yFEGVbgmjZaaFSDkNs5QHJEwaKocYkUW+cECOR9Oqd3bMADK/RStZ7eV
AX79/5cg5+dQhj51OrsZqsLxpUGT8LYU0lXHOdpSmgvz5IhN2KY60plOVi5/H0Vn0xWoutTQjhWH
lka8kGhw24zh6ANc9gLgzHC5mTD9Gfrwcoj+Waf74NAuK2U4NezSDdA7pXqlS5cQ31Jk2Ue8p2xi
19PRGbc0ccSBtFazgzIp0VB/ghbcVLTcfwiA+VqmoMG4z7PGW1cXP+YAXuC+WWwqHaJybXb3xPup
SJhO266vXgS1W/z+BckRbS5lbmRzdHJlYW0KZW5kb2JqCjE2MyAwIG9iagoxMDMyCmVuZG9iagox
NjcgMCBvYmoKPDwvTGVuZ3RoIDE2OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4
nK1W72/aSBD9zl8x4sslEhgMCTjV6SRMoJcfpMRY7elKP2ztBe9hdul6HUL++s7YJpBi7iJ0IIUw
2G/2vXkz4x/QtGxo0rv4DJaVhteFeVJpwrzyo2JnP0LxESzB9fECB+wW+LNKfo8NrTZ0uw74y8rZ
jTRcS27q15rNDOSv3uMI+hHTLMAfxQszQkn4mIqQx0LyBPZeI7aBVtPunPv/VNpX4N9XzjD61Rv2
W53u1TfEipc8qcFHqwZ3LBahkKGowQS/MhnCyIK/+YKlyYLhRdUefJK8vmab898qdnuLtve65jEm
HHGjRQAzpeFmPB5Va4D5gBLW4PrTDdK37O6F020Ux6gh3C9AE74yfPmda7CvrvC23yNjVh8ajfV6
belZUOehMEpbSs8bQs5UA2OE9IeFUK3OW55O83/nOWbBghu4V0lylK3TLOF1SB8v+5Xt4W3vou80
S+i37Y6D9D22ZAstkkgyiQog7WGsNuFOgWsL3BhZIXs/4tALMQPa6pgAagaD51UsAmGgr+ScJ5kJ
H5QRMxHkjpyeDfoP03MwCoWplrAineh8h67IoztZWs2mfZoshFQmS8e2UZahFjxckiQ+6jAI8U+f
BVyTVbxthOTpWdCPmV7koWOqVD1/THIYrWIYa2VUgP8Mng2XIQ/B4yulTYLCeH5/DH950/OjsuD5
SmTJog/q6VWV9omqIFCJKpftCzLLnjX+RPIx39SwQ2ro+jDa8BrcFqLcWvBFhEuuyTT98TFVSGRE
2aAJDX+VZ3rmD73+9PzDTqjJigev9jmmDJ3xUJk8+sYwzmnSEFKZNBcOGWaEBVRoF/QDKeBmthAJ
ilItZkI+Aj8zLdi/NVBvRd3DvotYmA1MDEqz5NIU04OylZCk6CGpEdNBRIzfNycJpYxgJyPYi+Os
H/J6PydE9nNR70E2I2QmABV8r/OP0SyqvaXVKaWVRd/U7sQZSEgl1Dqtqy5S+8Ljl5iYbQeep/Jh
P0n1E9/QTLtXa67rJmKy7iKx+mCGY90cI+drJhNq6VcLJwVRynhINI/eppIfssMlbb+rfARSxtGx
ieMkYnEq1dO2e194nC+9mw2Xc6Z3zYsy3KU8ivkaV+HxiYaK0ADTrDC2iy6fa5Uiwo7+9Ox+cO32
fJpnOX88zTu2X3YZAgfbwtut0wpPQCWidO0L8rSLiy9Q2KOutZ1bIyZlNrfcDc4kChbt+9+W3t9x
BV3KU6PjX5Sc4bJDhXHZgvIN86WSZfxowZAJHaU6McWqqd4M/OGxxB4P1BKHRJilTvA7FhQfZObQ
C4x44vCY8pQTNTYvhsmhmC62rU02zM6NZzu0aR69TePs0fHytIoQSFaRy1ZG5S6NcGqgwCy29qHw
KULgut0tNdvJlOy8zfh1jJyg3f6GiAO/8ojvn7ZV9GxlbmRzdHJlYW0KZW5kb2JqCjE2OCAwIG9i
agoxMDU5CmVuZG9iagoxNzIgMCBvYmoKPDwvTGVuZ3RoIDE3MyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nH1VXXPaOhB951fs8NJkBlwMTULzcseYj5AEQsCTO502D8JZsFpZopIc
Sn79Xclwm/JRMwNCllbnnN09+gmNIISG+2x/07zycXoFS1NpwLLysxL6l7D9SXPoJLSgDWETkkWl
3BNCswVXV21I8srZUFrUEm29q9nCQvlEjyOIM6ZZSi/5G7NcSRgU/AUFl2jg3TNiG2g2wsvz5Hul
9RmS+8pZ2A6aAcBQLpTOae8rwhQXqFGmaM4/VJqXfhlt/hqNe/e0+9MzTYet3fS7J5IoBK/BJKhB
lzPJajClIZMv0AvgXqUZlzWo9tmr0o8FFngNjGLtRZkQlRyJi0BjIEo9Jr+c8Eu2xBylBatgmK+0
ondJPDmMkpBCC57CBLVnRnSqNYhVviooNIzRrpX+YeBViQAuGzWny6fgT8KdDk2GzzSsdooFidIR
itlrWGfMfjCw1kouYc1tBjZD4Nvk/EPnRPHolEglE3/sZ39quHfq4GE8+KvMAzq2Bl9I2akyhvTu
0jBBY0nvmIZPTJBCND/bit8NIGGZrR2qVO3zZWY50XAM5p7kvCRJReTmUoW/uLGuHEAtfLFRyMNI
Qq1hpbnS3G5ok1wSHleINLRaiWPaH8HTEwZfOeoyHTWfmNUqCMMLqFNbtOFonm6i2azZaLRPKnbD
jGEbVUinyU4SEo+K8Z4khNlGphllc9c9bsVUObCHEMtKgBl/47vs35CI9dkK8QWeUBuKYJxWVJdE
e9jr9Q6jDMf9h/hhBP86ITK1Mp5Zo73P7KE3JMIXp5kp5ILg1m8V6iVKg8QxobyP0juUEjdlN/r0
+zoZoLWbY9Lf/u7UbpGzN7SuVSmtvmDrsSI/8XSSPnw7c7jrXNaPtK9WS02d++2cKN0yWTDtTedi
j9pt9IUIX1J33bItyn5Rg8ctjEEAkc65pX4nHBHVFtlZzqWLRi4gNoabU6KQ9sKl1ezSasq0zqnw
EH1NpoXWzkYoR7AgkqZ6RJKoMFYzQU5G7SUwVXleSJ6Wwf53EIc2Wq3E9sVhmFjJraGScFEyjmKv
jWO/p8noYTql6cbJdI+U1tyUtlqdpUywufAGeLzl/l57HkJjD8J4GN9QtponIYx5milBGO7KTnoK
KIGpmhvlvD0uzxauN0qn66Jgm6PqxqPtEt/UzT0gk2hMs61ndyHIkvGYWbobvru/rlwmfCmIL5au
N9FsnlEBjcj1TmGfFXO6W5jkLsQTbeqwH85s+tui6wSugWcWkQy2Ohn2riE6YnXOM9fovndag0kz
upfcrcReXlz57xvqYRi6vCh5+TZNcDOZTUslWk6JMLzyBO6KjLCiBUYXxrun92vF6RwY0w2Yz8mQ
wrbffPnnIV8n1EDQ8pdJL6k80uc/GwM/iWVuZHN0cmVhbQplbmRvYmoKMTczIDAgb2JqCjEwMzcK
ZW5kb2JqCjE3NyAwIG9iago8PC9MZW5ndGggMTc4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K
c3RyZWFtCnicfVVLd9o6EN7zK+awaTjX8cU4z64KxuQkBULALee0dKHYg60iS1SSaemvvyMDt0lI
ai+wpfFovscMP6DtB9B29/43LRv/Ti8hN4025I0fjaDehP1PWkIvoYArCDqQLBu7bwLohHB5eQVJ
2Ti5lRa1RHva12xpYXd1H0YQFUyzlDb5b2a5knBT8QwFl2jgyTViW+i0g4tW8r0RXkMybJzQ6tfp
IOqE7etvAD3NMpQe9HwPIsH0yoO+e9TqZ6rV0npwR699tuG4C+ojnSlzr/WuEYSHhE+uGcXExlLM
LtNAqG3m1ct3LFWPRtHGZ3obcWkKJoQHN77L9iLPhGlKkuV0bETREySs9bdDepuykq00N4VktPKR
VmYFyhXqVxK5k+dapYL9NCu+w8NkRnngS8EICTSnmKqyRJnVVBpQ8jjNQ4UVEp+S5Uihts4RKZmj
qfnvbhTPmEwRuARb4HGGg5ZNqn8QgRPAg+5acwHB9fWVT190Lv6XKJl2x6Tc2be3iE50XbyD97Eq
iIYxPQ1VWjjmY3rusSpT7sXx168eFTf1xnFlDsrEhxskA5BWzXsJSYEQ/+LGooN0v4T7teUlEzCM
+71u8qperKxFIny3cRzDbRQ5753BKfFUlpXk6c6qD2r2ShFTci975ILbbV3QSNV+zmG2LdfK8KoE
r873gqh5PPxCy+dvEjVH8ZtcNvLrtDc+DBjXRaUNmbvpcPZQ4pJbA1aRHmuxr9Mc16iWUBlXU/zL
hXH71AFjZfnygHFxEkfjRavmIhkcZ1qczJVenXJ5OtEq12jMokX47iqJDuT5S5C349lf3TCnbrLI
993QdOYwa6UtdDU5wmJqKzoElkoTCxBvlNgQjr+adFL0nZGNs82IGcPSojJoiadbOovbyiIRcpwi
wbSQSqh8eyxYt7KF0uYddLPMgcYDyWOeKsFMbWUiBzNulV60nsGNxvHMo/TCtStNLrQsl4dGC66A
bVBSj8aZqsjHJCvZZ7+bqEooqh4gDM7a7f3qQLuGfcb0pFAS38M/YQjncEGz+BLCDgThs0LiknHx
HuSuZn9FNX9IafL6S01xf+bsRCPagsOYWeqO7+xtZNykioxOEpYHRs7pX2KURjQGiy30xCbbr4+4
WHPLSJSICU6CSs72W58kKZ3BzDJbE/sH1r7itUbpavmQugN9orEuo12H7aYI0mQT/lM9yevceWes
Nlg+oiaqa10vnsv+dUKTEcK6D+Ok8UD3f71q4XVlbmRzdHJlYW0KZW5kb2JqCjE3OCAwIG9iago5
MzQKZW5kb2JqCjE4MiAwIG9iago8PC9MZW5ndGggMTgzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Pj4Kc3RyZWFtCnichZFBc9owEIXv+hXvVpgS15YdMDklFKaTCQFCnFPSg2LLWI0lJZIgcX99ZXCm
MNOZrg4a7dtdfW/2DWEQIWxPd+eSfFuPsLEkxIa8kWgvortyiUnmC1JEFFlJDj0RaIzRKEUmSe9a
OW4Ud2dTw0qHQ1zd3eJ7xQzLvSh+Mye0wo+tKHgtFLc4ilvWgIbRsJ/9IvEY2Zz0fHbBOJe4qVjB
pcBTjxfCafPU738hUfxZ9KDEjhsrXANdYmlr7eVWmPJXZpzkyrXCtSq1kZ4htwOslpjoD+8vDTHx
MIWH77oWZ2EcDY/nLLR5Z41/0OHnn6tKK36Br8kIlKbnoAnG8QnVTDJRX0C1Dl4uRSmCrdCBamf+
9TdlO1Fgre1J672Q25phzS1nJq8wZ8/aMG+8wdV9x7QKlsHBQpx0qXlj2Qs3A5+i5/9Hj2PQ8RjU
w/tNRv+CL4y2l3ZPcyBPErovudlWagDuwOrgeIuzj1dh/GIXesflMzeI0sF+rTiJxxXbcMTDn37k
LCN3/vwBUrmorWVuZHN0cmVhbQplbmRvYmoKMTgzIDAgb2JqCjM5OQplbmRvYmoKNCAwIG9iago8
PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS
Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOSAwIFIKL0ZvbnQg
MTAgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZS9QYWdl
L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz
PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0IDAgUgovRm9udCAxNSAwIFIKPj4K
L0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94
IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl
dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgovRm9udCAyMCAwIFIKPj4KL0NvbnRlbnRz
IDE3IDAgUgo+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1
IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U
ZXh0XQovRXh0R1N0YXRlIDI0IDAgUgovRm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIyIDAgUgo+
PgplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv
dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0
R1N0YXRlIDI5IDAgUgovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI3IDAgUgo+PgplbmRvYmoK
MzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh
cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM0
IDAgUgovRm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMyIDAgUgo+PgplbmRvYmoKMzYgMCBvYmoK
PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg
UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM5IDAgUgovRm9u
dCA0MCAwIFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+PgplbmRvYmoKNDEgMCBvYmoKPDwvVHlwZS9Q
YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy
Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ0IDAgUgovRm9udCA0NSAwIFIK
Pj4KL0NvbnRlbnRzIDQyIDAgUgo+PgplbmRvYmoKNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh
Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv
Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAgUgovRm9udCA1MCAwIFIKPj4KL0NvbnRl
bnRzIDQ3IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg
NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG
IC9UZXh0XQovRXh0R1N0YXRlIDU0IDAgUgovRm9udCA1NSAwIFIKPj4KL0NvbnRlbnRzIDUyIDAg
Ugo+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K
L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov
RXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv
YmoKNjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw
L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl
IDY0IDAgUgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRzIDYyIDAgUgo+PgplbmRvYmoKNjYgMCBv
YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz
IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY5IDAgUgov
Rm9udCA3MCAwIFIKPj4KL0NvbnRlbnRzIDY3IDAgUgo+PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlw
ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz
b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc0IDAgUgovRm9udCA3NSAw
IFIKPj4KL0NvbnRlbnRzIDcyIDAgUgo+PgplbmRvYmoKNzYgMCBvYmoKPDwvVHlwZS9QYWdlL01l
ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv
UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5IDAgUgovRm9udCA4MCAwIFIKPj4KL0Nv
bnRlbnRzIDc3IDAgUgo+PgplbmRvYmoKODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw
IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv
UERGIC9UZXh0XQovRXh0R1N0YXRlIDg0IDAgUgovRm9udCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgy
IDAgUgo+PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0
Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0
XQovRXh0R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIKPj4KL0NvbnRlbnRzIDg3IDAgUgo+Pgpl
bmRvYmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0
ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0
YXRlIDk0IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRlbnRzIDkyIDAgUgo+PgplbmRvYmoKOTYg
MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu
dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk5IDAg
UgovRm9udCAxMDAgMCBSCj4+Ci9Db250ZW50cyA5NyAwIFIKPj4KZW5kb2JqCjEwMSAwIG9iago8
PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS
Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA0IDAgUgovRm9u
dCAxMDUgMCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSCj4+CmVuZG9iagoxMDYgMCBvYmoKPDwvVHlw
ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz
b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEwOSAwIFIKL0ZvbnQgMTEw
IDAgUgo+PgovQ29udGVudHMgMTA3IDAgUgo+PgplbmRvYmoKMTExIDAgb2JqCjw8L1R5cGUvUGFn
ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl
czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMTQgMCBSCi9Gb250IDExNSAwIFIK
Pj4KL0NvbnRlbnRzIDExMiAwIFIKPj4KZW5kb2JqCjExNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk
aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q
cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE5IDAgUgovRm9udCAxMjAgMCBSCj4+Ci9D
b250ZW50cyAxMTcgMCBSCj4+CmVuZG9iagoxMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94
IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl
dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyNCAwIFIKL0ZvbnQgMTI1IDAgUgo+PgovQ29udGVu
dHMgMTIyIDAgUgo+PgplbmRvYmoKMTI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw
IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE
RiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjkgMCBSCi9Gb250IDEzMCAwIFIKPj4KL0NvbnRlbnRzIDEy
NyAwIFIKPj4KZW5kb2JqCjEzMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg
ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl
eHRdCi9FeHRHU3RhdGUgMTM0IDAgUgovRm9udCAxMzUgMCBSCj4+Ci9Db250ZW50cyAxMzIgMCBS
Cj4+CmVuZG9iagoxMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K
L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov
RXh0R1N0YXRlIDEzOSAwIFIKL0ZvbnQgMTQwIDAgUgo+PgovQ29udGVudHMgMTM3IDAgUgo+Pgpl
bmRvYmoKMTQxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh
dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT
dGF0ZSAxNDQgMCBSCi9Gb250IDE0NSAwIFIKPj4KL0NvbnRlbnRzIDE0MiAwIFIKPj4KZW5kb2Jq
CjE0NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAv
UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg
MTQ5IDAgUgovRm9udCAxNTAgMCBSCj4+Ci9Db250ZW50cyAxNDcgMCBSCj4+CmVuZG9iagoxNTEg
MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu
dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE1NCAw
IFIKL0ZvbnQgMTU1IDAgUgo+PgovQ29udGVudHMgMTUyIDAgUgo+PgplbmRvYmoKMTU2IDAgb2Jq
Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw
IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTkgMCBSCi9G
b250IDE2MCAwIFIKPj4KL0NvbnRlbnRzIDE1NyAwIFIKPj4KZW5kb2JqCjE2MSAwIG9iago8PC9U
eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S
ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTY0IDAgUgovRm9udCAx
NjUgMCBSCj4+Ci9Db250ZW50cyAxNjIgMCBSCj4+CmVuZG9iagoxNjYgMCBvYmoKPDwvVHlwZS9Q
YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy
Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE2OSAwIFIKL0ZvbnQgMTcwIDAg
Ugo+PgovQ29udGVudHMgMTY3IDAgUgo+PgplbmRvYmoKMTcxIDAgb2JqCjw8L1R5cGUvUGFnZS9N
ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8
L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNzQgMCBSCi9Gb250IDE3NSAwIFIKPj4K
L0NvbnRlbnRzIDE3MiAwIFIKPj4KZW5kb2JqCjE3NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC
b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j
U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTc5IDAgUgovRm9udCAxODAgMCBSCj4+Ci9Db250
ZW50cyAxNzcgMCBSCj4+CmVuZG9iagoxODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw
IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv
UERGIC9UZXh0XQovRXh0R1N0YXRlIDE4NCAwIFIKL0ZvbnQgMTg1IDAgUgo+PgovQ29udGVudHMg
MTgyIDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0IDAgUgox
MSAwIFIKMTYgMCBSCjIxIDAgUgoyNiAwIFIKMzEgMCBSCjM2IDAgUgo0MSAwIFIKNDYgMCBSCjUx
IDAgUgo1NiAwIFIKNjEgMCBSCjY2IDAgUgo3MSAwIFIKNzYgMCBSCjgxIDAgUgo4NiAwIFIKOTEg
MCBSCjk2IDAgUgoxMDEgMCBSCjEwNiAwIFIKMTExIDAgUgoxMTYgMCBSCjEyMSAwIFIKMTI2IDAg
UgoxMzEgMCBSCjEzNiAwIFIKMTQxIDAgUgoxNDYgMCBSCjE1MSAwIFIKMTU2IDAgUgoxNjEgMCBS
CjE2NiAwIFIKMTcxIDAgUgoxNzYgMCBSCjE4MSAwIFIKXSAvQ291bnQgMzYKPj4KZW5kb2JqCjEg
MCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDE4NiAwIFIKPj4K
ZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKOSAwIG9iago8
PC9SNwo3IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNCAwIG9i
ago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxOSAw
IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoy
NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i
agoyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozMCAwIG9iago8PC9SOAo4IDAgUj4+CmVu
ZG9iagozNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9SOAo4IDAgUj4+
CmVuZG9iagozOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0MCAwIG9iago8PC9SOAo4IDAg
Uj4+CmVuZG9iago0NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NSAwIG9iago8PC9SOAo4
IDAgUj4+CmVuZG9iago0OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MCAwIG9iago8PC9S
OAo4IDAgUj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1NSAwIG9iago8
PC9SOAo4IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2MCAwIG9i
ago8PC9SOAo4IDAgUj4+CmVuZG9iago2NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2NSAw
IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3
MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i
ago3NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3OSAwIG9iago8PC9SNwo3IDAgUj4+CmVu
ZG9iago4MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4NCAwIG9iago8PC9SNwo3IDAgUj4+
CmVuZG9iago4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4OSAwIG9iago8PC9SNwo3IDAg
Uj4+CmVuZG9iago5MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5NCAwIG9iago8PC9SNwo3
IDAgUj4+CmVuZG9iago5NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5OSAwIG9iago8PC9S
Nwo3IDAgUj4+CmVuZG9iagoxMDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTA0IDAgb2Jq
Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDkg
MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTEwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2Jq
CjExNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMTUgMCBvYmoKPDwvUjgKOCAwIFI+Pgpl
bmRvYmoKMTE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEyMCAwIG9iago8PC9SOAo4IDAg
Uj4+CmVuZG9iagoxMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTI1IDAgb2JqCjw8L1I4
CjggMCBSPj4KZW5kb2JqCjEyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMzAgMCBvYmoK
PDwvUjgKOCAwIFI+PgplbmRvYmoKMTM0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEzNSAw
IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMzkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK
MTQwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0NCAwIG9iago8PC9SNwo3IDAgUj4+CmVu
ZG9iagoxNDUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTQ5IDAgb2JqCjw8L1I3CjcgMCBS
Pj4KZW5kb2JqCjE1MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNTQgMCBvYmoKPDwvUjcK
NyAwIFI+PgplbmRvYmoKMTU1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE1OSAwIG9iago8
PC9SNwo3IDAgUj4+CmVuZG9iagoxNjAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTY0IDAg
b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE2NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagox
NjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTcwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k
b2JqCjE3NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNzUgMCBvYmoKPDwvUjgKOCAwIFI+
PgplbmRvYmoKMTc5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE4MCAwIG9iago8PC9SOAo4
IDAgUj4+CmVuZG9iagoxODQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTg1IDAgb2JqCjw8
L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFzZUZvbnQvQ291cmllci9UeXBlL0ZvbnQK
L1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTg2IDAgb2JqCjw8L1R5cGUvTWV0YWRhdGEKL1N1YnR5
cGUvWE1ML0xlbmd0aCAxMzU0Pj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0w
TXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4K
PHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQg
Mi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cu
dzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRv
YmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo2MmViMDY0
NC01NDM5LTExZjEtMDAwMC01NjZhNjVlZGM4NDknIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2Jl
LmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQgOS4wNicvPgo8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo2MmViMDY0NC01NDM5LTExZjEtMDAwMC01NjZh
NjVlZGM4NDknIHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+PHhtcDpN
b2RpZnlEYXRlPjIwMTYtMDUtMTdUMDM6NDg6MDYtMDc6MDA8L3htcDpNb2RpZnlEYXRlPgo8eG1w
OkNyZWF0ZURhdGU+MjAxNi0wNS0xN1QwMzo0ODowNi0wNzowMDwveG1wOkNyZWF0ZURhdGU+Cjx4
bXA6Q3JlYXRvclRvb2w+R05VIEVuc2NyaXB0IDEuNi41LjkwPC94bXA6Q3JlYXRvclRvb2w+PC9y
ZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjYyZWIwNjQ0
LTU0MzktMTFmMS0wMDAwLTU2NmE2NWVkYzg0OScgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9i
ZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6NjJlYjA2NDQtNTQzOS0x
MWYxLTAwMDAtNTY2YTY1ZWRjODQ5Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlk
OjYyZWIwNjQ0LTU0MzktMTFmMS0wMDAwLTU2NmE2NWVkYzg0OScgeG1sbnM6ZGM9J2h0dHA6Ly9w
dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRj
OnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+RW5zY3JpcHQgT3V0
cHV0PC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRm
OlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFj
a2V0IGVuZD0ndyc/PgplbmRzdHJlYW0KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdo
b3N0c2NyaXB0IDkuMDYpCi9DcmVhdGlvbkRhdGUoRDoyMDE2MDUxNzAzNDgwNi0wNycwMCcpCi9N
b2REYXRlKEQ6MjAxNjA1MTcwMzQ4MDYtMDcnMDAnKQovVGl0bGUoRW5zY3JpcHQgT3V0cHV0KQov
Q3JlYXRvcihHTlUgRW5zY3JpcHQgMS42LjUuOTApPj5lbmRvYmoKeHJlZgowIDE4NwowMDAwMDAw
MDAwIDY1NTM1IGYgCjAwMDAwNTA2MTQgMDAwMDAgbiAKMDAwMDA1NDQwOSAwMDAwMCBuIAowMDAw
MDUwMjkyIDAwMDAwIG4gCjAwMDAwNDQzOTQgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAow
MDAwMDAxMTU4IDAwMDAwIG4gCjAwMDAwNTA2ODAgMDAwMDAgbiAKMDAwMDA1MjkxNSAwMDAwMCBu
IAowMDAwMDUwNzIxIDAwMDAwIG4gCjAwMDAwNTA3NTAgMDAwMDAgbiAKMDAwMDA0NDU1MyAwMDAw
MCBuIAowMDAwMDAxMTc4IDAwMDAwIG4gCjAwMDAwMDIzNjIgMDAwMDAgbiAKMDAwMDA1MDc4MCAw
MDAwMCBuIAowMDAwMDUwODEwIDAwMDAwIG4gCjAwMDAwNDQ3MTUgMDAwMDAgbiAKMDAwMDAwMjM4
MyAwMDAwMCBuIAowMDAwMDAzNjIwIDAwMDAwIG4gCjAwMDAwNTA4NDAgMDAwMDAgbiAKMDAwMDA1
MDg3MCAwMDAwMCBuIAowMDAwMDQ0ODc3IDAwMDAwIG4gCjAwMDAwMDM2NDEgMDAwMDAgbiAKMDAw
MDAwNTIxOCAwMDAwMCBuIAowMDAwMDUwOTAwIDAwMDAwIG4gCjAwMDAwNTA5MzAgMDAwMDAgbiAK
MDAwMDA0NTAzOSAwMDAwMCBuIAowMDAwMDA1MjM5IDAwMDAwIG4gCjAwMDAwMDY1OTkgMDAwMDAg
biAKMDAwMDA1MDk2MCAwMDAwMCBuIAowMDAwMDUwOTkwIDAwMDAwIG4gCjAwMDAwNDUyMDEgMDAw
MDAgbiAKMDAwMDAwNjYyMCAwMDAwMCBuIAowMDAwMDA3ODI0IDAwMDAwIG4gCjAwMDAwNTEwMjAg
MDAwMDAgbiAKMDAwMDA1MTA1MCAwMDAwMCBuIAowMDAwMDQ1MzYzIDAwMDAwIG4gCjAwMDAwMDc4
NDUgMDAwMDAgbiAKMDAwMDAwOTE2MSAwMDAwMCBuIAowMDAwMDUxMDgwIDAwMDAwIG4gCjAwMDAw
NTExMTAgMDAwMDAgbiAKMDAwMDA0NTUyNSAwMDAwMCBuIAowMDAwMDA5MTgyIDAwMDAwIG4gCjAw
MDAwMTAzMDEgMDAwMDAgbiAKMDAwMDA1MTE0MCAwMDAwMCBuIAowMDAwMDUxMTcwIDAwMDAwIG4g
CjAwMDAwNDU2ODcgMDAwMDAgbiAKMDAwMDAxMDMyMiAwMDAwMCBuIAowMDAwMDExNzc2IDAwMDAw
IG4gCjAwMDAwNTEyMDAgMDAwMDAgbiAKMDAwMDA1MTIzMCAwMDAwMCBuIAowMDAwMDQ1ODQ5IDAw
MDAwIG4gCjAwMDAwMTE3OTcgMDAwMDAgbiAKMDAwMDAxMzI3NCAwMDAwMCBuIAowMDAwMDUxMjYw
IDAwMDAwIG4gCjAwMDAwNTEyOTAgMDAwMDAgbiAKMDAwMDA0NjAxMSAwMDAwMCBuIAowMDAwMDEz
Mjk1IDAwMDAwIG4gCjAwMDAwMTQyOTYgMDAwMDAgbiAKMDAwMDA1MTMyMCAwMDAwMCBuIAowMDAw
MDUxMzUwIDAwMDAwIG4gCjAwMDAwNDYxNzMgMDAwMDAgbiAKMDAwMDAxNDMxNiAwMDAwMCBuIAow
MDAwMDE1MTg4IDAwMDAwIG4gCjAwMDAwNTEzODAgMDAwMDAgbiAKMDAwMDA1MTQxMCAwMDAwMCBu
IAowMDAwMDQ2MzM1IDAwMDAwIG4gCjAwMDAwMTUyMDggMDAwMDAgbiAKMDAwMDAxNjQ5MCAwMDAw
MCBuIAowMDAwMDUxNDQwIDAwMDAwIG4gCjAwMDAwNTE0NzAgMDAwMDAgbiAKMDAwMDA0NjQ5NyAw
MDAwMCBuIAowMDAwMDE2NTExIDAwMDAwIG4gCjAwMDAwMTc4NzAgMDAwMDAgbiAKMDAwMDA1MTUw
MCAwMDAwMCBuIAowMDAwMDUxNTMwIDAwMDAwIG4gCjAwMDAwNDY2NTkgMDAwMDAgbiAKMDAwMDAx
Nzg5MSAwMDAwMCBuIAowMDAwMDE5MjExIDAwMDAwIG4gCjAwMDAwNTE1NjAgMDAwMDAgbiAKMDAw
MDA1MTU5MCAwMDAwMCBuIAowMDAwMDQ2ODIxIDAwMDAwIG4gCjAwMDAwMTkyMzIgMDAwMDAgbiAK
MDAwMDAyMDY1MiAwMDAwMCBuIAowMDAwMDUxNjIwIDAwMDAwIG4gCjAwMDAwNTE2NTAgMDAwMDAg
biAKMDAwMDA0Njk4MyAwMDAwMCBuIAowMDAwMDIwNjczIDAwMDAwIG4gCjAwMDAwMjIxMTAgMDAw
MDAgbiAKMDAwMDA1MTY4MCAwMDAwMCBuIAowMDAwMDUxNzEwIDAwMDAwIG4gCjAwMDAwNDcxNDUg
MDAwMDAgbiAKMDAwMDAyMjEzMSAwMDAwMCBuIAowMDAwMDIzMzczIDAwMDAwIG4gCjAwMDAwNTE3
NDAgMDAwMDAgbiAKMDAwMDA1MTc3MCAwMDAwMCBuIAowMDAwMDQ3MzA3IDAwMDAwIG4gCjAwMDAw
MjMzOTQgMDAwMDAgbiAKMDAwMDAyNDY2NyAwMDAwMCBuIAowMDAwMDUxODAwIDAwMDAwIG4gCjAw
MDAwNTE4MzAgMDAwMDAgbiAKMDAwMDA0NzQ3MCAwMDAwMCBuIAowMDAwMDI0Njg4IDAwMDAwIG4g
CjAwMDAwMjYwNzIgMDAwMDAgbiAKMDAwMDA1MTg2MSAwMDAwMCBuIAowMDAwMDUxODkyIDAwMDAw
IG4gCjAwMDAwNDc2MzYgMDAwMDAgbiAKMDAwMDAyNjA5NCAwMDAwMCBuIAowMDAwMDI3MzgxIDAw
MDAwIG4gCjAwMDAwNTE5MjMgMDAwMDAgbiAKMDAwMDA1MTk1NCAwMDAwMCBuIAowMDAwMDQ3ODAy
IDAwMDAwIG4gCjAwMDAwMjc0MDMgMDAwMDAgbiAKMDAwMDAyODUyMiAwMDAwMCBuIAowMDAwMDUx
OTg1IDAwMDAwIG4gCjAwMDAwNTIwMTYgMDAwMDAgbiAKMDAwMDA0Nzk2OCAwMDAwMCBuIAowMDAw
MDI4NTQ0IDAwMDAwIG4gCjAwMDAwMjk3OTggMDAwMDAgbiAKMDAwMDA1MjA0NyAwMDAwMCBuIAow
MDAwMDUyMDc4IDAwMDAwIG4gCjAwMDAwNDgxMzQgMDAwMDAgbiAKMDAwMDAyOTgyMCAwMDAwMCBu
IAowMDAwMDMwOTA4IDAwMDAwIG4gCjAwMDAwNTIxMDkgMDAwMDAgbiAKMDAwMDA1MjE0MCAwMDAw
MCBuIAowMDAwMDQ4MzAwIDAwMDAwIG4gCjAwMDAwMzA5MzAgMDAwMDAgbiAKMDAwMDAzMjAyMCAw
MDAwMCBuIAowMDAwMDUyMTcxIDAwMDAwIG4gCjAwMDAwNTIyMDIgMDAwMDAgbiAKMDAwMDA0ODQ2
NiAwMDAwMCBuIAowMDAwMDMyMDQyIDAwMDAwIG4gCjAwMDAwMzM0OTkgMDAwMDAgbiAKMDAwMDA1
MjIzMyAwMDAwMCBuIAowMDAwMDUyMjY0IDAwMDAwIG4gCjAwMDAwNDg2MzIgMDAwMDAgbiAKMDAw
MDAzMzUyMSAwMDAwMCBuIAowMDAwMDM0NjIyIDAwMDAwIG4gCjAwMDAwNTIyOTUgMDAwMDAgbiAK
MDAwMDA1MjMyNiAwMDAwMCBuIAowMDAwMDQ4Nzk4IDAwMDAwIG4gCjAwMDAwMzQ2NDQgMDAwMDAg
biAKMDAwMDAzNTg0OSAwMDAwMCBuIAowMDAwMDUyMzU3IDAwMDAwIG4gCjAwMDAwNTIzODggMDAw
MDAgbiAKMDAwMDA0ODk2NCAwMDAwMCBuIAowMDAwMDM1ODcxIDAwMDAwIG4gCjAwMDAwMzcyODEg
MDAwMDAgbiAKMDAwMDA1MjQxOSAwMDAwMCBuIAowMDAwMDUyNDUwIDAwMDAwIG4gCjAwMDAwNDkx
MzAgMDAwMDAgbiAKMDAwMDAzNzMwMyAwMDAwMCBuIAowMDAwMDM4MzI2IDAwMDAwIG4gCjAwMDAw
NTI0ODEgMDAwMDAgbiAKMDAwMDA1MjUxMiAwMDAwMCBuIAowMDAwMDQ5Mjk2IDAwMDAwIG4gCjAw
MDAwMzgzNDcgMDAwMDAgbiAKMDAwMDAzOTQzMyAwMDAwMCBuIAowMDAwMDUyNTQzIDAwMDAwIG4g
CjAwMDAwNTI1NzQgMDAwMDAgbiAKMDAwMDA0OTQ2MiAwMDAwMCBuIAowMDAwMDM5NDU1IDAwMDAw
IG4gCjAwMDAwNDA1NjEgMDAwMDAgbiAKMDAwMDA1MjYwNSAwMDAwMCBuIAowMDAwMDUyNjM2IDAw
MDAwIG4gCjAwMDAwNDk2MjggMDAwMDAgbiAKMDAwMDA0MDU4MyAwMDAwMCBuIAowMDAwMDQxNzE2
IDAwMDAwIG4gCjAwMDAwNTI2NjcgMDAwMDAgbiAKMDAwMDA1MjY5OCAwMDAwMCBuIAowMDAwMDQ5
Nzk0IDAwMDAwIG4gCjAwMDAwNDE3MzggMDAwMDAgbiAKMDAwMDA0Mjg0OSAwMDAwMCBuIAowMDAw
MDUyNzI5IDAwMDAwIG4gCjAwMDAwNTI3NjAgMDAwMDAgbiAKMDAwMDA0OTk2MCAwMDAwMCBuIAow
MDAwMDQyODcxIDAwMDAwIG4gCjAwMDAwNDM4NzkgMDAwMDAgbiAKMDAwMDA1Mjc5MSAwMDAwMCBu
IAowMDAwMDUyODIyIDAwMDAwIG4gCjAwMDAwNTAxMjYgMDAwMDAgbiAKMDAwMDA0MzkwMCAwMDAw
MCBuIAowMDAwMDQ0MzczIDAwMDAwIG4gCjAwMDAwNTI4NTMgMDAwMDAgbiAKMDAwMDA1Mjg4NCAw
MDAwMCBuIAowMDAwMDUyOTc3IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTg3IC9Sb290IDEg
MCBSIC9JbmZvIDIgMCBSCi9JRCBbPDA4Rjk1MUZCNjIxQjRFMzZDRDEwQTUwMEUyMDEwOUZDPjww
OEY5NTFGQjYyMUI0RTM2Q0QxMEE1MDBFMjAxMDlGQz5dCj4+CnN0YXJ0eHJlZgo1NDU4OAolJUVP
Rgo=

--_002_F3B0A07CFD358240926B78A680E166FF8DAF35TWMBXP03cnesnetad_--


From nobody Tue May 17 05:08:09 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3385C12D8AC; Tue, 17 May 2016 05:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 H-OBk48gECbn; Tue, 17 May 2016 05:08:04 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 3D5E812D8AB; Tue, 17 May 2016 05:08:04 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4HC80Qs019936 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 May 2016 15:08:00 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4HC80Kq026135; Tue, 17 May 2016 15:08:00 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22331.2463.998319.871791@fireball.acr.fi>
Date: Tue, 17 May 2016 15:07:59 +0300
From: Tero Kivinen 
To: Kuhn Nicolas 
In-Reply-To: 
References: <22304.47475.765923.579337@fireball.acr.fi> 
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 4 min
Archived-At: 
Cc: "draft-ietf-aqm-eval-guidelines.all@tools.ietf.org" , "Mirja Kuehlewind \(IETF\)" , "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 12:08:05 -0000

Kuhn Nicolas writes:
> Thanks a lot for your review. If you believe that your proposed
> changes on the references format should deserve changes in the
> document and a new ID, please let us know, we would try to integrate
> them ASAP.  

Current format makes the document hard to read, especially for those
who do are not very familiar with the area, as it is hard to remember
which rfc is which (7567, 5481, 2679 etc)

My recommendation would be to fix that, but this is my personal
preference on the matter.
-- 
kivinen@iki.fi


From nobody Tue May 17 08:23:52 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9527A12D99F; Tue, 17 May 2016 08:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9cMRWwLhmRz; Tue, 17 May 2016 08:23:45 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AD12D987; Tue, 17 May 2016 08:23:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400";  d="scan'208";a="3495729"
X-IPAS-Result: A2EFAgB0NjtX/wYBeApcHAGDGoFTBrltAQ2BdYYRAoE2OBQBAQEBAQEBA2InhEIBAQEBAgF5BQsCAQUDDRUdBzIUEQIEDgUIiB8IxG8BAQEBAQEBAwEBAQEBASGKcoRBgymCLgWOF4oSjwSBBIRPgx4MhTePQh4BAUKDbTwyAYcGAX4BAQE
From: Kuhn Nicolas 
To: Tero Kivinen 
Thread-Topic: Secdir review of draft-ietf-aqm-eval-guidelines-11
Thread-Index: AQHRoIyZ3aFSg9THzUGEGUMXQuD6up+860sggAAbloCAAFcrgA==
Date: Tue, 17 May 2016 15:23:42 +0000
Message-ID: 
References: <22304.47475.765923.579337@fireball.acr.fi>  <22331.2463.998319.871791@fireball.acr.fi>
In-Reply-To: <22331.2463.998319.871791@fireball.acr.fi>
Accept-Language: en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22328.000
x-tm-as-result: No--37.777500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-aqm-eval-guidelines.all@tools.ietf.org" , "Mirja Kuehlewind \(IETF\)" , "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 15:23:46 -0000

I agree with you: this format does not ease the reading.  This is however h=
ow it is done in, e.g. RFC 7567. This is more readable for someone aware of=
 the activity in the working group (for someone familiar with the mentioned=
 RFCs, seeing [RFC7567] is easier than [5]). It depends who is targeted by =
the draft. I think (hope?) that someone using these guidelines would have r=
ead RFC7567 first. =20

Nico

-----Message d'origine-----
De=A0: Tero Kivinen [mailto:kivinen@iki.fi]=20
Envoy=E9=A0: mardi 17 mai 2016 14:08
=C0=A0: Kuhn Nicolas
Cc=A0: iesg@ietf.org; secdir@ietf.org; draft-ietf-aqm-eval-guidelines.all@t=
ools.ietf.org; Mirja Kuehlewind (IETF)
Objet=A0: RE: Secdir review of draft-ietf-aqm-eval-guidelines-11

Kuhn Nicolas writes:
> Thanks a lot for your review. If you believe that your proposed=20
> changes on the references format should deserve changes in the=20
> document and a new ID, please let us know, we would try to integrate=20
> them ASAP.

> Current format makes the document hard to read, especially for those who =
do are not very familiar with the area, as it is hard to remember which rfc=
 is which (7567, 5481, 2679 etc)

> My recommendation would be to fix that, but this is my personal preferenc=
e on the matter.


--
kivinen@iki.fi


From nobody Wed May 18 16:29:11 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C8812D7C8; Wed, 18 May 2016 16:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXdDIefiXX4g; Wed, 18 May 2016 16:29:05 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512D512D7CD; Wed, 18 May 2016 16:29:05 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id v145so102280679oie.0; Wed, 18 May 2016 16:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=S7+oj1uz/h2bVGS/2barvO7xDC8vHbt+l1TWEDNEmr8=; b=BWZ4RDvYzW5O13s8a52+T8ztdt24Kh3EvP4k49FUCQ/p34WETc0m6r2/eMnAUY9Iuo hENQuHjJSNDPXwVdf80ejzS160UJftl/BiThKRXzPn/AcMZkSRzfmvqjLjeQrMOI/JrV 20vnPuHtdY8jBCFagr46mX321Omz3cLthGaGe8iN0dTswtDLmv27gGYkfHZIX3kxW0nC kEwVRAN1fThcHut0eQWPOfXSbSU+eIVpmXU6ihSWBE0pCAcDn6lKiCRl8/NFWzQptBwF RaoyORcBynx0xHON74THYCHwkc7ydhaFpEUfLcRhH9d4s/4+GtJrJ50yt+YVgOOWLTfe VtxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=S7+oj1uz/h2bVGS/2barvO7xDC8vHbt+l1TWEDNEmr8=; b=mODITezuL8IoVlwQOtBDJqZpLTymxEy30mjDHJ+pU42EidKecaXTGxu/4DSgIjjFMb r4/L/dD2ySVDTrjG8uj7t0KRXMPWCQtnINNSHmyUmWNoEnUELy0ga4G+tZ19BB0Jytjj lC7rVXmtXEW6LKXq4yl8TWV5UDVNzFzkBqDx7Zlof+vqVZgBNmSYN9/Xu9+Mw/6FR7+g gN5EOicJ1YrQuuyNAiDBu4uHqJVNhC/AuXGFJMDc+f3XJGT7rQ9n8BrPIDyRTmQFeQNc SUJc7zRDPreISrkawv4w7Zvuf9m6wLyKHahxfGM/pbt/i1yHj4mFGdJcj6/0Is1EO4fR DqLg==
X-Gm-Message-State: AOPr4FWcKqOH08QJmKYpe6BPuimkBfqlSihGAmpN4m6bzkQFekz3KQDZz+iNEYmHO9/HapbLc9/mPc5nHqU5FA==
MIME-Version: 1.0
X-Received: by 10.157.56.51 with SMTP id i48mr5779659otc.130.1463614144738; Wed, 18 May 2016 16:29:04 -0700 (PDT)
Received: by 10.182.188.7 with HTTP; Wed, 18 May 2016 16:29:04 -0700 (PDT)
Date: Wed, 18 May 2016 19:29:04 -0400
Message-ID: 
From: Radia Perlman 
To: "secdir@ietf.org" , The IESG ,  draft-ietf-dime-e2e-sec-req.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a113dc9be2f7d6d05332639ba
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-dime-e2e-sec-req-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 23:29:06 -0000

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

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is readable, though a pass through for simple grammar would be
helpful.  However, a more important editorial comment is that AVP should be
defined under terminology and not wait until section 3 to expand the
acronym.

-----------

Some things are confusing to me.  For instance,

     Requirement #7:  The solution MUST support symmetric keys and
      asymmetric keys.

         Motivation: Symmetric and asymmetric cryptographic algorithms
         provide different security services.  Asymmetric algorithms,
         for example, allow non-repudiation services to be offered.

I'm not sure what the motivation was for putting this in. Why would
diameter need nonrepudiation?  And if it's using asymmetric, because it
wants nonrepudiation, why would it also need symmetric keys?  Indeed,
usually protocols that use asymmetric keys also use symmetric.  Or is it
saying that preshared secret keys, or Kerberos must be supported even if a
public key scheme is fully deployed? Why would that be?

--------

I found this sentence confusing:

      As an example, consider the Diameter EAP
      application [4] that allows the transport of keying material
      between the Diameter server to the Diameter client (using the EAP-
      Master-Session-Key AVP) for the protection of air interface
      between the end device and the network access server.

What is "air interface"?  Do you mean the wireless link?  Is the "diameter
client" the same as the "end device"?  What is the "network access
server"?  None of these things are in the diagram.

------------
Also,

   {AVP}k refers to an AVP that
   experiences security protection (using key "k") without further
   distinguishing between integrity and confidentiality protection.

I think it's a good idea to have different notation for confidentiality and
integrity, because sometimes things need one, and sometimes they need both.

---------

Radia

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


I have reviewed this document as part of the security=
 directorate's=C2=A0
ongoing effort to review all IETF docume=
nts being processed by the=C2=A0
IESG.=C2=A0 These comments were =
written primarily for the benefit of the=C2=A0
security area dire=
ctors.=C2=A0 Document editors and WG chairs should treat=C2=A0
th=
ese comments just like any other last call comments.

The document is readable, though a pass through for simple grammar would=
 be helpful.=C2=A0 However, a more important editorial comment is that AVP =
should be defined under terminology and not wait until section 3 to expand =
the acronym.

-----------

=
Some things are confusing to me.=C2=A0 For instance, =C2=A0

<=
/div>
=C2=A0 =C2=A0 =C2=A0Requirement #7: =C2=A0The solution MUST suppo=
rt symmetric keys and
=C2=A0 =C2=A0 =C2=A0 asymmetric keys.
=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Motivation: Symmetric=
 and asymmetric cryptographic algorithms
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0provide different security services.=C2=A0 Asymmetric algorithms,=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for example, allow non-repudia=
tion services to be offered.

I'm not sure what=
 the motivation was for putting this in. Why would diameter need nonrepudia=
tion?=C2=A0 And if it's using asymmetric, because it wants nonrepudiati=
on, why would it also need symmetric keys?=C2=A0 Indeed, usually protocols =
that use asymmetric keys also use symmetric.=C2=A0 Or is it saying that pre=
shared secret keys, or Kerberos must be supported even if a public key sche=
me is fully deployed? Why would that be?

--------<=
/div>

I found this sentence confusing:

=C2=A0 =C2=A0 =C2=A0 As an example, consider the Diameter EAP
=

=C2=A0 =C2=A0 =C2=A0 application [4] that allows the transport of keyi=
ng material
=C2=A0 =C2=A0 =C2=A0 between the Diameter server to t=
he Diameter client (using the EAP-
=C2=A0 =C2=A0 =C2=A0 Master-Se=
ssion-Key AVP) for the protection of air interface
=C2=A0 =C2=A0 =
=C2=A0 between the end device and the network access server.

=

What is "air interface"?=C2=A0 Do you mean the wireles=
s link?=C2=A0 Is the "diameter client" the same as the "end =
device"?=C2=A0 What is the "network access server"?=C2=A0 No=
ne of these things are in the diagram.

-----------=
-
Also,=C2=A0

=C2=A0 =C2=A0{AVP}k refers=
 to an AVP that
=C2=A0 =C2=A0experiences security protection (usi=
ng key "k") without further
=C2=A0 =C2=A0distinguishing=
 between integrity and confidentiality protection.

I think it's a good idea to have different notation for confidentialit=
y and integrity, because sometimes things need one, and sometimes they need=
 both.

---------

Radia


--001a113dc9be2f7d6d05332639ba--


From nobody Thu May 19 01:59:50 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A043112D17C; Thu, 19 May 2016 01:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 BmCx_2CBew26; Thu, 19 May 2016 01:59:46 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 4D4D112D14C; Thu, 19 May 2016 01:59:41 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4J8xYaX015063 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 11:59:34 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4J8xYiQ002630; Thu, 19 May 2016 11:59:34 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <22333.32886.374388.282687@fireball.acr.fi>
Date: Thu, 19 May 2016 11:59:34 +0300
From: Tero Kivinen 
To: Kuhn Nicolas 
In-Reply-To: 
References: <22304.47475.765923.579337@fireball.acr.fi>  <22331.2463.998319.871791@fireball.acr.fi> 
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 16 min
X-Total-Time: 15 min
Archived-At: 
Cc: "draft-ietf-aqm-eval-guidelines.all@tools.ietf.org" , "Mirja Kuehlewind  \(IETF\)" , "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] Secdir review of draft-ietf-aqm-eval-guidelines-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2016 08:59:49 -0000

Kuhn Nicolas writes:
> I agree with you: this format does not ease the reading.  This is
> however how it is done in, e.g. RFC 7567. This is more readable for
> someone aware of the activity in the working group (for someone
> familiar with the mentioned RFCs, seeing [RFC7567] is easier than
> [5]).=20

Yes, using "as specified in [RFC7567]" is better than using "as
specified in [5]", but using "as specified in the AQM recommendations
document [RFC7567]" is even better, and provides the RFC number for
those who knows those, but also tells those who just read this
document information what that document is without the need to go and
check the document title.

Also you have several references ot the RFC7567 even in the same
sentence:

   Not all endpoints (or applications) using TCP use the same flavor of=

   TCP.  Variety of senders generate different classes of traffic which=

   may not react to congestion signals (aka non-responsive flows
   [RFC7567]) or may not reduce their sending rate as expected (aka
   Transport Flows that are less responsive than TCP[RFC7567], also
   called "aggressive flows").  In these cases, AQM schemes seek to
   control the queuing delay.

IF those refer to the specific recommendations in the RFC7567 then
pointing the section number or similar would make this text much more
useful than just pointing to the same document multiple times in same
sentence.=20

> It depends who is targeted by the draft.

I have no idea who the intended audience for this draft is. I could
not find that from the draft.

> I think (hope=3F) that someone using these guidelines would have read=

> RFC7567 first.

That hope is completely unjustified. There are always several people
reading RFCs, who have no idea what the referenced document specifies.
Quite often it is someone pointing them out that the RFC xxxx in
section yyy says zzz, do something, and then the person starts reading
that RFC xxxx without any prior knowledge about the subject. He might
end up reading relevant RFCs later, but he has to start from
somewehere. I think it is better if we can make RFCs easier to
understand for persons who just start reading them.

Also architecture, recommendations, and guidelines documents are quite
often so that actual implementors are not that interested reading on
them until they are forced to do so. They are important while we are
writing the actual specifications, as that creates the base work for
making protocol design, but when you are implementing the actual bits
on the wire, implementors usually just go directly to the bits on wire
and try to make them work, ignoring as much of other documents as they
can.

> Nico
>=20
> -----Message d'origine-----
> De=A0: Tero Kivinen [mailto:kivinen@iki.fi]=20
> Envoy=E9=A0: mardi 17 mai 2016 14:08
> =C0=A0: Kuhn Nicolas
> Cc=A0: iesg@ietf.org; secdir@ietf.org; draft-ietf-aqm-eval-guidelines=
.all@tools.ietf.org; Mirja Kuehlewind (IETF)
> Objet=A0: RE: Secdir review of draft-ietf-aqm-eval-guidelines-11
>=20
> Kuhn Nicolas writes:
> > Thanks a lot for your review. If you believe that your proposed=20
> > changes on the references format should deserve changes in the=20
> > document and a new ID, please let us know, we would try to integrat=
e=20
> > them ASAP.
>=20
> > Current format makes the document hard to read, especially for thos=
e who do are not very familiar with the area, as it is hard to remember=
 which rfc is which (7567, 5481, 2679 etc)
>=20
> > My recommendation would be to fix that, but this is my personal pre=
ference on the matter.
>=20
>=20
> --
> kivinen@iki.fi

--=20
kivinen@iki.fi


From nobody Thu May 19 02:07:36 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6612D118 for ; Thu, 19 May 2016 02:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 qyTsgQrKEPJK for ; Thu, 19 May 2016 02:07:34 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 C006512D12E for ; Thu, 19 May 2016 02:07:33 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4J97VjY027235 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 May 2016 12:07:31 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4J97VW6017708; Thu, 19 May 2016 12:07:31 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22333.33363.569210.67437@fireball.acr.fi>
Date: Thu, 19 May 2016 12:07:31 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 1 min
X-Total-Time: 1 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2016 09:07:36 -0000

We seem to be piling up some early reviews (marked as E below). It
would be nice to clear at least some of those out. 

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Tina TSOU is next in the rotation.

For telechat 2016-05-19

Reviewer                 LC end     Draft
Sandy Murphy           T 2016-05-12 draft-ietf-netmod-rfc6020bis-11


For telechat 2016-06-02

Eric Osterweil         T 2016-05-26 draft-hardie-rfc6455-iana-clarification-02
Vincent Roca           T 2016-05-16 draft-ietf-manet-rfc6779bis-05
Rich Salz              T 2016-05-23 draft-ietf-clue-data-model-schema-13
Melinda Shore          T 2016-05-31 draft-ietf-geojson-02
Robert Sparks          T 2016-06-01 draft-ietf-mile-rfc5070-bis-16

Last calls and special requests:

Alan DeKok               2016-04-30 draft-bradner-rfc3979bis-08
Daniel Kahn Gillmor    E 2016-02-01 draft-ietf-rtcweb-security-08
Yaron Sheffer            2016-05-23 draft-ietf-dhc-topo-conf-07
Takeshi Takahashi        2016-05-31 draft-ietf-tsvwg-rfc5405bis-11
Hannes Tschofenig        2015-12-28 draft-ietf-hip-rfc5204-bis-07
Hannes Tschofenig      E None       draft-ietf-ntp-network-time-security-13
Hannes Tschofenig      E None       draft-ietf-ntp-cms-for-nts-message-06
Hannes Tschofenig      E None       draft-ietf-ntp-using-nts-for-ntp-04
Brian Weis             E 2016-02-01 draft-ietf-cdni-uri-signing-07
-- 
kivinen@iki.fi


From nobody Thu May 19 12:02:54 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4912D1EC; Thu, 19 May 2016 12:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 EYEN9HQVmIjy; Thu, 19 May 2016 12:02:51 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E811312DBEE; Thu, 19 May 2016 12:02:33 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DA7DD42374B; Thu, 19 May 2016 19:02:32 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C36844F0B8; Thu, 19 May 2016 19:02:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463684552; bh=9T3k12/RVf9+J3wWBzjtJGYTGlOZAhhgCo2sFc/m5eo=; l=925; h=From:To:Date:From; b=SYpT4zfV8Sn63OAxiZrPxPOrYT9N5B/tzHEer3C/quo4bxyPYT8EkvmeLTgm2TAlO eMoLIqSFMK3RzKEv5yLt8i3d8wqXE4vSGObffbDOBX6scaoXP2qICigPeP5y6onKui OFRaUjzTMH0Ht6f6Yw8UUjJSCvVnhXoOwC6+oCHE=
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BD14D1FC90; Thu, 19 May 2016 19:02:32 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 19 May 2016 12:02:32 -0700
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 19 May 2016 15:02:32 -0400
From: "Salz, Rich" 
To: "draft-ietf-clue-data-model-schema.all@ietf.org" , "'iesg@ietf.org'" , "'secdir@ietf.org'" 
Thread-Topic: draft-ietf-clue-data-model-schema
Thread-Index: AdGx/5ZRRz2IzcDwTGqkTnDMmDGhPQ==
Date: Thu, 19 May 2016 19:02:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.41.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [secdir] draft-ietf-clue-data-model-schema
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2016 19:02:53 -0000

I have reviewed this document as part of the security directorate's  ongoin=
g effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the securit=
y area directors.  Document editors and WG chairs should treat  these comme=
nts just like any other last call comments.

Summary: this document is ready, perhaps with nits.

You might consider reducing the security considerations part, just to incre=
ase emphasis on the fact that while the data described by this schema is po=
tentially very privacy-impacting, it is the *protocol(s)* that need to addr=
ess those issues.    Perhaps adding an intro sentence like that to the Sec =
15 would be useful.

Thanks for the trip down my personal memory line.  Haven't deal with XML Sc=
hema since WS-star days :)

-- =20
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz



From nobody Mon May 23 23:37:31 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8C12DC6B; Mon, 23 May 2016 23:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.345
X-Spam-Level: 
X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eAU0dss7_Dq; Mon, 23 May 2016 23:37:25 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 E6A0012DC6C; Mon, 23 May 2016 23:37:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,359,1459807200";  d="asc'?scan'208,217";a="178778660"
Received: from geve.inrialpes.fr ([194.199.28.1]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 May 2016 08:37:19 +0200
From: Vincent Roca 
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_6D272E8D-8DDC-4B4D-9C18-86D619D32699"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 24 May 2016 08:37:18 +0200
Message-Id: <4673D914-BF52-4C1D-A559-64C1FBBE4FC2@inria.fr>
To: IESG , secdir@ietf.org, draft-ietf-manet-rfc6779bis.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [secdir] Sector review of draft-ietf-manet-rfc6779bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 06:37:28 -0000

--Apple-Mail=_6D272E8D-8DDC-4B4D-9C18-86D619D32699
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3C31295A-893A-434F-AA28-B73AB95DCF9D"


--Apple-Mail=_3C31295A-893A-434F-AA28-B73AB95DCF9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello,

I have reviewed this document as part of the security directorate=E2=80=99=
s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments =
just
like any other last call comments.


Summary: ready

The security considerations section is a carbon copy of that of RFC 6779 =
published in 2012. The only modification is the addition of a reference =
to "Mobile Ad Hoc Network (MANET)".

As explained by the authors, information contained in this MIB is highly =
sensitive, both from the security and privacy point of views. This is =
all the most true when considering some of the target use-cases =
(emergency services or military tactical applications).

If I find this section globally well written. I'm just a bit surprised =
by the following sentence:
	"It is thus important to control even GET and/or NOTIFY access =
to these objects
	 and possibly to even encrypt the values of these objects when =
sending them
	over the network via SNMP."
I would rather say that it is essential to encrypt and verify the =
integrity of all the SNMP traffic. Here I find the style not =
sufficiently directive... But this is a detail.


Cheers,

  Vincent

--Apple-Mail=_3C31295A-893A-434F-AA28-B73AB95DCF9D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello,

I have reviewed this document as part of the =
security directorate=E2=80=99s ongoing
effort to review =
all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the =
security area
directors.  Document editors and WG =
chairs should treat these comments just
like any other =
last call comments.


Summary: ready

The security considerations section is a carbon copy of that =
of RFC 6779 published in 2012. The only modification is the addition of =
a reference to "Mobile Ad Hoc Network (MANET)".

As explained by the authors, =
information contained in this MIB is highly sensitive, both from the =
security and privacy point of views. This is all the most true when =
considering some of the target use-cases (emergency services or military =
tactical applications).

If I find this section globally well written. I'm just a bit =
surprised by the following sentence:
	=
"It is thus important to control even GET and/or NOTIFY access to =
these objects
	 and possibly =
to even encrypt the values of these objects when sending =
them
	over the network via =
SNMP."
I would rather say that it is =
essential to encrypt and verify the integrity of all the SNMP traffic. =
Here I find the style not sufficiently directive... But this is a =
detail.


Cheers,

  =
Vincent
=

--Apple-Mail=_3C31295A-893A-434F-AA28-B73AB95DCF9D--

--Apple-Mail=_6D272E8D-8DDC-4B4D-9C18-86D619D32699
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBCgAGBQJXQ/afAAoJEHBYw8t72N4rIvEP/2Ngf0PnLzu8kDZOLflaNhaw
6x9OEW+ruMngXEH0Di4kcHzfceQYdxp+tR/AUfDRzo0w2BTxXBDFVwy5UYvGbpOP
TEcbloT6iC94Vn5+6mLLN7ElLJK3wEzFsLy0AF2pwYnM8uFMhTq16qgd7xUaShnU
D2y5VL/jsubQ60qOrsXuPJeCAy1lyFT2cjp0nDHCad3yFCfnBAvsRMwYB1g3Pe0H
jIWR9kdYDoxiKygEgQEWrEsx0qzkkNLTL44y7Sww3iPdcLXF9Ui/ABYQ9YNtMgqr
fQGCJqw3+a8GqAr+AC4VS3t5ZBr2YF6GleMH9/lyH0/rNI6YcyaJT9pfTASFz+ER
OVby31ZSELJXTNemuzfirl+IQlGvZrIcXu9dGFzobMy4UaB0JO9O55JPZu1zZ3+5
EdRwB4ysahbTf4X1D9oVL1HyrMEGXuCNmnQsl3t1CG4JGSKsxyIle0SXApmlNJPm
g91dUHjoJDn62/k6QEfkKNtLLhqIcGW2iYfGs/SkfokxjFpRTOKrAZ4riAXGw6It
gmixuA+t+P2FN5aXWFpUmrEsBZcqsT/TJrxI/88pRmf58aDCKJXIo0xzJCJufQ6i
5ETFDQrURzjFt615K30+l9lcenjXDvx4BSv1aJ/+IDGlstnj5IHLRzff6Pip/HOT
wBk0ZMLTfu55qSWTTcTp
=87Qz
-----END PGP SIGNATURE-----

--Apple-Mail=_6D272E8D-8DDC-4B4D-9C18-86D619D32699--


From nobody Tue May 24 01:58:58 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBB12D1EB; Tue, 24 May 2016 01:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.345
X-Spam-Level: 
X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBbtPPvlT_ba; Tue, 24 May 2016 01:58:55 -0700 (PDT)
Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0012D0EB; Tue, 24 May 2016 01:58:54 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.26,359,1459810800"; d="scan'208,217"; a="35884443"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 24 May 2016 09:58:45 +0100
X-IronPort-AV: E=Sophos;i="5.26,359,1459810800";  d="scan'208,217";a="119383083"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 24 May 2016 09:58:46 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Tue, 24 May 2016 09:58:45 +0100
From: "Dearlove, Christopher (UK)" 
To: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-manet-rfc6779bis.all@ietf.org" 
Thread-Topic: Sector review of draft-ietf-manet-rfc6779bis-05
Thread-Index: AQHRtYbBYQK/bSgCMkup8lbFjqMzAZ/HxjTA
Date: Tue, 24 May 2016 08:58:44 +0000
Message-ID: 
References: <4673D914-BF52-4C1D-A559-64C1FBBE4FC2@inria.fr>
In-Reply-To: <4673D914-BF52-4C1D-A559-64C1FBBE4FC2@inria.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [secdir] Sector review of draft-ietf-manet-rfc6779bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 08:58:57 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

VGhlIE1JQiBpbmZvcm1hdGlvbiBjYW4gbGFyZ2VseSwgdGhvdWdoIG5vdCBxdWl0ZSBlbnRpcmVs
eSwgYmUgcmVjb25zdHJ1Y3RlZCBmcm9tIHRoZSByb3V0aW5nIHNpZ25hbGxpbmcuIEFuZCB0aGVy
ZeKAmXMgbm8gcHJvcG9zYWwgb24gdGhlIHRhYmxlIHRoYXQgZW5jcnlwdHMgdGhhdC4gKEZ1dHVy
ZSB3b3JrLCBwZXJoYXBzLikNCg0KQ29uc2VxdWVudGx5IG1hbmRhdGluZyBlbmNyeXB0aW9uIG9m
IE1JQiBkYXRhIHJlYWxseSBkb2VzbuKAmXQgaGVscCBtdWNoLiBJbiBmYWN0IEkgdGhpbmsgdGhh
dCBhbHRob3VnaCB0aGUgTUlCIGluZm9ybWF0aW9uIG1heSBhZGQgYSBsaXR0bGUsIGl0IGlzbuKA
mXQgcmVndWxhciwgYW5kIG9ubHkgc29tZSBvZiBpdCBtaWdodCBiZSByZXF1ZXN0ZWQsIHVubGlr
ZSB0aGUgcm91dGluZyBzaWduYWxsaW5nIHRoYXQgaXMgY29udGludWFsIGFuZCBldmVyeXdoZXJl
LiBTbyBJ4oCZZCBjbGFzc2lmeSBpdCBhcyBzZWNvbmRhcnkgaW4gdmFsdWUgdG8gYW4gYXR0YWNr
ZXIuDQoNClRoYXQgc2FpZCwgZW5jcnlwdGluZyBpdCBpcyBlYXNpZXIsIGJlY2F1c2UgZW5jcnlw
dGluZyByb3V0aW5nIHNpZ25hbGxpbmcgZWl0aGVyIHJlcXVpcmVzIGEgc2hhcmVkIHNlY3JldCBr
ZXkgZXZlcnl3aGVyZSwgd2hpY2ggaXMgd2Vhaywgb3IgcnVucyBpbnRvIHRoZSBjaGlja2VuIGFu
ZCBlZ2cgcHJvYmxlbSBvZiB3aGljaCBjb21lcyBmaXJzdCwgZXN0YWJsaXNoaW5nIHRoZSByb3V0
aW5nIC0gaW4gcGFydGljdWxhciB0aGUgbmVpZ2hib3VyIGRpc2NvdmVyeSAtIG9yIGVzdGFibGlz
aGluZyB0aGUgZW5jcnlwdGlvbiBmb3IgdGhhdCBzaWduYWxsaW5nLiBUaGVyZSBhcmUgc29sdXRp
b25zLCBidXQgYXMgSSBzYWlkLCBub25lIHlldCBwcm9wb3NlZC4gV2hlcmVhcyBmb3IgTUlCIGlu
Zm9ybWF0aW9uIHJvdXRpbmcgaXMgYWxyZWFkeSBpbiBwbGFjZSwgYW5kIGhlbmNlIGNhbiBiZSB1
c2VkLg0KDQpXaGF0IGRvZXMgdGhhdCBtZWFuPyBTcGVha2luZyBqdXN0IGZvciBteXNlbGYsIEkg
dGhpbmsgdGhhdCBtZWFucyB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IG1pZ2h0IGhhdmUgdGhlIGJh
bGFuY2UgaW4gdGhlIHJpZ2h0IHBsYWNlLiBCdXQgSeKAmWxsIGxlYXZlIHRoYXQgZm9yIG90aGVy
cyB0byBkaXNjdXNzL2RlY2lkZS4NCg0KKEluIGZhY3QgZXZlbiBhdXRoZW50aWNhdGluZyB0aGUg
cm91dGluZyBzaWduYWxsaW5nIGlzbuKAmXQgbWFuZGF0ZWQ7IGFsdGhvdWdoIGltcGxlbWVudGlu
ZyBhbiBhcHByb2FjaCAgLSBhIHdlYWsgb25lLCBidXQgdGhlcmUgYXJlIGJldHRlciAtICB0byBp
dCBpcy4gSG93ZXZlciBhbnlvbmUgdXNpbmcgdGhpcyBpbiBhIHNlbnNpdGl2ZSBzY2VuYXJpbyB3
b3VsZCBiZSBpbGwtYWR2aXNlZCBub3QgdG8gdXNlIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz
bSwgaGVuY2UgdGhpcyBqdXN0IGJlaW5nIGFuIGFzaWRlLikNCg0KLS0NCkNocmlzdG9waGVyIERl
YXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDAp
MTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpj
aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl
bGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxt
c2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5i
YWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0
ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJl
ZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZ
UA0KDQpGcm9tOiBWaW5jZW50IFJvY2EgW21haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnJdDQpT
ZW50OiAyNCBNYXkgMjAxNiAwNzozNw0KVG86IElFU0c7IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQt
aWV0Zi1tYW5ldC1yZmM2Nzc5YmlzLmFsbEBpZXRmLm9yZw0KQ2M6IFZpbmNlbnQgUm9jYQ0KU3Vi
amVjdDogU2VjdG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLW1hbmV0LXJmYzY3NzliaXMtMDUNCg0K
SGVsbG8sDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl
Y3VyaXR5IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nDQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG
IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQpjb21tZW50cyB3
ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJl
YQ0KZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh
dCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu
DQoNCg0KU3VtbWFyeTogcmVhZHkNCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rp
b24gaXMgYSBjYXJib24gY29weSBvZiB0aGF0IG9mIFJGQyA2Nzc5IHB1Ymxpc2hlZCBpbiAyMDEy
LiBUaGUgb25seSBtb2RpZmljYXRpb24gaXMgdGhlIGFkZGl0aW9uIG9mIGEgcmVmZXJlbmNlIHRv
ICJNb2JpbGUgQWQgSG9jIE5ldHdvcmsgKE1BTkVUKSIuDQoNCkFzIGV4cGxhaW5lZCBieSB0aGUg
YXV0aG9ycywgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgTUlCIGlzIGhpZ2hseSBzZW5z
aXRpdmUsIGJvdGggZnJvbSB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgcG9pbnQgb2Ygdmlld3Mu
IFRoaXMgaXMgYWxsIHRoZSBtb3N0IHRydWUgd2hlbiBjb25zaWRlcmluZyBzb21lIG9mIHRoZSB0
YXJnZXQgdXNlLWNhc2VzIChlbWVyZ2VuY3kgc2VydmljZXMgb3IgbWlsaXRhcnkgdGFjdGljYWwg
YXBwbGljYXRpb25zKS4NCg0KSWYgSSBmaW5kIHRoaXMgc2VjdGlvbiBnbG9iYWxseSB3ZWxsIHdy
aXR0ZW4uIEknbSBqdXN0IGEgYml0IHN1cnByaXNlZCBieSB0aGUgZm9sbG93aW5nIHNlbnRlbmNl
Og0KICAgICAgICAgICAgIkl0IGlzIHRodXMgaW1wb3J0YW50IHRvIGNvbnRyb2wgZXZlbiBHRVQg
YW5kL29yIE5PVElGWSBhY2Nlc3MgdG8gdGhlc2Ugb2JqZWN0cw0KICAgICAgICAgICAgIGFuZCBw
b3NzaWJseSB0byBldmVuIGVuY3J5cHQgdGhlIHZhbHVlcyBvZiB0aGVzZSBvYmplY3RzIHdoZW4g
c2VuZGluZyB0aGVtDQogICAgICAgICAgICBvdmVyIHRoZSBuZXR3b3JrIHZpYSBTTk1QLiINCkkg
d291bGQgcmF0aGVyIHNheSB0aGF0IGl0IGlzIGVzc2VudGlhbCB0byBlbmNyeXB0IGFuZCB2ZXJp
ZnkgdGhlIGludGVncml0eSBvZiBhbGwgdGhlIFNOTVAgdHJhZmZpYy4gSGVyZSBJIGZpbmQgdGhl
IHN0eWxlIG5vdCBzdWZmaWNpZW50bHkgZGlyZWN0aXZlLi4uIEJ1dCB0aGlzIGlzIGEgZGV0YWls
Lg0KDQoNCkNoZWVycywNCg0KICBWaW5jZW50DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBh
bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50
IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQK
cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo
ZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z
ZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl
cnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioK

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98GLKXM0002VGREEN_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXtt
c28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIE1JQiBpbmZvcm1hdGlvbiBjYW4gbGFy
Z2VseSwgdGhvdWdoIG5vdCBxdWl0ZSBlbnRpcmVseSwgYmUgcmVjb25zdHJ1Y3RlZCBmcm9tIHRo
ZSByb3V0aW5nIHNpZ25hbGxpbmcuIEFuZCB0aGVyZeKAmXMgbm8gcHJvcG9zYWwgb24gdGhlIHRh
YmxlIHRoYXQgZW5jcnlwdHMNCiB0aGF0LiAoRnV0dXJlIHdvcmssIHBlcmhhcHMuKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Q29uc2VxdWVudGx5IG1hbmRhdGluZyBlbmNyeXB0aW9uIG9mIE1JQiBkYXRhIHJlYWxseSBk
b2VzbuKAmXQgaGVscCBtdWNoLiBJbiBmYWN0IEkgdGhpbmsgdGhhdCBhbHRob3VnaCB0aGUgTUlC
IGluZm9ybWF0aW9uIG1heSBhZGQgYSBsaXR0bGUsIGl0IGlzbuKAmXQgcmVndWxhciwNCiBhbmQg
b25seSBzb21lIG9mIGl0IG1pZ2h0IGJlIHJlcXVlc3RlZCwgdW5saWtlIHRoZSByb3V0aW5nIHNp
Z25hbGxpbmcgdGhhdCBpcyBjb250aW51YWwgYW5kIGV2ZXJ5d2hlcmUuIFNvIEnigJlkIGNsYXNz
aWZ5IGl0IGFzIHNlY29uZGFyeSBpbiB2YWx1ZSB0byBhbiBhdHRhY2tlci48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo
YXQgc2FpZCwgZW5jcnlwdGluZyBpdCBpcyBlYXNpZXIsIGJlY2F1c2UgZW5jcnlwdGluZyByb3V0
aW5nIHNpZ25hbGxpbmcgZWl0aGVyIHJlcXVpcmVzIGEgc2hhcmVkIHNlY3JldCBrZXkgZXZlcnl3
aGVyZSwgd2hpY2ggaXMgd2Vhaywgb3IgcnVucyBpbnRvIHRoZSBjaGlja2VuDQogYW5kIGVnZyBw
cm9ibGVtIG9mIHdoaWNoIGNvbWVzIGZpcnN0LCBlc3RhYmxpc2hpbmcgdGhlIHJvdXRpbmcgLSBp
biBwYXJ0aWN1bGFyIHRoZSBuZWlnaGJvdXIgZGlzY292ZXJ5IC0gb3IgZXN0YWJsaXNoaW5nIHRo
ZSBlbmNyeXB0aW9uIGZvciB0aGF0IHNpZ25hbGxpbmcuIFRoZXJlIGFyZSBzb2x1dGlvbnMsIGJ1
dCBhcyBJIHNhaWQsIG5vbmUgeWV0IHByb3Bvc2VkLiBXaGVyZWFzIGZvciBNSUIgaW5mb3JtYXRp
b24gcm91dGluZyBpcyBhbHJlYWR5DQogaW4gcGxhY2UsIGFuZCBoZW5jZSBjYW4gYmUgdXNlZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPldoYXQgZG9lcyB0aGF0IG1lYW4/IFNwZWFraW5nIGp1c3QgZm9yIG15c2VsZiwg
SSB0aGluayB0aGF0IG1lYW5zIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQgbWlnaHQgaGF2ZSB0aGUg
YmFsYW5jZSBpbiB0aGUgcmlnaHQgcGxhY2UuIEJ1dCBJ4oCZbGwgbGVhdmUgdGhhdCBmb3INCiBv
dGhlcnMgdG8gZGlzY3Vzcy9kZWNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oSW4gZmFjdCBldmVuIGF1dGhlbnRp
Y2F0aW5nIHRoZSByb3V0aW5nIHNpZ25hbGxpbmcgaXNu4oCZdCBtYW5kYXRlZDsgYWx0aG91Z2gg
aW1wbGVtZW50aW5nIGFuIGFwcHJvYWNoJm5ic3A7IC0gYSB3ZWFrIG9uZSwgYnV0IHRoZXJlIGFy
ZSBiZXR0ZXIgLSAmbmJzcDt0byBpdCBpcy4gSG93ZXZlcg0KIGFueW9uZSB1c2luZyB0aGlzIGlu
IGEgc2Vuc2l0aXZlIHNjZW5hcmlvIHdvdWxkIGJlIGlsbC1hZHZpc2VkIG5vdCB0byB1c2UgYW4g
YXV0aGVudGljYXRpb24gbWVjaGFuaXNtLCBoZW5jZSB0aGlzIGp1c3QgYmVpbmcgYW4gYXNpZGUu
KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpw
PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdF
N0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxi
cj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwv
c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3
RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6
DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3Bh
biBzdHlsZT0iY29sb3I6Ymx1ZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+
PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+
PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmss
IEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJo
dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+
d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTog
U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZpbmNlbnQgUm9j
YSBbbWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mcl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNCBN
YXkgMjAxNiAwNzozNzxicj4NCjxiPlRvOjwvYj4gSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFm
dC1pZXRmLW1hbmV0LXJmYzY3NzliaXMuYWxsQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBWaW5j
ZW50IFJvY2E8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU2VjdG9yIHJldmlldyBvZiBkcmFmdC1pZXRm
LW1hbmV0LXJmYzY3NzliaXMtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu
dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMgb25nb2luZzxicj4NCmVm
Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg
SUVTRy4gVGhlc2U8YnI+DQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg
YmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYTxicj4NCmRpcmVjdG9ycy4gJm5ic3A7RG9jdW1l
bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0
PGJyPg0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdW1tYXJ5OjxiPiZuYnNwO3JlYWR5PC9i
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyBhIGNhcmJvbiBjb3B5IG9mIHRo
YXQgb2YgUkZDIDY3NzkgcHVibGlzaGVkIGluIDIwMTIuIFRoZSBvbmx5IG1vZGlmaWNhdGlvbiBp
cyB0aGUgYWRkaXRpb24gb2YgYSByZWZlcmVuY2UgdG8gJnF1b3Q7TW9iaWxlIEFkIEhvYyBOZXR3
b3JrIChNQU5FVCkmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFzIGV4cGxhaW5lZCBieSB0aGUgYXV0aG9ycywgaW5mb3JtYXRpb24g
Y29udGFpbmVkIGluIHRoaXMgTUlCIGlzIGhpZ2hseSBzZW5zaXRpdmUsIGJvdGggZnJvbSB0aGUg
c2VjdXJpdHkgYW5kIHByaXZhY3kgcG9pbnQgb2Ygdmlld3MuIFRoaXMgaXMgYWxsIHRoZSBtb3N0
IHRydWUgd2hlbiBjb25zaWRlcmluZyBzb21lIG9mIHRoZSB0YXJnZXQgdXNlLWNhc2VzIChlbWVy
Z2VuY3kgc2VydmljZXMgb3IgbWlsaXRhcnkNCiB0YWN0aWNhbCBhcHBsaWNhdGlvbnMpLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBJIGZp
bmQgdGhpcyBzZWN0aW9uIGdsb2JhbGx5IHdlbGwgd3JpdHRlbi4gSSdtIGp1c3QgYSBiaXQgc3Vy
cHJpc2VkIGJ5IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRh
Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZxdW90O0l0IGlzIHRodXMgaW1wb3J0YW50IHRvIGNv
bnRyb2wgZXZlbiBHRVQgYW5kL29yIE5PVElGWSBhY2Nlc3MgdG8gdGhlc2Ugb2JqZWN0czxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh
c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZuYnNwOzxiPmFuZCBwb3NzaWJs
eSB0byBldmVuIGVuY3J5cHQgdGhlIHZhbHVlcyBvZiB0aGVzZSBvYmplY3RzPC9iPiB3aGVuIHNl
bmRpbmcgdGhlbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm92ZXIg
dGhlIG5ldHdvcmsgdmlhIFNOTVAuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcmF0aGVyIHNheSB0aGF0IGl0
IGlzIGVzc2VudGlhbCB0byBlbmNyeXB0IGFuZCB2ZXJpZnkgdGhlIGludGVncml0eSBvZiBhbGwg
dGhlIFNOTVAgdHJhZmZpYy4gSGVyZSBJIGZpbmQgdGhlIHN0eWxlIG5vdCBzdWZmaWNpZW50bHkg
ZGlyZWN0aXZlLi4uIEJ1dCB0aGlzIGlzIGEgZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBWaW5j
ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8g
dGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQg
ZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5v
dCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpk
aXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98GLKXM0002VGREEN_--


From nobody Wed May 25 23:16:46 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425C12D675; Wed, 25 May 2016 23:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7HUiXfFPE5P; Wed, 25 May 2016 23:16:39 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE6B12D67C; Wed, 25 May 2016 23:16:04 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id y69so27579380pfb.1; Wed, 25 May 2016 23:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=RD9U8t/2L/vRslfvo/rfoljIw5VAZYePv/Ds4lWf62U=; b=WNnqZEUVqjdhbzb3Q0Yxjikycz1fqiC5tH0J42CDWlQ4ryZ6vwmaMTdkHzYeIz2rY9 GJ1plCClFrptZSZNJBG+FhhnLsRGYCJMi+62TiA0oyPfU1ZRxGdmQsOrEHrMpa+aUlw5 iGSG9/yqvrjh54slRW9HZgSqruSUyMkammBsLIhrtgtaSPUUHvqd65W2yYXI7423VGcu nQwp0OVfdjxs25gas4rtB8r+onNvGg5vj15PuzYokRhEqE6+pkL3y2YnXmdYdM5WgoDP ks2utymIt4bPW5o8vPuvv4DQUWfXrdBBhcz0A6BUrFyARdftmt/3wiEBwv5iFbmunMjU AfYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=RD9U8t/2L/vRslfvo/rfoljIw5VAZYePv/Ds4lWf62U=; b=Bzp7MkQEJvQw/D2wyc49N8Xu0wPvzMDe5TgUBnC8CmbdEweZHAHML+smvPLBkir4q+ bBOzTJP/XzkCFIyFztSfwcjrwC2juvJfRGbF2dWresisVeGspEMJP37UvCQzO3ETVg2p 66H+g906qqu0aZYo8fPNcSCeWZk1ZjvA9TB54aAmUYbMr51BE+m+I1pKQSiJYsrc3Qf5 NkqXrCAi3JQDkeLW6fb6zlIokbmMt9eMKPXK6ei4bRADgy0en4cfEfE7rmtMy0hWaBD1 kan33x0z/B9Zn11P5sPiX4/ArEuzS+Rn8VudSM3JGPBVVpupYbJ36nykVPKc5KPd0grY vFSA==
X-Gm-Message-State: ALyK8tKDis5ACfMqxH0SqczFMlPdjjFUyLyLrtrArGjw83cWRqvuAnCst/+RZbFnFPmE6Q==
X-Received: by 10.98.8.69 with SMTP id c66mr11472333pfd.47.1464243364159; Wed, 25 May 2016 23:16:04 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (69-161-3-30-radius.dynamic.acsalaska.net. [69.161.3.30]) by smtp.googlemail.com with ESMTPSA id uw2sm17153789pac.10.2016.05.25.23.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 23:16:03 -0700 (PDT)
From: Melinda Shore 
To: draft-ietf-geojson.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Message-ID: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>
Date: Wed, 25 May 2016 22:15:07 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-geojson-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 06:16:41 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

(note: I was assigned the -02 revision of the document, but the -03
version was just issued and I am reviewing that).

Summary: this document is ready, with minor issues

This document describes a JSON format for representing geospatial
data.  It recommends a single coordinate reference system and does
not appear to be readily extensible to other coordinate reference
systems, but I'll assume that this has been addressed and resolved
by the responsible AD, etc. if it's actually a problem.

The security considerations section is brief and refers the reader
to the core JSON specification.  The second paragraph of the
security considerations sections may have minor issues in that it
says "if sensitive data requires privacy or integrity protection the
service must be provided externally."  It may be appropriate, and
provide additional clarity, to distinguish between protection of
data in flight and data at rest (the IETF does not typically deal
with protection of the latter).  It may be sufficient to make the
word "externally" go away and replace it with something more specific -
for example,
     "if sensitive data require privacy or integrity protection
     those must be provided by the transport, for example TLS or
     HTTPS."

Otherwise, looks ready.

Melinda


From nobody Thu May 26 03:21:18 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8259D12DA02 for ; Thu, 26 May 2016 03:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 MVOSeW0-BOyI for ; Thu, 26 May 2016 03:21:07 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 AB66412D129 for ; Thu, 26 May 2016 03:20:51 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4QAKihB027738 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 May 2016 13:20:44 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4QAKi6w020180; Thu, 26 May 2016 13:20:44 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22342.52732.294640.967983@fireball.acr.fi>
Date: Thu, 26 May 2016 13:20:44 +0300
From: Tero Kivinen 
To: secdir@ietf.org
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 10:21:10 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Brian Weis is next in the rotation.

For telechat 2016-06-02

Reviewer                 LC end     Draft
Eric Osterweil         T 2016-05-26 draft-hardie-rfc6455-iana-clarification-02
Robert Sparks          T 2016-06-01 draft-ietf-mile-rfc5070-bis-16


For telechat 2016-06-16

Tina TSOU              T 2016-06-08 draft-ietf-ccamp-additional-signal-type-g709v3-03
Sean Turner            T 2016-06-03 draft-ietf-dmarc-interoperability-14
Carl Wallace           T 2016-06-22 draft-ietf-forces-interfelfb-02
David Waltermire       T 2016-06-07 draft-ietf-idr-ix-bgp-route-server-09

Last calls and special requests:

Alan DeKok               2016-04-30 draft-bradner-rfc3979bis-08
Daniel Kahn Gillmor    E 2016-02-01 draft-ietf-rtcweb-security-08
Matthew Miller          R2016-06-01 draft-ietf-avtext-splicing-notification-06
Yaron Sheffer            2016-05-23 draft-ietf-dhc-topo-conf-07
Takeshi Takahashi        2016-05-31 draft-ietf-tsvwg-rfc5405bis-11
Hannes Tschofenig        2015-12-28 draft-ietf-hip-rfc5204-bis-07
Hannes Tschofenig      E None       draft-ietf-ntp-network-time-security-13
Hannes Tschofenig      E None       draft-ietf-ntp-cms-for-nts-message-06
Hannes Tschofenig      E None       draft-ietf-ntp-using-nts-for-ntp-04
Brian Weis             E 2016-02-01 draft-ietf-cdni-uri-signing-07
-- 
kivinen@iki.fi


From nobody Thu May 26 08:11:54 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CAC12D6F5; Thu, 26 May 2016 08:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 VJ15dc9lM2SV; Thu, 26 May 2016 08:11:51 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEF212D6C6; Thu, 26 May 2016 08:11:51 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id ct2so4704574igb.0; Thu, 26 May 2016 08:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TPJlasU6gOM/X/8jJqj/LG4zSRcPcFyDp9XMY/XqZ58=; b=Rb19EkdRTpgdPDFCpQ1zi/6InIu/9Lc0KsIuQJn/MQDaOlyFAZyawUR+5Exb4ctBek iyOcA2ei8yY1tXfcSV+bCkZnSxOnjUwlBcshY2K0NP3t1HVyXNexG67Xm/oBFkg56aKC 9OWzhwMGzGrImg7Ge71JU27kA2yzoO2rZwNL/8P2RhsLVHllkETIiPz4v3vpEjRPLJDK QZ4hoQG4YV28eLOD06NqIYHKOtglymPR7c7JBHNFnI/PkrbzWWRMh9hRrQ9rc3WvmHmY 9aJsb4xQIJuMnaWA2f1SRRoJ8jfbP65dpizccywK803E2/71iyO1Eh5lT+a7n573Semd xeuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TPJlasU6gOM/X/8jJqj/LG4zSRcPcFyDp9XMY/XqZ58=; b=OxEezS7MxwmqM+az4srvP5QRLBZfW0ETDATtH2DvHRp5B5u4FUZkUoowxQ7eKLx9OQ f0JbVTtWpVJCYVFBE+YYoaybxe5iR35ja9VPFOQuKc1oR4Mr8ArZwpuIDun18cF9DJ7c +JzmM4fSs9HdKdHLFQFlJgUGh7875Ox8NmaMqAR+AlpeQ7311wMw/9GSrWZsR+hte3ju 77rWbhAJVhuQq3GWsmfC1Pn31JV126TmC2mvUNYJckM+gmHKb5R9SMg/EdKWR7nktKcd hB9sz1OPvxMKUReyZSyOVt21Q3SqSPE0kIGwK+GlC4tcXPRk4yoz/BLgB0QI9xI7GIst UrRw==
X-Gm-Message-State: ALyK8tJYoLHD0rUuRNeowyEYKEkvsPfBKNB6OTO8hN1jZAv3JdMa+4C7/858/6TIR/9tiIfvOTNcBFHadFHPUg==
MIME-Version: 1.0
X-Received: by 10.50.20.40 with SMTP id k8mr3791225ige.9.1464275510245; Thu, 26 May 2016 08:11:50 -0700 (PDT)
Received: by 10.64.252.197 with HTTP; Thu, 26 May 2016 08:11:49 -0700 (PDT)
In-Reply-To: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>
References: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>
Date: Thu, 26 May 2016 09:11:49 -0600
Message-ID: 
From: Tim Schaub 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-geojson.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-geojson-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 15:11:53 -0000

Thanks for the feedback Melinda.  I put together a pull request with
your proposed changes:
https://github.com/geojson/draft-geojson/pull/205

Tim


On Thu, May 26, 2016 at 12:15 AM, Melinda Shore  wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> (note: I was assigned the -02 revision of the document, but the -03
> version was just issued and I am reviewing that).
>
> Summary: this document is ready, with minor issues
>
> This document describes a JSON format for representing geospatial
> data.  It recommends a single coordinate reference system and does
> not appear to be readily extensible to other coordinate reference
> systems, but I'll assume that this has been addressed and resolved
> by the responsible AD, etc. if it's actually a problem.
>
> The security considerations section is brief and refers the reader
> to the core JSON specification.  The second paragraph of the
> security considerations sections may have minor issues in that it
> says "if sensitive data requires privacy or integrity protection the
> service must be provided externally."  It may be appropriate, and
> provide additional clarity, to distinguish between protection of
> data in flight and data at rest (the IETF does not typically deal
> with protection of the latter).  It may be sufficient to make the
> word "externally" go away and replace it with something more specific -
> for example,
>     "if sensitive data require privacy or integrity protection
>     those must be provided by the transport, for example TLS or
>     HTTPS."
>
> Otherwise, looks ready.
>
> Melinda


From nobody Thu May 26 11:06:56 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E508C12D80E; Thu, 26 May 2016 11:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnrT25uB9j53; Thu, 26 May 2016 11:06:53 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AB512D0DD; Thu, 26 May 2016 11:06:53 -0700 (PDT)
Received: by mail-pa0-x22e.google.com with SMTP id fy7so15342202pac.2; Thu, 26 May 2016 11:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MSooQ351IEo2VlePEzBzBz4iKaTssO7BZB5DUuddhiE=; b=iZiYH9p+eArobTplKVIoUM9hBe5i7W7muhzIHKdQnjuPnDVqZemtC39PkNpigOnBOa mTAd4bH8NtcqP40Xsy0WZuSggcQ7/AYAHmUbyTBdiT8hT3OCdFB/V9Vfgo2D6Ksy+Hbm +5OMumT8T2UZxaYpsbg8hMnsUIEYT5gFHRk37ihefY8zrJrL3Mq7RirEKhJeikYoGxGW 07rf1K3zUnEgatWl0zfwOaMyc2kM7MOsbaJjcfiqTp14LM60idnAxv8MfIqO64DXME+G bSk4m6b0FEriGbwbwojpTEuH8+gpYQZoJaqx5rWny2nXPd/9XI07bKvynqT62YbR6T60 3GSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MSooQ351IEo2VlePEzBzBz4iKaTssO7BZB5DUuddhiE=; b=iMItCh6jUx0S7IIFmOqsauE2uvXVj5A9A2Ov3l11YZwvUAF2kbc2gEbtyaO6nCjlzP qEuHSxf1TpD6WLwu9Pq4TCoBBhfilzZVNEyVKnyFKOVPiOSYq9auaT7PJ/Jfq+4hIqAe FPMJurFkHiXKfC48Cugmu3xyBV5TYEqb3cdHgzVIBIEMvB4ycW6DW0n4FuVH+X+ylKIk an1cpjvIKLrjxOH/N+k8FpsKZ7Pf/r7Sr40QobTArfH0FKptQu2TbXsuDgJ2Sopsv2ka qruFUY9Gqf6vOMrw1OgGthFa1X73Hp8C1ba1gwaDbKPDuh6AvcGu9tdW4WeQdQO85OtR DODw==
X-Gm-Message-State: ALyK8tJkZzoBgGCW37tLmewBLK+BV+H2cntvIQn8s9yZwHsFfOi53fXE8+XDUUwTIkiAUA==
X-Received: by 10.66.132.37 with SMTP id or5mr16108123pab.144.1464286012897; Thu, 26 May 2016 11:06:52 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-210-20-radius.dynamic.acsalaska.net. [209.112.210.20]) by smtp.googlemail.com with ESMTPSA id 205sm7662401pfy.32.2016.05.26.11.06.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 11:06:51 -0700 (PDT)
To: Tim Schaub 
References: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com> 
From: Melinda Shore 
Message-ID: 
Date: Thu, 26 May 2016 10:05:45 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-geojson.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-geojson-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 18:06:55 -0000

On 5/26/16 7:11 AM, Tim Schaub wrote:
> Thanks for the feedback Melinda.  I put together a pull request with
> your proposed changes:
> https://github.com/geojson/draft-geojson/pull/205

Cool, thanks.  If text regarding data at rest is wanted
it may be sufficient to say something along the lines of
"There will be cases in which stored data need protection,
which is out of scope for this document."

Melinda



From nobody Fri May 27 00:05:11 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91C12D5D1; Fri, 27 May 2016 00:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6GGIiA4gFHM; Fri, 27 May 2016 00:05:04 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C1612D519; Fri, 27 May 2016 00:05:03 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id x7so73703090qkd.3; Fri, 27 May 2016 00:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=C3EZ1FMXoRbcNAuw6sFswlfEt2LeuskTwmADryK3fmM=; b=UIth/duNqzuqlIjAUggnU458/QVMZvaZn7uWoXWgMe0XH4j3c+Nqk3i2zxFHnUADOo d8ox1RL7IcxTvvXgUIfHJolKj3Lwe/e6lx8+qvInIo9TO1jg57cqYiIAsZUVJntL9NIS k/9vErP8lm6yyiKG0SSUrU2v633pEecHd6X8DvPeHzV/DYQZz9zZ4kU+xcVOj9a49NoX lANYsqT2670+4V8TDWyKgbz9wowD29Z7VHLadYpWltjA+jtPumPUvo+fWR+U4LTMLNSF Yu9q5Jphy/0r9gRI11hTjZArN8ECFkVK/JQgf8mGwdnFAJZve23jBxZ/VWyfuC9tZjeI rPQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=C3EZ1FMXoRbcNAuw6sFswlfEt2LeuskTwmADryK3fmM=; b=gNvJ7y+EEMZ2nKlKW5RzB+VewJDigAujIoYrYwPggWMv8CnmMZVDhGObFTSfDDuqv2 Mk+o3IJvTA6BXg1V6AcG3tTVvoiUDGFQIUwkE0Dutdo56pgoTktQtDha8uzW2ryvF8m6 IoqHBLt9i0/L9hvWagudYqkJVsbfNNpEA907h6MTHr/5t45T20OMBc2b0aEfSuKnt0cn vAhW4MGrqllOiJsOCStIBjqrWw9Yd/SEymAJZzprWrwkOWir4NaDDuZTt8hWz5v2fu7t mXkcwLHqrXbQO3pMqaFqyDqXk3vOIFNtPxbU+bCqJ/fum7Lal+JxMdXerPb7F8xeHScH fq0g==
X-Gm-Message-State: ALyK8tKbKPS44aYx3nXw2tHKWAJvzFUmAjVZQAWU+BpJA5k0ctjhCH9BvWATnHjgfwRtAKCM8LXxpU3shzAVCA==
MIME-Version: 1.0
X-Received: by 10.237.42.194 with SMTP id t60mr4321993qtd.40.1464332703045; Fri, 27 May 2016 00:05:03 -0700 (PDT)
Received: by 10.140.104.70 with HTTP; Fri, 27 May 2016 00:05:02 -0700 (PDT)
In-Reply-To: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>
References: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>
Date: Fri, 27 May 2016 17:05:02 +1000
Message-ID: 
From: Martin Thomson 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-geojson.all@ietf.org, The IESG , "secdir@ietf.org" 
Subject: Re: [secdir] secdir review of draft-ietf-geojson-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 07:05:06 -0000

On 26 May 2016 at 16:15, Melinda Shore  wrote:
> This document describes a JSON format for representing geospatial
> data.  It recommends a single coordinate reference system and does
> not appear to be readily extensible to other coordinate reference
> systems, but I'll assume that this has been addressed and resolved
> by the responsible AD, etc. if it's actually a problem.

This was discussed - extensively - by the working group.  The lack of
specific extensions for CRS is a deliberate decision.


From nobody Fri May 27 12:26:17 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6C12D7B6; Fri, 27 May 2016 12:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level: 
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkVJERlpAN1B; Fri, 27 May 2016 12:26:14 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E406812D123; Fri, 27 May 2016 12:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18011; q=dns/txt; s=iport; t=1464377174; x=1465586774; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=txYJZTMPpT5Q9dmvFF6l4HgvN7FFLACLzLa1LALMv1M=; b=nDawyZ3vaMMVaCnv5lrhSPib3XutK7wc3DBRirYUJrZu/YfixXqsEhAs Y1pivTORUrnbf984GpYt4t6FKeihy3KGGVRXMQ/qXtxYIFjPIPwAzrStd 3UOEwF9m9rG+HP1ngj3cPRrM3Hwroi8ZXoeUhdAQ9T0tWrgYIwFLJbLEU I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBgCknkhX/4cNJK1bgmxNgVMGtHqHA?= =?us-ascii?q?IYRAoE2OxEBAQEBAQEBZSeEQwEBAQSBCQIBCBEDAQIoBzIUCQgCBAESG4gTAcN?= =?us-ascii?q?tAQEBAQYBAQEBAQEBIIYng0mBA4RfhToFhXaNQYUAAYtkgjuBaY0zhjOJGAE2L?= =?us-ascii?q?INtbokJAX4BAQE?=
X-IronPort-AV: E=Sophos;i="5.26,375,1459814400";  d="scan'208,217";a="109127380"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2016 19:26:12 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4RJQCYk015756 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2016 19:26:12 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 27 May 2016 14:26:12 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Fri, 27 May 2016 14:26:11 -0500
From: "Rong Pan (ropan)" 
To: Warren Kumari , IETF Security Directorate , "draft-ietf-aqm-pie.all@ietf.org" , The IESG 
Thread-Topic: SecDir review of draft-ietf-aqm-pie
Thread-Index: AQHRpJAqD1rMJ9aCcEa7X80zJps755/NMJUA
Date: Fri, 27 May 2016 19:26:11 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [171.71.130.224]
Content-Type: multipart/alternative; boundary="_000_D36DED3E189FEropanciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [secdir] SecDir review of draft-ietf-aqm-pie
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 19:26:16 -0000

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

Thanks for the suggestions. I have included them accordingly.

Best,

Rong

From: Warren Kumari >
Date: Monday, May 2, 2016 at 9:31 AM
To: IETF Security Directorate >, "d=
raft-ietf-aqm-pie.all@ietf.org" >, The=
 IESG >
Subject: SecDir review of draft-ietf-aqm-pie


Be ye not afraid...

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Version reviewed: draft-ietf-aqm-pie-06 - PIE: A Lightweight Control Scheme=
 To Address the
Bufferbloat Problem

Summary:
LGTM, Security AD attention not required.

Details:
No major issues, some nits. Feel free to integrate or ignore.

Notes:
>5 authors. Many of the authors are experienced, so they probably already k=
now the RFC Ed might make sad face at you.

Comments in [O]riginal, [P]roposed, [R]eason.


Abstract

Bufferbloat is a phenomenon where excess buffers in the network cause
[O] phenomenon where excess
[P] phenomenon in which excess
[R] grammar
high latency and jitter. As more and more interactive applications

[SNIP]

There is a pressing need to design
intelligent queue management schemes that can control latency and
jitter; and hence provide desirable quality of service to users.
[O] jitter; and hence
[P] jitter, and hence
[R] grammar

[SNIP]
The design does not
require per-packet timestamp, so it incurs very small overhead and is
[O] require per-packet timestamp,
[P] require per-packet timestamps,
[R] grammar
[O] incurs very small overhead
[P] incurs very little overhead
[R] word choice



1. Introduction

The explosion of smart phones, tablets and video traffic in the
Internet brings about a unique set of challenges for congestion
control. To avoid packet drops, many service providers or data center
operators require vendors to put in as much buffer as possible. With
rapid decrease in memory chip prices, these requests are easily
[O] With rapid decrease in memory chip price,
[P] Because of the rapid decrease in memory chip prices,
accommodated to keep customers happy. While this solution succeeds in
assuring low packet loss and high TCP throughput, it suffers from a
major downside. The TCP protocol continuously increases its sending
rate and causes network buffers to fill up. TCP cuts its rate only
when it receives a packet drop or mark that is interpreted as a
congestion signal. However, drops and marks usually occur when
network buffers are full or almost full. As a result, excess buffers,
initially designed to avoid packet drops, would lead to highly
elevated queueing latency and jitter. It is a delicate balancing act
to design a queue management scheme that not only allows short-term
burst to smoothly pass, but also controls the average latency in the
presence of long-running greedy flows.
[O] It is a delicate balancing act to design a queue management scheme that=
 not only allows short-term burst to smoothly pass, but also controls the a=
verage latency in the presence of long-running greedy flows.
[P] Designing a queue management scheme that allows short-term bursts to pa=
ss smoothly as well as controlling the average latency in the presence of l=
ong-running greedy flows is a delicate balancing act.
[R] readability

[SNIP]

New algorithms are beginning to emerge to control queueing latency
directly to address the bufferbloat problem [CoDel]. Along these
lines, PIE also aims to keep the benefits of RED: such as easy
[O] the benefits of RED: such as easy
[P] the benefits of RED, including easy
[R] readability and grammar
implementation and scalability to high speeds. Similar to RED, PIE
randomly drops an incoming packet at the onset of the congestion. The
congestion detection, however, is based on the queueing latency
instead of the queue length like RED.

[SNIP]

In October 2013, CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1]
mandated that cable modems implement a specific variant of the PIE
design as the active queue management algorithm. In addition to cable
specific improvements, the PIE design in DOCSIS 3.1 [DOCSIS-PIE] has
improved the original design in several areas, including de-
randomization of coin tosses and enhanced burst protection.

This draft separates the PIE design into the basic elements that are
MUST to be implemented and optional SHOULD/MAY enhancement elements.
[O] that are MUST to be implemented
[R] This is awkward, but maybe should be left as is? Or delete "are"?



4. The Basic PIE Scheme

As illustrated in Fig. 1, PIE conceptually comprises three simple MUST
[O] PIE conceptually comprises three simple
[P] PIE is comprised of three simple
[R] I think this is what is meant -- PIE is made of three MUST components, =
not PIE makes those three components?

components: a) random dropping at enqueueing; b) periodic drop
probability update; c) latency calculation.

[SNIP]


5.2 Departure Rate Estimation

One way to calculate latency is to obtain the departure rate. The
draining rate of a queue in the network often varies either because
other queues are sharing the same link, or the link capacity fluctuates.
[O] because other queues are sharing the same link, or the link capacity fl=
uctuates.
[P] because other queues are sharing the link or because the link capacity =
fluctuates.
[R] clarity



9. Security Considerations

This document describes an active queue management algorithm based
on implementations in Cisco products. This algorithm introduces no
specific security exposures.


10. IANA Considerations

There are no actions for IANA.


-- END --


--_000_D36DED3E189FEropanciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <3EEC91F7E200BF4AA00F6380D941538C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Thanks for the suggestions. I have included them accordingly.







Best,







Rong









From: Warren Kumari <warren@kumari.net>

Date: Monday, May 2, 2016 at 9:31 A=
M

To: IETF Security Directorate <<=
a href=3D"mailto:secdir@ietf.org">secdir@ietf.org>, "draft-ietf-aqm-pie.all@ietf.org" <draft-ietf-a=
qm-pie.all@ietf.org>,
 The IESG <iesg@ietf.org>

Subject: SecDir review of draft-iet=
f-aqm-pie




















Be ye not afra=
id...






I have reviewed thi=
s document as part of the security directorate's

ongoing effort to review=
 all IETF documents being processed by the

IESG.  These commen=
ts were written primarily for the benefit of the

security area directors.=
  Document editors and WG chairs should treat

these comments just like=
 any other last call comments.









Version reviewed:&n=
bsp;draft-ietf-aqm-pie-06 - =
;PIE: A Lightweight
 Control Scheme To Address the


Bufferbloat Problem




Summary:

LGTM, Security AD attent=
ion not required.=










Details:

No major issues, so=
me nits. Feel free to integrate or ignore.







Notes: =



>5 authors. Many of the authors are ex=
perienced, so they probably already know the RFC Ed might make sad face at =
you.







Comments in [O]riginal, [P]roposed, [R]eason.












Abstract







Bufferbloat is a phenomenon where excess buffers in the network cause<=
/div>

[O] phenomenon where excess


[P] phenomenon in which excess


[R] grammar


high latency and jitter. As more and more interactive applications



[SNIP] 









There is a pressing need to design




intelligent queue management schemes that can control latency and

jitter; and hence provide desirable quality of service to users.


[O] jitter; and hence


[P] jitter, and hence


[R] grammar




[SNIP] 


The design does not




require per-packet timestamp, so it incurs very small overhead and is<=
/div>

[O] require per-packet timestamp,


[P] require per-packet timestamps,


[R] grammar


[O] incurs very small overhead


[P] incurs very little overhead


[R] word choice

















1. Introduction







The explosion of smart phones, tablets and video traffic in the


Internet brings about a unique set of challenges for congestion


control. To avoid packet drops, many service providers or data center<=
/div>

operators require vendors to put in as much buffer as possible. With

rapid decrease in memory chip prices, these requests are easily


[O] With rapid decrease in memory chip price,


[P] Because of the rapid decrease in memory chip prices,


accommodated to keep customers happy. While this solution succeeds in<=
/div>

assuring low packet loss and high TCP throughput, it suffers from a

major downside. The TCP protocol continuously increases its sending

rate and causes network buffers to fill up. TCP cuts its rate only

when it receives a packet drop or mark that is interpreted as a


congestion signal. However, drops and marks usually occur when


network buffers are full or almost full. As a result, excess buffers,<=
/div>

initially designed to avoid packet drops, would lead to highly


elevated queueing latency and jitter. It is a delicate balancing act

to design a queue management scheme that not only allows short-term

burst to smoothly pass, but also controls the average latency in the

presence of long-running greedy flows.


[O] It is a delicate balancing act to design a queue management scheme=
 that not only allows short-term burst to smoothly pass, but also controls =
the average latency in the presence of long-running greedy flows.


[P] Designing a queue management scheme that allows short-term bursts =
to pass smoothly as well as controlling the average latency in the presence=
 of long-running greedy flows is a delicate balancing act.


[R] readability




[SNIP] 









New algorithms are beginning to emerge to control queueing latency

directly to address the bufferbloat problem [CoDel]. Along these


lines, PIE also aims to keep the benefits of RED: such as easy


[O] the benefits of RED: such as easy


[P] the benefits of RED, including easy


[R] readability and grammar


implementation and scalability to high speeds. Similar to RED, PIE

randomly drops an incoming packet at the onset of the congestion. The<=
/div>

congestion detection, however, is based on the queueing latency


instead of the queue length like RED. 




[SNIP] 









In October 2013, CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1]

mandated that cable modems implement a specific variant of the PIE

design as the active queue management algorithm. In addition to cable<=
/div>

specific improvements, the PIE design in DOCSIS 3.1 [DOCSIS-PIE] has

improved the original design in several areas, including de-


randomization of coin tosses and enhanced burst protection.







This draft separates the PIE design into the basic elements that are

MUST to be implemented and optional SHOULD/MAY enhancement elements.

[O] that are MUST to be implemented


[R] This is awkward, but maybe should be left as is? Or delete "a=
re"?

















4. The Basic PIE Scheme







As illustrated in Fig. 1, PIE conceptually comprises three simple MUST=



[O] PIE conceptually comprises three simple


[P] PIE is comprised of three simple


[R] I think this is what is meant -- PIE is made of three MUST compone=
nts, not PIE makes those three components?







components: a) random dropping at enqueueing; b) periodic drop


probability update; c) latency calculation. 



[SNIP] 











5.2 Departure Rate Estimation







One way to calculate latency is to obtain the departure rate. The

draining rate of a queue in the network often varies either because

other queues are sharing the same link, or the link capacity fluctuate=
s.


[O] because other queues are sharing the same link, or the link capaci=
ty fluctuates.


[P] because other queues are sharing the link or because the link capa=
city fluctuates.


[R] clarity

















9. Security Considerations







This document describes an active queue management algorithm based

on implementations in Cisco products. This algorithm introduces no

specific security exposures.












10. IANA Considerations







There are no actions for IANA.












-- END --
















--_000_D36DED3E189FEropanciscocom_--


From nobody Fri May 27 17:52:43 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7316612D0BD; Fri, 27 May 2016 17:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiaFXKOaxT7m; Fri, 27 May 2016 17:52:39 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DCF12D558; Fri, 27 May 2016 17:52:37 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id f144so33309432pfa.3; Fri, 27 May 2016 17:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dFLHhpqxUOoQHRa5+BZhBVhTjFIe5OF7QPd5jWUb9pQ=; b=mEXfs7bT4IaVZG4YPOUZgELqF0V65lzvnPsOkJb0PPKVXepIzkVwnh/6ykN3C0sfBy 3QR4X4L07sta+Wk9LAERb/FMaD12ReGBbTwYvDFYc7+omt+kygPyYf+15xaGBIJDILAe JuWDGoMACSjra/1z3kyfugEtzWQChNyz/ijEevJvWdvW4jSrX2WHOJ1/tMFrgumB4D/0 RtMcsqX/eHINQu5bSQakOEJWiXENbUAZxN7TY9SrAoz1aWmrfUheBrLr5nSfwE23wPns ycCrzJyjIPDLFYGo40IloTfCA6W3Bg5QbBn2yS977/DYqm2Q8KEkuIdgvvdS0yegB6Op zKzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dFLHhpqxUOoQHRa5+BZhBVhTjFIe5OF7QPd5jWUb9pQ=; b=WTcyFT6gYFo1unRtHgISmADeealfr2N3iRnHCjSOFapqJXU/z+r5zZLlOjiaMQZtqI D5jSvkrPxR5r2TLzAbvRsoNPDFmP/p2h+4PIrMln6nUJn4ENyoW8VEljGjFKhcJ1RAXl LJ5uZS3oIkbIlg1fHovuxVnDqyZLtVKhIux+WwTgTUrYchvEdMm3eRz+MYjWYqNBpAF3 IM8M8pZ9iJu7nWLpVA50+NQW7nzqZzHpFVYMmx/ALQMAFsW/Hhc+mHskH+O7huXSEweV ys2eGixr81ymS0vxarrbJgyC/MOpUd/M8F3EQdQtjlVKiGt6iv4psSKr1EG1h7QL4lfF hHiA==
X-Gm-Message-State: ALyK8tJLEDIhki2I1Gj+t9kl4pK8RNvpAdmh8R54PZLHBCqg/pEUgi0MjmhmsfriLevDvg==
X-Received: by 10.98.43.209 with SMTP id r200mr26602643pfr.24.1464396757079; Fri, 27 May 2016 17:52:37 -0700 (PDT)
Received: from [10.16.65.166] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 17sm16327124pfa.59.2016.05.27.17.52.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 17:52:36 -0700 (PDT)
References: 
To: Radia Perlman , "secdir@ietf.org" , The IESG , draft-ietf-dime-e2e-sec-req.all@tools.ietf.org
From: Jouni Korhonen 
Message-ID: 
Date: Fri, 27 May 2016 17:52:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [secdir] Secdir review of draft-ietf-dime-e2e-sec-req-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 00:52:40 -0000

Hi Radia,

Sorry for the lag.. and thank you for the review. See some comments inline.

5/18/2016, 4:29 PM, Radia Perlman kirjoitti:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The document is readable, though a pass through for simple grammar would
> be helpful.  However, a more important editorial comment is that AVP
> should be defined under terminology and not wait until section 3 to
> expand the acronym.

Ack.

>
> -----------
>
> Some things are confusing to me.  For instance,
>
>      Requirement #7:  The solution MUST support symmetric keys and
>       asymmetric keys.
>
>          Motivation: Symmetric and asymmetric cryptographic algorithms
>          provide different security services.  Asymmetric algorithms,
>          for example, allow non-repudiation services to be offered.
>
> I'm not sure what the motivation was for putting this in. Why would
> diameter need nonrepudiation?  And if it's using asymmetric, because it
> wants nonrepudiation, why would it also need symmetric keys?  Indeed,
> usually protocols that use asymmetric keys also use symmetric.  Or is it
> saying that preshared secret keys, or Kerberos must be supported even if
> a public key scheme is fully deployed? Why would that be?

In most cases one would be interested in just providing proof of the 
integrity and origin of AVPs. This is actually the most likely use case. 
For that purpose asymmetric cryptographic algorithms would fit well.

If confidentiality of AVPs is required then symmetric keys would most 
likely to be used for that purpose.

Regading the uses.. the used crypto-suites should/would eventually be 
described per Diameter application. In that situation we are likely to 
see both symmetric and asymmetric crypto be used in the same Diameter 
node that handles multiple applications.


>
> --------
>
> I found this sentence confusing:
>
>       As an example, consider the Diameter EAP
>       application [4] that allows the transport of keying material
>       between the Diameter server to the Diameter client (using the EAP-
>       Master-Session-Key AVP) for the protection of air interface
>       between the end device and the network access server.
>
> What is "air interface"?  Do you mean the wireless link?  Is the
> "diameter client" the same as the "end device"?  What is the "network
> access server"?  None of these things are in the diagram.

Air interface == wireless link, yes. End device is not the Diameter 
client. The end device could e.g., be a mobile phone whereas the 
Diameter client could be an access point or a base station.

Network access server would be a node with a Diameter client. We need to 
add that into the diagrams.

>
> ------------
> Also,
>
>    {AVP}k refers to an AVP that
>    experiences security protection (using key "k") without further
>    distinguishing between integrity and confidentiality protection.
>
> I think it's a good idea to have different notation for confidentiality
> and integrity, because sometimes things need one, and sometimes they
> need both.

Ack, agree in general with the usefullness of different notations. In 
the examples we got there was just no need to make difference between 
confidentiality and integrity protection.

Thanks,
	Jouni

>
> ---------
>
> Radia


From nobody Sat May 28 15:15:35 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3953412D15A; Sat, 28 May 2016 15:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ul091s13qO5W; Sat, 28 May 2016 15:15:27 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FAD12D0C8; Sat, 28 May 2016 15:15:27 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id l63so15464555ita.1; Sat, 28 May 2016 15:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=yZk/hTWei/KfttLu+Vxtd72sOdga14w6TTLTeSaZ/tE=; b=jxkus3rlhGeobS7sTzjXQ+6Ulh4OYf1DnoWAXZinmgR7iR6tWshfty1jFg5luomAe7 ZLhq1D++Tn4LGH2i3FxmiSt42WuSrZwFTXVQaBDFN5pZj+OjN+FU+dPg4ci4VcC407ml 5w6NNDJ+xY3+dryB8HfP+SkwM2dYh+1ygsHplU6yhLJ9ce17PiBSKz56CDOPgbKT0f07 85SWqMAgrXD5n80RkLunrU3Ij+T4kLeKrNCqTEnvVPhKU6C/8QbQ6TnpIb9S/gU4AWso gigrd3q9u4UBnhdw43h6kLQzp8FYGSeRZyEwlAMCzthk3xObE/E0YFIFCa0rmVeLoHDM 1m5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=yZk/hTWei/KfttLu+Vxtd72sOdga14w6TTLTeSaZ/tE=; b=R78cKECUPYxTZnvkV2/U6KsVFlip9qu6pwljTYN5IZkSfZUvK2wPHrJJbjTnxvvkzL v1SEqHeKc2gtYVTEjWwZoPswDDUfEIKeOwcnEvrhzjdrVZ8/Ft4YaPE0KyevSpBnCMrw rzxYtlCEIa6ZXoYFVtFeK2xwOm6OCn132EZHYgDtOLcF9GSWd3uhUep+2Z2A24i9UBVo syIRACGWpnt6laSJ+93p2YlwblhAd+Cru0vbpDN3KP8tAo4Xsz+3jMM6/yhTu3oFdlHV 3X+z/v+we831MNqowSJkxG+GNzinG2ADYr/oS1H+opLWVt2orYTv8tWnm6h7mZGld8BS zdVQ==
X-Gm-Message-State: ALyK8tILU2nfZnGAvxB4AxM2klsZBhf2MTZs/2dvAf9XUJ2Ejf+c91ll13TwgFrUdIzlwXdHZohyy+NbuXMO4Q==
MIME-Version: 1.0
X-Received: by 10.36.137.131 with SMTP id s125mr3374401itd.93.1464473726615; Sat, 28 May 2016 15:15:26 -0700 (PDT)
Received: by 10.64.252.197 with HTTP; Sat, 28 May 2016 15:15:26 -0700 (PDT)
In-Reply-To: 
References: <2f7b562b-3455-3518-c933-12aeb6a3957a@gmail.com>  
Date: Sat, 28 May 2016 16:15:26 -0600
Message-ID: 
From: Tim Schaub 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: draft-ietf-geojson.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-geojson-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 22:15:29 -0000

On Thu, May 26, 2016 at 12:05 PM, Melinda Shore  w=
rote:
> On 5/26/16 7:11 AM, Tim Schaub wrote:
>>
>> Thanks for the feedback Melinda.  I put together a pull request with
>> your proposed changes:
>> https://github.com/geojson/draft-geojson/pull/205
>
>
> Cool, thanks.  If text regarding data at rest is wanted
> it may be sufficient to say something along the lines of
> "There will be cases in which stored data need protection,
> which is out of scope for this document."
>
> Melinda

Sounds good.

I've updated the pull request so the Security Considerations text now
finishes with this:

"If sensitive data requires privacy or integrity protection, those
must be provided by the transport =E2=80=94 for example TLS or HTTPS. There
will be cases in which stored data need protection, which is out of
scope for this document."

https://circle-artifacts.com/gh/geojson/draft-geojson/141/artifacts/0/home/=
ubuntu/draft-geojson/draft.html#rfc.section.10

https://github.com/geojson/draft-geojson/pull/205

>
>


From nobody Mon May 30 11:43:38 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8A312D56F; Mon, 30 May 2016 11:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=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 mjpWMm6AdI-T; Mon, 30 May 2016 11:43:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B36312D56C; Mon, 30 May 2016 11:43:31 -0700 (PDT)
Received: from unnumerable.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4UIhS50017211 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 30 May 2016 13:43:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be unnumerable.local
To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-mile-rfc5070-bis.all@ietf.org
From: Robert Sparks 
Message-ID: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com>
Date: Mon, 30 May 2016 13:43:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [secdir] Secdir review: draft-ietf-mile-5070-bis-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 18:43:37 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Document : draft-ietf-mile-rfc5070bis-22

Summary: This document has minor issues that should be addressed before 
publication as Proposed Standard

This document defines a document format for exchanging information between
operational security teams. It points out standardized mechanisms for
transporting the documents (RFC6545 and RFC6546), to provide 
confidentiality,
integrity, and authenticity, but does not restrict the use of the format to
within those protocols.  Instead, it provides a generic set of "Processing
Considerations" in section 4, which are augmented by the Security
Considerations in section 9.

There are some minor issues with this approach that should be addressed 
before
publication.

1) The document requires that implementations validate documents against the
schema, and reject any documents that fail validation.  In particular, 
Section
5.2 Item 4 requires rejecting documents with an unrecognized element in a
supported namespace as a syntax error. Section 4.3 requires 
implementations to
->dynamically generate the schema used for validation from IANA 
registries<-.
Section 5.2 Item 5 calls out that this dynamic generation has security and
performance implications, but does not describe them, and has a very vague
"SHOULD NOT download schemas at runtime" to guard against them.  I seem to
recall significant discussion in other contexts of the issues with 
generating
schema from IANA registries at runtime.  Perhaps the ADs can provide 
pointers
to material generated from those discussions that the group can reference.
Otherwise, the threats need to be described in more detail, and the 
operational
complexity of exercising these extension points (particularly given the
requirement to reject documents that do not validate against the content 
of the
registries) needs to be spelled out.

2) The document notes (in Section 9.1) that some fields in the document 
format
may contain executable content. It is not clear which fields are being
mentioned, or what _kind_ of executable content is being carried. Explicitly
calling out the fields that this document defines at this point, and
characterizing their content would help. The precautions you might need 
to take
against a regex are different from those you would take against arbitrary
bytecode the recipient might be asked to execute.

3) There are several fields that are characterized as "meaningful to the 
sender
and recipient". This implies that the document cannot be interpreted outside
some out-of-band prior arrangement defining the context in which those 
fields
are meaningful. The document should explicitly mention the need for such 
prior
arrangements in the Security Consideration section, and note the danger of
attempting to interpret those fields if the ability to ensure the 
message falls
within that pre-arranged context is suspect. The existing text around 
ensuring
proper authentication of the sender and recipient is a start, but is not
sufficient. While considering the problems with interpreting these fields in
the wrong context, the document should recognize the possibility that a 
given
sender/recipient pair might have _two different_ arrangements about what 
these
fields mean, especially given the passage of sufficient time.

Nits:

A) Section 2.11 calls out to RFC4519 to defined the syntax of telephone
numbers.  The document calls out to E.123, which provides guidelines for
representing phone numbers but does not define a rigorous format useful 
for a
protocol field.  If it's important to exchange phone numbers in an
interoperable way, consider pointing to something with more structure. 
Do you
want the string to conform to E.164?  Would it be useful to have 
something as
structured as a tel: URI?

B) Section 4.1 says a character encoding MUST be explicitly specified, 
but then
immediately shows an example of a document with no character encoding...

C) (micronit) The use of [RFC-ENUM] as a reference number is distracting.
Please change the reference tag to [RFC7495].

Note: I did _not_ verify that the schema was well formed or that it 
matched the
prose.


From nobody Tue May 31 03:06:16 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFFE12D6C6; Tue, 31 May 2016 03:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYccm9I91bUF; Tue, 31 May 2016 03:06:14 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6512D183; Tue, 31 May 2016 03:06:13 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id u4VA6Bhg014519; Tue, 31 May 2016 19:06:11 +0900 (JST)
Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp  with ESMTP id u4VA6BiV014511; Tue, 31 May 2016 19:06:11 +0900 (JST)
Received: from VAIO (unknown [133.243.30.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id B66256B95; Tue, 31 May 2016 19:06:10 +0900 (JST)
From: "Takeshi Takahashi" 
To: , , , 
Date: Tue, 31 May 2016 19:06:22 +0900
Message-ID: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdG7IyLdVBROrcWPQpmXcgE5pcjURQ==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 10:06:15 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.

[General summary]

This document is ready.

[Topic of this draft]

This draft talks about the UDP Usage Guidelines and replaces RFC 5405 (BCP).
It talks about how to use UDP, especially it pays attention to the fair use
of the network resourced and talks a lot on congestion control.

The RFC 5045 focuses on unicast case, but this bis document talks about
multicast, (anycast, broadcast, )and IP tunneling cases.

The content is useful, and I hope to see this draft to be published as an
RFC.

[Clarification question]

In Table 1 "Summary of recommendations", I wonder if the corresponding
section numbers are correct.

[Now]
"SHOULD avoid using multiple ports"  corresponds to Section 5.1
and 
"SHOULD use a randomized source port or equivalent technique" corresponds to
Section 5.2

[New]
"SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
and 
"SHOULD use a randomized source port or equivalent technique" corresponds to
Section 5.1.2

I might be wrong, so please check.

Also I have seen several typos (especially, missing parentheses around
referenced section numbers) on this document, so please revise the texts
before the publication of this document.

Thank you.
Take




From nobody Tue May 31 03:14:31 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949712D70C; Tue, 31 May 2016 03:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7Mt4RuzG-lx; Tue, 31 May 2016 03:14:28 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6C12D707; Tue, 31 May 2016 03:14:27 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id u4VAEQku026523; Tue, 31 May 2016 19:14:26 +0900 (JST)
Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp  with ESMTP id u4VAEQs3026520; Tue, 31 May 2016 19:14:26 +0900 (JST)
Received: from VAIO (unknown [133.243.30.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 38FAC6C33; Tue, 31 May 2016 19:14:26 +0900 (JST)
From: "Takeshi Takahashi" 
To: , , , 
References: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp>
In-Reply-To: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp>
Date: Tue, 31 May 2016 19:14:37 +0900
Message-ID: <009601d1bb25$3cb3dea0$b61b9be0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIqTpcD9HVvR9EqZoraa3UouOrYpp8hrLkQ
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 10:14:30 -0000

Hi again, let me correct the following part of my previous email.

> [New]
> "SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
>
> and
>
> "SHOULD use a randomized source port or equivalent technique" corresponds
to Section 5.1.2

[New]
"SHOULD avoid using multiple ports"  corresponds to Section 5.1.1

and

"SHOULD use a randomized source port or equivalent technique" corresponds to
Section 5.1

Thank you.
Take


> -----Original Message-----
> From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Takeshi
> Takahashi
> Sent: Tuesday, May 31, 2016 7:06 PM
> To: lars@netapp.com; iesg@ietf.org; secdir@ietf.org;
> draft-ietf-tsvwg-rfc5405bis.all@ietf.org
> Subject: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
> 
> I have reviewed this document as part of the security directorate's
ongoing
> effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> [General summary]
> 
> This document is ready.
> 
> [Topic of this draft]
> 
> This draft talks about the UDP Usage Guidelines and replaces RFC 5405
(BCP).
> It talks about how to use UDP, especially it pays attention to the fair
> use
> of the network resourced and talks a lot on congestion control.
> 
> The RFC 5045 focuses on unicast case, but this bis document talks about
> multicast, (anycast, broadcast, )and IP tunneling cases.
> 
> The content is useful, and I hope to see this draft to be published as an
> RFC.
> 
> [Clarification question]
> 
> In Table 1 "Summary of recommendations", I wonder if the corresponding
> section numbers are correct.
> 
> [Now]
> "SHOULD avoid using multiple ports"  corresponds to Section 5.1
> and
> "SHOULD use a randomized source port or equivalent technique" corresponds
> to
> Section 5.2
> 
> [New]
> "SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
> and
> "SHOULD use a randomized source port or equivalent technique" corresponds
> to
> Section 5.1.2
> 
> I might be wrong, so please check.
> 
> Also I have seen several typos (especially, missing parentheses around
> referenced section numbers) on this document, so please revise the texts
> before the publication of this document.
> 
> Thank you.
> Take
> 
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


From nobody Tue May 31 06:32:51 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242F12D1DC; Tue, 31 May 2016 06:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.747
X-Spam-Level: 
X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 H6EIeYRq3QOn; Tue, 31 May 2016 06:32:42 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 705B712D1D5; Tue, 31 May 2016 06:32:42 -0700 (PDT)
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4VDWeZJ015499 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 May 2016 09:32:40 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u4VDWeZJ015499
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1464701561; bh=fKCcQ0OL/lhidh6VPb1ctk53AfY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=fTyTyQavw7QdSiCNGwtuGFAxTU2I1atShzWr+rAhaQ89F9dpuznddphSKLRKY2mZq FPCQFLZrVkNwATk/ejj/FPWWSesMokxHn0VNJPG6Umo8QJYGx1AeKNkSVSY+vJuZaT VdCZf5u3poN2eAPQnckyCHn0gfN9O0LFBRpoNXdY=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u4VDWeZJ015499
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 31 May 2016 09:32:17 -0400
Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4VDWQsQ024565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 31 May 2016 09:32:26 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0266.001; Tue, 31 May 2016 09:32:26 -0400
From: "Black, David" 
To: Takeshi Takahashi , "lars@netapp.com" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" 
Thread-Topic: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
Thread-Index: AdG7IyLdVBROrcWPQpmXcgE5pcjURQAI6B+AAAGA3PA=
Date: Tue, 31 May 2016 13:32:25 +0000
Message-ID: 
References: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp> <009601d1bb25$3cb3dea0$b61b9be0$@nict.go.jp>
In-Reply-To: <009601d1bb25$3cb3dea0$b61b9be0$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.45.64]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Cc: "Black, David" 
Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 13:32:46 -0000

Take-san,

Many thanks for this review - we'll re-check Table 1 and make any necessary=
 corrections.

Thanks, --David (as draft shepherd)

> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Tuesday, May 31, 2016 6:15 AM
> To: lars@netapp.com; iesg@ietf.org; secdir@ietf.org; draft-ietf-tsvwg-
> rfc5405bis.all@ietf.org
> Subject: RE: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
>=20
> Hi again, let me correct the following part of my previous email.
>=20
> > [New]
> > "SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
> >
> > and
> >
> > "SHOULD use a randomized source port or equivalent technique" correspon=
ds
> to Section 5.1.2
>=20
> [New]
> "SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
>=20
> and
>=20
> "SHOULD use a randomized source port or equivalent technique" corresponds=
 to
> Section 5.1
>=20
> Thank you.
> Take
>=20
>=20
> > -----Original Message-----
> > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Takeshi
> > Takahashi
> > Sent: Tuesday, May 31, 2016 7:06 PM
> > To: lars@netapp.com; iesg@ietf.org; secdir@ietf.org;
> > draft-ietf-tsvwg-rfc5405bis.all@ietf.org
> > Subject: [secdir] Secdir review of draft-ietf-tsvwg-rfc5405bis-13
> >
> > I have reviewed this document as part of the security directorate's
> ongoing
> > effort to review all IETF documents being processed by the IESG.
> > These comments were written primarily for the benefit of the security a=
rea
> > directors.
> > Document editors and WG chairs should treat these comments just like an=
y
> > other last call comments.
> >
> > [General summary]
> >
> > This document is ready.
> >
> > [Topic of this draft]
> >
> > This draft talks about the UDP Usage Guidelines and replaces RFC 5405
> (BCP).
> > It talks about how to use UDP, especially it pays attention to the fair
> > use
> > of the network resourced and talks a lot on congestion control.
> >
> > The RFC 5045 focuses on unicast case, but this bis document talks about
> > multicast, (anycast, broadcast, )and IP tunneling cases.
> >
> > The content is useful, and I hope to see this draft to be published as =
an
> > RFC.
> >
> > [Clarification question]
> >
> > In Table 1 "Summary of recommendations", I wonder if the corresponding
> > section numbers are correct.
> >
> > [Now]
> > "SHOULD avoid using multiple ports"  corresponds to Section 5.1
> > and
> > "SHOULD use a randomized source port or equivalent technique" correspon=
ds
> > to
> > Section 5.2
> >
> > [New]
> > "SHOULD avoid using multiple ports"  corresponds to Section 5.1.1
> > and
> > "SHOULD use a randomized source port or equivalent technique" correspon=
ds
> > to
> > Section 5.1.2
> >
> > I might be wrong, so please check.
> >
> > Also I have seen several typos (especially, missing parentheses around
> > referenced section numbers) on this document, so please revise the text=
s
> > before the publication of this document.
> >
> > Thank you.
> > Take
> >
> >
> >
> > _______________________________________________
> > secdir mailing list
> > secdir@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


From nobody Tue May 31 15:56:28 2016
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4001E12D689 for ; Tue, 31 May 2016 15:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=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 hbZH6wdq0vth for ; Tue, 31 May 2016 15:56:25 -0700 (PDT)
Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1110312D8CA for ; Tue, 31 May 2016 15:56:20 -0700 (PDT)
X-ASG-Debug-ID: 1464733575-05f27567943a340001-mFDwdl
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id r4PyzVnlLfBoZx3u (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 01 Jun 2016 00:26:15 +0200 (CEST)
X-Barracuda-Envelope-From: spromano@unina.it
X-Barracuda-Apparent-Source-IP: 192.132.34.62
Received: from [192.168.178.20] ([151.70.36.98]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u4VMPvZM019594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 00:26:13 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF703B39-5497-45CF-B02A-2BF22C7A2829"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Simon Pietro Romano 
X-ASG-Orig-Subj: Re: draft-ietf-clue-data-model-schema
In-Reply-To: 
Date: Wed, 1 Jun 2016 00:26:13 +0200
Message-Id: <64FC0FC3-A963-431B-ACD2-575720937AE9@unina.it>
References: 
To: "Salz, Rich" 
X-Mailer: Apple Mail (2.2104)
X-Barracuda-Connect: smtp2.unina.it[192.132.34.62]
X-Barracuda-Start-Time: 1464733575
X-Barracuda-Encrypted: AES256-SHA
X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at unina.it
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30065 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Cc: "draft-ietf-clue-data-model-schema.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
Subject: Re: [secdir] draft-ietf-clue-data-model-schema
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 22:56:26 -0000

--Apple-Mail=_BF703B39-5497-45CF-B02A-2BF22C7A2829
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Rich,

> Summary: this document is ready, perhaps with nits.

Great!

> You might consider reducing the security considerations part, just to =
increase emphasis on the fact that while the data described by this =
schema is potentially very privacy-impacting, it is the *protocol(s)* =
that need to address those issues.    Perhaps adding an intro sentence =
like that to the Sec 15 would be useful.

No problem for us wrt to this. What do the chairs suggest?

> Thanks for the trip down my personal memory line.  Haven't deal with =
XML Schema since WS-star days :)

:-))

Cheers,

Simon

>=20
> -- =20
> Senior Architect, Akamai Technologies
> IM: richsalz@jabber.at Twitter: RichSalz
>=20
>=20
>=20

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico =
II
                		     Computer Engineering Department=20
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <>. =
Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            =
(   )
			                                  \_)          ) =
/
                                                                       =
(_/







--Apple-Mail=_BF703B39-5497-45CF-B02A-2BF22C7A2829
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello Rich,

Summary: this document is ready, perhaps with nits.

Great!

You might consider reducing the security =
considerations part, just to increase emphasis on the fact that while =
the data described by this schema is potentially very privacy-impacting, =
it is the *protocol(s)* that need to address those issues. =
   Perhaps adding an intro sentence like that to the Sec =
15 would be useful.

No problem for us wrt to this. What do the chairs =
suggest?

Thanks for the trip down my personal memory =
line.  Haven't deal with XML Schema since WS-star days :)

:-))
Cheers,

Simon


--  
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at =
Twitter: RichSalz






  =
                  =
 		=
			       =
_\\|//_
            =
               				=
      ( O-O )
  =
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =
    				=
Simon Pietro Romano
      =
       				 Universita' di Napoli =
Federico II
          =
      		    =
 Computer Engineering Department 
	  =
           Phone: +39 081 7683823 -- Fax: =
+39 081 7683816
          =
                    =
             e-mail: spromano@unina.it

		    =
<<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi =
degli 
		   =
 idioti. Ci rifletto un istante; e mi scoraggio>>. =
Magritte.
           =
    			=
                  =
   oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =
  )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
				=
	                =
 \ (            (   )
		=
	                =
                  \_) =
         ) /
    =
                    =
                    =
                    =
       (_/









=

--Apple-Mail=_BF703B39-5497-45CF-B02A-2BF22C7A2829--