Glen | 4 Aug 01:19 2015

Re: Update Re: IETF Website Degradation

Job -

Thank you so much!  Yes, we are aware of those numbers,  but thank you so much for making sure we have them!  And thanks also for making them aware of our situation here!

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

On Mon, Aug 3, 2015 at 3:50 PM, Job Snijders <job <at>> wrote:
I pinged two cloudflare employees via facebook to make them aware of the
fact you are trying to reach them.

Did you try the following to reach cloudflare:

    US callers: 1 (888) 99-FLARE
    UK callers: +44 (0)20 3514 6970
    International callers: +1 (650) 319-8930

Kind regards,


On Mon, Aug 03, 2015 at 03:24:08PM -0700, Glen wrote:
> All -
> We have determined that the degradation was caused by a DDoS attack against
> the 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)

Nalini Elkins | 3 Aug 17:49 2015

IETF Mentoring Survey (Last Call - Ends August 7)


We are trying to improve the IETF mentoring program.  But before we re-design or focus the program, we want to
find out who is coming to the IETF meetings and why they come.    There are a number of motivations and types of
attendees.  Our hope is to have a mentoring program that helps them to better achieve their goals. 

So, if you would, we would really appreciate if you could take the following survey. This is the same survey
as was sent out a couple of days ago - so if you have done it, then you do not need to do it again. 

We will close the survey on August 7, 2015.  There is room for 1,000 participants.  We have 90 responses so far
so it would be great to have more!  We especially would like comments from mentees as to what worked or what
did not work for them. 

We will make the responses public after consolidating them.

We have set up an email list where people can discuss their suggestions for the mentoring program.  You may
sign up at: 

We also had some people mention that they would like to work on the mentoring team.  Please contact me
directly.  We would love to have you!

Thanks so much.

Mentoring Team: 
Nalini Elkins 
Marius Georgescu 
Vinayak Hegde 
Kevin Chege 

Mentor Coordinators 
Wes Eddy 
Dan Romascanu 

Nalini Elkins 
Inside Products, Inc. 
(831) 659-8360

Brian E Carpenter | 3 Aug 17:09 2015

WG adoption threads

I've been watching several "WG adoption" threads since Prague,
and I have a question.

Is it useful for authors of a draft to send messages saying things
like "I support the adoption of this draft as a WG document." ?

I'm not asking whether it's right or wrong, just whether such
a message helps the WG Chairs in evaluating consensus.

(I see similar messages from non-authors, and I am definitely
doubtful about them unless they start with something like "I have
read this draft and...".)


Tal Mizrahi | 1 Aug 20:32 2015

Re: Gen-art LC review: draft-mm-netconf-time-capability-05

Hi Robert,

Thanks for the comments.

We have submitted an updated version of the draft, which addresses the comments we received from you and
other reviewers in IETF last call. 

Our responses to your comments can be found below.
Please let us know if you have further comments or questions.

Tal and Yoram.

>-----Original Message-----
>From: ietf [mailto:ietf-bounces <at>] On Behalf Of Robert Sparks
>Sent: Thursday, July 09, 2015 12:40 AM
>To: General Area Review Team; ietf <at>; draft-mm-netconf-time- 
>capability.all <at>
>Subject: Gen-art LC review: draft-mm-netconf-time-capability-05
>I am the assigned Gen-ART reviewer for this draft. For background on 
>Gen- ART, please see the FAQ at
>Please resolve these comments along with any other Last Call comments 
>you may receive.
>Document: draft-mm-netconf-time-capability-05
>Reviewer: Robert Sparks
>Review Date: 8 Jul 2015
>IETF LC End Date: 29 Jul 2015
>IESG Telechat date: not yet scheduled
>Summary: This draft has open issues to address before publication
>This draft adds two separable concepts to netconf
>* Asking for and receiving knowledge of when a command was executed
>* Requesting that a command be executed at a particular time
>The utility of the first is obvious, and I have no problems with the 
>specification of that part of this extension. Would it be better to 
>pull these apart and progress them separately?

We believe there is a great benefit to defining these two feature together, although each of them can be used
independently. The second certainly gains from the first, since the execution-time provides feedback
to the client about the actual time of execution compared to the scheduled time of execution.

>The utility of the second would be more obvious if the draft didn't 
>limit the time to be "near future scheduling". It punts on most of the 
>hard problems with scheduling things outside a very tight range (15 
>seconds in the future by default), without motivating the advantages of 
>saying "wait until 5 seconds from now before you do this".
>Why was 15 seconds chosen? Could you add a motivating example that 
>shows why being able to say "now is not good, but 5 seconds from now is 
>better" is useful? (Something like having a series of things happen as 
>close to simultaneously without the network delay of sending the 
>requests impacting how they are separated perhaps?)

Point well taken. We have added the following example, motivating why near future scheduling (<15
seconds) can be useful:

A typical example of using near-future scheduling is a coordinated commit; a client needs to trigger a
commit at n servers, so that the n servers perform the commit as close as possible to simultaneously.
Without the time capability, the client sends a sequence of n commit messages, and thus each server
performs the commit at a different time. By using the time capability, the client can send commit messages
that are scheduled to take place at time Ts, which is 5 seconds in the future, causing the servers to invoke
the commit as close as possible to time Ts.

We have also added an explanation of why 15 seconds were chosen as the default value:

The default value of sched-max-future is defined to be 15 seconds. This duration is long enough to allow the
scheduled RPC to be sent by the client, potentially to multiple servers, and in some cases to send a
cancellation message, as described in Section ‎3.2. On the other hand, the 15 second duration yields a
very low probability of a reboot or a permission change.

>Given the punt, why isn't there a statement that sched-max-future MUST 
>NOT be configured for more than some small value (twice the default, or
>30 seconds, perhaps), especially while this is targeted for 
>Experimental? Without something like that, I think the document needs 
>to talk about more of the issues it is trying to avoid with longer term 
>scheduling, even if it doesn't solve those issues. (If I have a fast 
>pipe, I can make a server keep a lot of queued requests, eating a lot 
>of state, even if the window is only 15 seconds. Pointing to how 
>netconf protects against state-exhaustion abuse might be useful).

Note that we did not define a maximal value for sched-max-future, since one of the goals was to define a
generic tool that can be used for various different environments. The draft clearly states the intention
of using near-future-scheduling, but the requirements and constraints of different environments may
require the sched-max-future to have a different value, potentially higher than 30 seconds. Hence, we
prefer not to define a maximal value. Indeed, in the draft 06 there is a more detailed discussion about the
issues we are trying to prevent by using near-future scheduling (Section 3.6).

>The security considerations section talks about malicious parties 
>attempting to cause sched-max-future to be configured to "a small 
>value". Could you more clearly characterize  "small", given that the 
>default is 15 seconds?

We rephrased this paragraph to be more clear about the "small" value:

This YANG module defines <sched-max-future> and <sched-max-past>, which are
writable/creatable/deletable. These data nodes may be considered sensitive or vulnerable in some
network environments. An attacker may attempt to maliciously configure these parameters to a low value,
thereby causing all scheduled RPCs to be discarded. For instance, if a client expects
<sched-max-future> to be 15 seconds, but in practice it is maliciously configured to 1 second, then a
legitimate scheduled RPC that is scheduled to be performed 5 seconds in the future will be discarded by the server.

>Even with the near-future limit, there are issues to discuss introduced 
>with the ability to cancel a request:
>* What prevents a 3rd party from cancelling a request? I think it's 
>only that the 3rd party would have to obtain the right id to put in the 
>cancel message. If so, the document should talk about how you keep 
>eavesdroppers from seeing those ids, and that the servers that generate 
>them should make ids that are hard to guess.

We understand this needs further clarification. As noted by Andy Bierman in a corresponding mail:

>>Since the scheduled rpc event is sent to every client that is 
>>listening for notifications, there is no possibility for security 
>>through hard-to-guess token, as is done with the "persist-id"  for cancelling a confirmed-commit.

We rephrased the paragraph to clarify these issues:

This YANG module defines the <cancel-schedule> RPC. This RPC may be considered sensitive or vulnerable in
some network environments. Since the value of the <schedule-id> is known to all the clients that are
subscribed to notifications from the server, the <cancel-schedule> RPC may be used maliciously to
attack servers by canceling their pending RPCs. This attack is addressed in two layers: (i) security at
the transport layer, limiting the attack only to clients that have successfully initiated a secure
session with the server, and (ii) the authorization level required to cancel an RPC should be the same as
the level required to schedule it.

>* Especially given the near-future limitation, you run a high risk that 
>the cancel arrives after the identified request has been executed. It's 
>not clear in the current text what the server should do. I assume you 
>want the server to reply to the cancel with a "I couldn't cancel that"
>rather than to do something like try to undo the request. The document 
>should be explicit.
>* The document should explicitly disallow adding <scheduled-time> to 

We have addressed these two comments by adding the following paragraph:

A cancel-schedule message MUST NOT include the scheduled-time parameter. A server that receives a
cancel-schedule should try to cancel the schedule as soon as possible. If the server is unable to cancel
the scheduled RPC, for example because it has already been executed, it should respond with an rpc-error
[RFC6241], in which the error-type is 'protocol', and the error-tag is 'operation-failed'.

>One editorial comment: It would help to move the concept of the 
>near-future limitation much earlier in the document, perhaps even into 
>the introduction and abstract.

We added the following to the introduction:

The NETCONF time capability is intended for scheduling RPCs that should be performed in the near future,
allowing to coordinate simultaneous configuration changes, or to specify an order of configuration
updates. Time-of-day-based policies and far-future scheduling, e.g., [Cond], are outside the scope of
this memo.

[Cond]                          Watsen, K., "Conditional Enablement of Configuration Nodes",
draft-kwatsen-conditional-enablement-00 (expired), 2013.

>And for the shepherding AD: The document has no shepherd or shepherd 
>writeup. While a writeup is not required, one would have been useful in 
>this case to discuss the history of (lack of) discussion of the 
>document on the group's list and the group's reaction to progressing as 
>Experimental as an Individual Submission.

IAB Chair | 31 Jul 23:10 2015

Request for volunteers or nominations to 2016 ICANN NomCom

Dear Colleagues:

The IAB (on behalf of the IETF) has been asked to supply a member to the 2016 ICANN
Nominating Committee (NomCom). The IAB would therefore like to ask the community 
for volunteers to serve on the ICANN NomCom. Last year, John Levine did the
job for the IETF community, and he is willing to serve again. The IAB would like to see
whether others are interested in serving in this capacity.

If you are interested in serving on the ICANN NomCom, please send a short e-mail to 
iab-chair at and execd at with your motivation and information concerning 
your familiarity with the IETF and ICANN. Alternatively, if you know of someone who may 
be a good fit for this position, please send the name and email address to e-mail to
iab-chair at and execd at The deadline for nominations or volunteers is 
28 August 2015.

After asking for community input on the candidates, the IAB will select from the available 
candidates. We shall take into account canidates' familiarity with ICANN and the IETF 
(including their roles and processes). The selected candidate will serve on the ICANN 
NomCom on personal title;  however, we will be looking for a candidate who has an 
understanding of the interests of the IETF and the broader technical community.

The ICANN NomCom process itself is governed by the ICANN bylaws; an abstract of the relevant 
articles can be found at  In addition, each NomCom 
determines a number of its own operational procedures, including the role of the NomCom in 
recruiting and selecting candidates for ICANN leadership positions.  Based on the experience
of previous volunteers, the time commitment is significant.  The selected person should be
prepared to participate in the recruitment of potential candidates for ICANN leadership
positions (a few hours per month November through April); a few hours on conference calls
each month (and even more near selection); ten or more hours per month reviewing and
assessing candidate qualifications in April, May, and June; and multiple days of face-to-face
meetings of the full NomCom at each of the three ICANN meetings.

The ICANN NomCom typically meets in person at or around three consecutive ICANN meetings
in various locations throughout the world, resulting next summer in a final slate of candidates 
for the ICANN Board, the GNSO, ccNSO, and ALAC.

NOTE: ICANN covers travel and hotel costs for a pre-determined number of days at each
of the 3 consecutive ICANN meetings under prevailing ICANN policies.

Candidates should be able to join monthly teleconferences (typically at UTC 14:00), with the 
expectation that these teleconferences will held weekly during the candidate assessment 
process in May and June.

For more information about the ICANN NomCom see:

On behalf of the IAB,
  Andrew Sullivan
  IAB Chair

Thomas Narten | 31 Jul 06:53 2015

Weekly posting summary for ietf <at>

Total of 148 messages in the last 7 days.

script run at: Fri Jul 31 00:53:02 EDT 2015

    Messages   |      Bytes        | Who
 12.16% |   18 | 10.84% |   141494 | john-ietf <at>
  6.08% |    9 |  7.26% |    94676 | ted.lemon <at>
  4.05% |    6 |  8.69% |   113439 | spromano <at>
  6.08% |    9 |  4.57% |    59661 | johnl <at>
  4.05% |    6 |  3.21% |    41938 | paf <at>
  3.38% |    5 |  3.00% |    39203 | stephen.farrell <at>
  3.38% |    5 |  2.85% |    37143 | sob <at>
  3.38% |    5 |  2.77% |    36163 | ietf-dane <at>
  2.70% |    4 |  2.67% |    34869 | azet <at>
  2.70% |    4 |  2.24% |    29228 | brian.e.carpenter <at>
  1.35% |    2 |  3.48% |    45408 | talmi <at>
  2.03% |    3 |  2.06% |    26848 | bob.hinden <at>
  2.03% |    3 |  2.02% |    26415 | lear <at>
  2.03% |    3 |  1.97% |    25721 | drc <at>
  2.03% |    3 |  1.83% |    23834 | tony <at>
  2.03% |    3 |  1.65% |    21514 | stbryant <at>
  2.03% |    3 |  1.62% |    21107 | mcr+ietf <at>
  2.03% |    3 |  1.56% |    20373 | dhc <at>
  1.35% |    2 |  1.87% |    24390 | ben <at>
  1.35% |    2 |  1.51% |    19758 | ynir.ietf <at>
  1.35% |    2 |  1.43% |    18625 | huitema <at>
  1.35% |    2 |  1.29% |    16835 | jcurran <at>
  1.35% |    2 |  1.23% |    15998 | adrian <at>
  1.35% |    2 |  1.16% |    15174 | david <at>
  1.35% |    2 |  1.15% |    15018 | melinda.shore <at>
  1.35% |    2 |  1.12% |    14652 | victor <at>
  1.35% |    2 |  1.01% |    13193 | alex <at>
  1.35% |    2 |  0.98% |    12786 | cabo <at>
  0.68% |    1 |  1.48% |    19320 | harald <at>
  0.68% |    1 |  1.12% |    14559 | eckert <at>
  0.68% |    1 |  0.98% |    12783 | warren <at>
  0.68% |    1 |  0.96% |    12500 | andy <at>
  0.68% |    1 |  0.96% |    12476 | nfiumarelli <at>
  0.68% |    1 |  0.90% |    11726 | phill <at>
  0.68% |    1 |  0.86% |    11278 | sunilks77 <at>
  0.68% |    1 |  0.86% |    11221 | rhansen <at>
  0.68% |    1 |  0.79% |    10331 | narten <at>
  0.68% |    1 |  0.74% |     9622 | jgs <at>
  0.68% |    1 |  0.67% |     8697 | mrcullen42 <at>
  0.68% |    1 |  0.66% |     8586 | ogud <at>
  0.68% |    1 |  0.66% |     8574 | hsantos <at>
  0.68% |    1 |  0.65% |     8543 | richard <at>
  0.68% |    1 |  0.62% |     8118 | agmalis <at>
  0.68% |    1 |  0.61% |     7943 | ietf <at>
  0.68% |    1 |  0.61% |     7932 | abdussalambaryun <at>
  0.68% |    1 |  0.60% |     7787 | gjshep <at>
  0.68% |    1 |  0.59% |     7661 | nalini.elkins <at>
  0.68% |    1 |  0.58% |     7538 | d3e3e3 <at>
  0.68% |    1 |  0.57% |     7464 | amorris <at>
  0.68% |    1 |  0.56% |     7255 | mcmanus <at>
  0.68% |    1 |  0.54% |     7056 | ajs <at>
  0.68% |    1 |  0.54% |     7001 | paul <at>
  0.68% |    1 |  0.53% |     6970 | rsalz <at>
  0.68% |    1 |  0.52% |     6795 | lberger <at>
  0.68% |    1 |  0.50% |     6495 | tjc <at>
  0.68% |    1 |  0.50% |     6469 | john <at>
  0.68% |    1 |  0.49% |     6399 | yakov-ietf <at>
  0.68% |    1 |  0.48% |     6255 | peter <at>
  0.68% |    1 |  0.47% |     6118 | sra <at>
  0.68% |    1 |  0.47% |     6111 | aallen <at>
  0.68% |    1 |  0.47% |     6068 | hosnieh.rafiee <at>
  0.68% |    1 |  0.44% |     5773 | dkg <at>
100.00% |  148 |100.00% |  1304887 | Total

Olafur Gudmundsson | 29 Jul 23:15 2015

Sec-Dir Review: draft-mm-netconf-time-capability-05.tx

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

This document is ready for publication
The document is well written.

The security considerations are clear and accurate. I would like highlight one omission though.  
This capability allows an attacker once it has gained access to schedule events in the future even 
though attackers access has been detected and revoked. 

Tim Chown | 29 Jul 18:15 2015

New WGs...

Bier, lager, banana... I spot a theme...


Adrian Farrel | 29 Jul 16:41 2015

New Version of draft-farrresnickel-harassment


After some very fruitful mail exchanges on and off the list and some detailed discussions face-to-face in
Prague, we have produced a new revision of the anti-harassment process document.

Some of the changes are quite large. Others are small, but subtle. I recommend reading the whole document,
but if you want to look only at changes, I suggest you diff against -05, the version that was updated after
IETF last call and went to the IESG for evaluation.

In checking to see what changes were made and whether they addressed your comments, please bear in mind that
there were a lot of comments made in a conversational manner and it was quite hard to round them up and
determine exactly what changes needed to be made. Ines did a great job helping as Shepherd, but if we have
missed something you said, it is not because we are ignoring you: it's just that we lost the point amongst
other comments and discussions.

Additionally, I'd ask you to think about whether what we have is "good enough" to act as a starting point. I'm
conscious that we have been debating having this piece of process for a long time and that my personal
preference is to get something going (a beta release?) and then tune it as we go forwards. In the light of
that I know that consensus on some parts of the document may be a little rough. This mainly happens when the
opinions on an issue are very divergent and not easily brought together. I hope that we have done a good job
at building bridges, but will not be surprised or upset if some of you are not happy.

I'm responsible for most of the edits in this round (with assistance from multiple people) so please blame
me (and complain about me to Pete) for any nonsense.

As to process, I suggest that this document needs to be taken around for another IETF last call, but I leave
that to Jari as the responsible AD.



In summary...

Abstract: clarify the nature of updates to existing RFCs.

Introduction: s/interpersonal/personal/

Definitions: Clarify that the definition of harassment is deliberately not a closed list.

Definitions: Add a paragraph (loosely based on the IEEE's equivalent policy) to scope when harassment
applies within the IETF.

Definitions: Add a clause recommended by our lawyers about applicable law.

Ombudsteam: Clarify "recompense" to mean "compensation from the IETF".

Term of Service: Add paragraph for when an Ombudsperson's term ends while they are acting as Lead
Ombudsperson .

Term of Service: Add a note about likelihood of reappointment.

Compensation: Clarify "recompense" to mean "compensation from the IETF".

Removal: Expand the times that an Ombudsperson can be removed.

Handling Reports: Fix email address and URL.

Handling Reports: Clarify that remedies are imposed only after completing investigations.

Operating Practices: Expand on confidentiality expectations.

Operating Practices: Clarify that the Respondent is contacted and given an opportunity to interact
before a remedy is imposed.

Operating Practices: Add when the Ombudsteam must commit things to writing.

Remedies: Add that mediation ned not be an end point.

Remedies: Show how remedies may be actioned through the Secretariat or IAD.

Remedies for Respondents in IETF Positions: Add substantial new section.

Purpose of Remedies: Expand on the details and theme of "not as punishment" remedies.

Confidentiality: Add new section to describe expectations.

Acknowledgements: What a lot of you have helped with this document!

> -----Original Message-----
> From: internet-drafts <at> [mailto:internet-drafts <at>]
> Sent: 29 July 2015 15:13
> To: Pete Resnick; Adrian Farrel; Adrian Farrel; Pete Resnick
> Subject: New Version Notification for draft-farrresnickel-harassment-07.txt
> A new version of I-D, draft-farrresnickel-harassment-07.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> Name:		draft-farrresnickel-harassment
> Revision:	07
> Title:		IETF Anti-Harassment Procedures
> Document date:	2015-07-29
> Group:		Individual Submission
> Pages:		17
> URL:  
> 07.txt
> Status:
> Htmlized:
> Diff: 

Peter Yee | 28 Jul 23:15 2015

Gen-ART LC review of draft-bradner-iaoc-terms-01

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-bradner-iaoc-terms-01
Reviewer: Peter Yee
Review Date: Jul-28-2015
IETF LC End Date: Jul-27-2015
IESG Telechat date: TBD

Summary: This draft is almost ready for publication as a BCP but has an
open issue, described in the review. [Ready with issues]

The draft updates BCP 101 to fix some issues around the beginning and end
of IAOC terms and how they relate to the first meeting of each IAOC cycle.

Major issues: None

Minor issues: 

The draft causes the IAOC chair’s term to end with the commencement of the
IAOC meeting occurring at the first IETF meeting of the year.  The new
chair is selected during the meeting.  That being the case, who chairs the
meeting and declares the results of the election?


Page 2, last paragraph, last sentence: change the second occurrence of
“IETF” to “IAOC”.  I believe that is what was meant.

Nalini Elkins | 26 Jul 15:35 2015

Mentoring Program Survey


We are trying to improve the IETF mentoring program.  But before we re-design or focus the program, we want to
find out who is coming to the IETF meetings and why they come.    There are a number of motivations and types of
attendees.  Our hope is to have a mentoring program that helps them to better achieve their goals. 

We are also setting up an email list where people can discuss their suggestions for the mentoring program. 

So, if you would, we would really appreciate if you could take the following survey. This is the same survey
as was sent out a couple of days ago - so if you have done it, then you do not need to do it again. 

We will close the survey on August 7, 2015.  There is room for 1,000 participants.  We only have 24 responses so
far so it would be great to have more!  We especially would like comments from mentees as to what worked or
what did not work for them.

Thanks so much! 

Mentoring Team: 
Nalini Elkins 
Marius Georgescu 
Vinayak Hegde 
Kevin Chege 

Mentor Coordinators 
Wes Eddy 
Dan Romascanu  

Nalini Elkins
Inside Products, Inc.
(831) 659-8360