Subject: RE: [[email-masked]: Mismanagement of the DNSOP list]

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 27 Sep 2005 11:01:18 +0200

Steve writes:

> Actually, 3683 specifically requires community discussion of motions to 
> block someone's posting rights.  It is, in so many words, done by a 
> Last Call.
> 

Steve, I thought that RFC3683 is intended to apply "drastic measures"
(see intro, page 4).
RFC2418 allows a WG chair and the ADs to also take measures if someone
is disrupting WG progress (sect 3.2).

I certainly hope that we do not have to have the equivalent of an
"IETF Last Call" everytime that a WG chair or AD finds that an individual
is disrupting normal WG process.

Bert

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Nick Staff" <[email-masked]>
Date: Tue, 27 Sep 2005 02:36:09 -0700

Bert,

David asked the IESG to consider a PR-action ("posting rights" action)
against Dean.  Posting rights actions are governed by RFC 3683.

I agree that 3683 is used to apply drastic measures, but unfortunately those
are the measures the AD saw as appropriate for Dean's supposed infractions.
Even the RFC refers to applicable cases as "serious situations", but again
it was the AD who thought it fair to levy the harshest sentence at our
disposal against Dean.  It's judgment calls like that which make everything
circumspect to me.

nick

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Tuesday, September 27, 2005 2:01 AM
> To: Steven M. Bellovin; [email-masked]
> Cc: [email-masked]; 'IESG'; [email-masked]
> Subject: RE: [[email-masked]: Mismanagement of the DNSOP list] 
> 
> Steve writes:
> 
> > Actually, 3683 specifically requires community discussion 
> of motions 
> > to block someone's posting rights.  It is, in so many 
> words, done by a 
> > Last Call.
> > 
> 
> RFC2418 allows a WG chair and the ADs to also take measures 
> if someone is disrupting WG progress (sect 3.2).
> 
> I certainly hope that we do not have to have the equivalent 
> of an "IETF Last Call" everytime that a WG chair or AD finds 
> that an individual is disrupting normal WG process.
> 
> Bert
>

---

From: John Leslie <[email-masked]>
Date: Tue, 27 Sep 2005 06:11:44 -0400

> is disrupting normal WG process.

   RFC 3683 (BCP 83) is concise enough to quote the applicable part in
its entirety:
] 
]    A PR-action identifies one or more individuals, citing messages
]  posted by those individuals to an IETF mailing list, that appear to
]  be abusive of the consensus-driven process.  If approved by the IESG,
]  then:
] 
]  o  those identified on the PR-action have their posting rights to
]     that IETF mailing list removed; and,
] 
]  o  maintainers of any IETF mailing list may, at their discretion,
]     also remove posting rights to that IETF mailing list.
] 
]  Once taken, this action remains in force until explicitly nullified
]  and SHOULD remain in force for at least one year.
] 
]  One year after the PR-action is approved, a new PR-action MAY be
]  introduced which restores the posting rights for that individual.
]  The IESG SHOULD consider the frequency of nullifying requests when
]  evaluating a new PR-action.  If the posting rights are restored the
]  individual is responsible for contacting the owners of the mailing
]  lists to have them restored.
] 
]  Regardless of whether the PR-action revokes or restores posting
]  rights, the IESG follows the same algorithm as with its other
]  actions:
] 
]  1.  it is introduced by an IESG Area Director (AD), who, prior to
]      doing so, may choose to inform the interested parties;
] 
]  2.  it is published as an IESG last call on the IETF general
]      discussion list;
] 
]  3.  it is discussed by the community;
] 
]  4.  it is discussed by the IESG; and, finally,
] 
]  5.  using the usual consensus-based process, it is decided upon by
]      the IESG.
] 
]  Of course, as with all IESG actions, the appeals process outlined in
]  [4] may be invoked to contest a PR-action approved by the IESG.
] 
]  Working groups SHOULD ensure that their associated mailing list is
]  manageable.  For example, some may try to circumvent the revocation
]  of their posting rights by changing email addresses; accordingly it
]  should be possible to restrict the new email address.

   A "PR-action" under BC 83 is intended to be permanent. I certainly
hope we _do_ have an IETF Last Call every time a WGC feels the "need"
to _permanently_ revoke posting rights.

> is disrupting WG progress (sect 3.2).
] 
] As with face-to-face sessions occasionally one or more individuals
] may engage in behavior on a mailing list which disrupts the WG's
] progress.  In these cases the Chair should attempt to discourage the
] behavior by communication directly with the offending individual
] rather than on the open mailing list.  If the behavior persists then
] the Chair must involve the Area Director in the issue.  As a last
] resort and after explicit warnings, the Area Director, with the
] approval of the IESG, may request that the mailing list maintainer
] block the ability of the offending individual to post to the mailing
] list.

   This looks similar, but it does not require the one-year minimum,
nor does it require a LastCall.

   Furthermore, this _has_been_done_ for Dean Anderson on dnsops.
>From the IESG minutes of 13 May 2004:
] 
] 7.2 Approval to block participant on a WG list (Bert Wijnen)
] 
] This management issue was discussed.  The IESG agrees that Bert 
] Wijnen may block posting rights for Dean Anderson on the dnsops 
] mailing list if he refuses to stay on topic as per the list rules.

which raises the question, "Why are we even discussing this?"

--
John Leslie <[email-masked]>

---

From: "Nick Staff" <[email-masked]>
Date: Tue, 27 Sep 2005 03:58:50 -0700

> > "IETF Last Call" everytime that a WG chair or AD finds that an 
> > individual is disrupting normal WG process.
> 
>    RFC 3683 (BCP 83) is concise enough to quote the 
> applicable part in its entirety:
> ] 
> ]  posted by those individuals to an IETF mailing list, that 
> appear to ]  be abusive of the consensus-driven process.  If 
> approved by the IESG, ]  then:
> ]
> ]  Once taken, this action remains in force until explicitly 
> nullified ]  and SHOULD remain in force for at least one year.
> ]
> ]  One year after the PR-action is approved, a new PR-action 
> MAY be ]  introduced which restores the posting rights for 
> that individual.
> ]  The IESG SHOULD consider the frequency of nullifying 
> requests when ]  evaluating a new PR-action.  If the posting 
> rights are restored the ]  individual is responsible for 
> contacting the owners of the mailing ]  lists to have them restored.
> ]
> ]  Regardless of whether the PR-action revokes or restores 
> posting ]  rights, the IESG follows the same algorithm as 
> with its other ]  actions:
> ]
> ]  3.  it is discussed by the community; ] ]  4.  it is 
> discussed by the IESG; and, finally, ] ]  5.  using the usual 
> consensus-based process, it is decided upon by
> ]      the IESG.
> ]
> ]  Of course, as with all IESG actions, the appeals process 
> outlined in ]  [4] may be invoked to contest a PR-action 
> approved by the IESG.
> ]
> ]  Working groups SHOULD ensure that their associated mailing 
> list is ]  manageable.  For example, some may try to 
> circumvent the revocation ]  of their posting rights by 
> changing email addresses; accordingly it ]  should be 
> possible to restrict the new email address.
> 
>    A "PR-action" under BC 83 is intended to be permanent. I 
> certainly hope we _do_ have an IETF Last Call every time a 
> WGC feels the "need"
> ] As with face-to-face sessions occasionally one or more 
> individuals ] may engage in behavior on a mailing list which 
> disrupts the WG's ] progress.  In these cases the Chair 
> should attempt to discourage the ] behavior by communication 
> directly with the offending individual ] rather than on the 
> open mailing list.  If the behavior persists then ] the Chair 
> must involve the Area Director in the issue.  As a last ] 
> resort and after explicit warnings, the Area Director, with 
> the ] approval of the IESG, may request that the mailing list 
> maintainer ] block the ability of the offending individual to 
> post to the mailing ] list.
> 
>    This looks similar, but it does not require the one-year 
> minimum, nor does it require a LastCall.
> 
> ] 7.2 Approval to block participant on a WG list (Bert 
> Wijnen) ] ] This management issue was discussed.  The IESG 
> agrees that Bert ] Wijnen may block posting rights for Dean 
> Anderson on the dnsops ] mailing list if he refuses to stay 
> on topic as per the list rules.
> 
John-

Could you please specify the RFC that details the procedure for when an AD
requests that the IESG remove someone's posting privileges from the IETF
list (the RFC other 3683 of course).  If there isn't one then I'd have to
ask that you refrain from making wildly unsupported claims as they are
disruptive to the process.

Thanks,
Nick

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 27 Sep 2005 15:26:50 +0200

The procedures for management of the IETF list are detailed in RFC 3005 
(the IETF list charter).

Note that there are presently selected IETF sergeants-at-arms.

                 Harald

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 27 Sep 2005 06:52:34 -0700 (PDT)

> disruptive to the process.

Apparently you missed this in John's message (which you quoted in

]

Look on the second paragraph on Page 13.

//cmh

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 27 Sep 2005 15:57:42 +0200

If we want to get some clarity in this debate it would be appropriate 
to quote the relevant RFCs. RFC 2418 has been updated by RFC 3934 
(BCP 94). The change is that posting rights on a WG mailing list is 
not removed anymore by the IESG on AD proposition. But by the WG 
Chair, for a maximum period of 30 days. The warning/removal (for no 
more than 30 days) sequence can be repeated indefinitely until the AD 
decides to engage an RFC 3683 (BSP 83) procedure.

RFC 3683 restores the decision by the IESG which permits longer 
suspension and to extend this suspension to other mailing lists. 
Return to positing rights is also an IESG decision. This is at least 
the way I read it.

This system does not address the most serious/interesting source of 
this type of problem: when the opposition is to an IETF consensus by 
another external consensus. At a time where the hysteresis of the 
network deployment makes erroneous propositions to stay "for ever", 
if some group identifies a proposition as harmful, it cannot simply 
wait for it to deprecate after failing the market filter. It must 
make sure that the proposition is corrected before being approved by 
the IESG. If the proposition has an IETF consensus we have a conflict.

- either the IETF must find a way to welcome that group as part of 
the IETF and there is no more consensus and a solution can be found 
along with the Internet standard process rules.
- or the IETF must be prepared to an endless battle where it will ban 
for life the current representative of the group every week, day ... 
On may imagine the havoc this would create.

My proposition would be to create a "minority position" system. Where 
such groups could be accepted as opposing without having to be 
fighting. They would be more stringently subject to suspension, but 
could freely comment in their context everyone would know. The 
proposed deliverable would include their comments - the IESG to 
decide if they would be attached to the RFC or not. At least this 
would remove the noise over the noise, would oblige the WG to 
understand the reasons of their opposition and probably lead to a 
final consensus. The obvious interest of such "minority positions" 
would be to be cooperative, so the IESG would consider their position 
in the final consensus.

Experience shows that progress usually comes from this kind of 
minority position.
jfc

>    RFC 3683 (BCP 83) is concise enough to quote the applicable part in

<snip>
> > is disrupting WG progress (sect 3.2).

<snip>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 27 Sep 2005 09:23:58 -0400

>disruptive to the process.

Have a look at 3934.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Nick Staff" <[email-masked]>
Date: Tue, 27 Sep 2005 08:41:59 -0700

> From: [email-masked] [mailto:[email-masked]] 
> 
> >> Wijnen) ] ] This management issue was discussed.  The IESG agrees 
> >> that Bert ] Wijnen may block posting rights for Dean 
> Anderson on the 
> >> dnsops ] mailing list if he refuses to stay on topic as 
> per the list 
> >> rules.
> >> 
> >Could you please specify the RFC that details the procedure 
> for when an 
> >AD requests that the IESG remove someone's posting 
> privileges from the 
> >IETF list (the RFC other 3683 of course).  If there isn't 
> one then I'd 
> >have to ask that you refrain from making wildly unsupported 
> claims as 
> >they are disruptive to the process.
> >
> 
> Have a look at 3934.
> 
Steve,

I might have misunderstood it, but I thought 3934 only pertained to
suspension from a Working Group list and that since David's request included
suspension from the main IETF list that it fell under 3683?

nick

---

From: "Nick Staff" <[email-masked]>
Date: Tue, 27 Sep 2005 18:31:51 -0700

C.M. - One of us has horribly missed the point of John's email (I'm not
inferring it's you).  Whichever one of us it is, the good news is I think we
actually agree with each other  =)

The passage you quoted was indeed quoted by John but the way I read his post
was that he was quoting it to show how this situation did not actually
apply.  That's why I asked him to provide relevant text from another rfc
other than 3683 since if he was saying that wasn't relevant I wanted to know
what was.

I support my interpretation by quoting what John said immediately after the
description:

"This looks similar, but it does not require the one-year minimum, nor does
it require a LastCall."

Basically CM I agree with you wholeheartedly that the passage does apply and
that this situation should be governed by 3683.

nick
> for when 
> > an AD requests that the IESG remove someone's posting 
> privileges from 
> > the IETF list (the RFC other 3683 of course).  If there 
> isn't one then 
> > I'd have to ask that you refrain from making wildly 
> unsupported claims 
> > as they are disruptive to the process.
> > 
> > Thanks,
> > Nick
> 
> Apparently you missed this in John's message (which you 
> quoted in its entirety, with garbled formatting):
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2005 19:17:53 +0200

...
> such groups could be accepted as opposing without having to be fighting. 

There is a perfectly civilised way of handling minority opinions already.

Please see RFC 3246 and RFC 3248 for an example I was personally
involved in. 3246 is the consensus and 3248 is the minority
opinion.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 28 Sep 2005 15:31:48 +0200

At 19:17 27/09/2005, Brian E Carpenter wrote:
>...
>>My proposition would be to create a "minority position" system. 
>>Where such groups could be accepted as opposing without having to be fighting.
>

Unfortunately not. RFC 3246 is Standard Track, RFC 3248 is 
informational. RFC 3246 is published. This case is when two IETF 
groups have different opinions.

The case I refer to is when an SSDO consensus opposes an IETF-WG 
consensus, while the Internet is no more a place where one can 
consider that an erroneous RFC supported by market leaders will 
quickly deprecate and not hurt.

The resources of the other SSDO are dedicated to its own business. It 
may however make the effort of a QA delegate to the Internet standard 
process. Experience shows that without an MoU a conflict may quickly 
develop (as if two foot-ball teams met, but one team would, in 
addition to be a challenger, have only one player present. This is 
all the more true if the results of the match counts for the world cup).

The "minority position" would avoid to enter into an SSDO/IETF 
complex MoU and liaison committee (I feel you are not found of 
anyway). All the more than the problem may be purely occasional and 
the solution be to politely pay attention to mutual needs rather than 
to ban the SSDO liaison. This can only be detrimental to a final 
common solution and would resolve nothing since the SSDO has human 
resources a plenty.

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2005 13:32:02 +0200

JFC (Jefsey) Morfin wrote:
> informational. RFC 3246 is published.

They are both published, and obviously the consensus document is
the one on the standards track. It exactly an example of the IETF
publishing a minority opinion. Obviously, we couldn't publish two
standards for the same bits.

> This case is when two IETF groups 
> have different opinions.
> 
> consensus, 

That doesn't affect what the IETF publishes. The IETF publishes
the documents that it reaches consensus on, after considering all
contributions. Liaisons from other SDOs are considered. That doesn't
mean we take them as instructions or have any obligations.

When we become aware of another SDO working on an alternative
solution, we normally attempt to engage in dialogue, but there is
no algorithm for how that dialogue will terminate.

> while the Internet is no more a place where one can consider 
> that an erroneous RFC supported by market leaders will quickly deprecate 
> and not hurt.
> 
> develop (as if two foot-ball teams met, but one team would, in addition 
> to be a challenger, have only one player present. This is all the more 
> true if the results of the match counts for the world cup).
> 
> The "minority position" would avoid to enter into an SSDO/IETF complex 
> MoU and liaison committee (I feel you are not found of anyway). All the 
> more than the problem may be purely occasional and the solution be to 
> politely pay attention to mutual needs rather than to ban the SSDO 
> liaison. This can only be detrimental to a final common solution and 
> would resolve nothing since the SSDO has human resources a plenty.

If people from another SDO wish to submit a draft for publication as
an RFC, I can't see any reason why the "RFC 3248 approach won't work.
I can't see any need to add more process than we already have.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 29 Sep 2005 17:47:23 +0200

>standards for the same bits.

Dear Brian,
this is why we need to find ways to help consensual standard publication first.
The problem is worst if the document claims to be a BCP.

>>This case is when two IETF groups have different opinions.
>>The case I refer to is when an SSDO consensus opposes an IETF-WG consensus,
>

We should not be here to develop non-interoperability.
However we know that competition may lead to some oddities. This is 
the theme of RFC 3869.

>no algorithm for how that dialogue will terminate.

"normally" should be replaced by "SHOULD".

All what I call for is not even to engage in a dialog, but to respect 
others and not refuse the dialog. And a way to politely but clearly 
address the possible non-technical motivations. I think an Ombudsman 
can help that. And that the minority position is the way to inform 
that he has been informed and taken the issue seriously. The impact 
is only to make the things even. Disfavors no one, helps everyone.

>I can't see any need to add more process than we already have.

The RFC 3248 approach is internal to IETF.

Other SSDOs have their own charters and agenda. We are talking of 
interoperability. When IETF disregards others, it is lucky others pay 
attention and delegate a resource they need. Forcing others to become 
more competent in a whole IETF area they are not interested in to 
publish a document so "the better win", just to prevent a lobby from 
creating a profitable interoperability conflict with other commercial 
or non-profit/publicly funded SSDO, is not the way I see global 
networking. Please consider RFC 3869.

I may be wrong though.
jfc

---

From: "Thomas Gal" <[email-masked]>
Date: Thu, 29 Sep 2005 11:10:15 -0700

> >They are both published, and obviously the consensus document is the 
> >one on the standards track. It exactly an example of the IETF 
> >That doesn't affect what the IETF publishes. The IETF publishes the 
> >documents that it reaches consensus on, after considering all 
> However we know that competition may lead to some oddities. 
> This is the theme of RFC 3869.
> 

So you said:
1) we shouldn't develop anything that disagrees with anything else (implying
external consensus as well as internal consensus).
-AND-
2) we should support spreading minority opinions, and the minority opinion
should be of the same status as the main opinion. 

That position is untenable. First you complained about the lack of minority
opinion, then the difference in status, then the fact that everyone didn't
just hang around waiting for everyone to agree. Perhaps instead of repeated
disagreement with people's positions, you should offer a clear concise
vision of your own.

As far as finding a "consensual standard," in anything I believe an open
mike in coordination with rough consensus and running code will always be
the best answer. 

> >When we become aware of another SDO working on an 
> alternative solution, 
> >we normally attempt to engage in dialogue, but there is no algorithm 
> >for how that dialogue will terminate.
> 

Why? So people who disagree internally can form an external body to
essentially propigate a DOS situation on our progress? So instead of
focusing on the technical issue at hand we can have engineers and scientists
(mostly) concerned with politics and diplomacy? I do not agree at all.

> All what I call for is not even to engage in a dialog, but to 
> respect others and not refuse the dialog. And a way to 
> politely but clearly address the possible non-technical 
> motivations. I think an Ombudsman can help that. And that the 
> minority position is the way to inform that he has been 
> informed and taken the issue seriously. The impact is only to 
> make the things even. Disfavors no one, helps everyone.
> 

Who is not permitted to make their voice heard on an IETF list? Are you
saying non-technical matters should in any way trump technical issues? I
don't believe that idea will find much of a home in this forum.

> >If people from another SDO wish to submit a draft for 
> publication as an 
> >RFC, I can't see any reason why the "RFC 3248 approach won't work.
> Other SSDOs have their own charters and agenda. We are 
> talking of interoperability. When IETF disregards others, it 
> is lucky others pay attention and delegate a resource they 
> need. Forcing others to become more competent in a whole IETF 
> area they are not interested in to publish a document so "the 
> better win", just to prevent a lobby from creating a 
> profitable interoperability conflict with other commercial or 
> non-profit/publicly funded SSDO, is not the way I see global 

I don't know about wrong, but seemingly political. It seems you've managed
to find fault in many other's statements (sometimes to the point of
contradicting your own), and succeded in prognosticating doomsday scenarios
all without suggesting a proactive response or outcome in anyway.

-Tom