Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc4071bis-08: (with DISCUSS and COMMENT)

Ted Hardie <ted.ietf@gmail.com> Mon, 08 April 2019 20:25 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5A31204BE; Mon, 8 Apr 2019 13:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nYsh4uQrxwOe; Mon, 8 Apr 2019 13:25:16 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96BA1204A8; Mon, 8 Apr 2019 13:25:10 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id x7so12245324ioh.4; Mon, 08 Apr 2019 13:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B+l4Lsv7yRHV7aqGsqZ9SNuVYBx4ftiYv8zf98/yLNg=; b=L9nl8X6cnlWdGQNIrVEqL3Aepe+QpZzGdImunjSbBr64+y6fTsmXOliABFMNo5YX36 gUPYucvmK+kyN7/X6OMptWsZqRmvj54tsTgj1p7zZsQUZa/ijJGeZUus9F96iILSUt3m gX7j3zQuhqtcG8vV+h42jQk3vhUmtRNyyUVdL/WwqJD1zqzTn61lNSmTFSV9CrTPxRWD Qe2RpkoiYkw+RjEHOOr3+Oly0zYMM8oAtW2/ucegYjBgJWwkIWkV0Iy4FvBemTijHH/n kV+AG9mp3Cl7tPiLGBlZSGpheycl9CNy45JfOFHWDUvXjjyqTWVlMu5D6/qEPfZ15KzX 5GLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B+l4Lsv7yRHV7aqGsqZ9SNuVYBx4ftiYv8zf98/yLNg=; b=VhFL5c6zp5rekysVMEohPWoI43uI5h8suPph+Ge2rZkEYc2GiWM+ltb0Dk99hNuOjZ j4Sq+dv3GYFtOCMowf8U5Wy5fgbgs/NfAs7kYbC7T84+JV3Rx0eMs15HyNly7Pw2MqwL yV5OHFQcGGP2hUqa6pJbY2Xlbnuc7j0V+PgumfPoDHHwPqkMFq0i4JdnXmeZn/XozxDb s/K3HRULKMqXnLaRvQCnwluTKijsKllaf/lB4Xb2/rOSvOne9F03gBARNYhHMWXF3DsB 7RsXm8kaWjIU/F6iXNxNgpsGgbF9rkV4u5NlH5D6cFEf3szS4G8I/SrT7wGM8dk/CsI2 GQqw==
X-Gm-Message-State: APjAAAVNo668JfsEiWg56Os9TSgHO1hBgN5Tc7xfUqPp5OAsKnAhyXrj 6tWKhu2GrgtYpEfrZvkZrjusWI+v0vgSwCid3as=
X-Google-Smtp-Source: APXvYqzVLIeNxWOLe+aoGseUp7YU5dZ79Nd6+YGl4i3lTsW0lpIxmERsP/HTNVkH/3oSQxrmfA+V29KVQOT/md+3Smg=
X-Received: by 2002:a6b:6f09:: with SMTP id k9mr12858114ioc.163.1554755110022; Mon, 08 Apr 2019 13:25:10 -0700 (PDT)
MIME-Version: 1.0
References: <155470226964.18209.2289908384768506570.idtracker@ietfa.amsl.com> <CA+9kkMB40Op1igA4emnkB=XWdj7ZzuUrK_5nTWBnW928FVW9pg@mail.gmail.com> <0B892B67-6402-4898-A041-C232CA4A2E35@vigilsec.com> <CA+9kkMBNVEFZQWO8c8g2AARZ7xidZLYGF1BhJnXvULkzrPBkSA@mail.gmail.com> <CALaySJKtQbFRQfv4ZfypeJe9hS++iVQNCvdMOgA08eBVE+=ehg@mail.gmail.com>
In-Reply-To: <CALaySJKtQbFRQfv4ZfypeJe9hS++iVQNCvdMOgA08eBVE+=ehg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 8 Apr 2019 13:24:42 -0700
Message-ID: <CA+9kkMCtAEug8q014oUtNgH7eSdkPfw3wRy-WL2oHOL58zKJLQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Russ Housley <housley@vigilsec.com>, Jon Peterson <jon.peterson@neustar.biz>, IASA 2 WG <iasa20@ietf.org>, iasa2-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-iasa2-rfc4071bis@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000bb55905860aa204"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/KgMsTU8YUokWLNefWAAdTreK0v8>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc4071bis-08: (with DISCUSS and COMMENT)
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 20:25:19 -0000

Howdy,

On Mon, Apr 8, 2019 at 12:18 PM Barry Leiba <barryleiba@computer.org> wrote:

> Lots of other discussion, but let's focus on the meat of it:
>
> > I believe Barry's DISCUSS was "was this choice made deliberately?" and
> the answer to
> > that is clear: yes.  We could take this as a signal to re-litigate it,
> but that is not the point
> > of the IESG review and would not be an appropriate reaction to this
> DISCUSS.
>
> Quite.  Yes, what makes this a DISCUSS is that I want to have a
> discussion about whether the working group considered the issues.
> You're quite correct that simply relitigating it would be
> inappropriate.
>
> What you're missing, perhaps, is that I'm not asking if the working
> group really discussed the desired term; I'm quite sure they did.  I'm
> asking if they properly considered the consequences of that decision
> on the IESG's ability to practically select someone other than the
> IETF Chair.
>
>
The document is quite clear that the default is to choose the IETF Chair:

   For the first slot listed above, the presumption is that the IETF
   Chair will serve on the board.  At the IESG's discretion, another
   area director may serve instead, or exceptionally the IESG may run a
   selection process to appoint a director.  The goal of having this
   slot on the board is to maintain coordination and communication
   between the board and the IESG.

As a participant in the discussion, my sense was that the Chair's view on
the overall organization/IESG was the one that was considered the *best
default*.  The IESG can choose another appointee, even one outside the
IESG, but the working group's default is that it should be the IETF Chair.
That was definitely considered by the working group.

Your DISCUSS comes from a different position than the working group's
agreed text: that  the IETF Chair job is time consuming  and shedding this
from the load might be a good thing to do.  That's permitted by the text
and at the IESG's discretion, but it is not what the working group thought
the default should be.  In that case, the IESG has to decide what balance
it is willing to trade--another member of the same NomCom cycle or the
possibility that someone appointed will have to go out of their way to
maintain the coordination once they have left the IESG.  Both are permitted
by the text; it's up to the IESG.

What it cannot trade in this formulation is the impact on the board of
changing a key point of coordination
every year. You would like to add that to the list of things the IESG can
trade off against the IETF chair's workload.

Had the working group, or the document, not made any preferences clear
here, that might be reasonable.  But I think in light of the long
discussion on terms and membership, the working group document's
presumption of the IETF chair as default, and the existing permission to
trade out other things, it is not something the IESG should change at this
stage of the proceedings.

I have no salient hats to wear on this one, thank goodness, so this is
simply my own opinion,

Ted





> First, while it's been mentioned in the discussion that we could have
> a non-AD in that position, I'll remind everyone that the document
> explicitly says "exceptionally".  We don't know exactly what that
> means, but I interpret it as an admonishment not to make it a routine
> thing.
>
> In practical terms, that means that half the ADs are at best
> questionably eligible and, depending upon interpretation, not
> practically eligible at all.  And they never will be, because they'll
> always be "off cycle".  This really pushed the IESG to appoint someone
> who has the same AD cycle as the IETF Chair, and to rule out the other
> seven.  Was this considered?
>
> But suppose we should choose to appoint a first-term AD in the middle
> of her term, figuring that she'll likely get a second term and that we
> can invoke "exceptionally" if she doesn't.  Might that affect NomCom's
> decision next year?  Did anyone think about that effect?
>
> Suppose someone wanted to stand for an AD position and specifically
> hoped to get the IESG's LLC appointment.  Perhaps she would choose NOT
> to stand next year because it will be off cycle and she'd be unlikely
> to get the appointment.  That has an effect on who puts their names in
> for AD positions.  Did the working group discuss that?
>
> It doesn't take too long to come up with a number of situations that
> the two-year term for the IESG appointment raises, if the IESG decides
> to appoint someone other than the chair... and, again, I think it's
> *very* important that we have the ability to assign tasks such as this
> to other than the IETF Chair, so I think that part of the working
> group's decision was well founded.
>
> As to Alissa's point about running a selection process, I'll note that
> the IESG itself can control that by explicitly appointing someone for
> two years -- essentially giving two one-year terms in the appointment.
> But that lets us control it.
>
> I appreciate that changing board members too often is bad.  I do not
> think that having one board member *potentially* change every year is
> not that bad -- and language can be there encouraging continuity and
> discouraging frequent replacement for no good reason.  And I think the
> benefits to opening up the IESG's choice outweighs the down side.
>
> But what I'm aiming at in the discussion is whether the working group
> considered that explicitly: were the issues that this raises for the
> IESG's decision process and practical ability to fill the position
> adequately considered and discussed.  I'm not sure they were.
>
> Barry
>
> On Mon, Apr 8, 2019 at 1:02 PM Ted Hardie <ted.ietf@gmail.com> wrote:
> >
> > On Mon, Apr 8, 2019 at 9:51 AM Russ Housley <housley@vigilsec.com>
> wrote:
> >>
> >>
> >>
> >> Speaking personally, I believe consideration to this point was given.
> See the threads leading up to Jason's message with the title "Consensus on
> Director Sources and Number"  August 1, 2018.
> >>
> >>
> >> I agree that this was discussed, but I can see that a one-year term for
> the IESG appointment would work better with the way that the IESG assigns
> various people to jobs.  That gets revisited every March.  So, if we really
> want the IESG to be able to pick someone other than the IETF Chair, the
> one-year term does seem to be a better fit.
> >>
> > But shifting that often would be terrible for the Board.  As it stands,
> there's a lot of context in all of this and that amount of transition is
> just bad for forward progress.  Since this appointee has to act on behalf
> of the whole organization (as all board members do), having them have less
> context than the other members is already bad; shifting to one year would
> make it potentially much worse.  I think that would make this much closer
> to a liaison role, with all the issues that entails.
> >
> > I believe Barry's DISCUSS was "was this choice made deliberately?" and
> the answer to that is clear: yes.  We could take this as a signal to
> re-litigate it, but that is not the point of the IESG review and would not
> be an appropriate reaction to this DISCUSS.  That would, in fact, shift it
> over the line in the DISCUSS criteria document to DISCUSS non-criteria:
> >
> > Disagreement with informed WG decisions that do not exhibit problems
> outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in
> preferences among technically sound approaches.
> >
> > regards,
> >
> > Ted
> >
> >
>