
From nobody Mon Aug  3 15:10:52 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1641B3187 for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 15:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.888
X-Spam-Level: 
X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsLDfxfsBw0D for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 15:04:12 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 692F41AD067 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:04:10 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7BB381E59E6 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:04:05 -0700 (PDT)
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by c8a.amsl.com (Postfix) with ESMTPSA id 4B7AF1E59E8 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:04:05 -0700 (PDT)
Received: by vkhg129 with SMTP id g129so47685340vkh.2 for <tools-development@ietf.org>; Mon, 03 Aug 2015 15:04:09 -0700 (PDT)
X-Received: by 10.52.137.236 with SMTP id ql12mr443871vdb.48.1438639449396; Mon, 03 Aug 2015 15:04:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Mon, 3 Aug 2015 15:03:50 -0700 (PDT)
From: Glen <glen@amsl.com>
Date: Mon, 3 Aug 2015 15:03:50 -0700
Message-ID: <CABL0ig7MuNW_zZg-_a0q+25h3fBsLaj-fNFxZOKd2KLONGnxxg@mail.gmail.com>
To: Glen Barney <glen@amsl.com>
Content-Type: multipart/alternative; boundary=bcaec51b9c0d575fa5051c6f5950
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/bF5ZffP21NYl_N2H3RzxansdDEg>
X-Mailman-Approved-At: Mon, 03 Aug 2015 15:10:49 -0700
Subject: [TOOLS-DEVELOPMENT] IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 22:04:13 -0000

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

All -

We are experiencing degradation on the websites served by the primary IETF
server group, including the IETF main website, the IAB and IRTF sites, and
the Datatracker.

Page load times for all sites are extremely slow.

We have engineers working on this now.

The problem *seems* to be that Cloudflare is sending us hundreds of
simultaneous connections from hundreds of different IP addresses across
many netblocks.  We are contacting Cloudflare now to see why this is
happening, and what can be done to mitigate it, and we are continuing to
investigate options on our end to restore normal service.

Other services and sites are not impacted, and one way or another we will
have service restored shortly.  Thank you for your patience in this matter.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

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

<div dir=3D"ltr"><div><div><div><div><div>All -<br><br></div>We are experie=
ncing degradation on the websites served by the primary IETF server group, =
including the IETF main website, the IAB and IRTF sites, and the Datatracke=
r.<br><br></div>Page load times for all sites are extremely slow.<br><br></=
div>We have engineers working on this now.<br><br></div>The problem *seems*=
 to be that Cloudflare is sending us hundreds of simultaneous connections f=
rom hundreds of different IP addresses across many netblocks.=C2=A0 We are =
contacting Cloudflare now to see why this is happening, and what can be don=
e to mitigate it, and we are continuing to investigate options on our end t=
o restore normal service.<br><br></div><div>Other services and sites are no=
t impacted, and one way or another we will have service restored shortly.=
=C2=A0 Thank you for your patience in this matter.<br><br></div><div>Glen<b=
r></div><div>Glen Barney<br></div><div>IT Director<br></div><div>AMS (IETF =
Secretariat)<br><br></div></div>

--bcaec51b9c0d575fa5051c6f5950--


From nobody Mon Aug  3 15:25:08 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF41A1B31DA for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 15:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.587
X-Spam-Level: 
X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jno_-jOeMnz for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 15:24:39 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 121331ACEA4 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:24:29 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 187171E5A00 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:24:24 -0700 (PDT)
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by c8a.amsl.com (Postfix) with ESMTPSA id DC30E1E59F0 for <tools-development@ietf.org>; Mon,  3 Aug 2015 15:24:23 -0700 (PDT)
Received: by vkgc186 with SMTP id c186so48056548vkg.0 for <tools-development@ietf.org>; Mon, 03 Aug 2015 15:24:28 -0700 (PDT)
X-Received: by 10.52.255.233 with SMTP id at9mr583730vdd.38.1438640668095; Mon, 03 Aug 2015 15:24:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Mon, 3 Aug 2015 15:24:08 -0700 (PDT)
From: Glen <glen@amsl.com>
Date: Mon, 3 Aug 2015 15:24:08 -0700
Message-ID: <CABL0ig6OHxGLHkB=syjFGmVitWyzmEgcYTe8B4EHxXwjsa6_yw@mail.gmail.com>
To: Glen Barney <glen@amsl.com>
Content-Type: multipart/alternative; boundary=001a1135f6fefb3aee051c6fa149
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/7ZREbzQm3Jbctt0SzeryMsv7Du8>
X-Mailman-Approved-At: Mon, 03 Aug 2015 15:25:06 -0700
Subject: [TOOLS-DEVELOPMENT] Update Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 22:24:43 -0000

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

All -

We have determined that the degradation was caused by a DDoS attack against
the www.ietf.org website.  The attack was a slowly-escalating attack, which
began several hours ago, and increased in load over the afternoon.  The
attack was directed at the Cloudflare servers, so we were not immediately
impacted.

However, as time passed, the results of the attack started to spill over to
the actual IETF webservers, with the result that our webservers started to
slow.  We were alerted to this by our own monitoring systems, which is when
we did an initial check, and I then sent the initial report out.

At this point, we have been unable to reach a human at Cloudflare, although
we are continuing to try.  We have therefore put our Cloudflare account
into "DDoS Mitigation Mode".

In this mode, users will see a brief interstitial page when browsing the
IETF website.  This page allows Cloudflare to perform testing on each
browser to determine whether the request is part of an attack or not.  You
may see this page as you approach the IETF website.  It is nothing to be
alarmed about, and is an expected side-effect of this protection mode.

It is unknown, at this point, why Cloudflare did not automatically detect,
and block, the attack.

It is unknown, at this point, why the attack caused Cloudflare to start
spilling requests over to us.

It is unknown, at this point, why we are unable to reach a human there. :-)

However, at this time, website service is restored, and, apart from the
interstitial page on the IETF website, everything is running as expected.
We will continue to reach out to Cloudflare to address these remaining
issues, and will get that check page deactivated as quickly as possible.

Thank you for your patience during that happily brief degradation.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div>All -<br><br></div>We have determined that the degradation was cause=
d by a DDoS attack against the <a href=3D"http://www.ietf.org">www.ietf.org=
</a> website.=C2=A0 The attack was a slowly-escalating attack, which began =
several hours ago, and increased in load over the afternoon.=C2=A0 The atta=
ck was directed at the Cloudflare servers, so we were not immediately impac=
ted.<br><br></div>However, as time passed, the results of the attack starte=
d to spill over to the actual IETF webservers, with the result that our web=
servers started to slow.=C2=A0 We were alerted to this by our own monitorin=
g systems, which is when we did an initial check, and I then sent the initi=
al report out.<br><br></div>At this point, we have been unable to reach a h=
uman at Cloudflare, although we are continuing to try.=C2=A0 We have theref=
ore put our Cloudflare account into &quot;DDoS Mitigation Mode&quot;.<br><b=
r></div>In this mode, users will see a brief interstitial page when browsin=
g the IETF website.=C2=A0 This page allows Cloudflare to perform testing on=
 each browser to determine whether the request is part of an attack or not.=
=C2=A0 You may see this page as you approach the IETF website.=C2=A0 It is =
nothing to be alarmed about, and is an expected side-effect of this protect=
ion mode.<br><br></div>It is unknown, at this point, why Cloudflare did not=
 automatically detect, and block, the attack.<br><br></div>It is unknown, a=
t this point, why the attack caused Cloudflare to start spilling requests o=
ver to us.<br><br></div>It is unknown, at this point, why we are unable to =
reach a human there. :-)<br><br></div>However, at this time, website servic=
e is restored, and, apart from the interstitial page on the IETF website, e=
verything is running as expected.=C2=A0 We will continue to reach out to Cl=
oudflare to address these remaining issues, and will get that check page de=
activated as quickly as possible.<br><br></div>Thank you for your patience =
during that happily brief degradation.<br><br></div>Glen<br></div>Glen Barn=
ey<br></div>IT Director<br></div>AMS (IETF Secretariat)<br><br></div>

--001a1135f6fefb3aee051c6fa149--


From nobody Mon Aug  3 16:52:24 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640B81B31D8; Mon,  3 Aug 2015 16:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.887
X-Spam-Level: 
X-Spam-Status: No, score=-100.887 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-znVSACZBop; Mon,  3 Aug 2015 16:52:15 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id C8F711B31BA; Mon,  3 Aug 2015 16:52:15 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 942B21E59E8; Mon,  3 Aug 2015 16:52:10 -0700 (PDT)
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by c8a.amsl.com (Postfix) with ESMTPSA id 502501E59D8; Mon,  3 Aug 2015 16:52:10 -0700 (PDT)
Received: by vkci6 with SMTP id i6so49635544vkc.3; Mon, 03 Aug 2015 16:52:14 -0700 (PDT)
X-Received: by 10.52.32.34 with SMTP id f2mr947008vdi.11.1438645934769; Mon, 03 Aug 2015 16:52:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Mon, 3 Aug 2015 16:51:55 -0700 (PDT)
From: Glen <glen@amsl.com>
Date: Mon, 3 Aug 2015 16:51:55 -0700
Message-ID: <CABL0ig6ax-qQ9fT1czs6E32Tpd1BeONG-G5k6i+TLfTvHo8ypg@mail.gmail.com>
To: iesg@ietf.org, iab@ietf.org, iaoc@ietf.org,  IETF Tools Development <tools-development@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec51d2b80e64b8d051c70dbd5
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/voMP8xvgaxFhz43hN9F4DmG396w>
Subject: [TOOLS-DEVELOPMENT] Leadership Update Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 23:52:19 -0000

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

I'm now narrowing the distribution of this discussion a little bit, to the
IETF leadership, as shown in the headers.

Here is where we stand at the moment.

First, as to the all-important question about "reaching a human."  It turns
out that Cloudflare does not provide human phone support.  We are on the
"Business Plan" at $200/month, which, if you look here,
https://www.cloudflare.com/plans , conspicuously does *not* include 24/7
phone support.

And before we run off and determine that we should immediately "upgrade to
the Enterprise plan", I'd like to call out a few other things.

The plan we *are* on includes what they call "Advanced DDoS mitigation".
As outlined here, https://www.cloudflare.com/ddos , Cloudflare is
*supposed* to *protect* us from DDoS attacks of the type we encountered
today.  But if we read the fine print, that turns out to not always be the
case...

--snip--

Layer 7 attacks

A new breed of attacks target Layer 7 of the OSI model, the "application"
layer. These attacks focus on specific characteristics of web applications
that create bottlenecks. For example, the so-called Slow Read attack sends
packets slowly across multiple connections. Because Apache opens a new
thread for each connection, and since connections are maintained as long as
there is traffic being sent, an attacker can overwhelm a web server by
exhausting its thread pool relatively quickly.

CloudFlare has protections in place against many of these attacks, and in
real world experiences we generally reduce HTTP attack traffic by 90%. For
most attacks, and for most of our customers, this is enough to keep them
online. However, the 10% of traffic that does get through traditional
protections can still be overwhelming to customers with limited resources
or in the face of very large attacks. In this case, CloudFlare offers a
security setting called "I'm Under Attack" mode (IUAM).

IUAM is a security level you can set for your site when you're under
attack. When IUAM is turned on, CloudFlare will add an additional layer of
protections to stop malicious HTTP traffic from being passed to your
server. While a number of additional checks are performed in the
background, an interstitial page is presented to your site's visitors for 5
seconds while the checks are completed. Think of it as a challenge where
the tests are automatic and visitors never need to fill in a CAPTCHA.

--snip--

This is the step we had to take today to fix this problem.  And that did
fix the problem.  At a cost, of course, of a javascript-and-cookie-based
interstitial page - hardly a permanent fix.

In other words, Cloudflare did *not* automatically stop this attack.  We
still had to suffer it, detect it, and take client action in order to
mitigate this attack.

And now we have to do a bit more:  Although we were never told about this,
and the sales pages don't mention it, we find via email support that there
is an Apache module we need to install to find out where the attack is
actually coming from, and thereby mitigate it.    So, for your info, our
next steps are:

1. Install the apache2 mod_cloudflare module (we're doing that this evening)
2. Turn off the "IUAM" mode and let the attack continue (assuming it does)
3. Use the logging provided by this module to determine the source of the
attack.
4. Insert that information back into the Cloudflare control panel to block
the IP address(es) from which the attack is originating.

We will be taking these steps as soon as possible.

But I spell this out for you all because I want to make clear that, while
for $200 I might not expect 24/7 phone support, for $200 I certainly expect
some kind of web interface that lets me directly determine where an attack
is coming from (we don't get that with Cloudflare, we have to let the
attack bleed through and figure it out with this add-on Apache module).
And I would certainly prefer (and the site certainly implies this) that
Cloudflare detect *and prevent* this kind of attack before it ever reaches
us, as every other section of their very expansive web page implies they do
automatically.

So I'm not particularly in the "let's jump to Enterprise service" because I
don't see any evidence that it will get us anything more than we already
have that is substantive.

But I do think that they have room for improvement, and so perhaps there is
another way to go:  Perhaps someone in an IETF leadership role might want
to reach out to Cloudflare with these concerns, and see if Cloudflare has
an answer, or perhaps a plan?  Perhaps the IETF could assist them with
these concerns somehow?  It might be to everyone's benefit.

And, on that same note, I've also observed that many companies are willing
to donate services and products to the IETF.  Maybe Cloudflare would like
to be generous as well?  Could be worth asking that question.

At any rate, to conclude, we are following the steps given by Cloudflare,
and we will work to get this resolved as soon as possible given the level
of support (email) and list of steps (webserver modification) we've been
given... but, to my surprise, the token is AMS' at this point, and not
Cloudflare's... which is not what I think any of us would have suspected
given what we thought Cloudflare was offering.

Please let me know if you have any questions, and, again, I apologize for
the disruption, and the learning curve, as we discover more about
Cloudflare's services and options.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>I&#39;m =
now narrowing the distribution of this discussion a little bit, to the IETF=
 leadership, as shown in the headers.<br><br></div>Here is where we stand a=
t the moment.<br><br></div>First, as to the all-important question about &q=
uot;reaching a human.&quot;=C2=A0 It turns out that Cloudflare does not pro=
vide human phone support.=C2=A0 We are on the &quot;Business Plan&quot; at =
$200/month, which, if you look here, <a href=3D"https://www.cloudflare.com/=
plans">https://www.cloudflare.com/plans</a> , conspicuously does *not* incl=
ude 24/7 phone support.=C2=A0 <br><br></div>And before we run off and deter=
mine that we should immediately &quot;upgrade to the Enterprise plan&quot;,=
 I&#39;d like to call out a few other things.=C2=A0 <br><br></div>The plan =
we *are* on includes what they call &quot;Advanced DDoS mitigation&quot;.=
=C2=A0 As outlined here, <a href=3D"https://www.cloudflare.com/ddos">https:=
//www.cloudflare.com/ddos</a> , Cloudflare is *supposed* to *protect* us fr=
om DDoS attacks of the type we encountered today.=C2=A0 But if we read the =
fine print, that turns out to not always be the case...<br><br></div>--snip=
--<br><br>Layer 7 attacks<br><br>A new breed of attacks target Layer 7 of t=
he OSI model, the &quot;application&quot; layer. These attacks focus on spe=
cific characteristics of web applications that create bottlenecks. For exam=
ple, the so-called Slow Read attack sends packets slowly across multiple co=
nnections. Because Apache opens a new thread for each connection, and since=
 connections are maintained as long as there is traffic being sent, an atta=
cker can overwhelm a web server by exhausting its thread pool relatively qu=
ickly.<br><br>CloudFlare has protections in place against many of these att=
acks, and in real world experiences we generally reduce HTTP attack traffic=
 by 90%. For most attacks, and for most of our customers, this is enough to=
 keep them online. However, the 10% of traffic that does get through tradit=
ional protections can still be overwhelming to customers with limited resou=
rces or in the face of very large attacks. In this case, CloudFlare offers =
a security setting called &quot;I&#39;m Under Attack&quot; mode (IUAM).<br>=
<br>IUAM is a security level you can set for your site when you&#39;re unde=
r attack. When IUAM is turned on, CloudFlare will add an additional layer o=
f protections to stop malicious HTTP traffic from being passed to your serv=
er. While a number of additional checks are performed in the background, an=
 interstitial page is presented to your site&#39;s visitors for 5 seconds w=
hile the checks are completed. Think of it as a challenge where the tests a=
re automatic and visitors never need to fill in a CAPTCHA.<br><br></div>--s=
nip--<br><br></div>This is the step we had to take today to fix this proble=
m.=C2=A0 And that did fix the problem.=C2=A0 At a cost, of course, of a jav=
ascript-and-cookie-based interstitial page - hardly a permanent fix.=C2=A0 =
<br><br></div>In other words, Cloudflare did *not* automatically stop this =
attack.=C2=A0 We still had to suffer it, detect it, and take client action =
in order to mitigate this attack.=C2=A0 <br><br></div>And now we have to do=
 a bit more:=C2=A0 Although we were never told about this, and the sales pa=
ges don&#39;t mention it, we find via email support that there is an Apache=
 module we need to install to find out where the attack is actually coming =
from, and thereby mitigate it.=C2=A0=C2=A0=C2=A0 So, for your info, our nex=
t steps are:<br><br></div><div>1. Install the apache2 mod_cloudflare module=
 (we&#39;re doing that this evening)<br></div><div>2. Turn off the &quot;IU=
AM&quot; mode and let the attack continue (assuming it does)<br></div><div>=
3. Use the logging provided by this module to determine the source of the a=
ttack.<br></div><div>4. Insert that information back into the Cloudflare co=
ntrol panel to block the IP address(es) from which the attack is originatin=
g.<br><br></div><div>We will be taking these steps as soon as possible.<br>=
<br></div><div>But I spell this out for you all because I want to make clea=
r that, while for $200 I might not expect 24/7 phone support, for $200 I ce=
rtainly expect some kind of web interface that lets me directly determine w=
here an attack is coming from (we don&#39;t get that with Cloudflare, we ha=
ve to let the attack bleed through and figure it out with this add-on Apach=
e module).=C2=A0 And I would certainly prefer (and the site certainly impli=
es this) that Cloudflare detect *and prevent* this kind of attack before it=
 ever reaches us, as every other section of their very expansive web page i=
mplies they do automatically.<br><br></div><div>So I&#39;m not particularly=
 in the &quot;let&#39;s jump to Enterprise service&quot; because I don&#39;=
t see any evidence that it will get us anything more than we already have t=
hat is substantive.<br><br></div><div>But I do think that they have room fo=
r improvement, and so perhaps there is another way to go:=C2=A0 Perhaps som=
eone in an IETF leadership role might want to reach out to Cloudflare with =
these concerns, and see if Cloudflare has an answer, or perhaps a plan?=C2=
=A0 Perhaps the IETF could assist them with these concerns somehow?=C2=A0 I=
t might be to everyone&#39;s benefit.<br><br>And, on that same note, I&#39;=
ve also observed that many companies are willing to donate services and pro=
ducts to the IETF.=C2=A0 Maybe Cloudflare would like to be generous as well=
?=C2=A0 Could be worth asking that question.<br><br></div><div>At any rate,=
 to conclude, we are following the steps given by Cloudflare, and we will w=
ork to get this resolved as soon as possible given the level of support (em=
ail) and list of steps (webserver modification) we&#39;ve been given... but=
, to my surprise, the token is AMS&#39; at this point, and not Cloudflare&#=
39;s... which is not what I think any of us would have suspected given what=
 we thought Cloudflare was offering.<br><br></div><div>Please let me know i=
f you have any questions, and, again, I apologize for the disruption, and t=
he learning curve, as we discover more about Cloudflare&#39;s services and =
options.<br><br></div><div>Glen<br></div><div>Glen Barney<br></div><div>IT =
Director<br></div><div>AMS (IETF Secretariat)<br><br></div></div>

--bcaec51d2b80e64b8d051c70dbd5--


From nobody Mon Aug  3 17:19:09 2015
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4591B2A15; Mon,  3 Aug 2015 17:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVlNFfuDHNE2; Mon,  3 Aug 2015 17:19:03 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 D188C1B2A13; Mon,  3 Aug 2015 17:19:02 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so155734018wib.1; Mon, 03 Aug 2015 17:19:01 -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-type; bh=0AGU2JhhSRiIpshdHsEmezZ4OsZmiZ1hXU/Zav7XRpc=; b=gLXtG4tJ3LjbwHkEEPyG/hNrViycseXE61UK300GdGKA6l90eH05ACzRM2OQ52JuWX FvwEq1ywZ7+ZJT4aTvvuBpftSsRVbFoemooAZIBMHuS6HPtuB5i/8RAypOwh1caR07OR mAdKfzXwSQSCJflwg/62ldnyiCCodDATUfcH5XobfDH4IdoVAVbN5UsmpLYu70GxM6e/ YAtvz89vvVJqMrRbM2eU6r0nvXJ6Nbj3SdHIoNGmaftLRDhF0knSaM6r3jalmTNtCLa4 we57NebTMilcpZzpWIr1t8Eq0f6SYJPyseaQcpDheY3T/2sC/msVHocK/mDa1OCilCIr FmBw==
MIME-Version: 1.0
X-Received: by 10.180.82.230 with SMTP id l6mr37059964wiy.61.1438647541654; Mon, 03 Aug 2015 17:19:01 -0700 (PDT)
Received: by 10.28.0.67 with HTTP; Mon, 3 Aug 2015 17:19:01 -0700 (PDT)
In-Reply-To: <CABL0ig6ax-qQ9fT1czs6E32Tpd1BeONG-G5k6i+TLfTvHo8ypg@mail.gmail.com>
References: <CABL0ig6ax-qQ9fT1czs6E32Tpd1BeONG-G5k6i+TLfTvHo8ypg@mail.gmail.com>
Date: Mon, 3 Aug 2015 20:19:01 -0400
Message-ID: <CAHbuEH75wEAVSp+8dCVPtkG9poMny_J23_g9DJLXxOAF8W5+ww@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: glen@amsl.com
Content-Type: multipart/alternative; boundary=f46d04440408ad6ab7051c713be8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/O4_hweqtKPgZSjIjPIZrKE813UI>
Cc: IAOC IAOC <iaoc@ietf.org>, IAB <iab@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Leadership Update Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 00:19:06 -0000

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

Hi Glen,

Thank you for sharing the details of this, I do have one thought...

On Mon, Aug 3, 2015 at 7:51 PM, Glen <glen@amsl.com> wrote:

> I'm now narrowing the distribution of this discussion a little bit, to the
> IETF leadership, as shown in the headers.
>
> Here is where we stand at the moment.
>
> First, as to the all-important question about "reaching a human."  It
> turns out that Cloudflare does not provide human phone support.  We are on
> the "Business Plan" at $200/month, which, if you look here,
> https://www.cloudflare.com/plans , conspicuously does *not* include 24/7
> phone support.
>
> And before we run off and determine that we should immediately "upgrade to
> the Enterprise plan", I'd like to call out a few other things.
>
> The plan we *are* on includes what they call "Advanced DDoS mitigation".
> As outlined here, https://www.cloudflare.com/ddos , Cloudflare is
> *supposed* to *protect* us from DDoS attacks of the type we encountered
> today.  But if we read the fine print, that turns out to not always be the
> case...
>
> --snip--
>
> Layer 7 attacks
>
> A new breed of attacks target Layer 7 of the OSI model, the "application"
> layer. These attacks focus on specific characteristics of web applications
> that create bottlenecks. For example, the so-called Slow Read attack sends
> packets slowly across multiple connections. Because Apache opens a new
> thread for each connection, and since connections are maintained as long as
> there is traffic being sent, an attacker can overwhelm a web server by
> exhausting its thread pool relatively quickly.
>
> CloudFlare has protections in place against many of these attacks, and in
> real world experiences we generally reduce HTTP attack traffic by 90%. For
> most attacks, and for most of our customers, this is enough to keep them
> online. However, the 10% of traffic that does get through traditional
> protections can still be overwhelming to customers with limited resources
> or in the face of very large attacks. In this case, CloudFlare offers a
> security setting called "I'm Under Attack" mode (IUAM).
>
> IUAM is a security level you can set for your site when you're under
> attack. When IUAM is turned on, CloudFlare will add an additional layer of
> protections to stop malicious HTTP traffic from being passed to your
> server. While a number of additional checks are performed in the
> background, an interstitial page is presented to your site's visitors for 5
> seconds while the checks are completed. Think of it as a challenge where
> the tests are automatic and visitors never need to fill in a CAPTCHA.
>
> --snip--
>
> This is the step we had to take today to fix this problem.  And that did
> fix the problem.  At a cost, of course, of a javascript-and-cookie-based
> interstitial page - hardly a permanent fix.
>
> In other words, Cloudflare did *not* automatically stop this attack.  We
> still had to suffer it, detect it, and take client action in order to
> mitigate this attack.
>
> And now we have to do a bit more:  Although we were never told about this,
> and the sales pages don't mention it, we find via email support that there
> is an Apache module we need to install to find out where the attack is
> actually coming from, and thereby mitigate it.    So, for your info, our
> next steps are:
>
> 1. Install the apache2 mod_cloudflare module (we're doing that this
> evening)
> 2. Turn off the "IUAM" mode and let the attack continue (assuming it does)
> 3. Use the logging provided by this module to determine the source of the
> attack.
> 4. Insert that information back into the Cloudflare control panel to block
> the IP address(es) from which the attack is originating.
>
> We will be taking these steps as soon as possible.
>
> But I spell this out for you all because I want to make clear that, while
> for $200 I might not expect 24/7 phone support, for $200 I certainly expect
> some kind of web interface that lets me directly determine where an attack
> is coming from (we don't get that with Cloudflare, we have to let the
> attack bleed through and figure it out with this add-on Apache module).
> And I would certainly prefer (and the site certainly implies this) that
> Cloudflare detect *and prevent* this kind of attack before it ever reaches
> us, as every other section of their very expansive web page implies they do
> automatically.
>
> So I'm not particularly in the "let's jump to Enterprise service" because
> I don't see any evidence that it will get us anything more than we already
> have that is substantive.
>
> But I do think that they have room for improvement, and so perhaps there
> is another way to go:  Perhaps someone in an IETF leadership role might
> want to reach out to Cloudflare with these concerns, and see if Cloudflare
> has an answer, or perhaps a plan?  Perhaps the IETF could assist them with
> these concerns somehow?  It might be to everyone's benefit.
>

We just approved the DDoS Open Threat Signaling (DOTS) working group.  The
WG participants include a bunch of DDoS experts from providers and
vendors.  It might be helpful to get their advice on this attack type.
Additionally, it may also be useful for them to have the real world use
case for their use case document.  CloudFlare does participate in the WG,
so timing might be important to first give them an opportunity to respond
during normal business hours or to see if this attack type could use more
eyes from other experts.  The write up might have to be altered a bit to be
used in a draft as a use case.

Thanks,
Kathleen


> And, on that same note, I've also observed that many companies are willing
> to donate services and products to the IETF.  Maybe Cloudflare would like
> to be generous as well?  Could be worth asking that question.
>
> At any rate, to conclude, we are following the steps given by Cloudflare,
> and we will work to get this resolved as soon as possible given the level
> of support (email) and list of steps (webserver modification) we've been
> given... but, to my surprise, the token is AMS' at this point, and not
> Cloudflare's... which is not what I think any of us would have suspected
> given what we thought Cloudflare was offering.
>
> Please let me know if you have any questions, and, again, I apologize for
> the disruption, and the learning curve, as we discover more about
> Cloudflare's services and options.
>
> Glen
> Glen Barney
> IT Director
> AMS (IETF Secretariat)
>
>


-- 

Best regards,
Kathleen

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

<div dir=3D"ltr">Hi Glen,<div><br></div><div>Thank you for sharing the deta=
ils of this, I do have one thought...</div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Mon, Aug 3, 2015 at 7:51 PM, Glen <span dir=3D=
"ltr">&lt;<a href=3D"mailto:glen@amsl.com" target=3D"_blank">glen@amsl.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><div><div><div><div><div><div><div><div><div>I&#39;m now narrowing the d=
istribution of this discussion a little bit, to the IETF leadership, as sho=
wn in the headers.<br><br></div>Here is where we stand at the moment.<br><b=
r></div>First, as to the all-important question about &quot;reaching a huma=
n.&quot;=C2=A0 It turns out that Cloudflare does not provide human phone su=
pport.=C2=A0 We are on the &quot;Business Plan&quot; at $200/month, which, =
if you look here, <a href=3D"https://www.cloudflare.com/plans" target=3D"_b=
lank">https://www.cloudflare.com/plans</a> , conspicuously does *not* inclu=
de 24/7 phone support.=C2=A0 <br><br></div>And before we run off and determ=
ine that we should immediately &quot;upgrade to the Enterprise plan&quot;, =
I&#39;d like to call out a few other things.=C2=A0 <br><br></div>The plan w=
e *are* on includes what they call &quot;Advanced DDoS mitigation&quot;.=C2=
=A0 As outlined here, <a href=3D"https://www.cloudflare.com/ddos" target=3D=
"_blank">https://www.cloudflare.com/ddos</a> , Cloudflare is *supposed* to =
*protect* us from DDoS attacks of the type we encountered today.=C2=A0 But =
if we read the fine print, that turns out to not always be the case...<br><=
br></div>--snip--<br><br>Layer 7 attacks<br><br>A new breed of attacks targ=
et Layer 7 of the OSI model, the &quot;application&quot; layer. These attac=
ks focus on specific characteristics of web applications that create bottle=
necks. For example, the so-called Slow Read attack sends packets slowly acr=
oss multiple connections. Because Apache opens a new thread for each connec=
tion, and since connections are maintained as long as there is traffic bein=
g sent, an attacker can overwhelm a web server by exhausting its thread poo=
l relatively quickly.<br><br>CloudFlare has protections in place against ma=
ny of these attacks, and in real world experiences we generally reduce HTTP=
 attack traffic by 90%. For most attacks, and for most of our customers, th=
is is enough to keep them online. However, the 10% of traffic that does get=
 through traditional protections can still be overwhelming to customers wit=
h limited resources or in the face of very large attacks. In this case, Clo=
udFlare offers a security setting called &quot;I&#39;m Under Attack&quot; m=
ode (IUAM).<br><br>IUAM is a security level you can set for your site when =
you&#39;re under attack. When IUAM is turned on, CloudFlare will add an add=
itional layer of protections to stop malicious HTTP traffic from being pass=
ed to your server. While a number of additional checks are performed in the=
 background, an interstitial page is presented to your site&#39;s visitors =
for 5 seconds while the checks are completed. Think of it as a challenge wh=
ere the tests are automatic and visitors never need to fill in a CAPTCHA.<b=
r><br></div>--snip--<br><br></div>This is the step we had to take today to =
fix this problem.=C2=A0 And that did fix the problem.=C2=A0 At a cost, of c=
ourse, of a javascript-and-cookie-based interstitial page - hardly a perman=
ent fix.=C2=A0 <br><br></div>In other words, Cloudflare did *not* automatic=
ally stop this attack.=C2=A0 We still had to suffer it, detect it, and take=
 client action in order to mitigate this attack.=C2=A0 <br><br></div>And no=
w we have to do a bit more:=C2=A0 Although we were never told about this, a=
nd the sales pages don&#39;t mention it, we find via email support that the=
re is an Apache module we need to install to find out where the attack is a=
ctually coming from, and thereby mitigate it.=C2=A0=C2=A0=C2=A0 So, for you=
r info, our next steps are:<br><br></div><div>1. Install the apache2 mod_cl=
oudflare module (we&#39;re doing that this evening)<br></div><div>2. Turn o=
ff the &quot;IUAM&quot; mode and let the attack continue (assuming it does)=
<br></div><div>3. Use the logging provided by this module to determine the =
source of the attack.<br></div><div>4. Insert that information back into th=
e Cloudflare control panel to block the IP address(es) from which the attac=
k is originating.<br><br></div><div>We will be taking these steps as soon a=
s possible.<br><br></div><div>But I spell this out for you all because I wa=
nt to make clear that, while for $200 I might not expect 24/7 phone support=
, for $200 I certainly expect some kind of web interface that lets me direc=
tly determine where an attack is coming from (we don&#39;t get that with Cl=
oudflare, we have to let the attack bleed through and figure it out with th=
is add-on Apache module).=C2=A0 And I would certainly prefer (and the site =
certainly implies this) that Cloudflare detect *and prevent* this kind of a=
ttack before it ever reaches us, as every other section of their very expan=
sive web page implies they do automatically.<br><br></div><div>So I&#39;m n=
ot particularly in the &quot;let&#39;s jump to Enterprise service&quot; bec=
ause I don&#39;t see any evidence that it will get us anything more than we=
 already have that is substantive.<br><br></div><div>But I do think that th=
ey have room for improvement, and so perhaps there is another way to go:=C2=
=A0 Perhaps someone in an IETF leadership role might want to reach out to C=
loudflare with these concerns, and see if Cloudflare has an answer, or perh=
aps a plan?=C2=A0 Perhaps the IETF could assist them with these concerns so=
mehow?=C2=A0 It might be to everyone&#39;s benefit.<br></div></div></blockq=
uote><div><br></div><div>We just approved the DDoS Open Threat Signaling (D=
OTS) working group.=C2=A0 The WG participants include a bunch of DDoS exper=
ts from providers and vendors.=C2=A0 It might be helpful to get their advic=
e on this attack type.=C2=A0 Additionally, it may also be useful for them t=
o have the real world use case for their use case document.=C2=A0 CloudFlar=
e does participate in the WG, so timing might be important to first give th=
em an opportunity to respond during normal business hours or to see if this=
 attack type could use more eyes from other experts.=C2=A0 The write up mig=
ht have to be altered a bit to be used in a draft as a use case.</div><div>=
<br></div><div>Thanks,</div><div>Kathleen</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br>And, on that same note, I&#39;v=
e also observed that many companies are willing to donate services and prod=
ucts to the IETF.=C2=A0 Maybe Cloudflare would like to be generous as well?=
=C2=A0 Could be worth asking that question.<br><br></div><div>At any rate, =
to conclude, we are following the steps given by Cloudflare, and we will wo=
rk to get this resolved as soon as possible given the level of support (ema=
il) and list of steps (webserver modification) we&#39;ve been given... but,=
 to my surprise, the token is AMS&#39; at this point, and not Cloudflare&#3=
9;s... which is not what I think any of us would have suspected given what =
we thought Cloudflare was offering.<br><br></div><div>Please let me know if=
 you have any questions, and, again, I apologize for the disruption, and th=
e learning curve, as we discover more about Cloudflare&#39;s services and o=
ptions.<br><br></div><div>Glen<br></div><div>Glen Barney<br></div><div>IT D=
irector<br></div><div>AMS (IETF Secretariat)<br><br></div></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><br><div>Best regards,</div><div>Kath=
leen</div></div></div>
</div></div>

--f46d04440408ad6ab7051c713be8--


From nobody Mon Aug  3 17:50:36 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B221B3257; Mon,  3 Aug 2015 17:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.288
X-Spam-Level: 
X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 GVgg0P5padCk; Mon,  3 Aug 2015 17:50:29 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE31B3253; Mon,  3 Aug 2015 17:50:29 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id DD03C1E59E4; Mon,  3 Aug 2015 17:50:23 -0700 (PDT)
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by c8a.amsl.com (Postfix) with ESMTPSA id ACCC71E59E6; Mon,  3 Aug 2015 17:50:23 -0700 (PDT)
Received: by vkhg129 with SMTP id g129so48791842vkh.2; Mon, 03 Aug 2015 17:50:28 -0700 (PDT)
X-Received: by 10.52.112.67 with SMTP id io3mr1326153vdb.58.1438649428178; Mon, 03 Aug 2015 17:50:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Mon, 3 Aug 2015 17:50:08 -0700 (PDT)
In-Reply-To: <CAHbuEH75wEAVSp+8dCVPtkG9poMny_J23_g9DJLXxOAF8W5+ww@mail.gmail.com>
References: <CABL0ig6ax-qQ9fT1czs6E32Tpd1BeONG-G5k6i+TLfTvHo8ypg@mail.gmail.com> <CAHbuEH75wEAVSp+8dCVPtkG9poMny_J23_g9DJLXxOAF8W5+ww@mail.gmail.com>
From: Glen <glen@amsl.com>
Date: Mon, 3 Aug 2015 17:50:08 -0700
Message-ID: <CABL0ig7BjipGO6zGFNb67595c93u9jjBmfAtZc7eT4fy0d83Rg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec548a9111f7f4b051c71acf2
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/6BzE7r9mASf6YCXFlS6eDEWJ2RI>
Cc: IAOC IAOC <iaoc@ietf.org>, IAB <iab@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Leadership Update Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 00:50:30 -0000

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

On Mon, Aug 3, 2015 at 5:19 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:
> Hi Glen,
> Thank you for sharing the details of this, I do have one thought...
> We just approved the DDoS Open Threat Signaling (DOTS) working group.
The WG participants include a bunch of DDoS experts from providers and
vendors.  It might be helpful to get their advice on this attack type.
Additionally, it may also be useful for them to have the real world use
case for their use case document.  CloudFlare does participate in the WG,
so timing might be important to first give them an opportunity to respond
during normal business hours or to see if this attack type could use more
eyes from other experts.  The write up might have to be altered a bit to be
used in a draft as a use case.
> Thanks,
> Kathleen

Hi Kathleen!

Absolutely agreed.

This particular attack seems to have stopped, so I don't believe we'll have
any more follow-up from Cloudflare this time.

Feel free to use or modify all, some or none of my email if you want to
approach Cloudflare or the WG with this.

If you want me to take any specific action with respect to the WG, or
Cloudflare's interaction thereon, please let me know at any time!

Thanks,
Glen

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

<div dir=3D"ltr"><div><div><div><div><div><div>On Mon, Aug 3, 2015 at 5:19 =
PM, Kathleen Moriarty &lt;<a href=3D"mailto:kathleen.moriarty.ietf@gmail.co=
m">kathleen.moriarty.ietf@gmail.com</a>&gt; wrote:<br>&gt; Hi Glen,<br>&gt;=
 Thank you for sharing the details of this, I do have one thought...<br>&gt=
; We just approved the DDoS Open Threat Signaling (DOTS) working group.=C2=
=A0 The WG participants include a bunch of DDoS experts from providers and =
vendors.=C2=A0 It might be helpful to get their advice on this attack type.=
=C2=A0 Additionally, it may also be useful for them to have the real world =
use case for their use case document.=C2=A0 CloudFlare does participate in =
the WG, so timing might be important to first give them an opportunity to r=
espond during normal business hours or to see if this attack type could use=
 more eyes from other experts.=C2=A0 The write up might have to be altered =
a bit to be used in a draft as a use case.<br>&gt; Thanks,<br>&gt; Kathleen=
<br><br></div>Hi Kathleen!<br><br></div>Absolutely agreed.=C2=A0 <br><br>Th=
is particular attack seems to have stopped, so I don&#39;t believe we&#39;l=
l have any more follow-up from Cloudflare this time.<br><br></div>Feel free=
 to use or modify all, some or none of my email if you want to approach Clo=
udflare or the WG with this.<br><br></div>If you want me to take any specif=
ic action with respect to the WG, or Cloudflare&#39;s interaction thereon, =
please let me know at any time!<br><br></div>Thanks,<br></div>Glen<br><br><=
/div>

--bcaec548a9111f7f4b051c71acf2--


From nobody Mon Aug  3 18:06:54 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E731B3294 for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 18:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.689
X-Spam-Level: 
X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqBfCUvkfN-U for <tools-development@ietfa.amsl.com>; Mon,  3 Aug 2015 18:04:10 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 98AD41B3288 for <tools-development@ietf.org>; Mon,  3 Aug 2015 18:04:10 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 342CF1E59C2 for <tools-development@ietf.org>; Mon,  3 Aug 2015 18:04:05 -0700 (PDT)
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by c8a.amsl.com (Postfix) with ESMTPSA id 037041E59DE for <tools-development@ietf.org>; Mon,  3 Aug 2015 18:04:05 -0700 (PDT)
Received: by vkci6 with SMTP id i6so50116745vkc.3 for <tools-development@ietf.org>; Mon, 03 Aug 2015 18:04:09 -0700 (PDT)
X-Received: by 10.52.109.230 with SMTP id hv6mr1353821vdb.43.1438650249649; Mon, 03 Aug 2015 18:04:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Mon, 3 Aug 2015 18:03:50 -0700 (PDT)
From: Glen <glen@amsl.com>
Date: Mon, 3 Aug 2015 18:03:50 -0700
Message-ID: <CABL0ig4oX-6sGs-bXO8dBdzz234APB9e+x0MDMfZT+4i0SZHLw@mail.gmail.com>
To: Glen Barney <glen@amsl.com>
Content-Type: multipart/alternative; boundary=bcaec548617c1623c6051c71ddbb
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/odmhhWBh8vtfBJBvK7zipFI_NoU>
X-Mailman-Approved-At: Mon, 03 Aug 2015 18:06:48 -0700
Subject: [TOOLS-DEVELOPMENT] Resolution Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 01:04:12 -0000

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

All -

I'm pleased to report that the earlier degradation of the IETF websites
which we were experiencing has been resolved.

We were able to make contact with Cloudflare.  They provided us with
several steps to take to manage the attack.  We followed their suggestions,
and have been able to restore fully normal service to the IETF websites,
and servers.

We'll be doing follow-up with Cloudflare, through the IETF leadership
teams, to determine what changes we might want to make to help prevent this
type of thing from happening again.  Indeed, even the steps they provided
this time will already help us respond more quickly to similar events in
the future.

Thank you all for your patience during this time, and thank you to those of
you who got in touch with me privately to offer specific insights as to the
handling of this event.  I appreciate all of the support I received from
the community, even as we here at AMS work to support you all!

Have a great night/day, and thanks again for your patience with this
incident.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div>All -<br><br>=
</div>I&#39;m pleased to report that the earlier degradation of the IETF we=
bsites which we were experiencing has been resolved.<br><br></div>We were a=
ble to make contact with Cloudflare.=C2=A0 They provided us with several st=
eps to take to manage the attack.=C2=A0 We followed their suggestions, and =
have been able to restore fully normal service to the IETF websites, and se=
rvers.<br><br></div>We&#39;ll be doing follow-up with Cloudflare, through t=
he IETF leadership teams, to determine what changes we might want to make t=
o help prevent this type of thing from happening again.=C2=A0 Indeed, even =
the steps they provided this time will already help us respond more quickly=
 to similar events in the future.<br><br></div>Thank you all for your patie=
nce during this time, and thank you to those of you who got in touch with m=
e privately to offer specific insights as to the handling of this event.=C2=
=A0 I appreciate all of the support I received from the community, even as =
we here at AMS work to support you all!<br><br></div>Have a great night/day=
, and thanks again for your patience with this incident.<br><br></div>Glen<=
br></div>Glen Barney<br></div>IT Director<br></div>AMS (IETF Secretariat)<b=
r><br></div>

--bcaec548617c1623c6051c71ddbb--


From nobody Tue Aug  4 08:00:46 2015
Return-Path: <glen@amsl.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933E71A00F0; Tue,  4 Aug 2015 08:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.287
X-Spam-Level: 
X-Spam-Status: No, score=-101.287 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 Bm4PwGKQxKE7; Tue,  4 Aug 2015 08:00:35 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 67BFA1A0125; Tue,  4 Aug 2015 08:00:35 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B221A1E59DE; Tue,  4 Aug 2015 08:00:27 -0700 (PDT)
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by c8a.amsl.com (Postfix) with ESMTPSA id 685BC1E59E4; Tue,  4 Aug 2015 08:00:27 -0700 (PDT)
Received: by vkhg129 with SMTP id g129so4537826vkh.2; Tue, 04 Aug 2015 08:00:34 -0700 (PDT)
X-Received: by 10.52.112.67 with SMTP id io3mr5522024vdb.58.1438700434249; Tue, 04 Aug 2015 08:00:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.74.7 with HTTP; Tue, 4 Aug 2015 08:00:14 -0700 (PDT)
In-Reply-To: <55C055E7.1030200@gondrom.org>
References: <CABL0ig6ax-qQ9fT1czs6E32Tpd1BeONG-G5k6i+TLfTvHo8ypg@mail.gmail.com> <CAHbuEH75wEAVSp+8dCVPtkG9poMny_J23_g9DJLXxOAF8W5+ww@mail.gmail.com> <55C055E7.1030200@gondrom.org>
From: Glen <glen@amsl.com>
Date: Tue, 4 Aug 2015 08:00:14 -0700
Message-ID: <CABL0ig4swk5mc-kZwg8kSO6cwPYE06+Vb1Wb_Wu7KEtPM2j2Dg@mail.gmail.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: multipart/alternative; boundary=bcaec548a911526029051c7d8c9a
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/K0ZPtJAl_wmrRg1mPb5_N6nBQtc>
Cc: IAOC IAOC <iaoc@ietf.org>, IAB <iab@ietf.org>, iesg@ietf.org, IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] [IAOC] Leadership Update Re: IETF Website Degradation
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: glen@amsl.com
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 15:00:38 -0000

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

Hi Tobias -

It's certainly fine with AMS if you share this information with a larger
audience!  In essence this information "belongs" to the IETF, so we would
not take exception to that!

Best regards,
Glen
Glen Barney
IT Director
AMS (IETF Secretariat)


On Mon, Aug 3, 2015 at 11:04 PM, Tobias Gondrom <tobias.gondrom@gondrom.org>
wrote:

> Hi Glen and Kathleen,
>
> a good idea.
> This might indeed be a good source of expertise.
>
> As I currently consider the received information "internal", I will wait
> for an "ok" from amsl and IAD before sharing this information with the
> community in DOTS.
>
> A more detailed write-up, e.g. incl. traffic amounts and any specifics
> might also be helpful to minimise question-roundtrips.
>
> Best regards,
>
> Tobias
> (IAOC chair)
> (and coincidentally DOTS co-chair)
>
>
> On 04/08/15 08:19, Kathleen Moriarty wrote:
>
> Hi Glen,
>
> Thank you for sharing the details of this, I do have one thought...
>
> On Mon, Aug 3, 2015 at 7:51 PM, Glen <glen@amsl.com> wrote:
>
>> I'm now narrowing the distribution of this discussion a little bit, to
>> the IETF leadership, as shown in the headers.
>>
>> Here is where we stand at the moment.
>>
>> First, as to the all-important question about "reaching a human."  It
>> turns out that Cloudflare does not provide human phone support.  We are on
>> the "Business Plan" at $200/month, which, if you look here,
>> https://www.cloudflare.com/plans , conspicuously does *not* include 24/7
>> phone support.
>>
>> And before we run off and determine that we should immediately "upgrade
>> to the Enterprise plan", I'd like to call out a few other things.
>>
>> The plan we *are* on includes what they call "Advanced DDoS mitigation".
>> As outlined here, https://www.cloudflare.com/ddos , Cloudflare is
>> *supposed* to *protect* us from DDoS attacks of the type we encountered
>> today.  But if we read the fine print, that turns out to not always be the
>> case...
>>
>> --snip--
>>
>> Layer 7 attacks
>>
>> A new breed of attacks target Layer 7 of the OSI model, the "application"
>> layer. These attacks focus on specific characteristics of web applications
>> that create bottlenecks. For example, the so-called Slow Read attack sends
>> packets slowly across multiple connections. Because Apache opens a new
>> thread for each connection, and since connections are maintained as long as
>> there is traffic being sent, an attacker can overwhelm a web server by
>> exhausting its thread pool relatively quickly.
>>
>> CloudFlare has protections in place against many of these attacks, and in
>> real world experiences we generally reduce HTTP attack traffic by 90%. For
>> most attacks, and for most of our customers, this is enough to keep them
>> online. However, the 10% of traffic that does get through traditional
>> protections can still be overwhelming to customers with limited resources
>> or in the face of very large attacks. In this case, CloudFlare offers a
>> security setting called "I'm Under Attack" mode (IUAM).
>>
>> IUAM is a security level you can set for your site when you're under
>> attack. When IUAM is turned on, CloudFlare will add an additional layer of
>> protections to stop malicious HTTP traffic from being passed to your
>> server. While a number of additional checks are performed in the
>> background, an interstitial page is presented to your site's visitors for 5
>> seconds while the checks are completed. Think of it as a challenge where
>> the tests are automatic and visitors never need to fill in a CAPTCHA.
>>
>> --snip--
>>
>> This is the step we had to take today to fix this problem.  And that did
>> fix the problem.  At a cost, of course, of a javascript-and-cookie-based
>> interstitial page - hardly a permanent fix.
>>
>> In other words, Cloudflare did *not* automatically stop this attack.  We
>> still had to suffer it, detect it, and take client action in order to
>> mitigate this attack.
>>
>> And now we have to do a bit more:  Although we were never told about
>> this, and the sales pages don't mention it, we find via email support that
>> there is an Apache module we need to install to find out where the attack
>> is actually coming from, and thereby mitigate it.    So, for your info, our
>> next steps are:
>>
>> 1. Install the apache2 mod_cloudflare module (we're doing that this
>> evening)
>> 2. Turn off the "IUAM" mode and let the attack continue (assuming it does)
>> 3. Use the logging provided by this module to determine the source of the
>> attack.
>> 4. Insert that information back into the Cloudflare control panel to
>> block the IP address(es) from which the attack is originating.
>>
>> We will be taking these steps as soon as possible.
>>
>> But I spell this out for you all because I want to make clear that, while
>> for $200 I might not expect 24/7 phone support, for $200 I certainly expect
>> some kind of web interface that lets me directly determine where an attack
>> is coming from (we don't get that with Cloudflare, we have to let the
>> attack bleed through and figure it out with this add-on Apache module).
>> And I would certainly prefer (and the site certainly implies this) that
>> Cloudflare detect *and prevent* this kind of attack before it ever reaches
>> us, as every other section of their very expansive web page implies they do
>> automatically.
>>
>> So I'm not particularly in the "let's jump to Enterprise service" because
>> I don't see any evidence that it will get us anything more than we already
>> have that is substantive.
>>
>> But I do think that they have room for improvement, and so perhaps there
>> is another way to go:  Perhaps someone in an IETF leadership role might
>> want to reach out to Cloudflare with these concerns, and see if Cloudflare
>> has an answer, or perhaps a plan?  Perhaps the IETF could assist them with
>> these concerns somehow?  It might be to everyone's benefit.
>>
>
> We just approved the DDoS Open Threat Signaling (DOTS) working group.  The
> WG participants include a bunch of DDoS experts from providers and
> vendors.  It might be helpful to get their advice on this attack type.
> Additionally, it may also be useful for them to have the real world use
> case for their use case document.  CloudFlare does participate in the WG,
> so timing might be important to first give them an opportunity to respond
> during normal business hours or to see if this attack type could use more
> eyes from other experts.  The write up might have to be altered a bit to be
> used in a draft as a use case.
>
> Thanks,
> Kathleen
>
>
>> And, on that same note, I've also observed that many companies are
>> willing to donate services and products to the IETF.  Maybe Cloudflare
>> would like to be generous as well?  Could be worth asking that question.
>>
>> At any rate, to conclude, we are following the steps given by Cloudflare,
>> and we will work to get this resolved as soon as possible given the level
>> of support (email) and list of steps (webserver modification) we've been
>> given... but, to my surprise, the token is AMS' at this point, and not
>> Cloudflare's... which is not what I think any of us would have suspected
>> given what we thought Cloudflare was offering.
>>
>> Please let me know if you have any questions, and, again, I apologize for
>> the disruption, and the learning curve, as we discover more about
>> Cloudflare's services and options.
>>
>> Glen
>> Glen Barney
>> IT Director
>> AMS (IETF Secretariat)
>>
>>
>
>
> --
>
> Best regards,
> Kathleen
>
>
>

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

<div dir=3D"ltr"><div><div><div><div><div><div>Hi Tobias -<br><br></div>It&=
#39;s certainly fine with AMS if you share this information with a larger a=
udience!=C2=A0 In essence this information &quot;belongs&quot; to the IETF,=
 so we would not take exception to that!<br><br></div>Best regards,<br></di=
v>Glen<br></div>Glen Barney<br></div>IT Director<br></div>AMS (IETF Secreta=
riat)<br><div><div><div><br></div></div></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Mon, Aug 3, 2015 at 11:04 PM, Tobias =
Gondrom <span dir=3D"ltr">&lt;<a href=3D"mailto:tobias.gondrom@gondrom.org"=
 target=3D"_blank">tobias.gondrom@gondrom.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <font face=3D"Arial">Hi Glen and Kathleen, <br>
      <br>
      a good idea. <br>
      This might indeed be a good source of expertise. <br>
      <br>
      As I currently consider the received information &quot;internal&quot;=
, I
      will wait for an &quot;ok&quot; from amsl and IAD before sharing this=
 information
      with the community in DOTS. <br>
      <br>
      A more detailed write-up, e.g. incl. traffic amounts and any
      specifics might also be helpful to minimise question-roundtrips. <br>
      <br>
      Best regards, <br>
      <br>
      Tobias<br>
      (IAOC chair)<br>
      (and coincidentally DOTS co-chair)<br>
      <br>
    </font><br>
    <div>On 04/08/15 08:19, Kathleen Moriarty
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">Hi Glen,
        <div><br>
        </div>
        <div>Thank you for sharing the details of this, I do have one
          thought...</div>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Mon, Aug 3, 2015 at 7:51 PM, Glen
            <span dir=3D"ltr">&lt;<a href=3D"mailto:glen@amsl.com" target=
=3D"_blank">glen@amsl.com</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>
                            <div>
                              <div>
                                <div>
                                  <div>I&#39;m now narrowing the
                                    distribution of this discussion a
                                    little bit, to the IETF leadership,
                                    as shown in the headers.<br>
                                    <br>
                                  </div>
                                  Here is where we stand at the moment.<br>
                                  <br>
                                </div>
                                First, as to the all-important question
                                about &quot;reaching a human.&quot;=C2=A0 I=
t turns out
                                that Cloudflare does not provide human
                                phone support.=C2=A0 We are on the &quot;Bu=
siness
                                Plan&quot; at $200/month, which, if you loo=
k
                                here, <a href=3D"https://www.cloudflare.com=
/plans" target=3D"_blank">https://www.cloudflare.com/plans</a>
                                , conspicuously does *not* include 24/7
                                phone support.=C2=A0 <br>
                                <br>
                              </div>
                              And before we run off and determine that
                              we should immediately &quot;upgrade to the
                              Enterprise plan&quot;, I&#39;d like to call o=
ut a
                              few other things.=C2=A0 <br>
                              <br>
                            </div>
                            The plan we *are* on includes what they call
                            &quot;Advanced DDoS mitigation&quot;.=C2=A0 As =
outlined
                            here, <a href=3D"https://www.cloudflare.com/ddo=
s" target=3D"_blank">https://www.cloudflare.com/ddos</a>
                            , Cloudflare is *supposed* to *protect* us
                            from DDoS attacks of the type we encountered
                            today.=C2=A0 But if we read the fine print, tha=
t
                            turns out to not always be the case...<br>
                            <br>
                          </div>
                          --snip--<br>
                          <br>
                          Layer 7 attacks<br>
                          <br>
                          A new breed of attacks target Layer 7 of the
                          OSI model, the &quot;application&quot; layer. The=
se
                          attacks focus on specific characteristics of
                          web applications that create bottlenecks. For
                          example, the so-called Slow Read attack sends
                          packets slowly across multiple connections.
                          Because Apache opens a new thread for each
                          connection, and since connections are
                          maintained as long as there is traffic being
                          sent, an attacker can overwhelm a web server
                          by exhausting its thread pool relatively
                          quickly.<br>
                          <br>
                          CloudFlare has protections in place against
                          many of these attacks, and in real world
                          experiences we generally reduce HTTP attack
                          traffic by 90%. For most attacks, and for most
                          of our customers, this is enough to keep them
                          online. However, the 10% of traffic that does
                          get through traditional protections can still
                          be overwhelming to customers with limited
                          resources or in the face of very large
                          attacks. In this case, CloudFlare offers a
                          security setting called &quot;I&#39;m Under Attac=
k&quot;
                          mode (IUAM).<br>
                          <br>
                          IUAM is a security level you can set for your
                          site when you&#39;re under attack. When IUAM is
                          turned on, CloudFlare will add an additional
                          layer of protections to stop malicious HTTP
                          traffic from being passed to your server.
                          While a number of additional checks are
                          performed in the background, an interstitial
                          page is presented to your site&#39;s visitors for
                          5 seconds while the checks are completed.
                          Think of it as a challenge where the tests are
                          automatic and visitors never need to fill in a
                          CAPTCHA.<br>
                          <br>
                        </div>
                        --snip--<br>
                        <br>
                      </div>
                      This is the step we had to take today to fix this
                      problem.=C2=A0 And that did fix the problem.=C2=A0 At=
 a
                      cost, of course, of a javascript-and-cookie-based
                      interstitial page - hardly a permanent fix.=C2=A0 <br=
>
                      <br>
                    </div>
                    In other words, Cloudflare did *not* automatically
                    stop this attack.=C2=A0 We still had to suffer it, dete=
ct
                    it, and take client action in order to mitigate this
                    attack.=C2=A0 <br>
                    <br>
                  </div>
                  And now we have to do a bit more:=C2=A0 Although we were
                  never told about this, and the sales pages don&#39;t
                  mention it, we find via email support that there is an
                  Apache module we need to install to find out where the
                  attack is actually coming from, and thereby mitigate
                  it.=C2=A0=C2=A0=C2=A0 So, for your info, our next steps a=
re:<br>
                  <br>
                </div>
                <div>1. Install the apache2 mod_cloudflare module (we&#39;r=
e
                  doing that this evening)<br>
                </div>
                <div>2. Turn off the &quot;IUAM&quot; mode and let the atta=
ck
                  continue (assuming it does)<br>
                </div>
                <div>3. Use the logging provided by this module to
                  determine the source of the attack.<br>
                </div>
                <div>4. Insert that information back into the Cloudflare
                  control panel to block the IP address(es) from which
                  the attack is originating.<br>
                  <br>
                </div>
                <div>We will be taking these steps as soon as possible.<br>
                  <br>
                </div>
                <div>But I spell this out for you all because I want to
                  make clear that, while for $200 I might not expect
                  24/7 phone support, for $200 I certainly expect some
                  kind of web interface that lets me directly determine
                  where an attack is coming from (we don&#39;t get that wit=
h
                  Cloudflare, we have to let the attack bleed through
                  and figure it out with this add-on Apache module).=C2=A0
                  And I would certainly prefer (and the site certainly
                  implies this) that Cloudflare detect *and prevent*
                  this kind of attack before it ever reaches us, as
                  every other section of their very expansive web page
                  implies they do automatically.<br>
                  <br>
                </div>
                <div>So I&#39;m not particularly in the &quot;let&#39;s jum=
p to
                  Enterprise service&quot; because I don&#39;t see any evid=
ence
                  that it will get us anything more than we already have
                  that is substantive.<br>
                  <br>
                </div>
                <div>But I do think that they have room for improvement,
                  and so perhaps there is another way to go:=C2=A0 Perhaps
                  someone in an IETF leadership role might want to reach
                  out to Cloudflare with these concerns, and see if
                  Cloudflare has an answer, or perhaps a plan?=C2=A0 Perhap=
s
                  the IETF could assist them with these concerns
                  somehow?=C2=A0 It might be to everyone&#39;s benefit.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>We just approved the DDoS Open Threat Signaling (DOTS)
              working group.=C2=A0 The WG participants include a bunch of
              DDoS experts from providers and vendors.=C2=A0 It might be
              helpful to get their advice on this attack type.=C2=A0
              Additionally, it may also be useful for them to have the
              real world use case for their use case document.=C2=A0
              CloudFlare does participate in the WG, so timing might be
              important to first give them an opportunity to respond
              during normal business hours or to see if this attack type
              could use more eyes from other experts.=C2=A0 The write up
              might have to be altered a bit to be used in a draft as a
              use case.</div>
            <div><br>
            </div>
            <div>Thanks,</div>
            <div>Kathleen</div>
            <div><br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div><br>
                  And, on that same note, I&#39;ve also observed that many
                  companies are willing to donate services and products
                  to the IETF.=C2=A0 Maybe Cloudflare would like to be
                  generous as well?=C2=A0 Could be worth asking that
                  question.<br>
                  <br>
                </div>
                <div>At any rate, to conclude, we are following the
                  steps given by Cloudflare, and we will work to get
                  this resolved as soon as possible given the level of
                  support (email) and list of steps (webserver
                  modification) we&#39;ve been given... but, to my surprise=
,
                  the token is AMS&#39; at this point, and not
                  Cloudflare&#39;s... which is not what I think any of us
                  would have suspected given what we thought Cloudflare
                  was offering.<br>
                  <br>
                </div>
                <div>Please let me know if you have any questions, and,
                  again, I apologize for the disruption, and the
                  learning curve, as we discover more about Cloudflare&#39;=
s
                  services and options.<br>
                  <br>
                </div>
                <div>Glen<br>
                </div>
                <div>Glen Barney<br>
                </div>
                <div>IT Director<br>
                </div>
                <div>AMS (IETF Secretariat)<br>
                  <br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
          <br clear=3D"all"><span class=3D"HOEnZb"><font color=3D"#888888">
          <div><br>
          </div>
          -- <br>
          <div>
            <div dir=3D"ltr"><br>
              <div>Best regards,</div>
              <div>Kathleen</div>
            </div>
          </div>
        </font></span></div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>

--bcaec548a911526029051c7d8c9a--


From nobody Wed Aug 12 07:39:05 2015
Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BDD1A897C for <tools-development@ietfa.amsl.com>; Wed, 12 Aug 2015 07:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp7A84pP2tgU for <tools-development@ietfa.amsl.com>; Wed, 12 Aug 2015 07:39:02 -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 0749C1A8973 for <tools-development@ietf.org>; Wed, 12 Aug 2015 07:39:01 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7CEcxhG017233 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 12 Aug 2015 09:39:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <55CB5A7F.1060009@nostrum.com>
Date: Wed, 12 Aug 2015 09:38:55 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>
References: <55A43292.8040909@nostrum.com> <8F88EBA6-2294-452D-943F-492E6887AEFD@vigilsec.com> <55A470F6.2010609@nostrum.com>
In-Reply-To: <55A470F6.2010609@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/_S08NsHwMYmkoJlwL2scYX_QTK8>
Cc: IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] interim meeting management SoW
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 14:39:03 -0000

Did anyone else have any comments on what's at 
http://www.nostrum.com/~rjsparks/interim.html/?
(I haven't made any changes yet)

RjS

On 7/13/15 9:16 PM, Robert Sparks wrote:
>
>
> On 7/13/15 5:32 PM, Russ Housley wrote:
>> I think the ics view of interim meetings should only contain upcoming 
>> meetings.
> Definitely - if the text implies reflecting things in the past, it 
> should be fixed.
>>    Cancelled and ones that already happened should not appear there.
> So cancelled things in the future are a different story. I've heard 
> from the secretariat rather strongly that it is far more confusing for 
> people (more questions get sent in) if a meeting in the future just 
> disappears as opposed to being marked cancelled.
>>
>> In terms of the meeting request user interface, wouldn't it be better 
>> to have a type that is face-to-face or virtual, and gather location 
>> information only for face-to-face meetings.
> So, we could present two different views and populate the models 
> accordingly, sure.
>
> The models we have were envisioned for meetings (mostly our main ietf 
> meetings) that have a face-to-face component (and lots of sessions).
> If the trend of many virtual meetings continues, we may want to 
> reoptimize....
>>
>> Russ
>>
>> On Jul 13, 2015, at 5:50 PM, Robert Sparks wrote:
>>
>>> I've updated http://www.nostrum.com/~rjsparks/interim.html/ with 
>>> input from the secretariat.
>>> It is sufficiently complete to warrant careful review and discussion 
>>> in Prague.
>>> Please look it over and let me know what needs to change before we 
>>> format it as an SoW and ask someone to work on it.
>>>
>>> RjS
>>>
>>> _______________________________________________
>>> TOOLS-DEVELOPMENT mailing list
>>> TOOLS-DEVELOPMENT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tools-development
>


From nobody Wed Aug 12 07:42:09 2015
Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921791A8982 for <tools-development@ietfa.amsl.com>; Wed, 12 Aug 2015 07:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgd5ZJLMIAak for <tools-development@ietfa.amsl.com>; Wed, 12 Aug 2015 07:42:05 -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 1932F1A897E for <tools-development@ietf.org>; Wed, 12 Aug 2015 07:42:05 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7CEg46E017576 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for <tools-development@ietf.org>; Wed, 12 Aug 2015 09:42:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <55CB5B37.8070802@nostrum.com>
Date: Wed, 12 Aug 2015 09:41:59 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IETF Tools Development <tools-development@ietf.org>
References: <559FEC30.9010504@nostrum.com> <55A01476.5080500@nostrum.com>
In-Reply-To: <55A01476.5080500@nostrum.com>
Content-Type: multipart/alternative; boundary="------------050601030007010609020907"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/73trkDuSq3BH-aFsQwf-8tPfGW0>
Subject: Re: [TOOLS-DEVELOPMENT] Fwd: [Tools-discuss] Raw 1st draft: SoW for improvements to the manual submission process
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 14:42:07 -0000

This is a multi-part message in MIME format.
--------------050601030007010609020907
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I don't think I've gotten any comment on this proposed SoW.
If you've given me any (especially verbally) and I've forgotten, please 
retransmit.
Otherwise, is this ready to ship?

RjS

On 7/10/15 1:52 PM, Robert Sparks wrote:
> I got bitten by a bad autocomplete again.
> This (development) is where I really meant to send this.
>
> RjS
>
>
> -------- Forwarded Message --------
> Subject: 	[Tools-discuss] Raw 1st draft: SoW for improvements to the 
> manual submission process
> Date: 	Fri, 10 Jul 2015 11:00:48 -0500
> From: 	Robert Sparks <rjsparks@nostrum.com>
> To: 	Tools Team Discussion <tools-discuss@ietf.org>
>
>
>
> The transparency of the ID submission process needs to be improved,
> particularly for those submissions that are handled directly by the
> secretariat ("manual" and "forced" submissions).
>
> When an author uses the datatracker submission tool, SubmissionEvents
> are captured, noting when the draft was submitted, when it was approved
> by previous authors (and by who), when it was approved by a WG chair if
> such approval was necessary, and when it was posted into the
> repository. Currently, the document’s history shows only that a new
> version is available.
>
> The submission tool presents an option to authors to request that the
> secretariat finish the submission process. The datatracker captures the
> candidate document and sends email to the secretariat. Often the
> request is made because the submission tool was unable to extract the
> correct meta-data from the document. In this case, the secretariat
> populates the meta-data, and forces the post. In other cases, there are
> issues identified by id-nits that the secretariat helps diagnose, and
> the author is guided through fixing the issues and restarting the
> submission process with a repaired document. Again, SubmissionEvents
> are captured as the document goes through this process, but for drafts
> that are forced, the document history does not reflect these events.
>
> The secretariat also receives requests to post a draft by direct email,
> bypassing the submission tool altogether. (Currently, the secretariat
> receives around 10 such requests each meeting cycle). The secretariat
> operates the submission tool on behalf of the author. The
> SubmissionEvents currently captured do not reflect that this was a
> manual submission request.
>
> The secretariat currently relies on a combination of RT and personal
> email archives to keep track of the outstanding manual submission
> requests.
>
> This project will make the following improvements:
>
> When a document is posted via the normal submission process, DocEvents
> reflecting the SubmissionEvents for the initial submission, the
> approval of previous authors, and the approval of a stream authority
> (such as WG chairs for a WG -00) will be added to the document. That
> is, where documents currently typically have a first history entry of
> "New version available: whatever-00", The first entries will be "New
> version submitted", "New version approved by previous author: (name)",
> "WG -00 approved by (name)", "New version available: whatever-00". The
> entries for subsequent versions are analogous.
>
> When manual submission is requested via the submission tool, and the
> document is posted by the secretariat, DocEvents reflecting that the
> manual posting was requested, any approvals obtained, and that the
> document was forced will be added to the document.  An example of the
> entries would be  "Manual submission requested by (name)", "Meta-data
> set to <metadata> by (name)", "WG -00 approved by (name)", "New version
> available: whatever -00".
>
> When manual submission is requested by direct email, the secretariat
> will have the ability to tell the tracker that the request was received
> and upload the document from the email request, but not handle the
> request immediately. After this indication, the document will be in the
> same condition as a document requesting manual submission via the
> submission tool.
>
> However the secretariat should not be forced to take that extra step if
> the request will be processed immediately. The submission tool should
> be modified to allow the secretariat to indicate they are submitting
> the document on behalf of an author at their request for manual
> submission. SubmissionEvents indicating that manual submission was
> requested will be created. Once the document is posted, DocEvents
> reflecting the history of the submission (as described for the above
> cases) will be created.
>
> A page will be created (readable by anyone) that shows the set of
> outstanding manual submission requests. Each entry will either show, or
> provide navigation to a separate page that shows, the SubmissionEvent
> history for the outstanding submission. When logged in as the
> secretariat, there will be easy navigation from each entry to the page
> that allows processing the request.
>
> Note that as of release 6.0.4, the manual submission process results in
> a DocEvent that says simple "New version available" without providing a
> link to the version that became available.  This project will ensure
> that all paths that produce a "New version available" DocEvent include
> a link to the new version in the event’s description.
>
> -- 
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org bugs athttp://tools.ietf.org/tools/ietfdb
> Please report tools.ietf.org bugs athttp://tools.ietf.org/tools/issues  or
> send email towebmaster@tools.ietf.org
>
>


--------------050601030007010609020907
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I don't think I've gotten any comment on this proposed SoW.<br>
    If you've given me any (especially verbally) and I've forgotten,
    please retransmit.<br>
    Otherwise, is this ready to ship?<br>
    <br>
    RjS<br>
    <br>
    <div class="moz-cite-prefix">On 7/10/15 1:52 PM, Robert Sparks
      wrote:<br>
    </div>
    <blockquote cite="mid:55A01476.5080500@nostrum.com" type="cite">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      I got bitten by a bad autocomplete again.<br>
      This (development) is where I really meant to send this.<br>
      <br>
      RjS<br>
      <div class="moz-forward-container"><br>
        <br>
        -------- Forwarded Message --------
        <table class="moz-email-headers-table" border="0"
          cellpadding="0" cellspacing="0">
          <tbody>
            <tr>
              <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:

              </th>
              <td>[Tools-discuss] Raw 1st draft: SoW for improvements to
                the manual submission process</td>
            </tr>
            <tr>
              <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
              </th>
              <td>Fri, 10 Jul 2015 11:00:48 -0500</td>
            </tr>
            <tr>
              <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
              </th>
              <td>Robert Sparks <a moz-do-not-send="true"
                  class="moz-txt-link-rfc2396E"
                  href="mailto:rjsparks@nostrum.com">&lt;rjsparks@nostrum.com&gt;</a></td>
            </tr>
            <tr>
              <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
              <td>Tools Team Discussion <a moz-do-not-send="true"
                  class="moz-txt-link-rfc2396E"
                  href="mailto:tools-discuss@ietf.org">&lt;tools-discuss@ietf.org&gt;</a></td>
            </tr>
          </tbody>
        </table>
        <br>
        <br>
        <pre>The transparency of the ID submission process needs to be improved,
particularly for those submissions that are handled directly by the
secretariat ("manual" and "forced" submissions).

When an author uses the datatracker submission tool, SubmissionEvents
are captured, noting when the draft was submitted, when it was approved
by previous authors (and by who), when it was approved by a WG chair if
such approval was necessary, and when it was posted into the
repository. Currently, the document’s history shows only that a new
version is available.

The submission tool presents an option to authors to request that the
secretariat finish the submission process. The datatracker captures the
candidate document and sends email to the secretariat. Often the
request is made because the submission tool was unable to extract the
correct meta-data from the document. In this case, the secretariat
populates the meta-data, and forces the post. In other cases, there are
issues identified by id-nits that the secretariat helps diagnose, and
the author is guided through fixing the issues and restarting the
submission process with a repaired document. Again, SubmissionEvents
are captured as the document goes through this process, but for drafts
that are forced, the document history does not reflect these events.

The secretariat also receives requests to post a draft by direct email,
bypassing the submission tool altogether. (Currently, the secretariat
receives around 10 such requests each meeting cycle). The secretariat
operates the submission tool on behalf of the author. The
SubmissionEvents currently captured do not reflect that this was a
manual submission request.

The secretariat currently relies on a combination of RT and personal
email archives to keep track of the outstanding manual submission
requests.

This project will make the following improvements:

When a document is posted via the normal submission process, DocEvents
reflecting the SubmissionEvents for the initial submission, the
approval of previous authors, and the approval of a stream authority
(such as WG chairs for a WG -00) will be added to the document. That
is, where documents currently typically have a first history entry of
"New version available: whatever-00", The first entries will be "New
version submitted", "New version approved by previous author: (name)",
"WG -00 approved by (name)", "New version available: whatever-00". The
entries for subsequent versions are analogous.

When manual submission is requested via the submission tool, and the
document is posted by the secretariat, DocEvents reflecting that the
manual posting was requested, any approvals obtained, and that the
document was forced will be added to the document.  An example of the
entries would be  "Manual submission requested by (name)", "Meta-data
set to &lt;metadata&gt; by (name)", "WG -00 approved by (name)", "New version
available: whatever -00".

When manual submission is requested by direct email, the secretariat
will have the ability to tell the tracker that the request was received
and upload the document from the email request, but not handle the
request immediately. After this indication, the document will be in the
same condition as a document requesting manual submission via the
submission tool.

However the secretariat should not be forced to take that extra step if
the request will be processed immediately. The submission tool should
be modified to allow the secretariat to indicate they are submitting
the document on behalf of an author at their request for manual
submission. SubmissionEvents indicating that manual submission was
requested will be created. Once the document is posted, DocEvents
reflecting the history of the submission (as described for the above
cases) will be created.

A page will be created (readable by anyone) that shows the set of
outstanding manual submission requests. Each entry will either show, or
provide navigation to a separate page that shows, the SubmissionEvent
history for the outstanding submission. When logged in as the
secretariat, there will be easy navigation from each entry to the page
that allows processing the request.

Note that as of release 6.0.4, the manual submission process results in
a DocEvent that says simple "New version available" without providing a
link to the version that became available.  This project will ensure
that all paths that produce a "New version available" DocEvent include
a link to the new version in the event’s description.

-- 
Tools-discuss mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tools-discuss@ietf.org">Tools-discuss@ietf.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/tools-discuss">https://www.ietf.org/mailman/listinfo/tools-discuss</a>

Please report datatracker.ietf.org bugs at <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://tools.ietf.org/tools/ietfdb">http://tools.ietf.org/tools/ietfdb</a>
Please report tools.ietf.org bugs at <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://tools.ietf.org/tools/issues">http://tools.ietf.org/tools/issues</a> or
send email to <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:webmaster@tools.ietf.org">webmaster@tools.ietf.org</a>
</pre>
        <br>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------050601030007010609020907--


From nobody Thu Aug 27 10:53:03 2015
Return-Path: <housley@vigilsec.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD21B3BE3 for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 10:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level: 
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czR8R8cCMP-w for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 10:53:01 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E92701ACCDA for <tools-development@ietf.org>; Thu, 27 Aug 2015 10:53:00 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 57995F2416C for <tools-development@ietf.org>; Thu, 27 Aug 2015 13:52:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id hTrU0rOBJ7s7 for <tools-development@ietf.org>; Thu, 27 Aug 2015 13:51:32 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C5720F24169 for <tools-development@ietf.org>; Thu, 27 Aug 2015 13:52:29 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 27 Aug 2015 13:52:19 -0400
Message-Id: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
To: IETF Tools Development <tools-development@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/dGtx6enf1eliLVS-5v5-Lbi1dwA>
Subject: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 17:53:02 -0000

I have received a request to shift the tools call from 8 Sept. to 15 =
Sept.  Would this cause a problem for anyone.  If so, we will leave it =
as currently scheduled.=


From nobody Thu Aug 27 10:58:39 2015
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D501AC3BC for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 10:58:38 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvPECRBmULzP for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 10:58:36 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 AC9DF1B3709 for <tools-development@ietf.org>; Thu, 27 Aug 2015 10:58:36 -0700 (PDT)
Received: by qgeh99 with SMTP id h99so17310134qge.0 for <tools-development@ietf.org>; Thu, 27 Aug 2015 10:58:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HTZn6Mi4XxG1sqr1BsqiG8wY5kQxiRG1i4VTflt4x+w=; b=s6Cnegf+7xybebaBVWe2YtGt4bJFxBkiNvZb35pkN0Cbx2trsXJPBsHY0JdQZ5bfQj aETR3uJkNRRS7vlqBkj+RnLIlKGflrpCZUtEgju+YBxodGHyx/tcfu6isUdccbTsw+nO yiU7WrpzA4gBtHCdebnd9UP3psbu+R/gNvNS07NJxzACwtR22lL4qVcgGJHiV+iPXLGE In1Dfz6bGAzTrwZiUVM9GXNReO4HepGJIu2zxwlryM9ICtQ512zPOzUyLyvOrCJwZvyd TtMgZDqiu6f9LIT+4EjRVopGAfc9sJjllxcbHwbtfTMdTBi470udOZnx/iqI7XEelsAi T1Ug==
X-Received: by 10.140.133.67 with SMTP id 64mr9356314qhf.52.1440698315955; Thu, 27 Aug 2015 10:58:35 -0700 (PDT)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id p24sm1682939qki.9.2015.08.27.10.58.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Aug 2015 10:58:35 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
Date: Thu, 27 Aug 2015 13:58:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD51E9AA-D626-4810-BD2E-1FE438791ACD@gmail.com>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/p3IFYQu2OckBAMAAA5rwz2X2lCQ>
Cc: IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 17:58:38 -0000

What time would the call be at?

Thank you,
Kathleen=20

Sent from my iPhone

> On Aug 27, 2015, at 1:52 PM, Russ Housley <housley@vigilsec.com> wrote:
>=20
> I have received a request to shift the tools call from 8 Sept. to 15 Sept.=
  Would this cause a problem for anyone.  If so, we will leave it as current=
ly scheduled.
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-development


From nobody Thu Aug 27 11:32:18 2015
Return-Path: <henrik@levkowetz.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9D01A1A8D for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar5Mdr0Xbjlp for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:32:15 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 0F12A1A00DD for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:32:15 -0700 (PDT)
Received: from localhost ([::1]:40554 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <henrik@levkowetz.com>) id 1ZV1y9-0006w6-Hb; Thu, 27 Aug 2015 11:32:14 -0700
To: Russ Housley <housley@vigilsec.com>, IETF Tools Development <tools-development@ietf.org>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <55DF5795.3080901@levkowetz.com>
Date: Thu, 27 Aug 2015 20:31:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="370OC6VrHI2kFgUnUBfkUIvFqesCKrXoc"
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-development@ietf.org, housley@vigilsec.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/ooE6ZVU8dSZcMoEZxM4OHcVg85c>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 18:32:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--370OC6VrHI2kFgUnUBfkUIvFqesCKrXoc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 2015-08-27 19:52, Russ Housley wrote:
> I have received a request to shift the tools call from 8 Sept. to 15
> Sept.  Would this cause a problem for anyone.  If so, we will leave
> it as currently scheduled.

September 15th would certainly be easier for me, as I'm travelling
on September 6th - 9th.


	Henrik


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

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

iQIcBAEBCAAGBQJV31eVAAoJEE6bV0uPuxcaR2AP/3UmH6bOUpt+bfwAQqRAI5c8
KA3+NwDBZswmlg5fqseiZYfE0zJ0hlocN/5Ks2cd3Cau2Qxfjqp7x2BmBd0NG12l
ygtdtQz99SarPC1eK7DZseGpRZG/OQgOl2pmcPYPophlADqjlcZL/U4jNTZK6l+Y
ZETF9s8JZMLDg8ImHEaYV8yJlxi7/0gDly9QIhUQ95VTm8MLtf7ApJne4Whl1YtX
9P2ECHIX3Egf5waW9fHvnNvQChL+Cg6DLuenlKBRxKwpCTGFTLo+pntVdu3wa2ae
wT1OTNI08yVGpcz1ChNMN+BX0GkP5+OgMhTX/Pwu4cCnFdq7pawdZxxyOLuxL4xZ
iMqE54vtuFCV7XKJ769MzCMr2gVtIZFYfXNXxu9+QNw/tw9QqQLRifZFEH6usv8/
paevp+RZc1nUszhkfZcAJCLA7EFKcfYrplw1M/TpEsVQm2i6ZRO9N1iYYkASTQw6
6m4M/1xR68KIAKU5UtjE2ShOQm+ZevVvWuR16GtOmn5YlzTQ2CJD7wl7F2nMnkEC
9P5wBzm2ubaqZqHCjxuFgmdPDAvnJ8LABt5eAWsIFdDUfGEcm9fK3C5R86v1lQGg
iFxE/StlpKacTkM/HL98EwirnuULxEWzAjGD2CdDu8+Hd4WwkCm2esjgGRAampeq
nRsbGbW5WNap38A1wNy0
=4si2
-----END PGP SIGNATURE-----

--370OC6VrHI2kFgUnUBfkUIvFqesCKrXoc--


From nobody Thu Aug 27 11:32:48 2015
Return-Path: <bob.hinden@gmail.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994221ACEE7 for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:32:47 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nzkLP1n3C4u for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:32:46 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 2B5FE1ACE93 for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:32:46 -0700 (PDT)
Received: by iods203 with SMTP id s203so67510844iod.0 for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Lw6b8Ka2iY487QjcGzBVhhJA64GAyxeFNqMUQRFHP8Y=; b=rLd2b3xO5q0wDoEms75Ku7G3u/8slFcTpByprPLGlBKHv4XWk1dGr6/r3sll9NV1AY 91rMGoNN32cLkjXHB/XP6p7du/5+ddguHW60Yqpb4FYZhIhHhFo0dkIxEFk6l/Gt64tW St9A4PGblQ6OTui2bWJ/Vs38pVbz2h2Gg758mtoocDerKKncMbzza+MqLOPViOrY6H9u G07WCIn4HG50X8HCqVNM1Z2bOu6VcioLj8c6BQPbB0WcuXExg83utz0/HY7vuqK5JbkB +rLlqPpgIr+gqc7ns75xxLUF4Kn+yQVKRwCOMhu2M4W68d1tvlkJMuGhb4u2VyKSdrbF gnXA==
X-Received: by 10.107.148.7 with SMTP id w7mr12633415iod.82.1440700365670; Thu, 27 Aug 2015 11:32:45 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 3sm6995igy.10.2015.08.27.11.32.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Aug 2015 11:32:45 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_434BE450-EF6F-4C7C-9F81-86C02DD1C53B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
Date: Thu, 27 Aug 2015 11:32:44 -0700
Message-Id: <3D5ECECB-565A-4337-88EF-1247E2C7CBB6@gmail.com>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/By2diLdiNNG8Lj-lS2S6ZMWPaf0>
Cc: IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 18:32:47 -0000

--Apple-Mail=_434BE450-EF6F-4C7C-9F81-86C02DD1C53B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

OK for me.

Bob

> On Aug 27, 2015, at 10:52 AM, Russ Housley <housley@vigilsec.com> =
wrote:
>=20
> I have received a request to shift the tools call from 8 Sept. to 15 =
Sept.  Would this cause a problem for anyone.  If so, we will leave it =
as currently scheduled.
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-development


--Apple-Mail=_434BE450-EF6F-4C7C-9F81-86C02DD1C53B
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

iQEcBAEBCgAGBQJV31fMAAoJEK7rdBF357uoHsgH/0ccmAl+hWL09vyj9RIBo8C+
Ikwho+nj8YKZymQcbsCmVrsN7rjNtHaGv2UydLC/q89yDp6WKdTFHzlbLvQCDeU9
muBGwIhNAiIx+/q2+nvkFfzulaMR80pEEqDCY05CVgezkVD+DNjiWPMNc+KsWmVb
iiSGqmjT/06WHTI5XS3pNcHgNJGTefYw3AmasrQrEiwJF+7U5KT7BeUT5rom0aYb
tBzaj78Y1RM0F6nLb5VTnGRIHtFjBy2MG09Zj0y63/TcvLtjjS/a6O23rHyeTr49
mwXrIT9uHvPkm73+MhpvL289in/tm/LU5luMMxmXoxHhomaa5PxPwqPdB+vY4zc=
=KFjP
-----END PGP SIGNATURE-----

--Apple-Mail=_434BE450-EF6F-4C7C-9F81-86C02DD1C53B--


From nobody Thu Aug 27 11:35:00 2015
Return-Path: <housley@vigilsec.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4921ACE9E for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbr33wDekUuH for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:34:58 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E09611AD0D7 for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:34:57 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 74AE3F24163; Thu, 27 Aug 2015 14:34:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id uBzV7Et81IT9; Thu, 27 Aug 2015 14:33:50 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 21358F24143; Thu, 27 Aug 2015 14:34:47 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <DD51E9AA-D626-4810-BD2E-1FE438791ACD@gmail.com>
Date: Thu, 27 Aug 2015 14:34:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFCCDD4A-8411-4202-AAFD-13C695AD08C7@vigilsec.com>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com> <DD51E9AA-D626-4810-BD2E-1FE438791ACD@gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/hjdWruwsZlipKTS6t4HyizogDBc>
Cc: IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 18:34:59 -0000

Same time on either day: 1pm Eastern.


On Aug 27, 2015, at 1:58 PM, Kathleen Moriarty wrote:

> What time would the call be at?
>=20
> Thank you,
> Kathleen=20
>=20
> Sent from my iPhone
>=20
>> On Aug 27, 2015, at 1:52 PM, Russ Housley <housley@vigilsec.com> =
wrote:
>>=20
>> I have received a request to shift the tools call from 8 Sept. to 15 =
Sept.  Would this cause a problem for anyone.  If so, we will leave it =
as currently scheduled.
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> TOOLS-DEVELOPMENT@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-development


From nobody Thu Aug 27 11:48:44 2015
Return-Path: <rse@rfc-editor.org>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B371B3091 for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6J9EHIllS18 for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 11:48:37 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF351B2F4C for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:48:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3E9CF1E5A0C for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjPdnzQyCvrW for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:48:17 -0700 (PDT)
Received: from Heathers-MacBook-Pro.local (unknown [207.98.72.69]) by c8a.amsl.com (Postfix) with ESMTPSA id 229311E5A01 for <tools-development@ietf.org>; Thu, 27 Aug 2015 11:48:17 -0700 (PDT)
To: tools-development@ietf.org
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
From: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>
Message-ID: <55DF5B85.3000602@rfc-editor.org>
Date: Thu, 27 Aug 2015 11:48:37 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/yS-u-tG5oNLkciLH3xVusBZaMWA>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 18:48:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 8/27/15 10:52 AM, Russ Housley wrote:
> I have received a request to shift the tools call from 8 Sept. to 15 Sept.  Would this cause a
problem for anyone.  If so, we will leave it as currently scheduled.

That's fine, though I won't want to say much. Getting braces on 14
September. I may send in my update via the list and folks can just let
me know if they have questions.

- -Heather

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJV31uEAAoJEER/xjINbZoGZaQH/0qFpgOEam6DrvJ3GmDCNpNs
hWA1naKhFBF46SikmzofHYtP8qIDp7+VqCkOC0TLrBqSiih/bXgOCJdxeZ0vSDGz
ZsBkMedwDeGaCwTVHCIE8cmqZ+Rj5VN0IUpZUlhbbpmeammfbaFGfy5v1eNCvQIm
I4CcSFnRolFJEtnWYhPozW8hZGy2P97wcNUwyh/fuktMY38mOjBtf7RF9fC3TwkW
KOqqePX9iulAjndD7YITVDljR0ULG1gMYe8+Ux7cHOhVH2AUxKBIXPmeIa9IDGjb
j5LE/8GL/wMo/FvhK6cbD+KF0vMK+h5XFmL5ISj2MJLJTFJSzPV4zoI2oVn8GaU=
=x/Sx
-----END PGP SIGNATURE-----


From nobody Thu Aug 27 12:02:53 2015
Return-Path: <lberger@labn.net>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EC01B2BDD for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 12:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 OT6XpSihPFQu for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 12:02:49 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 3AB681A8978 for <tools-development@ietf.org>; Thu, 27 Aug 2015 12:02:49 -0700 (PDT)
Received: (qmail 12348 invoked by uid 0); 27 Aug 2015 19:02:48 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 27 Aug 2015 19:02:48 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 9v2d1r00F2SSUrH01v2gk7; Thu, 27 Aug 2015 13:02:46 -0600
X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=pnw5wfTdeqEA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=nmvAJ_fypAMA:10 a=uRRa74qj2VoA:10 a=QF2H0--CAAAA:8 a=48vgC7mUAAAA:8 a=0_MLKSQaRTQotpgfBvEA:9 a=CjuIK1q_8ugA:10 a=rKrVYePj7rwA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=NzqBxWKLFkwh2Dv0QaFbGaL/B/OXDDSEfXb4J1QrjOk=;  b=EG6gTe2fBuksgwN/oFZxN6T0jVVwIBfSfiW376Hf8qmXPkgAB7ZpMpXLKkDdgzjDZprlRiWas5QKgndelIiJ5OhkzYb75ndfysHgLQzNVhzaakYl3Xqndd7nkndj1UtU;
Received: from [134.207.17.13] (port=39752) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from <lberger@labn.net>) id 1ZV2Ra-000190-RV; Thu, 27 Aug 2015 13:02:39 -0600
From: Lou Berger <lberger@labn.net>
To: Henrik Levkowetz <henrik@levkowetz.com>, Russ Housley <housley@vigilsec.com>, IETF Tools Development <tools-development@ietf.org>
Date: Thu, 27 Aug 2015 15:02:37 -0400
Message-ID: <14f708a4510.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <55DF5795.3080901@levkowetz.com>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com> <55DF5795.3080901@levkowetz.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 134.207.17.13 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/kzYlELqPUJxtauzvHTn8R7ClXAo>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 19:02:52 -0000

I'm unavailable on the 15th, but reschedule if it's best for everyone. ..

Lou


On August 27, 2015 2:32:41 PM Henrik Levkowetz <henrik@levkowetz.com> wrote:

> On 2015-08-27 19:52, Russ Housley wrote:
>> I have received a request to shift the tools call from 8 Sept. to 15
>> Sept.  Would this cause a problem for anyone.  If so, we will leave
>> it as currently scheduled.
>
> September 15th would certainly be easier for me, as I'm travelling
> on September 6th - 9th.
>
>
> 	Henrik
>
>
>
>
> ----------
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-development
>



From nobody Thu Aug 27 12:14:56 2015
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7131E1B37F2 for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 12:14:54 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEDU5hXjK48g for <tools-development@ietfa.amsl.com>; Thu, 27 Aug 2015 12:14:53 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 AAFC71B371D for <tools-development@ietf.org>; Thu, 27 Aug 2015 12:14:52 -0700 (PDT)
Received: by wicgk12 with SMTP id gk12so1468985wic.1 for <tools-development@ietf.org>; Thu, 27 Aug 2015 12:14: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:content-type; bh=rpXQbGvb9VKBNP7bgAnA6JqNfU6F4golcAZuR2+STmE=; b=ZcKh+5tjyY5bTl/gKzxcFwhD2tq8J4F7HsE817geQzKcT3Xbg8Vfm6II+DT4oPSNbH Q8zoYnNsxDIaELdT5VCCg62CH1dpa4xRofEnXj0lGF4ITR/8vXQgfG3uw/WScMQU4f2u jllGELGfIaoWIZ0wMlv7o1wXLCxBzK9XEfmUEjRBkVHBTrQaqmQf9DmLje/dhft4Aq2o UuSWDGOvB9bhhYtgjnoGDed8dc0Jxj9arEOGzr56v9McpHThqtwXxCA8lKBtxSIWHbyM PWb1yLV+aAfuVTFkGtTsfpHhLrSpH+/xipYKvPW6/PzC5tKJyzoVTVxFgGKgMopM3fHn u/SA==
MIME-Version: 1.0
X-Received: by 10.180.106.68 with SMTP id gs4mr167447wib.61.1440702891420; Thu, 27 Aug 2015 12:14:51 -0700 (PDT)
Received: by 10.28.157.84 with HTTP; Thu, 27 Aug 2015 12:14:51 -0700 (PDT)
In-Reply-To: <14f708a4510.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <1DD216DF-B6FB-4908-AA29-AF4BA8C80C55@vigilsec.com> <55DF5795.3080901@levkowetz.com> <14f708a4510.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Date: Thu, 27 Aug 2015 15:14:51 -0400
Message-ID: <CAHbuEH4A4qbWs==e9PFF9hi75VHFb5vnbAUEim95DZ5+NOs-1Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/mz8FqT36XUJdYNoo3Kq_xHEkT6I>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, IETF Tools Development <tools-development@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] Shifting the Tools Call?
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 19:14:54 -0000

1PM on the 15th is fine with me right now.

Thanks,
Kathleen

On Thu, Aug 27, 2015 at 3:02 PM, Lou Berger <lberger@labn.net> wrote:
> I'm unavailable on the 15th, but reschedule if it's best for everyone. ..
>
> Lou
>
>
>
> On August 27, 2015 2:32:41 PM Henrik Levkowetz <henrik@levkowetz.com> wrote:
>
>> On 2015-08-27 19:52, Russ Housley wrote:
>>>
>>> I have received a request to shift the tools call from 8 Sept. to 15
>>> Sept.  Would this cause a problem for anyone.  If so, we will leave
>>> it as currently scheduled.
>>
>>
>> September 15th would certainly be easier for me, as I'm travelling
>> on September 6th - 9th.
>>
>>
>>         Henrik
>>
>>
>>
>>
>> ----------
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> TOOLS-DEVELOPMENT@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-development
>>
>
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> TOOLS-DEVELOPMENT@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-development



-- 

Best regards,
Kathleen


From nobody Sat Aug 29 17:48:50 2015
Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DFA1B3B4E; Sat, 29 Aug 2015 17:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPFd9cfZJO0u; Sat, 29 Aug 2015 17:48:45 -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 CD6B41B34DB; Sat, 29 Aug 2015 17:48:44 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7U0mhum062462 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sat, 29 Aug 2015 19:48:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <55E252E6.5040604@nostrum.com>
Date: Sat, 29 Aug 2015 19:48:38 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IETF Tools Development <tools-development@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/uDxGW-b8Gx-NSGOHU0TSF0Oaggo>
Subject: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: IETF Tools Development <tools-development@ietf.org>
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2015 00:48:48 -0000

All -

At this year's IAB/IESG retreat we discussed making the recipients of 
the email
messages the datatracker sends more configurable, reducing the number of 
messages
sent for a given action, and making the messages themselves more meaningful.

One of the primary goals was to make it so that the people who needed to
receive each message would receive the message by default, and we would stop
doing things like putting document shepherds in the notify field. The intent
now is for the notify field to be empty most of the time, only containing
addresses that are special cases.

We made a great deal of progress on this front and have some changes ready
for you to look over and test. There are many things here that need 
feedback.
Please take a few moments to poke around this. If you don't find any 
showstoppers,
I'll send this to the wg-chairs list mid-week.

Start with <https://dt-test.rjsparks.org/mailtoken/token>
(This is a development instance of the tracker - you can log in as 
anyone using
their datatracker login name and the password "password").
You'll see a list of actions on the left, and recipients on the right.
Mouse over any of them for a short pop-up description.
You can focus on a particular action by going to, for example,
<https://dt-test.rjsparks.org/mailtoken/token/last_call_issued/>

The recipients listed are table driven - the secretariat can change them.
Note that the actions are configured at the moment to reach more people than
the production system currently does in many cases. One of the most 
important
things you can do is provide feedback on whether we have the set of 
recipients
for a given action right. Another is whether we have the right actions 
listed -
in other words, are there times when we send email now that we 
shouldn't, and
are there other times where we aren't sending email that we should? 
(Note that
there are small number of places that the tracker sends email that are 
not yet
using this system, but if you spot a place that's not covered here, 
please ask
about it.)

Before brute-forcing your way through the first link above, however, let me
introduce a few other new things. If you go to a specific document, or a 
group,
there is now a tab on the main page that shows what the email expansions 
turn
into for that document or group. For example, look at
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications>
and note the "Email expansions" tab that takes you to
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/email/>

The way each recipient is computed is shown at
<https://dt-test.rjsparks.org/mailtoken/recipient/>
Again, you can hover over a token for a short text description, or focus on
a particular recipient using, for example,
<https://dt-test.rjsparks.org/mailtoken/recipient/doc_shepherd>

Wherever possible, the recipient is expanded using a Django template.  
When the
logic for expanding a recipient is too complicated for a template, the 
work is
done using a short function, as shown on the recipient page.  As we go 
forward,
we'll be working to simplify this gathering process so that many of the
recipients that require functions now can be moved into templates (but 
it will
be important to not just bury the details of the truly complicated 
recipients -
one of the other goals of this project is to make it less of a mystery where
mail is sent)

Now, the IESG will be particularly interested in one special case: Look 
at the
list of recipients for ballot_saved.  The save-and-send email form will 
offer
all of the addresses that are expanded from these recipients and allow the
AD to chose which recipient tokens to actually use (by default, all are
selected). When logged in as an AD or the Secretariat, go to
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/ballot/425017/emailposition/?ad=107190>

Here are a few other highlights from the changes made so far:
* The secretariat has been sending the internal-review and new-work
   messages manually. The Datatracker now assists with those messages.
* The mail sent when issuing ballots has been simplified
* Instead of a generic "state changed" message, recipients get a message
   that says
   - Comment has been added
   - Intended publication status changed
   - Document has been adopted by group
   - IESG is proccessing this document

Finally, there is a script that will run when this is deployed (it has 
been run
already on this test instance) that will scrub recipients that should be
normally copied out of the Notify field for each document. The 
leadership associated
with the document will get an email message explaining the change. The 
IESG will
get a message for all the docs that do not have currently active 
leadership associated
with them (that message to the IESG will be long). Currently, when that 
script runs it
reports: Changed 4858 documents. 3775 of those had their notify field 
emptied

An example of the message that gets sent is at:
<http://www.nostrum.com/~rjsparks/example_notify_email.txt>


From nobody Mon Aug 31 14:51:27 2015
Return-Path: <barryleiba@gmail.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19B1B45A1; Mon, 31 Aug 2015 14:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 r220_KH0zdX2; Mon, 31 Aug 2015 14:51:20 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 C06DA1B4612; Mon, 31 Aug 2015 14:51:19 -0700 (PDT)
Received: by vkbc123 with SMTP id c123so45852173vkb.3; Mon, 31 Aug 2015 14:51:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=04tGVqEoEWKpzYDTd5IxeGA7wRHSDy8iYIfMNFJByjw=; b=HOw+eELuz+Gpv2rNte+zeQUOQC+cm5+07eou2fKIjMlm4jXo1+8/vYSA/e6INwbkJN t5XI1xvx/bYZhk2lEfgug33VFMKdpXqj8BPNJY5QMJSoMieSI/wOkpx9lYE0Bo0NuT8u lh5H/GvvQTMAa67H4vjwOdrLHWj37y4tXazshpFWOhRJ7o4j5tB8Xr7tB5IqvCU00hnC WOY9USomHWpn+s8F8ETCl90JuPByfveUUHxA0U0gO7FuTf86AaBsieFPSc/UmAZDCv1s yYUoA2XatKtbcWgqBlYZ3r2c/up3/YG1L2w5M4l9KFlKxF4xzv+TfJRyRy0lAAstyy/J qAFQ==
MIME-Version: 1.0
X-Received: by 10.52.184.65 with SMTP id es1mr17683926vdc.92.1441057878734; Mon, 31 Aug 2015 14:51:18 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.31.88.196 with HTTP; Mon, 31 Aug 2015 14:51:18 -0700 (PDT)
In-Reply-To: <55E252E6.5040604@nostrum.com>
References: <55E252E6.5040604@nostrum.com>
Date: Mon, 31 Aug 2015 17:51:18 -0400
X-Google-Sender-Auth: uzuaZVed_Xdu34c64RbahWHFEDc
Message-ID: <CALaySJ+dv-az-D-DSUChKRcc2nb_EJ-zQxJ0CNKBfPW8E1jz0Q@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: IETF Tools Development <tools-development@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tools-development/Q514g_rCOFanPYHpCkTqSUJO7VM>
Cc: "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 21:51:22 -0000

Robert, thanks so much for dealing with this!

I see a few things I have questions about:

1. Why does last_call_expired go to iesg?  Shouldn't it be doc_ad?

2. doc_pulled_from_rfc_queue: that goes to doc_ad and not to iesg.  I
think that might be a sufficiently unusual and remarkable situation
that maybe that one *should* go to iesg, no?

3. A question I've always had is whether it makes sense for a
document's "ad" alias to include all ADs in the area, rather than just
the responsible AD.  I can see occasions when one would want to alert
all ADs in the area, but in the vast majority of situations, I think
we want only the responsible AD.

Example of (3):
draft-ietf-sipcore-refer-clarifications.ad@ietf.org and
draft-ietf-sipcore-refer-clarifications.all@ietf.org -- those aliases
include all three ART ADs, and probably should just include the
responsible one.

For WGs with out-of-area responsible ADs, we get this:
draft-ietf-uta-email-tls-certs.ad@ietf.org
ben@nostrum.com, barryleiba@computer.org, alissa@cooperw.in,
stephen.farrell@cs.tcd.ie
That's Stephen AND the ART ADs.

What do we really want here?  I think those aliases should just
include the responsible AD, and perhaps we should have some way of
delegating for coverage during vacations and whatnot.  Otherwise, most
of the time we're sending noise to the irresponsible (ahem) ADs.

That's all I have -- the rest of it looks good.

Barry

On Sat, Aug 29, 2015 at 8:48 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
> All -
>
> At this year's IAB/IESG retreat we discussed making the recipients of the
> email
> messages the datatracker sends more configurable, reducing the number of
> messages
> sent for a given action, and making the messages themselves more meaningful.
>
> One of the primary goals was to make it so that the people who needed to
> receive each message would receive the message by default, and we would stop
> doing things like putting document shepherds in the notify field. The intent
> now is for the notify field to be empty most of the time, only containing
> addresses that are special cases.
>
> We made a great deal of progress on this front and have some changes ready
> for you to look over and test. There are many things here that need
> feedback.
> Please take a few moments to poke around this. If you don't find any
> showstoppers,
> I'll send this to the wg-chairs list mid-week.
>
> Start with <https://dt-test.rjsparks.org/mailtoken/token>
> (This is a development instance of the tracker - you can log in as anyone
> using
> their datatracker login name and the password "password").
> You'll see a list of actions on the left, and recipients on the right.
> Mouse over any of them for a short pop-up description.
> You can focus on a particular action by going to, for example,
> <https://dt-test.rjsparks.org/mailtoken/token/last_call_issued/>
>
> The recipients listed are table driven - the secretariat can change them.
> Note that the actions are configured at the moment to reach more people than
> the production system currently does in many cases. One of the most
> important
> things you can do is provide feedback on whether we have the set of
> recipients
> for a given action right. Another is whether we have the right actions
> listed -
> in other words, are there times when we send email now that we shouldn't,
> and
> are there other times where we aren't sending email that we should? (Note
> that
> there are small number of places that the tracker sends email that are not
> yet
> using this system, but if you spot a place that's not covered here, please
> ask
> about it.)
>
> Before brute-forcing your way through the first link above, however, let me
> introduce a few other new things. If you go to a specific document, or a
> group,
> there is now a tab on the main page that shows what the email expansions
> turn
> into for that document or group. For example, look at
> <https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications>
> and note the "Email expansions" tab that takes you to
> <https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/email/>
>
> The way each recipient is computed is shown at
> <https://dt-test.rjsparks.org/mailtoken/recipient/>
> Again, you can hover over a token for a short text description, or focus on
> a particular recipient using, for example,
> <https://dt-test.rjsparks.org/mailtoken/recipient/doc_shepherd>
>
> Wherever possible, the recipient is expanded using a Django template.  When
> the
> logic for expanding a recipient is too complicated for a template, the work
> is
> done using a short function, as shown on the recipient page.  As we go
> forward,
> we'll be working to simplify this gathering process so that many of the
> recipients that require functions now can be moved into templates (but it
> will
> be important to not just bury the details of the truly complicated
> recipients -
> one of the other goals of this project is to make it less of a mystery where
> mail is sent)
>
> Now, the IESG will be particularly interested in one special case: Look at
> the
> list of recipients for ballot_saved.  The save-and-send email form will
> offer
> all of the addresses that are expanded from these recipients and allow the
> AD to chose which recipient tokens to actually use (by default, all are
> selected). When logged in as an AD or the Secretariat, go to
> <https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/ballot/425017/emailposition/?ad=107190>
>
> Here are a few other highlights from the changes made so far:
> * The secretariat has been sending the internal-review and new-work
>   messages manually. The Datatracker now assists with those messages.
> * The mail sent when issuing ballots has been simplified
> * Instead of a generic "state changed" message, recipients get a message
>   that says
>   - Comment has been added
>   - Intended publication status changed
>   - Document has been adopted by group
>   - IESG is proccessing this document
>
> Finally, there is a script that will run when this is deployed (it has been
> run
> already on this test instance) that will scrub recipients that should be
> normally copied out of the Notify field for each document. The leadership
> associated
> with the document will get an email message explaining the change. The IESG
> will
> get a message for all the docs that do not have currently active leadership
> associated
> with them (that message to the IESG will be long). Currently, when that
> script runs it
> reports: Changed 4858 documents. 3775 of those had their notify field
> emptied
>
> An example of the message that gets sent is at:
> <http://www.nostrum.com/~rjsparks/example_notify_email.txt>
>

