Re: [Iasa20] Comments on draft-ietf-iasa2-rfc4844-bis-01

Richard Barnes <rlb@ipv.sx> Sun, 10 February 2019 22:19 UTC

Return-Path: <rlb@ipv.sx>
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 4EBD612941A for <iasa20@ietfa.amsl.com>; Sun, 10 Feb 2019 14:19:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 7XLuolZr_UsR for <iasa20@ietfa.amsl.com>; Sun, 10 Feb 2019 14:19:09 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 465A8128CF3 for <iasa20@ietf.org>; Sun, 10 Feb 2019 14:19:09 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id s5so14491285oth.7 for <iasa20@ietf.org>; Sun, 10 Feb 2019 14:19:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MJspfX8lEFll2i2Dniq8xw4adHI78xrRhXrTBFpwqI8=; b=y0eEpjDYdkEndcK1zPnOdLl40XRXHc+/M/Epwmil6RIfzYrjBe3XHdMR+JV4aJysB7 MP/aDM/cjcKmQ4xxJt3mdMsM8D+BN71wn7uK9n1PSwQRb6cIv04hvlU5/j1FOMURwdYP EZkOv4lmMw5A3yiXQcParKro71j4di5XZpAj7zHoSzUd/P9kaBoQJgkULM8hUMG/uyrC HIrTHXVlTm/AC9dbmIHKvuApt21R5avstpC99h1i6jNmyjp3XIqRup4dvoPGeGoizsbC VX2Q5DcoLB411HsTFYoxi/6XOp/KFveYnfdty7Kb5clJstnSzgJiHAYz8Lt93FlHmEHN Rnug==
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=MJspfX8lEFll2i2Dniq8xw4adHI78xrRhXrTBFpwqI8=; b=OZcYkH5L6GQtYUqV9M/wVvTb0vIz9k6dRXbsQGLeAKtwNvWc+1X9H//TKX8PWr7YGT boPEt+enWskz/KYr7UEG+/Eh7P+AbMBZEYFwZayya7riGbY3jgZg6hU5ByebxXX8gL31 BEYwZkBRKPvR1Z2R6zC1vG4YWBSbQfarSpRIde2WpqycOfyaSkDBfd6xe5YYvmgZddUX R+8/FGp6D28GzwH7VdrNOTqzScKadYpYRvnlHkCkDoSzoqIVq/uzNIxT2hF3y5tZkbSS kOhGnKkVmcyStdEFJxXAOgT/09edhHAThzAALsRvOoNOyRhjRPSJGbTpTNOlAt8bt68/ oXIA==
X-Gm-Message-State: AHQUAuYres5kXt3hDepo4AuPHdR/OQtDPr31o+OZWau3p1NYznpExLl7 hwgModdRpT0RTl/g1sqDI/ExDGhN22kdThUBmYRABH0zw8g=
X-Google-Smtp-Source: AHgI3IZTm5KsHcaJOHKLTaN+BRsQ4aesEJa4fSv+bMXSaC0Y0k5YqhtlQ8d4wBblNHhiX5cypC3m1dsYXaLW9sjaDAc=
X-Received: by 2002:a9d:3a22:: with SMTP id j31mr24821471otc.238.1549837148248; Sun, 10 Feb 2019 14:19:08 -0800 (PST)
MIME-Version: 1.0
References: <32C06675-C60B-4D6A-979A-FC3653E56D42@cooperw.in> <23C614C4-5C79-4355-9D74-2ED7D0DE63B2@vigilsec.com> <CAL02cgTzEQPTXyPL-ermABDne2G8F8UjbPpYADkyxxWHnVVf4g@mail.gmail.com> <a0a2ef94-335f-5ab6-e49c-7b1c985af3fc@cs.tcd.ie> <CAL02cgSnxB8-W_m13KM_HsSrE308vv5DuRJzt=t140G9JBdhUw@mail.gmail.com> <8873e4a0-a3d4-02b3-1c7b-28a9ea347165@joelhalpern.com> <CAL02cgQTzWtNVAWRZizFEekLDmapL7wOUMkJ0CWT_P_t3SDEtA@mail.gmail.com> <7436cbec-32a2-274d-7a22-b3db8388b10a@joelhalpern.com> <CAL02cgRGFXZY7+nPZx6eLoWjZ9o4RQ--aKs_seXbOfepiYBCpA@mail.gmail.com> <0C57D4C6-0F6D-47E9-81FC-3DE005FDDDFC@gmail.com> <9BC29406-F067-4BBD-8E3C-BE533B8EF1F5@cisco.com> <4861.1549818359@localhost>
In-Reply-To: <4861.1549818359@localhost>
From: Richard Barnes <rlb@ipv.sx>
Date: Sun, 10 Feb 2019 17:18:53 -0500
Message-ID: <CAL02cgTWdfYXprgh9qG=MVK4fZW1bFqAUviio_DhVYFA-A3cgg@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae6e9d0581919493"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/P90GGR0jnqOQ_GJOpjQpzOCU2gw>
Subject: Re: [Iasa20] Comments on draft-ietf-iasa2-rfc4844-bis-01
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: Sun, 10 Feb 2019 22:19:11 -0000

On Sun, Feb 10, 2019 at 12:06 Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Eliot Lear <lear@cisco.com> wrote:
>     > This is the desired process. I think what Richard is pointing out is
>     > that the LLC is under no formal obligation to pay attention to the
>     > IAB. And so like all good contractual relationships one has to ask
> what
>     > the recourse is for the LLC not following through. The answer is
> quite
>     > simple: appoint different LLC directors the next time around.
>
> We do this regularly in our day jobs.
> As hiring managers ("IAB"), we interview and hire people.
> Once we've decided, we sent them to HR ("LLC"), and they negotiate an
> agreement.   HR can (and sometimes does) have reasons why they won't hire
> the
> people we want.  They also let people go for a variety of reasons, many
> of which are against the wishes of the hiring manager.
>
> What's unique about this situation is that we ("IAB") have some control
> over HR.


This is an OK analogy, especially if you extend it to say that HR can hire
whomever they want and fire them at will, but the hiring manager might not
actually put them in the intended role if they don't like them.

Eliot exactly captured what I was trying to say, and I think he points to
the right resolution here.  Instead of saying "the hiring/firing of the RFC
Series Editor to stay with the IAB, but the funding to stay with IASA", we
can instead express the expectation of the community:

- The IAB will designate a person to be RSE, and may choose to remove or
change that designation at any time.
- The IASA is expected to make appropriate hiring/contractual arrangements
to enable the IAB's designated person to perform the RSE role.

The key difference here are the IAB does not "hire / fire", they
"designate", since they clearly cannot have the power to force the IASA to
enter into contracts.  Otherwise, I think text to this effect would encode
the desired case that Bob describes.

--Richard




>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>