Subject: Moderation on [email-masked]

From: IETF Chair <[email-masked]>
Date: Tue, 22 Jul 2014 10:24:22 -0400

The [email-masked] list is very active. It hosts varied discussions ranging from last calls to IETF organisation matters to any Internet technology-related topics that come up. We all have seen how much discussion there is, and occasionally, discussions that become unproductive or repetitive. Part of the root cause of this is that unlike most IETF lists, there is no working group chair overseeing and driving discussions.

The IESG has discussed this and plans to add moderators to manage the list discussion. The moderators will track and guide discussions and remind people when they get outside of the lines. Please respect the feedback from the moderators when they say, for instance, that an issue has been already previously discussed. 

The moderation system will not affect other mailing list management methods that are used on this list or in the IETF in general.

If you have feedback on this plan, please let us know.

Jari Arkko for the IESG

---

From: Ted Hardie <[email-masked]>
Date: Tue, 22 Jul 2014 10:40:04 -0400

Howdy,

Does this eliminate the position of sargeant-at-arms for the list?   If
not, how do they relate?

regards,

Ted

On Tue, Jul 22, 2014 at 10:24 AM, IETF Chair <[email-masked]> wrote:

> The [email-masked] list is very active. It hosts varied discussions
> ranging from last calls to IETF organisation matters to any Internet
> technology-related topics that come up. We all have seen how much
> discussion there is, and occasionally, discussions that become unproductive
> or repetitive. Part of the root cause of this is that unlike most IETF
> lists, there is no working group chair overseeing and driving discussions.
>
> The IESG has discussed this and plans to add moderators to manage the list
> discussion. The moderators will track and guide discussions and remind
> people when they get outside of the lines. Please respect the feedback from
> the moderators when they say, for instance, that an issue has been already
> previously discussed.
>
> The moderation system will not affect other mailing list management
> methods that are used on this list or in the IETF in general.
>

---

From: manning bill <[email-masked]>
Date: Tue, 22 Jul 2014 08:12:26 -0700

like this has never been a problem in the past … yet every time it has worked out that a reasonable adults, we were able to get past
the problems and the list survived - until now.   Moderation is the explicit application of personal bias over the discussion.   In other words,
censorship.  Which is your prerogative - since you are the current,temporary steward.   But it will drive more work away from IETF.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jul 2014 11:20:35 -0400

I would suggest that the IESG is probably putting the cart before the horse.   The IETF mailing list is an IETF asset, not an IESG one.  Instead, let's have the discussion of what's needed by the IETF first, and then figure out how to accomplish it.  While at times the IETF list is unruly and irrelevant, it truly is our open forum, and placing moderators on it will have - my opinion - a chilling affect on open discourse.  

I see no evidence that the sergeant-at-arms approach is not working and while I might like tweaks to what gets posted to the list, I am mostly willing to endure what noise there is for the occasional nuggets of wisdom, technical thought and weird comments.   

That said, if the IESG wants to moderate something, feel free to copy the IETF mailing list and republish it as a second moderated list.  Let the market decide by subscriptions to one or the other.  

Mike

Sent from my iPad

> On Jul 22, 2014, at 10:24, IETF Chair <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Tue, 22 Jul 2014 08:59:50 -0700 (PDT)

> censorship.  Which is your prerogative - since you are the current,temporary steward.   But it will drive more work away from IETF.

I agree with all of this, especially the last point.

				Ned

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 22 Jul 2014 12:08:23 -0400

I agree. Moderated mailing lists in these forums are bogus.

	--Tom

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Jul 2014 12:12:55 -0400

This message proposes a problem exists and then without any discussion
announces a decision.

That is a problem.

I didn't get to vote for you. Only ten of us did. And it isn't clear
that this is an IESG list as opposed to an IAB list. Shouldn't the
Internet Administration Board have a voice in what is an
administrative matter?

---

From: IETF Chair <[email-masked]>
Date: Tue, 22 Jul 2014 12:16:18 -0400

> This message proposes a problem exists and then without any discussion

I want to clarify what the mail said. It said we are planning to do this and called for feedback. A decision will be made after discussion.

Jari

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jul 2014 12:22:08 -0400

+1 on all points.

--
Hector Santos
http://www.santronics.com

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 12:22:50 -0400

> I want to clarify what the mail said. It said we are planning to do this and called for feedback. A decision will be made after discussion.

Since we're clarifying, I'm wondering whether you mean moderation in
the way it usually does, or in the way it socially does.

That is, is the plan to turn on the moderation feature of mailman?  Or
is the plan instead to have a group of people who are basically much
more active seargents-at-arms, catching people when they go over the
line and then moderating those individuals quickly if things continue
to proceed?  Your text seemed to suggest the latter, but in the
context of mailing lists "moderation" usually means the former.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jul 2014 12:33:02 -0400

Andrew,

> context of mailing lists "moderation" usually means the former.

I was on the latter plan. Personally, and I think this is what the IESG wanted to see.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Jul 2014 17:35:55 +0100

> context of mailing lists "moderation" usually means the former.

Yes, the latter is what we've been discussing as Jari said.

But one more clarification: we don't think those moderators
would be empowered to prevent people mailing to the list even
if those people misbehave, that remains for the sergeant at
arms role was the plan. Its defo more social than enforcement.

S

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jul 2014 04:39:39 +1200

> I was on the latter plan. Personally, and I think this is what the IESG wanted to see.

So, I have to repeat the question that someone else asked: aren't
you just proposing to have the sergeant-at-arms job performed
more aggressively? (Not that I am criticising Jordi in any way -
he has been limiting himself to fairly extreme cases, and he's been
dinged for doing even that minimum.)

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jul 2014 13:07:12 -0400

>I want to clarify what the mail said. It said we are planning to do this and called for feedback. A decision will be made after discussion.

Hi Jari  -

"Planning to do this" implies "we've already decided and it will go forward unless something changes.  

Perhaps instead - "We're considering approaches to manage noise on the IETF list.  One possibility discussed by the IESG is providing moderators to remonstrate with the noise producers prior to action by the sergeant-at-arms.  The IESG would like to solicit comments on this and also solicit guidance on other possibilities prior to making any decision".

Thanks - Mike

---

From: IETF Chair <[email-masked]>
Date: Tue, 22 Jul 2014 13:08:38 -0400

> Perhaps instead - "We're considering approaches to manage noise on the IETF list.  One possibility discussed by the IESG is providing moderators to remonstrate with the noise producers prior to action by the sergeant-at-arms.  The IESG would like to solicit comments on this and also solicit guidance on other possibilities prior to making any decision”.

That makes a lot of sense to me. Thanks.

jari

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jul 2014 13:09:47 -0400

>arms role was the plan. Its defo more social than enforcement.

Hall monitors?  Those annoying kids wandering the halls during recess?    I'm not sure how this is more effective than the Sergeant at arms giving a warning.

Perhaps more than a paragraph on the IESG *proposal* would be useful.  I didn't get the above from Jari's note nor from his clarification.

Mike

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 22 Jul 2014 13:13:26 -0400

> Perhaps instead - "We're considering approaches to manage noise on the IETF list.  One possibility discussed by the IESG is providing moderators to remonstrate with the noise producers prior to act…

Mike,

This is what I thought we were doing. Thanks for sending text.

Spencer, speaking as 1/16th of the IESG

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 13:14:45 -0400

>From what Stephen said, no.  Instead, it sounds like the plan is to
appoint some people as behaviour moderators, who are specifically
looking for early signs of bad behaviour and who will, doubtless,
first call out such behaviour privately, then publicly; only later
will the Sergeant-at-Arms be invoked, and it is hoped that doesn't
become necessary.

I suppose that in practice what's really being admitted is that we're
not doing this ourselves already informally, and this is a way to
formalize that sort of desirable social pressure without acutally
creating more Official Jobs and Procedures.  I like that aspect of
this proposal, because I don't think that bullies and so on are
effectively controlled by elaborate rules but are quite effectively
handled by the right sorts of social pressure.  The danger, of course,
is that we end up with a group of self-satisfied smuggies who turn
into the new IETF bully class.  Presumably, the rest of us will still
have a job to do in preventing that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Tue, 22 Jul 2014 13:16:34 -0400

On 7/22/14 1:07 PM, Michael StJohns wrote:
> Perhaps instead - "We're considering approaches to manage noise on the 
> IETF list. One possibility discussed by the IESG is providing 
> moderators to remonstrate with the noise producers prior to action by 
> the sergeant-at-arms. The IESG would like to solicit comments on this 
> and also solicit guidance on other possibilities prior to making any 
> decision".

I absolutely agree, with the caveat that "remonstrate" is probably a bit 
strong. I'd hope that that the moderator would be there to guide the 
discussion before remonstration is necessary.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: James Woodyatt <[email-masked]>
Date: Tue, 22 Jul 2014 10:23:38 -0700

The question about the proposed relationship between moderators and the
sergeant-at-arms is the interesting one to me.  I can see the appeal of
having a class of moderators without the formal responsibilities of the
sergeant-at-arms but with an informal echo of authority, but I'm interested
to know how the authority of the moderators will be established and
maintained.

—james

On Tue, Jul 22, 2014 at 10:16 AM, Pete Resnick <[email-masked]>
wrote:

>> IETF list. One possibility discussed by the IESG is providing moderators to
>> remonstrate with the noise producers prior to action by the
>> sergeant-at-arms. The IESG would like to solicit comments on this and also
>> solicit guidance on other possibilities prior to making any decision".
>>
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jul 2014 13:22:25 -0400

> discussion before remonstration is necessary.

Given the description in the last few postings on this and the local,
existing use of the term 'moderator', a common label that could be more
helpful and less confusing would be 'facilitator'.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 13:28:51 -0400

On Jul 22, 2014, at 1:07 PM, Michael StJohns <[email-masked]> wrote:
> We're considering approaches to manage noise on the IETF list.  One possibility discussed by the IESG is providing moderators to remonstrate with the noise producers prior to action by the sergeant-at-arms.  The IESG would like to solicit comments on this and also solicit guidance on other possibilities prior to making any decision

As Spencer said, this is good text.   However, it's worth noting that we /really do/ have a problem here, and we need to do something about it.   What Pete proposed was /really/ mild: he proposed that when people exhibit certain behavior patterns, they be asked to step back--to count to ten, as Vint said.   Is that actually an unreasonable thing to be doing?

I agree with the hall monitor comment--we really don't want to turn this into a new, improved IETF bullying system.   If that's what this looks like to people who are objecting, we probably ought to try to figure out why, and whether there's something we can do to mitigate that concern.

---

From: Chris Elliott <[email-masked]>
Date: Tue, 22 Jul 2014 14:36:24 -0400

On Tuesday, July 22, 2014, Ted Lemon <[email-masked]> wrote:

> On Jul 22, 2014, at 1:07 PM, Michael StJohns <[email-masked]
> <javascript:;>> wrote:
> > We're considering approaches to manage noise on the IETF list.  One
> possibility discussed by the IESG is providing moderators to remonstrate
> with the noise producers prior to action by the sergeant-at-arms.  The IESG
> would like to solicit comments on this and also solicit guidance on other
> possibilities prior to making any decision
>
> As Spencer said, this is good text.   However, it's worth noting that we
> /really do/ have a problem here, and we need to do something about it.
> What Pete proposed was /really/ mild: he proposed that when people exhibit
> certain behavior patterns, they be asked to step back--to count to ten, as
> Vint said.   Is that actually an unreasonable thing to be doing?
>
> I agree with the hall monitor comment--we really don't want to turn this
> into a new, improved IETF bullying system.   If that's what this looks like
> to people who are objecting, we probably ought to try to figure out why,
> and whether there's something we can do to mitigate that concern.
>

I suggest that the moderators share a mailing list with a private
archive and copy said list on all private comments.

That way, first, the moderators can monitor themselves as a group, and the
Sargent-at-arms and those with a need to know can access the archive should
there be a complaint about a moderator's comments.

Chris.

-- 
Chris Elliott
CCIE # 2013

“You and I are mirages that perceive themselves”
--Douglas Hofstadter

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 14:45:37 -0400

On Jul 22, 2014, at 2:36 PM, Chris Elliott <[email-masked]> wrote:
> I suggest that the moderators share a mailing list with a private archive and copy said list on all private comments. 
> 
> That way, first, the moderators can monitor themselves as a group, and the Sargent-at-arms and those with a need to know can access the archive should there be a complaint about a moderator's comments.

This sounds reasonable, although it will probably involve some tools work...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Jul 2014 15:20:49 -0400

> dinged for doing even that minimum.)

No, the SaA is called in to deal with problems. The proposal here
seems to be that the moderators would be pro-active and act on their
own initiative.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jul 2014 15:21:18 -0400

>This sounds reasonable, although it will probably involve some tools work...

Cart meet horse.   

First we decide if there's a consensus that there's a problem.

Then we decide what approach to take to mitigate the problem.

And THEN we talk about the details (e.g. the mailing list as above).

Keep in mind that I'm not in agreement that the IESG gets to "decide" in this case. I find discussions that assume that as fact somewhat problematic.

Mike

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jul 2014 15:27:53 -0400

No hats...

> First we decide if there's a consensus that there's a problem.

There's a problem.  To the point where it drives people (further) away
from this list.  This list is important to raise last call issues, as
well as other important issues.  Some dialog is perfectly
understandable.  But one recent discussion demonstrated that even the
last call discussion got out of hand.  We need mechanisms for things to
get back in hand.

> Then we decide what approach to take to mitigate the problem. 

I don't think all this mechanism is necessary or appropriate at this
stage, since what we are talking about is people who are meant to call
on people to moderate their own behavior.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jul 2014 15:31:21 -0400

At 01:16 PM 7/22/2014, Pete Resnick wrote:
>I absolutely agree, with the caveat that "remonstrate" is probably a bit strong. I'd hope that that the moderator would be there to guide the discussion before remonstration is necessary.

When people argue about my word choices, I tend to go back to the dictionary to confirm I meant what I said.

In this case:

>intransitive verb
>:  to present and urge reasons in opposition :  <http://www.merriam-webster.com/dictionary/expostulate>expostulate usually used with with 

I think this is pretty close to what I meant.  Chide, correct or amend would not be incorrect either.

If the "moderator" steps in too early, too often, the back lash will put paid to the experiment. So I expect that there will be an element of correction from the formal "facilitators" or silence.

Assuming of course that the IETF agrees to this.

Mike

---

From: John W Noerenberg II <[email-masked]>
Date: Tue, 22 Jul 2014 12:32:48 -0700

At 10:24 AM -0400 7/22/14, IETF Chair wrote:
>The IESG has discussed this and plans to add moderators to manage 
>the list discussion. The moderators will track and guide discussions 
>and remind people when they get outside of the lines. Please respect 
>the feedback from the moderators when they say, for instance, that 
>an issue has been already previously discussed.

and so the fun begins.  I might actually go for the kettle corn for 
this.  3 bags, at least.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 22 Jul 2014 15:51:39 -0400

On 7/22/14 3:31 PM, Michael StJohns wrote:
> If the "moderator" steps in too early, too often, the back lash will 
> put paid to the experiment. So I expect that there will be an element 
> of correction from the formal "facilitators" or silence.

We have, over the years, have had chairs who only step in to working 
group discussions when it's time to chide or correct people. We've had 
other chairs who are very proactive, who guide this discussion by saying 
things like, "It sounds to me like the conclusion of this discussion is 
X. Anyone disagree with that, or are we done?" Which model gets used 
depends on the particular chair and their skill level, the participants 
and their interaction mode, and sometimes even the tone of a particular 
discussion. Sometimes "guidance" will work well, and sometimes 
"remonstration" is the only thing one can do.

I think on the IETF list, this will depend on the abilities of the 
moderator/facilitator/whateverator, and depend on the discussion being 
moderated/facilitated/whateverated.

pr

---

From: Scott Brim <[email-masked]>
Date: Tue, 22 Jul 2014 16:04:45 -0400

I'm just concerned about people who see moderating as their "job". If your
job is to look for problems, you will find them, or else you will look like
you're not doing your job, not demonstrating sincerity, not getting your
name out in front of people, etc.

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jul 2014 06:34:29 +0200

Thanks. I thought this list issue was solved/organised as any IETF list
should be moderated some how through our procedures as IETF is an
organisation. This list belongs to General Area, so IMHO each IETF list
MUST be connected to an Area, and it's AD is responsible as well with
moderators. However, I support the plans as long moderators follow some
clear procedure that can be used while they post (they need to include
procedure texts in their posts).

AB

On Tuesday, July 22, 2014, IETF Chair wrote:

> The [email-masked] <javascript:;> list is very active. It hosts varied
> discussions ranging from last calls to IETF organisation matters to any
> Internet technology-related topics that come up. We all have seen how much

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jul 2014 10:40:41 -0400

Following up on some of the Plenary discussion:

1) 'Newbies' and 'Clueless people'

There are some folk who come to the list with proposals that are
clearly deranged. The guy proposing that TCP/IP should switch from
using square packets to round ones for instance.

That said, if there is one thing that is likely to set me off it is
when I see someone make a perfectly sensible proposal on the list and
gets back a response of the form 'This is insane and if you understood
anything about the subject area you would know why'.

When I see people trying to pull rank to squish ideas, I think it is
incumbent on the rest of us to respond.

2) 'Already agreed'

I have great difficulty in determining what is 'already agreed' in an
organization that has no democratic decision making process. The IESG
can make decisions for the IESG but those are not necessarily
decisions of the IETF. We don't have an architecture board any more
since the legendary Kobe event.

But another problem with 'already agreed' is that most often the
people prating some dogma don't realize that (1) they are repeating a
slogan summarizing what was a subtle, highly nuanced argument and (2)
the Internet of 2 billion users is very different to the Internet of
the 1970s when some of these slogans were coined.

Take being permissive in what you accept. We built HTML on that
principle. It was a mistake. The problem is that people don't write
HTML to the spec, they suck-it-and-see. And most times they only try
one browser. So the behavior of browsers has become bizarrely
non-deterministic.

Recourse to the End-To-End protocol is also common. But rarely do I
hear people use it to say 'we should stop allowing SMTP mail servers
damaging messages by wrapping lines to fit messages into a VT100
terminal' which is the type of argument that it applies to. Instead it
is used as an all purpose cudgel to beat up opponents by reference to
irrelevant authority.

Modern IP networks actually do a lot of work at places other than the
endpoints and there are sound architectural arguments for doing so. I
have over a hundred IP enabled devices in my house. Some of those are
things like light switches, coffee machines, daleks, laundry, etc. I
don't want to have to install anti-virus on an arduino. Having worked
in industrial control, I want to be able to find out the purpose of
every packet on my network. And that means having a front door and
only letting in packets that I think I want.

3) Never the right time

One of the process abuses that annoys me the most is when people find
that there is never a right time to raise their objection. During
charter formation they will be told that the focus must be highly
restricted to get anywhere. During the Working Group they are told it
is not in the charter. Then decisions get made that pre-empt their
proposal completely and they are told that it is too late THEY SHOULD
HAVE RAISED THEM EARLIER.

This has happened to me more than once and it is the reason that there
are some people I won't work with because that type of behavior has
consequences as far as I am concerned.

If the IESG does not want to have that sort of unpleasantness appear
on IETF list then they need to be more pro-active in making sure the
problem doesn't arise.

These days when someone tries to tell me 'you can't raise that now' I
ask when I can raise it and try to get a statement to that effect from
an AD.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 24 Jul 2014 10:50:35 -0400

Well said Phillip.

One question:

Phillip Hallam-Baker wrote: (snipped)
> We don't have an architecture board any more since the legendary Kobe event.
>

Perhaps not quite legendary to those of us who weren't there.  Can you 
elaborate on the "legendary Kobe event," and why we no longer have an 
architecture board?

> 3) Never the right time
Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jul 2014 11:14:48 -0400

In discussions it seems to me that "redit" (which I've rarely used),
and/or uservoice/stackexchange.com style (see, for instance
http://serverfault.com/), which I've used a lot, is actually
exactly what we *DO* want for IETF Last calls.

I think that much of the software is open source (and perhaps the
comment stream could be turned into emails that those who
won't use web browsers can read, but also it would make a better long term
archive).

In the end, I think that IETF Last Calls actually do benefit from +1's on
well reasoned comments/objections.  Stackexchange also has -1s.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 04:51:17 +1200

I'm going to be contrarian.

I think [email-masked] is *exactly* what we want for IETF last
calls. Most last calls are silent. Some trigger a small,
non-annoying amount of technical discussion. The remaining
ones cause mailstorms. Those are exactly the ones I, as an
IETF citizen, want to know about. They tell me that the IETF
is about to do something controversial, and I need to have
a careful look to see if I care. If I decide that I don't care,
it's trivial to ignore the thread.

This essential feature would be lost if the last call traffic
was hidden in some place dedicated to the particular draft;
I'd never be aware that there was a controversy.

To say that another way: a last call message on IETF-announce
would at most attract the attention of people who already care.
A last call mailstorm here will attract the attention of
people who ought to care, and slightly interrupt the viewing
experience of people who don't care.

That said, I'm all for attempting to dissuade inappropriate
messages during such a mailstorm. But the mailstorm itself
has value.

    Brian

---

From: Pete Resnick <[email-masked]>
Date: Thu, 24 Jul 2014 13:20:47 -0400

I agree with Brian on the important outcome of having everyone be able 
to watch the mailstorm, but there are other ways to accomplish the same 
task:

- We could have a separate [email-masked] list that only had last 
calls. That would eliminate side discussions about IANA transitions and 
the importance of cookies.

- We could have each Last Call announced on ietf-announce with a 
specific list, say, <draftname>[email-masked], for Last Call 
comments on that particular. We could make [email-masked] a 
read-only list that would get a copy of everything to 
<draftname>[email-masked]. That way, it would be straightforward to 
separate the threads for the different Last Calls (and have the chair or 
AD who is running the Last Call lead their particular discussion), but 
still allow everyone to see the mailstorm if they subscribed to 
[email-masked].

We've got to decide what we want to accomplish out of this task (as was 
mentioned in several ways last night) and lay out the different 
side-effects of changing how we do things. Back in the day, I thought it 
a perfectly sane move to separate the regular ietf-announce list from 
the i-d-announce list. Perhaps separating out Last Calls (with different 
possible variants, examples above) makes sense too.

I did hear last night, as I've been hearing for a long time, that 
*something* not-so-good is going on, and that we should at least 
consider the changes we might make *and* consider side-effects of such 
changes before we make them. We obviously shouldn't try to engineer on 
this list every last detail of how things might work, but general ideas 
about how we might arrange things and comments like Brian's about 
possible bad side-effects are exactly what we need to be thinking about.

pr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 13:29:32 -0400

I think the observation you are making (mailstorm as evidence of controversy) is interesting, but I'm not convinced that mailstorms are the only or best way to identify such documents.   And given that we have the existence proof that the current solution is dissatisfactory to at least half the people who came to the plenary last night, I think we need to come up with something better.

It would be good if we could figure out a way that that something better would address your need.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Jul 2014 12:42:48 -0500

On Jul 24, 2014 1:22 PM, "Pete Resnick" <[email-masked]> wrote:
>
> I agree with Brian on the important outcome of having everyone be able to
watch the mailstorm, but there are other ways to accomplish the same task:

Keeping in mind that if I learned anything in the past week, it's that the
IESG doesn't need to whip up detailed proposals during IETF week ...

I'd be a better AD if Last Call discussions worked something like the way
Pete described below.

Spencer

> - We could have a separate [email-masked] list that only had last
calls. That would eliminate side discussions about IANA transitions and the
importance of cookies.
>
> - We could have each Last Call announced on ietf-announce with a specific
list, say, <draftname>[email-masked], for Last Call comments on that
particular. We could make [email-masked] a read-only list that would
get a copy of everything to <draftname>[email-masked]. That way, it
would be straightforward to separate the threads for the different Last
Calls (and have the chair or AD who is running the Last Call lead their
particular discussion), but still allow everyone to see the mailstorm if
they subscribed to [email-masked].
mentioned in several ways last night) and lay out the different
side-effects of changing how we do things. Back in the day, I thought it a
perfectly sane move to separate the regular ietf-announce list from the
i-d-announce list. Perhaps separating out Last Calls (with different
possible variants, examples above) makes sense too.
> I did hear last night, as I've been hearing for a long time, that
*something* not-so-good is going on, and that we should at least consider
the changes we might make *and* consider side-effects of such changes
before we make them. We obviously shouldn't try to engineer on this list
every last detail of how things might work, but general ideas about how we
might arrange things and comments like Brian's about possible bad
side-effects are exactly what we need to be thinking about.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jul 2014 13:54:00 -0400

> elaborate on the "legendary Kobe event," and why we no longer have an

I was not their either. But here is my interpretation of what was going on.

The received version is that the IAB cut a backroom deal with OSI to
settle the IPv4 address space exhaustion issue with a move to the OSI
stack. This obviously did not fly with the IETF participants and there
was a major row. This had three lasting consequences, first any future
co-operation with OSI was abandoned, second the NOMCON process was
invented to address complaints about the lack of influence in the
management of the organization while making sure that it would remain
in the hands of the 'right' people and the IAB stopped attempting to
do architecture.

As we all know the IETF has its roots in the ARPANET. At the time of
Kobe the management of the IETF was dominated by current and former
DARPA program managers and principal investigators but the membership
was considerably more diverse. So the Kobe rebellion was really the
point at which the participants told the management that IETF was not
going to be an appendage of DARPA any more and threatened to fork the
IETF if they didn't agree.

Bringing it back to the current governance issues it might be useful
to point out that the IETF declared independence from the US
government back in the 1990s and is already a thoroughly independent
body that is in practice accountable only to the Internet Society and
various sugar daddies and that to a limited degree.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 Jul 2014 11:02:01 -0700

Hi Phillip,
>anything about the subject area you would know why'.

What is considered as perfectly sensible is subjective.  I would not 
label someone as clueless as I consider it as a rude ( 
http://www.ietf.org/mail-archive/web/diversity/current/msg00251.html ).

>incumbent on the rest of us to respond.

That's not a good career move.

>since the legendary Kobe event.

I don't think that the architecture board pays much attention to 
architecture in IETF drafts.  Some years ago, it could be blamed on 
Kobe.  Nowadays, there isn't any incentive to do that 
work.  Architecture is left to industry consortiums.

>the 1970s when some of these slogans were coined.

Yes.

It is bad form to question an Area Director when he or she says 
"already agreed".

>HAVE RAISED THEM EARLIER.

In my opinion the IESG would like to get feedback when they sent out 
a charter for review.  I don't know the level of feedback it 
receives.  If I had Recall privileges I would consider using it when 
there are process abuses.

The following question may be relevant:

   'Is the proposed work plan an open IETF effort or is it an attempt
    to "bless" non-IETF technology where the effect of input from IETF
    participants may be limited?'

And:

   The interest must be broad enough that a working group would not be seen
   as merely the activity of an industry consortium.

Regards,
S. Moonesamy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Jul 2014 14:28:24 -0400

On Jul 24, 2014, at 1:20 PM, Pete Resnick <[email-masked]> wrote:

> I agree with Brian on the important outcome of having everyone be able to watch the mailstorm, but there are other ways to accomplish the same task:
> 
> - We could have a separate [email-masked] list that only had last calls. That would eliminate side discussions about IANA transitions and the importance of cookies.
> 
> - We could have each Last Call announced on ietf-announce with a specific list, say, <draftname>[email-masked], for Last Call comments on that particular. We could make [email-masked] a read-only list that would get a copy of everything to <draftname>[email-masked]. That way, it would be straightforward to separate the threads for the different Last Calls (and have the chair or AD who is running the Last Call lead their particular discussion), but still allow everyone to see the mailstorm if they subscribed to [email-masked].
> 
> We've got to decide what we want to accomplish out of this task (as was mentioned in several ways last night) and lay out the different side-effects of changing how we do things. Back in the day, I thought it a perfectly sane move to separate the regular ietf-announce list from the i-d-announce list. Perhaps separating out Last Calls (with different possible variants, examples above) makes sense too.
> 
> I did hear last night, as I've been hearing for a long time, that *something* not-so-good is going on, and that we should at least consider the changes we might make *and* consider side-effects of such changes before we make them. We obviously shouldn't try to engineer on this list every last detail of how things might work, but general ideas about how we might arrange things and comments like Brian's about possible bad side-effects are exactly what we need to be thinking about.

I think trying some discussion forum, such as Disqus or one of the things MCR suggested would be a good experiment. 

So we can choose 2-3 documents, and when they get to IETF LC, we add to the announcement a message that says that for that document the discussion takes place at this link.

Then we create a page with the text of the draft (+ iinks to the WG page and mail archive), and add at the bottom a Disqus message widget. We can even make the document shepherd the moderator for this forum.

IETF LC is supposed to get review and comments from the entire community. What we heard at the plenary is that a large part of the community doesn’t want to participate in the IETF mailing list. I think that would be a worthwhile experiment.

Yoav

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 08:10:41 +1200

On 25/07/2014 05:54, Phillip Hallam-Baker wrote:
...

> I was not their either. But here is my interpretation of what was going on.

Interpretation indeed.

> stack. 

I very much doubt that there was a backroom deal; that's conspiracy
theory. For many people, it was actually the obvious thing to do.

> This obviously did not fly with the IETF participants and there
> co-operation with OSI was abandoned, 

Not at all. In fact, twenty years minus one week ago, during IETF 30,
after the IPng->IPv6 decision was announced, I sat on a bench alongside
University Ave about three blocks from here, drafting (with pen and
paper) what later became RFC 1888 (OSI NSAPs and IPv6). That was a
direct collaboration between several IETF participants and a couple of
OSI participants (whether they were affiliated with ISO or ITU is
fairly irrelevant). Actually we tried quite hard to maintain good
relations with the OSI community, but they vanished.

> second the NOMCON process was

That is not true. The IAB stopped being responsible for approving
Internet standards; that job was transferred to the IESG. The IAB
still has architecture in its name and its charter. As to what
we mean by "architecture" ... well, that is exactly why the IAB
did RFC 1958 (while I was IAB Chair) and later added language to
the IAB charter (RFC 2850 section 2.1).

> various sugar daddies and that to a limited degree.

Yes, if we were no longer perceived useful by a certain number
of companies, participation and funding would tail off. I'm not
sure we provide the kind of services that sugar daddies normally
expect, however.

     Brian

---

From: Avri Doria <[email-masked]>
Date: Thu, 24 Jul 2014 23:39:36 -0400

Hi,

I tend to agree with Brian on this.

avri

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jul 2014 00:35:32 -0400

Well said.  A mail storm at least gets me to see what the fuss is all about. e.g.; the http "prefer:safe" header and know I am aware of possible work areas.   The nullmx proposal is another where MTA vendors have to be their faith on the draft author and others that say there is mom problems with this.  As a side related note, I think the recent trend for fast tracking of documents can and does contribute to conflicts, i.e. lower quality, not enough review, etc.

> On Jul 24, 2014, at 12:51 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Jul 2014 10:43:25 -0400

Before we close on this, another point of cluelessness is that it
comes in two kinds

One kind is that in a network of 2 billion users you are going to find
some people who are genuinely mentally ill making paranoid accusations
and generally being a problem. But thats a very small problem.

The other is the case where someone is clueless about IETF process or
protocols but has a problem they need to solve. And most often they
will present their problem in the form of a proposal for a solution.

Reject the proposed solution as clueless without thinking about it and
you also reject any attempt to solve the problem.

A slight variant of that is when there is a tension between two
different objectives and someone is defending one pole and rejecting
any attempt to address the other.

Case in point here is the frequent insistence on protecting the
privacy of opposition movements in repressive countries. Which is of
course an important objective but not actually the only or most
important one if you want to get rid of said repressive governments.
'Because freedom' is not looking into the totality of requirements.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 26 Jul 2014 11:45:58 -0400

> any attempt to address the other.

Recent discussions of DMARC p=reject have flavors of these.

Miles Fidelman