Re: Last Call: <draft-secretaries-good-practices-06.txt> (IETF Working Groups' Secretaries) to Best Current Practice

Ralph Droms <rdroms.ietf@gmail.com> Wed, 03 December 2014 15:58 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6C71A1B83 for <ietf@ietfa.amsl.com>; Wed, 3 Dec 2014 07:58:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqsPbNohy26j for <ietf@ietfa.amsl.com>; Wed, 3 Dec 2014 07:58:33 -0800 (PST)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DA71A1B95 for <ietf@ietf.org>; Wed, 3 Dec 2014 07:58:28 -0800 (PST)
Received: by mail-pa0-f48.google.com with SMTP id rd3so16007254pab.21 for <ietf@ietf.org>; Wed, 03 Dec 2014 07:58:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9bEbsVbrr+NSsl3+XvEoEq2lBWCmekKkd/4DliSdOXo=; b=IJMqLk21Nwqii9Kl3IxE2uoUpwdxOZGJX7dh4dn/xBKxT8pxsUg9Gba82im0CbLV4d /AQp49Py9puw5RkN2BAEfixVDkPruiw+/sweQYDLdb2zti8imxwPfjqO3/15BooKiuaI y8lRWfCyiosyIVnSpm0ZIVvDaM12qO3TR8sKtGU0Rlygyjdl1RHlR0CelXnVrR1B28n5 9Gl28kBIdGf+OtL67ZYjoMMTJuhOCtFQyrsTCrAFFb6GuloEADc/mxRuOTR/Tm2rdTfX EZl21L611MqqDBkkIs+w0phS41x1xM0DLy4IFYIIm26iTJUWBo47NgkP+qt8dokI5nuM JluA==
X-Received: by 10.66.220.134 with SMTP id pw6mr9658920pac.91.1417622307874; Wed, 03 Dec 2014 07:58:27 -0800 (PST)
Received: from [192.168.6.172] (ip-64-134-224-188.public.wayport.net. [64.134.224.188]) by mx.google.com with ESMTPSA id on1sm23542621pdb.32.2014.12.03.07.58.26 for <ietf@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 07:58:27 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call: <draft-secretaries-good-practices-06.txt> (IETF Working Groups' Secretaries) to Best Current Practice
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <D51141636F7AC8CBFE11FA93@JcK-HP8200.jck.com>
Date: Wed, 03 Dec 2014 07:44:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB01FE06-54EF-4935-BA8C-567C96EAAF69@gmail.com>
References: <20140612132656.8100.57197.idtracker@ietfa.amsl.com> <CAL0qLwZEo-AN4Er0gmbCyWJwTqOKBUKKMHEMQ_YqhK+oB+pcgg@mail.gmail.com> <547E9DBA.9040703@pi.nu> <0c1001d00ee9$36598670$a30c9350$@olddog.co.uk> <D51141636F7AC8CBFE11FA93@JcK-HP8200.jck.com>
To: ietf <ietf@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/1N5rq3fJdY6FLprJ2g0ylWdAUHc
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 03 Dec 2014 15:58:37 -0000

I agree with what John has written.

In pragmatic support of John's points, I am currently co-chair of one WG and interim co-chair of another.  The two WGs I currently co-chair simply don't involve enough operational overhead to warrant a secretary.  I don't see the need for (quoting John) a "document [that] reads in many places as if it is extremely normative and factual."

I will repeat my suggestions from the previous review cycle for this document:

Here are my opinions on how to proceed...

First, it's important that RFC 2418 be updated to allow for a WG
secretary to take on greater responsibilities, at the discretion of
the WG chairs.  It's also important that the update include formal
recognition that WG secretaries should be given access to WG support
tools.  Therefore, I recommend that RFC 2418 be updated with a short
RFC that expands the potential role for WG secretaries and that
formally grants permission for secretaries to have access to WG tools.

Second, because the [the document contains] a series of recommendations
that may not apply to all WGs and that may change over time, I
recommend that this very useful material be integrated into the IETF
wiki "Working Group Chairs' Page" <http://www.ietf.org/wg/chairs-page.html>

- Ralph


On Dec 3, 2014, at 6:40 AM 12/3/14, John C Klensin <john-ietf@jck.com> wrote:

> Hi.
> 
> I imagine I'm wasting my time, but I want to at least reference
> comments that I have made before about this document and that,
> AFAICT, have not been responded to in any way.
> 
> Whether as BCP (worse) or Informational, this document reads in
> many places as if it is extremely normative and factual.   It is
> not the second and should not be the first.  Practices differ to
> a very large degree among WGs, WG Chairs, Areas, and and
> circumstances.  What works well in one situation may not work at
> all well in others.  The IETF has succeeded in part, not only
> because of the quality of our technical work but because we've
> had, and carefully guarded, the ability to adjust procedures and
> practices to meet circumstances rather than trying to force
> everything into a "one size fits all" mold.   While I assume,
> from some of the text, that is not the intention of the authors,
> our increasingly-long history of having general guidance evolve
> into rigid rules indicates that, if the document is published in
> its current form, it will be only a matter of time before
> someone complains about proposed publication of a document
> because the WG did not have a secretary or someone else
> complains that, as a WG Secretary, he or she has certain
> entitlements.
> 
> Statements like the following illustrate the problem (I'm giving
> only a few in the hope of keeping this short enough that people
> will actually read it):
> 
> "this role has greatly evolved and increased both in value and
> scope..." (Abstract).  True for some WGs, simply false for many
> others, and we could have a long discussion about "value".  That
> discussion, however, would be a waste of valuable time that
> could better be spent on technical work.
> 
> "WG Secretary's role has greatly evolved to include a number of
> additional delegated functions and responsibilities which are
> critical to the smooth operation of IETF WGs." (Introduction)
> "Critical to smooth operation" strongly implies that any WG that
> does not have a Secretary is defective and, a priori, doesn't
> operate well.
> 
> "Section 3 of this document gives detailed descriptive
> information of the WG Secretary's functions, responsibilities,
> and good practices." (Introduction) Strongly implies that all
> Secretaries and their roles are the same, or should be.
> 
> "However, WG Chairs can delegate punctually or durably any of
> their responsibilities to someone else." (Section 2).  I don't
> know what that sentence means and have some claim to be a native
> and literate speaker and reader of English.
> 
> "...lists a subset of WG Chairs' functions and responsibilities
> which can typically be delegated to a WG Secretary." (Section 2)
> Whether 2119 is invoked or not, that is normative language.  It
> is also unclear what it means: "can typically be delegated"
> requires clarification as to what the exceptions are.  Otherwise
> they either "can be delegated" or they cannot; "typically can"
> makes no sense.  
> 
> The following paragraph,
>  "The framework and perimeter of action associated to the WG
>  Secretary's role, depends on the WG Secretary and the
>  Chairs, as well as on the professional relationship they
>  establish. Therefore this document does not prescribe what
>  must be performed, but lists what might be performed by a WG
>  Secretary. Also, this list is intended to be as complete as
>  possible, but it shall not be considered as exhaustive. This
>  document is therefore not a rigid job description."
> effectively contradicts what has come before, possibly to blunt
> some of the type of the criticism I (and others) have voiced.
> Its effect, however, is merely to contradict and create
> confusion.
> 
> More examples on request.
> 
> This document is not ready for prime time in its current form.
> It is part of a style of doing things by making more rules or
> apparent rules that is actually hazardous to the further of the
> IETF as anything but a traditional SDO that approves things on
> the basis of procedure-conformance rather than thinking.  If
> approved for publication at all, it should be approved only
> after revision to make it very clear it is about suggestions
> that might be applicable to some situations, with those
> situations at WG Chair discretion.
> 
>   john
> 
>