Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt

S Moonesamy <sm+ietf@elandsys.com> Tue, 21 August 2012 21:36 UTC

Return-Path: <sm@elandsys.com>
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 8BEFA21F86A5 for <ietf@ietfa.amsl.com>; Tue, 21 Aug 2012 14:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvZXUK-HIC7e for <ietf@ietfa.amsl.com>; Tue, 21 Aug 2012 14:36:01 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC54721F86A2 for <ietf@ietf.org>; Tue, 21 Aug 2012 14:36:01 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7LLZe6E022176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2012 14:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345584955; bh=NNV0ar5i0p52DSBKtENanY/DIvVuhBFEBVCpwmjI6c8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EQG8rVtrk7ixpiBxCoeDF4XlJ8AJ/cu2MQu7d7H2/RBPHMVhnu0OtugC1nMGLy91F LFOciWkrkMPJttUm7q1PbkCaph4JGHtsbQPzb7j+lSSnQ3DBT3hVJ6Ihbf1zLQrnvh iL97Ow7w1dZdjAwdSh/K2AtcTizJ6lhit7L6kfGc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345584955; i=@elandsys.com; bh=NNV0ar5i0p52DSBKtENanY/DIvVuhBFEBVCpwmjI6c8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3BmISNPaktRnwvSUmJ4gk0VHnex6c7CRLZFsy1iNaE46FPJ91EDZk5uwD6vqPzG+k JkFmtktue8Fk7o093dnKulD3GWRE0hLGKf0Y5Ddwynnfv7TnD0UIGpFH3W6ECQvXvJ yGcHIn2HHdbOyfmuvAnoipF+76iB6mY1mXdFuJ+8=
Message-Id: <6.2.5.6.2.20120821123650.0a0ee688@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 21 Aug 2012 14:13:50 -0700
To: adrian@olddog.co.uk, Donald Eastlake <d3e3e3@gmail.com>, Margaret Wasserman <margaretw42@gmail.com>, Bob Hinden <bob.hinden@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt
In-Reply-To: <CAC4RtVB=N=CP7ManPZ=Hu65QbrX5WXnWRFFDZ-CpOcKQyqRWqg@mail.g mail.com>
References: <133201cd7f85$325f59a0$971e0ce0$@olddog.co.uk> <CAC4RtVB=N=CP7ManPZ=Hu65QbrX5WXnWRFFDZ-CpOcKQyqRWqg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: draft-leiba-3777upd-eligibility@tools.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: Tue, 21 Aug 2012 21:36:02 -0000

At 12:34 21-08-2012, Barry Leiba wrote:
>I do, and I actually had the same problem with it when I wrote it as
>you do.  So help me, please: How *should* this be put?  I don't like,
>"and those employed in the RFC Editor function," and I really can't
>think of a concise, clean, accurate way to write it down, though we
>all (today) know what it means.  Text, please, someone.

RFC 4844 (see Section 3.1) uses the term "RFC Editor".  RFC 6635 
mentions "RFC Editor function".  I suggest going with the RFC 4844 
argument about simplicity and using "RFC Editor".  I cannot think of 
an accurate way to write that paragraph.

>I'm inclined to pull it out (having not checked that with SM yet,
>though).  Does anyone (including SM) think it definitely needs to be
>in here?

I don't have a strong opinion about the erratum.  Pull it out.

At 12:45 21-08-2012, Donald Eastlake wrote:
>In particular, I believe the there are Editorial Boards that the
>various fragments of the RFC Editor appoint and consult which should
>not be excluded.

These bodies were left out.  There is a comment in the draft labelled 
as anchor1.

At 13:11 21-08-2012, Margaret Wasserman wrote:
>Why do you want to rule out employees of those groups?
>
>I don't think that most of them would have any interest in 
>volunteering for the nomcom, but why would it be a problem if they 
>did?  I mean, I could picture someone who worked for the RFC Editor 
>who was also technically involved in the IETF, like Aaron Falk used 
>to be, and I don't know why we would want to disqualify someone like 
>that from volunteering for the nomcom.

I'll comment as part of the message which Adrian posted.

At 03:10 21-08-2012, Adrian Farrel wrote:
>However, the document very quickly launches into a discussion of other
>people to exclude from NomCom. It does this by introducing the concept
>of a "conflict of interest." There may be a valid debate to have about
>conflict of interest, but I personally find it a very long wedge, and
>although there may be clear-cut cases at either extreme, it is by no
>means clear where to draw the line.

Yes.

>I find the excuse used (that those excluded are unlikely to volunteer)
>as rather poor taste. It may be true that such people have not
>volunteered in the past, but that should not be used as a reason. You
>are removing rights that people previously had - you should have good,
>stand-alone reasons and not depend on whether or not earlier holders of
>certain posts exercised those rights.

The last sentence broaches an interesting angle.  From RFC 3777:

   "The IETF Secretariat is responsible for confirming that
    volunteers have met the attendance requirement."

   "The IETF Secretariat is responsible for confirming that each
    signatory is qualified to be a voting member of a nominating
    committee."

As the IETF Secretariat has duties in the RFC 3777 mechanism, would 
it be a good stand-alone reason to remove the right to be a volunteer?

The RSE and ISE are under contract with the IAOC.  The other part of 
the RFC Editor (function) are external organizations.

At 13:52 21-08-2012, Bob Hinden wrote:
>While on this topic, we might as well get it right.  The text in the draft is:
>
>    This document also excludes certain individuals who are directly paid
>    for their work with the IETF, and who, therefore, have a direct
>    personal financial incentive in the selection of the leadership
>    boards.  We limit this exclusion to a few people who are paid for
>    long-term full-time work.  In practice, they are unlikely to
>    volunteer for the NomCom anyway, so this addition makes little
>    practical change.
>
>I assume the intent is exclude people who are paid by the IETF to do 
>work in the IETF.  For example, the IAD.  The problem is that no one 
>is paid by the IETF.  The IETF has several people who do work at 
>it's direction.  This is done as direct employees of ISOC or as 
>contractors who have their contracts with ISOC.  We also hire (via 
>ISOC) companies that provide services to the IETF.  This ranges from 
>the secretariat services, NOC services, tools development, program 
>management services, and tools specification development.  In these 
>cases it difficult to tell if an individual is working for the IETF 
>"long-term full-time work".

Ok. :-)

>Further, the text as written could be interpreted to exclude people 
>who's employers pay they to participate in the IETF.  For example, 
>that would include me because it is part of my job to participate in 
>the IETF.  I don't think that is the intent of the text in the 
>draft, but it would be easy to interpret it that way.  OK, maybe I 
>don't do it full time, but all of the IESG position require full time support.

It is the additions to RFC 3777 that matters as they become part of 
the RFC 3777 rules.

I'll discuss about the comments with Barry before commenting further.

Regards,
S. Moonesamy