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

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 10 February 2019 23:36 UTC

Return-Path: <jmh@joelhalpern.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 88B43129284 for <iasa20@ietfa.amsl.com>; Sun, 10 Feb 2019 15:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 s7dTpgrMeZ0Z for <iasa20@ietfa.amsl.com>; Sun, 10 Feb 2019 15:36:26 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7871295D8 for <iasa20@ietf.org>; Sun, 10 Feb 2019 15:36:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43yQKj3hcPzrd31; Sun, 10 Feb 2019 15:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549841785; bh=ql6dbJLrIlLPTWhy+VqWq2ZM+GxJOktnCwcv93iMBp0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LO8KyWwr/CEzknazIxvgCDQbwLnW/YOpPrMKSZnJ4F648rfUYzFupTyhNapakXwlJ 6Rhe+Ef4+ht2ZORZcq4aw9q1KeJ/Jj9BlLvIlBH3NzJt/oChvpuqzpRkoUFrKvrTXr 7p9aJM60jnWsOQvZPRgMPo4QLoUcoa8zHhy8+sFQ=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43yQKh74YszFqXP; Sun, 10 Feb 2019 15:36:24 -0800 (PST)
To: Richard Barnes <rlb@ipv.sx>
Cc: IASA 2 WG <iasa20@ietf.org>
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> <CAL02cgTWdfYXprgh9qG=MVK4fZW1bFqAUviio_DhVYFA-A3cgg@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <34991cc7-a588-910a-db45-13a026f9eea2@joelhalpern.com>
Date: Sun, 10 Feb 2019 18:36:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAL02cgTWdfYXprgh9qG=MVK4fZW1bFqAUviio_DhVYFA-A3cgg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/JVnvUW4XiqMawa0yZ86yCJmlDk4>
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 23:36:29 -0000

Why do we need to change the wording we have?  It has worked 
sufficiently well for quite some years.  To the degree the legal 
separation is important, it was just as important then.

This working group is not chartered to fix all the potential 
misunderstandings in our process documents.  Those are almost infinite.

Yours,
Joel

On 2/10/19 5:18 PM, Richard Barnes wrote:
> 
> 
> On Sun, Feb 10, 2019 at 12:06 Michael Richardson <mcr+ietf@sandelman.ca 
> <mailto:mcr%2Bietf@sandelman.ca>> wrote:
> 
> 
>     Eliot Lear <lear@cisco.com <mailto: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 <mailto:mcr@sandelman.ca>
>     http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
>     --
>     Michael Richardson <mcr+IETF@sandelman.ca
>     <mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works
>       -= IPv6 IoT consulting =-
> 
> 
> 
>     _______________________________________________
>     iasa20 mailing list
>     iasa20@ietf.org <mailto:iasa20@ietf.org>
>     https://www.ietf.org/mailman/listinfo/iasa20
> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>