Re: Last Call: <draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC

"Bradner, Scott" <sob@harvard.edu> Fri, 08 June 2012 19:46 UTC

Return-Path: <sob@harvard.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAC821F8716 for <ietf@ietfa.amsl.com>; Fri, 8 Jun 2012 12:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NUYgI2gKOk0 for <ietf@ietfa.amsl.com>; Fri, 8 Jun 2012 12:46:32 -0700 (PDT)
Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id D2DC221F871D for <ietf@ietf.org>; Fri, 8 Jun 2012 12:46:30 -0700 (PDT)
Received: from exchange.university.harvard.edu (entwedge0000004.university.harvard.edu [10.35.202.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 4A41EE8C48; Fri, 8 Jun 2012 15:46:30 -0400 (EDT)
Received: from ENTWHUBT0000006.university.harvard.edu (192.168.236.26) by entwedge0000004.university.harvard.edu (10.35.202.51) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Jun 2012 15:46:23 -0400
Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.61]) by ENTWHUBT0000006.university.harvard.edu ([192.168.236.28]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 15:46:29 -0400
From: "Bradner, Scott" <sob@harvard.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Last Call: <draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Thread-Topic: Last Call: <draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Thread-Index: AQHNRRPjzeDlNmma+0yP4HiwzJMosQ==
Date: Fri, 08 Jun 2012 19:46:29 +0000
Message-ID: <09A09092-51D1-4406-9387-5F988552BF8A@harvard.edu>
References: <20120530225655.19475.74871.idtracker@ietfa.amsl.com> <4FC70E09.30002@cisco.com> <91BA408B-60F6-4451-910A-7D5C33F48038@vpnc.org> <52CB44AB-006B-407F-AA44-976271B3E27E@harvard.edu> <03EE51C5-CDAB-471B-8DE2-DFB40CE1E93D@vpnc.org>
In-Reply-To: <03EE51C5-CDAB-471B-8DE2-DFB40CE1E93D@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [136.248.127.162]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C5B4FB593B706E448E128C7D8BDDB794@Exchange.university.harvard.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ietf@ietf.org>" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2012 19:46:33 -0000

On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote:

> On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote:
> 
>> On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote:
>> 
>>> On May 30, 2012, at 11:22 PM, Eliot Lear wrote:
>>> 
>>>> 	• It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process.  In this way it may also make sense to move Section 3.2.1 further back behind the IAB.
>>> 
>>> I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from.
>> 
>> 
>> see RFC 2026 section 6.5.3
>> 
>> 6.5.3 Questions of Applicable Procedure
>> 
>>  Further recourse is available only in cases in which the procedures
>>  themselves (i.e., the procedures described in this document) are
>>  claimed to be inadequate or insufficient to the protection of the
>>  rights of all parties in a fair and open Internet Standards Process.
>>  Claims on this basis may be made to the Internet Society Board of
>>  Trustees.  The President of the Internet Society shall acknowledge
>>  such an appeal within two weeks, and shall at the time of
>>  acknowledgment advise the petitioner of the expected duration of the
>>  Trustees' review of the appeal.  The Trustees shall review the
>>  situation in a manner of its own choosing and report to the IETF on
>>  the outcome of its review.
>> 
>>  The Trustees' decision upon completion of their review shall be final
>>  with respect to all aspects of the dispute.
>> 
>> note that the appeal to the ISOC BopT is only if the claim is that the rules are broken 
>> not the application of the rules
> 
> Exactly right. What Eliot said, and others have said, is that the ISOC board is the "final appellate avenue in the standardization process". That's quite different than "the rules are broken".

just to be clear - saying "final appellate avenue in the standardization process". could be read as meaning
that a appeal of a technical decision could be made to the ISOC Board and that is not the case - 
this is why I used different language

not sure which you were supporting

Scott

> 
>> there has never been such an appeal
> 
> 
> Happily noted.
> 
> --Paul Hoffman
>