Subject: Re: Response to the Appeal by [...]

From: Todd Glassey <[email-masked]>
Date: Tue, 18 Jul 2006 14:07:13 -0400 (EDT)

-----Original Message-----
>From: Brian E Carpenter <[email-masked]>
>Sent: Jul 18, 2006 5:13 AM
>To: Pete Resnick <[email-masked]>
>Cc: Frank Ellermann <[email-masked]>, [email-masked]
>Subject: Re: Response to the Appeal by [...]
>
>Speaking only for myself, I have always read the words
>"Further recourse is available..." at the beginning of
>section 6.5.3 of RFC 2026 to mean that an appeal to the
>ISOC Board can only follow rejection of an appeal by both
>the IESG and IAB. 

The problem is that the language of the control is not specific to when it is envoked and as such it is open to others interpetations as well. The problem Brian is to write control's in language that is not open to interpretation and this IETF has failed miserably at that. 

Virtually all the IETF's control process documents have a number of holes in each control process such that they are neither reliable or accountable for anything below them. This is one of the real issues moving forward and needs to be corrected.

Todd Glassey as an Auditor

> Therefore, in my opinion, it is required
>for the IESG to consider such grounds for appeal, and to
>decide whether to accept or reject them. It is then the
>appellant's right to decide whether to take the appeal
>further.
>
>     Brian
>
>Pete Resnick wrote:
>> On 7/17/06 at 8:52 PM +0200, Frank Ellermann wrote:
>> 
>>> Pete Resnick wrote:
>>>
>>>> Appeals of this sort should not be brought to the IESG (or the IAB). 
>>>> I suggest that the IESG and the IAB always decline to decide such 
>>>> issues in the future should similar appeals come up.
>>>
>>>
>>> The question then shifts from "is there a problem with 'this' 
>>> (whatever, here 3683) document" to "is there a general problem with 
>>> the standards process up to and including the IAB appeal".
>> 
>> 
>> No. In this particular case, the appeal was specifically about the 
>> fairness of the procedure as documented in RFC 3683, not about the 
>> process in adopting 3683. See 
>> <http://www.ietf.org/IESG/APPEALS/morfin-appeal-against-appeal.txt> 
>> where it says:
>> 
>> "I am not interested in this part in the conformance of the IESG 
>> procedure with RFC 3683, nor in the particulars of the case. They are 
>> addressed in other parts. I am interested in the general conformance of 
>> RFC 3683 (as experimented through this case) with the Human Rights. From 
>> my experience RFC 3863 PR-actions are in violation of the most 
>> elementary rights of the persons."
>> 
>> RFC 2026 is pretty plain on this. Section 6.5 allows for 3 kinds of 
>> appeals:
>> 
>> - 6.5.1 says that you can appeal a WG decision on the grounds that your 
>> view hasn't been heard or it's technically wrong. In that case, 6.5.1 
>> says the appeal goes WG-chair->AD->IESG->IAB->end.
>> 
>> - 6.5.2 says that you can appeal an IESG action on the grounds that it 
>> didn't follow the process. In that case, 6.5.2 says the appeal goes 
>> IESG-chair->IESG->IAB->end.
>> 
>> - 6.5.3 says that you can appeal on the grounds that the procedures 
>> themselves are unfair. In that case, 6.5.3 says the appeal goes 
>> ISOC-BoT->end.
>> 
>> This appeal was (as stated by the appellant) clearly one of type 6.5.3. 
>> It (and appeals like it) should therefore be rejected without 
>> consideration by the IESG or the IAB. The appellant should bring them 
>> directly to the ISOC Board of Trustees. (*Do not pass Go. Do not collect 
>> $200.*)
>> 
>> pr
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 20 Jul 2006 08:37:43 -0700

There is a certain irony in the fact that the starting point here was aledged overuse of mailing list bandwidth.

 -----Original Message-----
From: 	JFC Morfin [mailto:[email-masked]]
Sent:	Wednesday, July 19, 2006 01:32 PM Pacific Standard Time
To:	Thomas Narten; Brian E Carpenter
Cc:	Pete Resnick; Frank Ellermann; [email-masked]
Subject:	Re: Response to the Appeal by [...] 

This is my understanding.

However this rises a problem in cases like RFC 3683. Because in this 
case (this what the IESG claims) the delay for appealing the RFC 3863 
text is over. This is why I spoke of "RFC 3863 application", the same 
as there is usually a text and a running code. In a "BCP" organising 
the Internet standard process the "running code" can only come 
afterward. This is why I did not appeal against the RFC 3683 but 
against the way it was applied (underlining that possible bias would 
be discussed separately). Being the first one subject to the "RFC 
3863 running code", however the appeal delay against the text is 
over, the appeal delay against the way the running code works had 
just started.

jfc

At 15:02 19/07/2006, Thomas Narten wrote:

>I think this is essentially right. That is, it makes no sense to
>appeal to ISOC that "the process itself was unfair and has failed to
>produce a proper result", if there wasn't first an appeal on actual
>substance that didn't result in the appropriate outcome.
>
>But, technically, I would not expect the appeal to the IESG/IAB and
>the one to the ISOC to be exactly the same. In the former case, the
>appeal is presumably on actual decisions and actions made in WGs, by
>the IESG, etc. In the latter case, the argument is much more about the
>process itself (and how it failed to "protect the rights of all
>parties in a fair and open Internet Standards Process" as indicated in
>2026) and is less focussed on the details that led to the original
>appeal.
>
>Thomas
>