IETF Anti-Harassment Procedures
draft-farrresnickel-harassment-10

Secretary (Bcced),

This draft is approved. Please send the approval announcement and work the rest of your magic.

All,

I want to thank Pete and Adrian and everyone else for their very hard work on this. This has taken longer than needed, and there were surprises along the road when that we had hit. But I think it is now done.

For what it is worth, I know it is not perfect, but I think it is the best we can construct under the circumstances, and I think we can move forward. As happens with some other things in our societies as well, the IETF discussion focused more on the process than practical ways of helping those who need help. The final version of the draft does have text about the important function of the Ombudsteam being to provide advice and counsel for participants (Sect. 4). The formal duties are there for the situations that need it, but I consider our earlier policy statement and that counsel function as the most important things we have done in this matter.

The last discuss was from Stephen, on points that I sympathise with. I think though that on the point about the aspirational goal you are perhaps right but also in the rough :-) With regards to the statement regarding laws, my read of that statement is that it binds the IETF very little, but our legal advice recommended it be included, for reasons that I think are reasonable. I do think though that the likelihood of that statement affecting our situation in any way was small.

I have decided that the current language should stay.

As this is now approved, we have an important task of setting up the team and associated machinery. I have made some preliminary inquiries - expect some follow up soon on this.

Jari

[Ballot comment]

I'm sorry to move from a yes ballot to an abstain on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this a while
back for -05. I'm entirely happy that the authors have been
trying to handle the usual diverse IETF participant input
so me moving to abstain is just one of those things and
does not mean I think the ombudsteam process being
established is flawed. The document has ended up with
sufficient flaws though that me abstaining and getting out
of the way is the better path.

My last discuss text (prior to abstaining is below).

START last-discuss-text

I've chatted (via IM) with Pete about the -10 version and I
cleared point 3, we agreed that point 2 is for Jari to go and
check with the lawyers, (or to decide to not do that) and we
developed a set of OLD/NEW changes for points 1, 4 and 5.
My plan is to move to a yes if all of those go my way, but to
an abstain if not (with the relevant remaining discuss points
turned into comments).

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated.
IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to all the laws of all countries all at once.
This seems to assert that and that there is IETF
consensus for that assertion. I don't believe either
is true and believe this sentence should be deleted.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those.  Put another way: I read this as saying that we're asserting
that at any given time the IETF will have consensus on the
relevance of every applicable law everywhere. I do not think
such an IETF consensus exists or can exist.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
So this one is now for Jari to ask Lawyer: given the above
interpretation, wouldn't it be better to remove the sentence
since it could do harm and not match IETF consensus if included?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.
A suggested OLD/NEW:
OLD:
  It should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.
NEW
    As the Ombudsteam function is seen to be improving the IETF
  and gains the respect of participants over time,
  it should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.
The following change would however fix this:
OLD
is to prevent all
NEW
is to deal with and discourage

END last-discuss-text, old non-discuss comments are
below here.

(I didn't check -10 against these comments - I'm fine to chat
more about them if the authors want but I suspect we'd all
prefer to get this out the door instead.)

Some of my comments on the changed text here are close to
discusses, but I think if we resolve the discusses then we'll
hopefully also fix what needs fixing below.

- intro, 2nd last para: I'd prefer s/intended/only intended/
I do think we should ensure that the ombudsteam can't get out
of control, to the extent any formalism would help there.

- section 2, 3rd last para: What is the sentence starting
with "One way..." supposed to mean? Are you trying to get at
situations where someone demands favours of some kind (e.g.
sexual?) in return for doing what they ought in any case do?
I don't think it's useful to be unclear like that.

- 3.5: Say if someone refuses to accept that a report has
been dealt with for 5 years. Does the lead ombudsbeing
continue to be part of the team for all of that time? Do they
only handle the existing "case"? Is there no way to hand off
and finally free our poor ombudsbeing in such a case? (There
will be reporters who don't want to let go, and that could be
a problem for team members.) Just extending the term isn't a
good plan I believe.

- 4.1: The respondent is not obliged to co-operate is a
tautology and should be omitted. "May consider failure to
co-operate" sounds a bit too threatening and is it really
needed or useful here?

- 4.1: All reports in writing? Why? I think that's a detail
for the ombudsteam and they ought be allowed to decide that a
word in the ear is the most effective thing to do. I of
course agree that all reports of substance need to be dealt
with in writing, but even in that case, I don't think you
mean that the reporter has to use writing to report.

- 5.1: Why does 5.1 say "Per section 5.1"?

- 5.1: The two places you say that folks are not qualified
are not needed (recall ctte and appointing body) and are I
think counterproductive. Any such set of IETFers is actually
reasonably likely to have some qualified folks and some not.
(And for everyone to believe themselves qualified.) I think
you want to say that (over time) we ought (grow to) respect
the ombudsteam decisions which is a good goal, (over time)
but one that can only be reached (over time) with good
demonstrated performance and respect can't just be declared
to be required.

- 5.1: The AD specific bullet is odd.  What if the remedy is
to be applied to an IAB programme lead or liaison manager or
directorate secretary? I think you could generalise, but at
that point it's probably so obvious as to not need saying.
Maybe delete that bullet.

- 5.1, the last-resort bit: this is good but I think s/should
consider/must consider/ is needed there. I can't see there
being a case where the ombudsbeing wouldn't consider a lesser
remedy and if they ever get to the last resort they really
had better have documented (internally) that they did
consider lesser remedies.

- section 8: this is not only a summary, the last point
was not previously made. I didn't check all the others.

comments on text previously reviewed:

- section 2: the term "potential harrassment" is weird, esp
in "reports potential harrassment" - this would allow a
reporter Bob to say that Charlie might be able to harrass
Alice. That is always true.

- 3.1: The 1st and 2nd sentences here contradict one another.
Rewording can fix, e.g. s/shall/ought/ and s/will rapidly/
should rapidly/

- 3.2: "may consider elements of diversity" is bogus. Of
course the IETF chair can do that. If we want the IETF chair
to do so, we should say they ought, not that they may. Strike
this or s/may/ought/

- section 4: Will normal web access logs to related web pages
be kept? Maybe this'd be better on another domain?

- 4.1: The ombudsteam set their own procedures but if the
community are unhappy with those the only recourse is the
(never used) recall for the IETF chair? That's not going to
happen. I think you're missing a middle step where the IETF
chair should fire the ombudsteam if the community don't
accept team practices and the team don't fix those in
response.

- 4.1: This dives into too much detail in a number of ways.
Let the team figure out those details.  E.g., saying "do like
nomcom" is a bit strong here, I'd allow the team to decide
that. They could e.g.  prefer to use some kind of
whistleblower technology and no email at all. (The statement
isn't entirely broken as-is, but is also not needed.) One
could maybe say that the team need to be at least as careful
as nomcom should be.

- 4.1: The shall in "shall not be subject to retaliation" is
wishful thinking. Nobody can control that. I think you want
to say that good-faith reports ought not by themselves be
considered a negative and that this is something on which the
IETF has consensus.

[Ballot discuss]

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this a while
back for -05.

I've chatted (via IM) with Pete about the -10 version and I
cleared point 3, we agreed that point 2 is for Jari to go and
check with the lawyers, (or to decide to not do that) and we
developed a set of OLD/NEW changes for points 1, 4 and 5.
My plan is to move to a yes if all of those go my way, but to
an abstain if not (with the relevant remaining discuss points
turned into comments).

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated.
IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to all the laws of all countries all at once.
This seems to assert that and that there is IETF
consensus for that assertion. I don't believe either
is true and believe this sentence should be deleted.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those.  Put another way: I read this as saying that we're asserting
that at any given time the IETF will have consensus on the
relevance of every applicable law everywhere. I do not think
such an IETF consensus exists or can exist.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
So this one is now for Jari to ask Lawyer: given the above
interpretation, wouldn't it be better to remove the sentence
since it could do harm and not match IETF consensus if included?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.
A suggested OLD/NEW:
OLD:
  It should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.
NEW
    As the Ombudsteam function is seen to be improving the IETF
  and gains the respect of participants over time,
  it should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.
The following change would however fix this:
OLD
is to prevent all
NEW
is to deal with and discourage

[Ballot discuss]

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this a while
back for -05.

I've chatted (via IM) with Pete about the -10 version and I
cleared point 3, we agreed that point 2 is for Jari to go and
check with the lawyers, (or to decide to not do that) and we
developed a set of OLD/NEW changes for points 1, 4 and 5.
My plan is to move to a yes if all of those go my way, but to
an abstain if not (with the relevant remaining discuss points
turned into comments).

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated.
IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
So this one is now for Jari to ask Lawyer: given the above
interpretation, wouldn't it be better to remove the sentence
since it could do harm and not match IETF consensus if included?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.
A suggested OLD/NEW:
OLD:
  It should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.
NEW
    As the Ombudsteam function is seen to be improving the IETF
  and gains the respect of participants over time,
  it should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.
The following change would however fix this:
OLD
is to prevent all
NEW
is to deal with and discourage

[Ballot comment]

(I didn't check -10 against these comments - I'm fine to chat
more about them if the authors want but I suspect we'd all
prefer to get this out the door instead.)

Some of my comments on the changed text here are close to
discusses, but I think if we resolve the discusses then we'll
hopefully also fix what needs fixing below.

- intro, 2nd last para: I'd prefer s/intended/only intended/
I do think we should ensure that the ombudsteam can't get out
of control, to the extent any formalism would help there.

- section 2, 3rd last para: What is the sentence starting
with "One way..." supposed to mean? Are you trying to get at
situations where someone demands favours of some kind (e.g.
sexual?) in return for doing what they ought in any case do?
I don't think it's useful to be unclear like that.

- 3.5: Say if someone refuses to accept that a report has
been dealt with for 5 years. Does the lead ombudsbeing
continue to be part of the team for all of that time? Do they
only handle the existing "case"? Is there no way to hand off
and finally free our poor ombudsbeing in such a case? (There
will be reporters who don't want to let go, and that could be
a problem for team members.) Just extending the term isn't a
good plan I believe.

- 4.1: The respondent is not obliged to co-operate is a
tautology and should be omitted. "May consider failure to
co-operate" sounds a bit too threatening and is it really
needed or useful here?

- 4.1: All reports in writing? Why? I think that's a detail
for the ombudsteam and they ought be allowed to decide that a
word in the ear is the most effective thing to do. I of
course agree that all reports of substance need to be dealt
with in writing, but even in that case, I don't think you
mean that the reporter has to use writing to report.

- 5.1: Why does 5.1 say "Per section 5.1"?

- 5.1: The two places you say that folks are not qualified
are not needed (recall ctte and appointing body) and are I
think counterproductive. Any such set of IETFers is actually
reasonably likely to have some qualified folks and some not.
(And for everyone to believe themselves qualified.) I think
you want to say that (over time) we ought (grow to) respect
the ombudsteam decisions which is a good goal, (over time)
but one that can only be reached (over time) with good
demonstrated performance and respect can't just be declared
to be required.

- 5.1: The AD specific bullet is odd.  What if the remedy is
to be applied to an IAB programme lead or liaison manager or
directorate secretary? I think you could generalise, but at
that point it's probably so obvious as to not need saying.
Maybe delete that bullet.

- 5.1, the last-resort bit: this is good but I think s/should
consider/must consider/ is needed there. I can't see there
being a case where the ombudsbeing wouldn't consider a lesser
remedy and if they ever get to the last resort they really
had better have documented (internally) that they did
consider lesser remedies.

- section 8: this is not only a summary, the last point
was not previously made. I didn't check all the others.

comments on text previously reviewed:

- section 2: the term "potential harrassment" is weird, esp
in "reports potential harrassment" - this would allow a
reporter Bob to say that Charlie might be able to harrass
Alice. That is always true.

- 3.1: The 1st and 2nd sentences here contradict one another.
Rewording can fix, e.g. s/shall/ought/ and s/will rapidly/
should rapidly/

- 3.2: "may consider elements of diversity" is bogus. Of
course the IETF chair can do that. If we want the IETF chair
to do so, we should say they ought, not that they may. Strike
this or s/may/ought/

- section 4: Will normal web access logs to related web pages
be kept? Maybe this'd be better on another domain?

- 4.1: The ombudsteam set their own procedures but if the
community are unhappy with those the only recourse is the
(never used) recall for the IETF chair? That's not going to
happen. I think you're missing a middle step where the IETF
chair should fire the ombudsteam if the community don't
accept team practices and the team don't fix those in
response.

- 4.1: This dives into too much detail in a number of ways.
Let the team figure out those details.  E.g., saying "do like
nomcom" is a bit strong here, I'd allow the team to decide
that. They could e.g.  prefer to use some kind of
whistleblower technology and no email at all. (The statement
isn't entirely broken as-is, but is also not needed.) One
could maybe say that the team need to be at least as careful
as nomcom should be.

- 4.1: The shall in "shall not be subject to retaliation" is
wishful thinking. Nobody can control that. I think you want
to say that good-faith reports ought not by themselves be
considered a negative and that this is something on which the
IETF has consensus.

[Ballot discuss]

(Minor addition to discuss#2 below, otherwise no change)

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
If we got that result, I'd be fine with that rationale for doing
the right thing:-)
So this one is now for Jari to ask Lawyer: given the above
interpretation, wouldn't it be better to remove the sentence?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.
A suggested OLD/NEW:
OLD:
  It should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.
NEW
    As the Ombudsteam function is seen to be improving the IETF
  and gains the respect of participants over time,
  it should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.
The following change would however fix this:
OLD
is to prevent all
NEW
is to deal with and discourage

[Ballot discuss]

(Minor addition to discuss#2 below, otherwise no change)

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
If we got that result, I'd be fine with that rationale for doing
the right thing:-)
So this one is now for Jari to ask Laywer: given the above
interpretation, wouldn't it be better to remove the sentence?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.
A suggested OLD/NEW:
OLD:
  It should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.
NEW
    As the Ombudsteam function is seen to be improving the IETF
  and gains the respect of participants over time,
  it should be enough that the Ombudsteam explains
  the severity of the situation, that they have considered other lesser   
  remedies, and that they deem the recommended remedy to be   
  appropriate.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.  "make sure" and "ensure" in the 2nd para are
also overstated.

[Ballot discuss]

(Minor addition to discuss#2 below, otherwise no change)

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
If we got that result, I'd be fine with that rationale for doing
the right thing:-)

(3) 5.1: The recall ctte can't re-evaluate? That is plain
odd.  Once matters are public to that extent I think that
forces a re-evaluation for the sake of fairness.  In cases
where e.g.  the IESG can quietly ask a chair to step aside
that's not an issue, but it certainly would be with a public
recall. A claim that the recall ctte aren't qualified is not
enough to justify a potentially unfair public process like
that IMO.

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.  "make sure" and "ensure" in the 2nd para are
also overstated.

[Ballot discuss]

(Minor addition to discuss#2 below, otherwise no change)

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or of creating an environment within the IETF that
  would be intimidating, hostile, or offensive in such a situation.

NEW:
  This document concerns itself with harassment that has the purpose or
  effect of unreasonably interfering with an individual's participation
  in IETF activities or harassment which creates an environment within the IETF that
  would be intimidating, hostile, or offensive.

In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
If we got that result, I'd be fine with that rationale for doing
the right thing:-)
(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.

(3) 5.1: The recall ctte can't re-evaluate? That is plain
odd.  Once matters are public to that extent I think that
forces a re-evaluation for the sake of fairness.  In cases
where e.g.  the IESG can quietly ask a chair to step aside
that's not an issue, but it certainly would be with a public
recall. A claim that the recall ctte aren't qualified is not
enough to justify a potentially unfair public process like
that IMO.

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.  "make sure" and "ensure" in the 2nd para are
also overstated.

[Ballot comment]
I cleared my discuss based on telechat discussion. I'm balloting "yes" because I think we need to have a policy on this, and have reached diminishing returns in attempts to tweak things. We need to close on this and get implementation experience. I hope that we will learn that something lighter weight and less formal will work in the long run.

Section 2:

-- Reporter vs Subject: There are several mentions of roles the reporter might fill if there is no subject. I assume that also applies to situations where the subject does not want to make themselves known. But it seems to open up the possibility of a reporter pursuing something against the wishes of the subject, and that if a subject exists that person should be able to shut things down at any time. Is that correct, and if so did I miss some place it was covered?

-- Stephen brought up the issue about creating a hostile environment, and mentioned the potential for situations where a hostile environment might be reasonable. In the paragraph starting with "This  document concerns itself...", there's a reasonableness standard applied to interfering with participation. Does that also apply to creating a hostile or intimidating environment?

-- I share Stephen's concern about the last paragraph incorporating laws from jurisdictions that we might not want to incorporate without examination.

Section 4:

-- Could the 2nd paragraph be expanded to cover some of Alissa's concerns?

-- 5th paragraph: "... how the reporter can handle"
Or subject?

Section 6:
  "All elements of the appeal, including the fact of the appeal, will be
  held in confidence, but will be recorded and held securely for future
  reference."

Why does an appeal of ombudsteam action require confidentiality beyond that already protected for the subject, reporter, and respondant. More to the point, I'm not sure why an ombudsperson would have an expectation of confidentiality about their own actions, beyond that incident to protecting the other parties.

[Ballot comment]
I cleared my discuss based on telechat discussion.

Section 2:

-- Reporter vs Subject: There are several mentions of roles the reporter might fill if there is no subject. I assume that also applies to situations where the subject does not want to make themselves known. But it seems to open up the possibility of a reporter pursuing something against the wishes of the subject, and that if a subject exists that person should be able to shut things down at any time. Is that correct, and if so did I miss some place it was covered?

-- Stephen brought up the issue about creating a hostile environment, and mentioned the potential for situations where a hostile environment might be reasonable. In the paragraph starting with "This  document concerns itself...", there's a reasonableness standard applied to interfering with participation. Does that also apply to creating a hostile or intimidating environment?

-- I share Stephen's concern about the last paragraph incorporating laws from jurisdictions that we might not want to incorporate without examination.

Section 4:

-- Could the 2nd paragraph be expanded to cover some of Alissa's concerns?

-- 5th paragraph: "... how the reporter can handle"
Or subject?

Section 6:
  "All elements of the appeal, including the fact of the appeal, will be
  held in confidence, but will be recorded and held securely for future
  reference."

Why does an appeal of ombudsteam action require confidentiality beyond that already protected for the subject, reporter, and respondant. More to the point, I'm not sure why an ombudsperson would have an expectation of confidentiality about their own actions, beyond that incident to protecting the other parties.

[Ballot comment]
Thanks for your work on this draft.  I have no new points to add, but am interested to follow the points raised by several ADs in this second review.

I didn't see anything that would prevent someone from multiple 2-year terms, so I think that text is ok if they are up for it as this is very difficult work.

[Ballot comment]
I'm sympathetic to the complaints people have shared about the level of complexity and formality in this document.

https://www.ietf.org/ombudsteam does not yet contain what Section 4 says it should contain (contact information, the list of people that are on the e-mail exploder, etc.). That doesn't matter at approval time, but should probably be updated before we announce approval.

I'm sympathetic to the idea that more than one or two people may end up knowing many/most of the details. Perhaps it would be helpful to

  o  The Ombudsteam shall strive to keep all information brought to it
      in strict confidence.  However, it is acknowledged that the
      operation of the Ombudsteam will necessarily involve sharing of
                                  ^^^^ say "may" instead of "will"?
      information within the team, and may require that the parties to
      the complaint (the Reporter, Respondent, and Subject) learn some
      of the confidential information. 
     
Thank you for adding Section 5.1. This covers the biggest issue we tripped over in the previous Last Call, and I know it wasn't easy, and I was one of the folks who said "why isn't the recall procedure sufficient?" on the previous iteration, so I probably wasn't as helpful as I wanted to be.

I don't know what to call the discussion around Alissa's Abstain ("an absticussion"???), but the proposed changes coming out of it are helping me, too.

[Ballot comment]
I've re-reviewed the whole document, as well as focusing on the diffs between the last time and now.  In the end I remain a "Yes", because I think it's important that we do this... but I share Alissa's concern about the over-formalized aspect of it.  It's a shame that we're in a place where that's necessary.  I'm afraid that there's no way we could possibly get consensus for any formal process without the sort of heavyweight specification we now have, which attempts to look into every nook and butter every cranny.

I think some of that could be mitigated by some extra stuff at the beginning of Section 4 that makes it clear that the first steps in a harassment complaint could be less formal.  A Subject could contact a Reporter, someone the Subject trusts, to get advice.  Perhaps that Reporter could work with the Subject to determine a course of action the Subject would feel comfortable with, and that course might include having the Reporter talk less formally with the Respondent or with others who could help the situation.  Section 4 might then say that if that sort of thing is not what the Subject wants, or if it's tried and doesn't work, the formal process could be taken on.

My point here is to make it clear that there are options -- that this is meant to provide a formal process for when that is needed, but that the most important thing is for harassment issues to be handled in a manner that the Subject feels comfortable with (and that, as Alissa says, the Subject is in control of).

I'm leaving this as a non-blocking comment.  I know that the informal handling that might happen before a complaint is formally given to the Ombudsteam is out of scope for this document, but I'd like to see some outline included to make it clear that the choices are not to live with the harassment, to leave, or to invoke some Obuds-nuclear-bomb, as it might seem.

[Ballot discuss]
I expect the following is just a matter of word smithing or my own comprehension, in which case I can quickly convert to a yes.

I am concerned about some text that repeats several times in section 5 for different responsible bodies/persons:

    "the Recall Committee is expected to
      understand that their investigation as described in [RFC7437] is
      not to re-evaluate the events of the harassment, and that they are
      not qualified in handling issues of harassment."

That can be construed to say that the responsible body cannot disagree with the recommendations of the ombudsteam. How can the body disagree without evaluating things? I don't think that is the intent. If the point is that they are not to re-investigate the facts of the matter, but may make their own decisions about the recommendations of the ombudsteam, I am fine with it--I'm just not sure the text supports that. (For the record, I do not object to the related expectation that responsible bodies take ombudsteam recommendations seriously.)

Along those lines, there is a several-times repeated expectation that responsible bodies/persons will follow the recommendations of the ombudsteam. I would prefer not to presume the actions of such bodies. This could be taken as an expectation to rubber-stamp things.

[Ballot comment]

Section 2:

-- Reporter vs Subject: There are several mentions of roles the reporter might fill if there is no subject. I assume that also applies to situations where the subject does not want to make themselves known. But it seems to open up the possibility of a reporter pursuing something against the wishes of the subject, and that if a subject exists that person should be able to shut things down at any time. Is that correct, and if so did I miss some place it was covered?

-- Stephen brought up the issue about creating a hostile environment, and mentioned the potential for situations where a hostile environment might be reasonable. In the paragraph starting with "This  document concerns itself...", there's a reasonableness standard applied to interfering with participation. Does that also apply to creating a hostile or intimidating environment?

-- I share Stephen's concern about the last paragraph incorporating laws from jurisdictions that we might not want to incorporate without examination.

Section 4:

-- Could the 2nd paragraph be expanded to cover some of Alissa's concerns?

-- 5th paragraph: "... how the reporter can handle"
Or subject?

Section 6:
  "All elements of the appeal, including the fact of the appeal, will be
  held in confidence, but will be recorded and held securely for future
  reference."

Why does an appeal of ombudsteam action require confidentiality beyond that already protected for the subject, reporter, and respondant. More to the point, I'm not sure why an ombudsperson would have an expectation of confidentiality about their own actions, beyond that incident to protecting the other parties.

[Ballot discuss]

(Minor addition to discuss#2 below, otherwise no change)

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have
to figure out which of all possible laws in the world are applicable,
and this sentence doesn’t add anything really, since the ombuds
get to decide how to handle any complaint, whether it falls
under any definition or not. So let’s just strike the sentence."
If we got that result, I'd be fine with that rationale for doing
the right thing:-)
(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.

(3) 5.1: The recall ctte can't re-evaluate? That is plain
odd.  Once matters are public to that extent I think that
forces a re-evaluation for the sake of fairness.  In cases
where e.g.  the IESG can quietly ask a chair to step aside
that's not an issue, but it certainly would be with a public
recall. A claim that the recall ctte aren't qualified is not
enough to justify a potentially unfair public process like
that IMO.

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.  "make sure" and "ensure" in the 2nd para are
also overstated.

[Ballot comment]
I am balloting ABSTAIN on this document because I did not manage to find time to provide my thoughts when the document was being developed and discussed in the community. I do regret that. It seems inappropriate to hold it up at this stage and given how much discussion has taken place.

When discussions about developing an anti-harassment policy first began I was in favor of the idea for two reasons. First, I thought we could improve the experience of attending IETF meetings by having a trusted person or people whom attendees could talk to and possibly strategize with if the attendees had experienced harassment. Second, I thought it was important to establish publicly the expectation that all attendees be treated with dignity, decency, and respect. The IESG policy accomplishes the second of these goals and this document seems aimed at accomplishing the first, among other things.

I do not believe the document accomplishes the first goal, however. This is because the procedures as outlined turn what could have been the key incremental improvement -- having a trusted person for attendees to talk to -- into a legalistic pile of process and communications that I believe will deter victims of harassment from making use of the system at all. When I have a sensitive incident to report, I want to report it to a single person whom I trust. I do not want to have to agree a priori to having that information shared with a team of three people, nor do I want to be re-directed to some other person who I perhaps trust less. I do not want the person to whom I report it to write it down. I just want to talk it through with the person. Then, if we both agree that some further course of action is warranted, I want to be involved in deciding what course of action I am comfortable with, and I want to continue to be involved in deciding whether to proceed at every step of the way, including steps that involve informing ADs, the secretariat, and other parties. I want to reserve the right to change my mind at any time. The problem with the document as written is that it severely disenfranchises the victim of the harassment, to the point where I expect that most victims would be afraid to actually make use of the procedures outlined in the document. Being harassed can be scary. The policies outlined in the document have utterly failed to account for that.

Furthermore, the document in sections 5.1 and 6 contemplates all manner of scenarios that may or may not come to pass and specifies detailed procedures for how to handle them. In practice I expect that there are probably scenarios we haven't thought of that will arise, while the ones for which detailed procedures have been specified might never get used. I wish we could have started with an incremental approach that achieves the two goals stated above, and then checked in after some implementation experience to see where the gaps are and what needs beefing up procedurally. Instead we are going from no process to an over-specified process without any implementation experience to build on.

I hope I'm wrong about the potential utility of the process specified in the document, but I cannot support it as written.

[Ballot discuss]
I reviewed the version 9. One point I want to discuss before moving back to a YES.


-
      It
      is not the intent that the AD re-evaluate the events, and the AD
      is expected to understand that they are not qualified in handling
      issues of harassment and they must preserve confidentiality.  The
      AD is strongly encouraged to discuss with the Ombudsteam in the
      event that the AD feels removal from position is not the correct
      remedy.

Btw, a nit: they -> he

It seems that the two sentences contradict each other.
"Strongly encouraged to discuss with the Ombudsteam in the event that the AD feels removal from position is not the correct remedy " but, at the same time, "is not the intent that the AD re-evaluate the events"
If the Ombudsteam is really in charge, if "The Ombudsteam is expected to strive for confidentiality" (so basically the AD shouldn't know all the details),  and if the "AD should not re-evaluate the events", should we remove this sentence?

      "The AD is strongly encouraged to discuss with the Ombudsteam in the
      event that the AD feels removal from position is not the correct
      remedy."

Same remark for:

      It is not the intent
      that the AD or WG chairs re-evaluate the events, and the AD and WG
      chairs are expected to understand that they are not qualified in
      handling issues of harassment and that they must preserve
      confidentiality.  The AD is strongly encouraged to discuss with
      the Ombudsteam in the event that they or the WG chairs feel
      removal from position is not the correct remedy.


- There is also an issue with the second part of this sentence that contradicts "is not the intent that the AD re-evaluate the events" :

      In the event that an AD declines to follow the recommendation of
      the Ombudsteam as described in the previous bullets, and if the AD
      fails to convince the Ombudsteam of the reasons for this

[Ballot comment]
The IESG statement must be updated with a link to the new BCP.
Whether this is done with "This IESG Statement is superseded by BCP xx" or "The IETF's procedures for handling cases of harassment are documented in BCP xx" is less important to me ... even if I have a small preference for the superseded version, as the BCP integrates the IESG statement definition.

[Ballot discuss]

I'm sorry to move from a yes ballot to a discuss on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this (which was
-05). I'm unsure if I'll be moving from discuss back to yes
or to abstain.  Other than as noted, my comments (and all
discuss points) are only on text changed since -05.

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. I think you need to
strike the text about "creating an environment that would be
intimidating."

(2) section 2, last para: I do not want the IETF to be
subject to the laws of all countries. This seems to do that.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those. This sentence should go, or should say something else.
Put another way: I read this as saying that we're asserting
that the IETF has consensus on every applicable law
everywhere. I do not think such an IETF consensus exists.

(3) 5.1: The recall ctte can't re-evaluate? That is plain
odd.  Once matters are public to that extent I think that
forces a re-evaluation for the sake of fairness.  In cases
where e.g.  the IESG can quietly ask a chair to step aside
that's not an issue, but it certainly would be with a public
recall. A claim that the recall ctte aren't qualified is not
enough to justify a potentially unfair public process like
that IMO.

(4) 5.1, 2nd last para: respect has to be earned it's not ok to
just say "ombudsteam => correct" for such a new construct. I
think this kind of text might be enough to be problematic
if/when someone goes to court and claims these are unfair
procedures.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me.  "make sure" and "ensure" in the 2nd para are
also overstated.

[Ballot comment]

Some of my comments on the changed text here are close to
discusses, but I think if we resolve the discusses then we'll
hopefully also fix what needs fixing below.

- intro, 2nd last para: I'd prefer s/intended/only intended/
I do think we should ensure that the ombudsteam can't get out
of control, to the extent any formalism would help there.

- section 2, 3rd last para: What is the sentence starting
with "One way..." supposed to mean? Are you trying to get at
situations where someone demands favours of some kind (e.g.
sexual?) in return for doing what they ought in any case do?
I don't think it's useful to be unclear like that.

- 3.5: Say if someone refuses to accept that a report has
been dealt with for 5 years. Does the lead ombudsbeing
continue to be part of the team for all of that time? Do they
only handle the existing "case"? Is there no way to hand off
and finally free our poor ombudsbeing in such a case? (There
will be reporters who don't want to let go, and that could be
a problem for team members.) Just extending the term isn't a
good plan I believe.

- 4.1: The respondent is not obliged to co-operate is a
tautology and should be omitted. "May consider failure to
co-operate" sounds a bit too threatening and is it really
needed or useful here?

- 4.1: All reports in writing? Why? I think that's a detail
for the ombudsteam and they ought be allowed to decide that a
word in the ear is the most effective thing to do. I of
course agree that all reports of substance need to be dealt
with in writing, but even in that case, I don't think you
mean that the reporter has to use writing to report.

- 5.1: Why does 5.1 say "Per section 5.1"?

- 5.1: The two places you say that folks are not qualified
are not needed (recall ctte and appointing body) and are I
think counterproductive. Any such set of IETFers is actually
reasonably likely to have some qualified folks and some not.
(And for everyone to believe themselves qualified.) I think
you want to say that (over time) we ought (grow to) respect
the ombudsteam decisions which is a good goal, (over time)
but one that can only be reached (over time) with good
demonstrated performance and respect can't just be declared
to be required.

- 5.1: The AD specific bullet is odd.  What if the remedy is
to be applied to an IAB programme lead or liaison manager or
directorate secretary? I think you could generalise, but at
that point it's probably so obvious as to not need saying.
Maybe delete that bullet.

- 5.1, the last-resort bit: this is good but I think s/should
consider/must consider/ is needed there. I can't see there
being a case where the ombudsbeing wouldn't consider a lesser
remedy and if they ever get to the last resort they really
had better have documented (internally) that they did
consider lesser remedies.

- section 8: this is not only a summary, the last point
was not previously made. I didn't check all the others.

comments on text previously reviewed:

- section 2: the term "potential harrassment" is weird, esp
in "reports potential harrassment" - this would allow a
reporter Bob to say that Charlie might be able to harrass
Alice. That is always true.

- 3.1: The 1st and 2nd sentences here contradict one another.
Rewording can fix, e.g. s/shall/ought/ and s/will rapidly/
should rapidly/

- 3.2: "may consider elements of diversity" is bogus. Of
course the IETF chair can do that. If we want the IETF chair
to do so, we should say they ought, not that they may. Strike
this or s/may/ought/

- section 4: Will normal web access logs to related web pages
be kept? Maybe this'd be better on another domain?

- 4.1: The ombudsteam set their own procedures but if the
community are unhappy with those the only recourse is the
(never used) recall for the IETF chair? That's not going to
happen. I think you're missing a middle step where the IETF
chair should fire the ombudsteam if the community don't
accept team practices and the team don't fix those in
response.

- 4.1: This dives into too much detail in a number of ways.
Let the team figure out those details.  E.g., saying "do like
nomcom" is a bit strong here, I'd allow the team to decide
that. They could e.g.  prefer to use some kind of
whistleblower technology and no email at all. (The statement
isn't entirely broken as-is, but is also not needed.) One
could maybe say that the team need to be at least as careful
as nomcom should be.

- 4.1: The shall in "shall not be subject to retaliation" is
wishful thinking. Nobody can control that. I think you want
to say that good-faith reports ought not by themselves be
considered a negative and that this is something on which the
IETF has consensus.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-09


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
This document changes IETF procedures and updates other IETF procedures.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Version 09 addresses the comments  gotten during last call

There are issues arrised during IESG Evaluation (http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ballot/) and in IETF mailing list after Last Call.
The plan is to correct the issues and start a new short Last Call on the corrections. --> Version 08 address these comments.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF. It got the review of several mailing list in the IETF, such as: IETF, diversity and systers.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document was discussed with HR personnel at ISOC (specifically Linda Klieforth) who reviewed the document for feasibility

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian Farrel confirmed. the author will retain their copyright and publish the material under CC0 on their own web site.
Pete Resnick confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

References [1] and [2] are going to be fixed by the RFC Editor




Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548

   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-08


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
This document changes IETF procedures and updates other IETF procedures.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

There was a last call for version 08 ending 09-21. Two comments to be addressed.

There are issues arrised during IESG Evaluation (http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ballot/) and in IETF mailing list after Last Call.
The plan is to correct the issues and start a new short Last Call on the corrections. --> Version 08 address these comments.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF. It got the review of several mailing list in the IETF, such as: IETF, diversity and systers.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document was discussed with HR personnel at ISOC (specifically Linda Klieforth) who reviewed the document for feasibility

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian Farrel confirmed. the author will retain their copyright and publish the material under CC0 on their own web site.
Pete Resnick confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

References [1] and [2] are going to be fixed by the RFC Editor




Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548

   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-farrresnickel-harassment-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IETF Anti-Harassment Procedures) to Best Current Practice

This document has been in last call previously, and one issue in particular
caused concern. A design team was  created in May 2015 to address this
issue, and the document has also otherwise been updated. See further
below for a detailed list of changes and history.

The sponsoring Area Director believes a new formal last call is needed
to ensure that the resulting document matches the community's
expectations on this important topic.

The sponsoring Area Director also believes that this is a topic where
it is important to have an official IETF policy. Policies relating to
human behaviour can be difficult topics to deal with, particularly
in the all-cases-fully-specified manner that we are accustomed in
our technical work. However, policies can be also be updated
if later experience proves they have issues.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

- 'IETF Anti-Harassment Procedures'
  as Best Current Practice

The file can be obtained via
https://datatracker.ietf.org/doc/draft-farrresnickel-harassment/

Changes since the previous last call can be seen via
https://tools.ietf.org/rfcdiff?url1=draft-farrresnickel-harassment-05.txt&url2=draft-farrresnickel-harassment-08.txt

Adrian Farrel, one of the document editors stated this as a summary
of the changes on the IETF list (the email is copied below and originally
from http://www.ietf.org/mail-archive/web/ietf/current/msg94129.html):

----

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.

Thanks,
Adrian

------

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!

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-08


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
This document changes IETF procedures and updates other IETF procedures.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

There are issues arrised during IESG Evaluation (http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ballot/) and in IETF mailing list after Last Call.
The plan is to correct the issues and start a new short Last Call on the corrections. --> Version 08 address these comments.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF. It got the review of several mailing list in the IETF, such as: IETF, diversity and systers.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document was discussed with HR personnel at ISOC (specifically Linda Klieforth) who reviewed the document for feasibility

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian Farrel confirmed. the author will retain their copyright and publish the material under CC0 on their own web site.
Pete Resnick confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

References [1] and [2] are going to be fixed by the RFC Editor




Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548

   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

I have decided to put the document to a last call. I think the changes are in the big picture the right
ones, and there’s a reasonable chance of attaining community (rough) consensus. I do think that
given the magnitude of changes, a formal last call is appropriate. Although I may not ask for full
four weeks.

I have comments that I list below, but I can send them during the last call period.

I also talked to Ines, and I asked if she is (a) happy with the resulting document herself
and that (b) she believes comments to date have been adequately addressed in the
new version. She promised to come back on that. Once she does, I make the final
decision to proceed.

My comments are all editorial and they are here:

Section 5:

o  At the other end of the spectrum the Ombudsteam could decide that
    the Respondent is no longer permitted to participate in a
    particular IETF activity, for example, ejecting them from a
    meeting or requiring that the Respondent can no longer attend
    future meetings.  If the Respondent holds a management position ...

I’d suggest adding a sentence here about the purpose of the remedy,
even if there’s a whole section about it later. For instance: “… no
longer attend future meetings as a way to ensure that  a serious
harassment can not continue. If the Respondent … "

Section 5.1:
  o  In the event that an AD declines to act on the recommendation of
      the Ombudsteam and fails to convince the Ombudsteam, the
      Ombudsteam should raise the issue with the whole IESG while
      continuing to attempt to retain confidentiality.  The IESG may
      choose to reorganize the responsibilities for working groups
      within its own structure so that the conflicted AD is no longer in
      the direct management path.

Where does “declines to act” refer to? The previous bullet item, where
an AD is expected to follow the advice of the ombudsteam? I that case
“conflicted” is probably the wrong term. I could imagine a disagreement
with regards to what should be done. "Disagreeing" may be the right term.
Although I’m not sure you want write that either, because as it stands
this paragraph would seem to imply that the team’s recommendations
are not just recommendations.

I’d suggest just saying “The IESG may make a new decision
regarding the recommendation."

Section 5.1:
  All such forced removals from management positions should be
  considered by the Ombudsteam as acts of last resort.  That is, before
  a Respondent is recommended for removal, the Ombudsteam should
  discuss the situation with the Respondent giving them ample
  opportunity to understand what might happen and to step down of their
  own volition.

This text could perhaps be modified to also account for the fact that
not only are these removals last resort in the above sense, but also
in the sense that not all situations require removal/stepping down.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-06


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
This document changes IETF procedures and updates other IETF procedures.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

There are issues arrised during IESG Evaluation (http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ballot/) and in IETF mailing list after Last Call.
The plan is to correct the issues and start a new short Last Call on the corrections.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF. It got the review of several mailing list in the IETF, such as: IETF, diversity and systers.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document was discussed with HR personnel at ISOC (specifically Linda Klieforth) who reviewed the document for feasibility

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian Farrel confirmed. the author will retain their copyright and publish the material under CC0 on their own web site.
Pete Resnick confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

References [1] and [2] are going to be fixed by the RFC Editor




Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548

   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

[Ballot comment]
Thanks for this document.

The IESG statement must be updated with a link to the new BCP.
Whether this is done with "This IESG Statement is superseded by BCP xx" or "The IETF's procedures for handling cases of harassment are documented in BCP xx" is less important to me ... even if I have a small preference for the superseded version, as the BCP integrates the IESG statement definition.

[Ballot comment]
This could have been a Discuss, but I don't think it needs to be ...

I struggle with this text in Section 5.  Remedies:

      At the other end of the spectrum the Ombudsteam could decide that
      the Respondent is no longer permitted to participate in a
      particular IETF activity, for example, ejecting them from a
      meeting or requiring that the Respondent can no longer attend
      future meetings.  (The Ombudsteam can recommend, but can not
      impose, that a Respondent who is in a IETF management position be
      removed from that position.  There are existing mechanisms within
      IETF process for the removal of people from IETF management
      positions that may be used as necessary.)
     
I don't understand how a recommendation for removal works in practice.

My understanding is that we're not adding a way to remove I-star folk from their positions, and what's available is the recall procedure in https://tools.ietf.org/html/rfc7437#section-7.

So, who would the Ombudsteam make a recommendation to, in order to remove a Respondent?



I suspect that the most the Ombudsteam could do, is to point out the existence of the recall procedure to the Reporter and/or Subject, and trust that the right thing happens.

My thought is that if privacy matters, having the Ombudsteam even initiate a recall petition tells the community quite a bit about what's happened ("the Ombudsteam is petitioning to recall Spencer, what did he do now?!?").

If a recall seems appropriate to the Reporter and/or Subject, they can tell as much or as little of their story as necessary, and they can decide what's necessary.

[Ballot comment]
One minor point, and some editorial nits:

There are a couple of instances of "... Reporter if there is no individual Subject".  Isn't it also possible that there is a specific Subject, but Reporter != Subject?  Or in this latter case, does the Reporter's involvement stop after the reporting, with the Subject being responsible afterward?  It might be helpful to clarify.

Nits:

Section 3.3: Are the quotes around "as needed" needed?

Section 3.6: Isn't "compensation" more common usage than "recompense"?

Section 4. Reference [3] seems kind of silly.  I hope this isn't an indication of the wonders that increased use of XML is expected to bring.

[Ballot comment]
Thanks for your work on this draft.  I have no new points to add, but like Barry will wait on the legal review.

I didn't see anything that would prevent someone from multiple 2-year terms, so I think that text is ok if they are up for it as this is very difficult work.

[Ballot comment]

- This defines harassment by reference to the IESG statement,
which does have a good enough definition, and that is quoted.
However, it's unclear unclear which text wins if the IESG
modify the definition in the IESG statement in some odd way.
While that's very unlikely, I like the idea of modifying the
IESG statement to say that the BCP wins.

- intro: "often more interpersonal" is odd, I think you just
mean "often more personal" actually

- intro: I think the sentence that "These procedures are
intended to be used when other IETF policies and procedures
do not apply or have been ineffective." should be in its own
paragraph. It's a standalone point and important and easy to
miss at the end of a paragraph.  A separate para there might
cause a reporter to first try a less nuclear option, which I
think is preferable in cases where it's correct.

- section 2: "interpersonal" again - I still think you mean
"personal"

- section 2: "is more easily handled by" is a pretty
confident prediction which is not what I think you meant. I
think what you're trying to say is something like "the more
the problem matches the definition of harassment, then the
more you should consider using this process instead of other
mechanisms"

- 3.5: Probably too late to do it now, but it might have been
nice if, before IETF LC, we'd thought to add "Given the
sensitivity of, and training required for, this role and the
ideal being a lack of activity, it is likely the IETF chair
may choose to re-appoint a successful and still-willing
ombudsperson for a number of two-year terms." If folks think
that would be ok to add now, then I think it might be useful
to set an expectation that 2 or 4 years is not the norm for
this one since I think if we do find good ombudspersonages we
probably want to keep 'em and aim for minimal turnover.

- section 4: https://www.ietf.org/ombudsteam is still a 404,
ombudsteam@ietf.org also bounces ("user unknown")  Please fix
soon and definitely before the RFC issues.  Immediately after
IESG approval is probably a good point in time to put things
in place, even if there aren't yet selected ombudsfolks

- 4.1: holy crap batman, we're recalling the entire IESG?
The language there seems a bit overblown;-)

- 11.2: use https URIs please, and [1] and [2] are the same;
is 11.2 normative or informative? (see my earlier point)

IESG/Authors:

IANA has reviewed draft-farrresnickel-harassment-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IETF Anti-Harassment Procedures) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'IETF Anti-Harassment Procedures'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  IETF Participants must not engage in harassment while at IETF
  meetings, virtual meetings, social events, or on mailing lists.  This
  document lays out procedures for managing and enforcing this policy.

  This document updates RFC 2418.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-05


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
This document changes IETF procedures and updates other IETF procedures.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF. It got the review of several mailing list in the IETF, such as: IETF, diversity and systers.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document was discussed with HR personnel at ISOC (specifically Linda Klieforth) who reviewed the document for feasibility

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian Farrel confirmed. the author will retain their copyright and publish the material under CC0 on their own web site.
Pete Resnick confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

References [1] and [2] are going to be fixed by the RFC Editor




Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548

   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-05


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
It is related with the correct behaviour of the IETF members.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

This section Not apply

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity, IETF, systers Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
Adrian confirmed. the author will retain their copyright and publish the material under CC0 on their own web site
Waiting for Pete Resnick confirmation

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.\
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548


   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

The references are going to be updated as normative

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The references are going to be updated as normative

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

Document Writeup - IETF Anti-Harassment Procedures - draft-farrresnickel-harassment-05


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Intended status: Best Current Practice

Why is this the proper type of RFC?
It is related with the correct behaviour of the IETF members.

Is this type of RFC indicated in the title page header?
Yes



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary

Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document?

It is a not technical topic, it is related with the behaviour of people into the IETF.


Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

This section Not apply

Personnel

Who is the Document Shepherd?
Ines Robles

Who is the Responsible Area Director?
Jari Arkko

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

This document was discussed basically in the diversity and ietf Mailing lists.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.
TBD.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.\
No

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?
The document is very clear, involved the opinion of members from diverses areas. The shepherd believe that it got consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. The lasts thread in ietf Mailing list were in march 2014, and the draft was updated in January 2015, no new comments gotten since then.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 5 comments (--).

Miscellaneous warnings:
  ----------------------------------------------------------------------------

    (Using the creation date from RFC2418, updated by this document, for
    RFC5378 checks: 1998-09-09)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

  -- The document date (January 6, 2015) is 9 days in the past.  Is this
    intentional?


  Checking references for intended status: Best Current Practice
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 542

  -- Looks like a reference, but probably isn't: '2' on line 545

  -- Looks like a reference, but probably isn't: '3' on line 548


   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not apply

(13) Have all references within this document been identified as either normative or informative?

As a no technical draft the references are mentioned just with the word "references"

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Not apply.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

This document update RFC 2418, it was mentioned in the abstract and mentioned in the introduction as well.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Not apply.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not apply.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not apply.

This was my AD review:

Refresh my memory on what Linda has said about this. Is she ok?

I have sent the draft to IAOC as the commitments for IETF funds should not come as a surprise to them.

In the meantime I have adopted the draft and performed an AD review.

I think it is ready to move forward, but I do have a couple of comments that might require changes. Please see below, most of these are question marks, and I might have missed something obvious. Let me know what you think. I’ve chatted a bit about these with Pete. I think he was fine with two first suggested changes, agreed there was an issue in the third (but it could be addressed in different ways), and he disagreed with the fourth one.

I have absolutely no problem with the two “open” issues.

I’m a bit concerned about the level of process implied for selections.

  The appointment is
  solely the responsibility of the IETF Chair although the Chair may
  choose to consult with the IESG, the IAB, and with the ISOC Board of
  Trustees.  Furthermore, the IETF Chair may take opinion from the
  community.

Which I think is formally fine. But if I were now to select some people with a call for volunteers, but not, e.g., consult one of the above leadership boards, would that be taken negatively? Or what if I ask ISOC CEO and not the board? I think you are being unnecessarily broad in the list above. Perhaps it would be better to generalise the text a bit and just say:

  The appointment is
  solely the responsibility of the IETF Chair although the Chair may
  choose to consult with the IETF or ISOC leadership, or listen for
  feedback from the community.

I’m also a bit wary about strong language regarding commitment to provide training. Of course we will provide training. However, do we really want to say

  Since all of these attributes may be regarded
  by the IETF Chair as essential for an appointment, the IETF is
  committed to provide funding for necessary training for appointed
  Ombudspersons. 

since I’m not sure all necessary training means, and we do not want to ask for our professional advisers to recommend training under all possible circumstances but rather what is reasonable for our situation. Also, we should be allowed to provide training rather than funding, if it suits our situation better. Finally, a team is a team and probably consists of people with complementary skills, even if basic ability to deal with these complex situations is necessary for everyone.

Suggested new wording:

  Since all of these attributes may be regarded
  by the IETF Chair as essential for the team, the IETF is
  committed to providing training (or funding for it) deemed necessary for each of
  the individual appointed Ombudspersons. 

It seems that there should always be a way to remove Ombudspersons by someone, even the IETF chair would be recused. But the text below seems to preclude that. Consider the degenerate case of IETF chair being the Reporter and one of the Ombudspersons being the Respondent.

  An Ombudsperson shall not be removed from service, even if their term
  has expired, if the IETF Chair is recused as described in
  Section 7

And in any case, the above text seems like a duplicate in some ways, because if, say, the IETF chair is recused, then at least the IETF chair is not removing anyone. I have no good text suggestion, but maybe I’m just misunderstanding something.

Pete says that once a case is closed, an Ombudsperson could be removed (eg., in my degenerate example above). That is a way to handle the situation, but even that might benefit from some explanation in the draft. There might be other approaches.

Finally, in other appeals we often have had a lead appeal handling AD. I’ve found such delegation useful. I’m not trying to evade the responsibility to deal with the harassment case appeals, but I wonder if it would be reasonable to leave room delegation of an appeal within the IESG? The text below seems to preclude this.

  In the event that there is an appeal and the IETF Chair is somehow
  involved, the Chair will immediately recuse themself and the IESG
  will select a single person to take the Chair's role in the appeal
  process.

You could perhaps say also “The IETF Chair may also, with the agreement of the IESG, delegate a specific appeal to be handled by another IESG member."