Re: [Iasa20] 6635bis

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 29 April 2019 14:16 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 26A181200F9 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 07:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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 dSw0xDaRkNk5 for <iasa20@ietfa.amsl.com>; Mon, 29 Apr 2019 07:16:23 -0700 (PDT)
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 5F72C12004E for <iasa20@ietf.org>; Mon, 29 Apr 2019 07:16:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 44t6CW22wlzyfPY; Mon, 29 Apr 2019 07:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1556547383; bh=4Umn6/6WzNsADQYx5iV3bmBIwbnRmrejbsm/JcMkYbs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AqhY7pX40M20X4JI0pKNf4YGPDEhryDlX0i5DDIEUnDQJ3hIVTzLDWiLaELAcONdP kEd+0FrZ8LLcOAG1ePaRQ/tF5EqS7l/qm/fEQMtEIGybfV2WXVOTjM7HtCs9D2B+Vn 9aiFXOlOIQhUwxvYGAEAUl+JGIp/Z7SrsfI9Kqrg=
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 44t6CV5Ln4zyfP3; Mon, 29 Apr 2019 07:16:22 -0700 (PDT)
To: Alissa Cooper <alissa@cooperw.in>
Cc: iasa20@ietf.org
References: <20190426211900.555852012FE081@ary.qy> <22f00e3c-faa1-2eb3-ad38-97f6fb743aac@joelhalpern.com> <alpine.OSX.2.21.1904261835490.29589@ary.qy> <c2a25515-b5cc-13f9-cdf9-058170194d1f@joelhalpern.com> <A0C444C3-8184-4117-B3D4-9F58584292FD@cooperw.in>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <daf8ee48-91fa-4a29-9ca8-8e348ed8e0cd@joelhalpern.com>
Date: Mon, 29 Apr 2019 10:16:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <A0C444C3-8184-4117-B3D4-9F58584292FD@cooperw.in>
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/qp9h_J0Ap1bz4ReUubolDMUv-lA>
Subject: Re: [Iasa20] 6635bis
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <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, 29 Apr 2019 14:16:25 -0000

Allisa, I am not following your reasoning.
Sean brought this up as a change he was asking this working group to 
consider.  It was not brought up by the IAB.  It was not brought to the 
IAB.  It was brought to this working group.  it is clearly out of scope 
for this working group.

Some folks have claimed that it is not a policy change.  If it is not a 
policy change, then it does not appear to be necessary.  If it is a 
policy change, it does not seem to be appropriate.

As a separate matter for whomever wants to consider this outside of the 
working group, there are multiple aspects of make the RSE an employee 
that would cause me concern.  For example, hiring part time employees 
who may also want to be free to engage in contract work for other people 
is doable but distinctly non-trivial.  The current approach was approved 
by the community.  And it demonstrably works.

Yours,
Joel

On 4/29/19 10:09 AM, Alissa Cooper wrote:
> Hi Joel,
> 
>> On Apr 26, 2019, at 8:29 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>
>> As far as I can tell, the change you propose is not necessary to get the LLC working.  This working group was specifically chartered NOT to change any policies.  The change you (and Sean if I understand properly) are proposing represents a change in policy.
>>
>> Yes, I disagree with the change in policy.  I think it would be a mistake.
>>
>> But more importantly, that change is clearly outside of the scope the community was told applied to this working group.
> 
> As noted previously, since this is an IAB stream document, this list is being used for discussion prior to the IAB processing the doc. I wouldn’t expect a WG consensus call on this document.
> 
>>
>> If you want to write a separate I-D, and try to find a venue for it, to change that policy, you clearly have the right and skills to do so.
>> But please do not put that substantive change into this I-D (RFC revision) that is specifically to make the necessary changes so the LLC can do the jobs it needs to do.
> 
> It seems that such a document would also need to be an IAB stream document, in which case having a mailing list where interested people are subscribed would still be a useful thing to have as a discussion venue prior to the IAB processing. So I don’t see how shifting to a separate I-D changes anything.
> 
> Alissa
> 
>>
>> Yours,
>> Joel
>>
>> On 4/26/19 6:39 PM, John R Levine wrote:
>>>> What I fail to see is why there is any need to change the wording that we have on the status of the RSE.  I can imagine that the LLC will need to continue to exercise care in the handling of the RSE to avoid accidental changes of status.  As you say John, it is tricky.
>>>> But I do not see why that should result in any change to the text in the revision of RFC 6635.
>>> Assuming we agree that the details of the agreement with the RSE are up to the LLC, I agree.
>>> But RFC 6635 says "The RFC Production Center function is performed by a paid contractor," and " The RFC Production Center contractor is to be selected through an IASA Request for Proposal (RFP) process as described in Section 4.1." and " The RFC Publisher contractor is to be selected through an IASA RFP process as described in Section 4.1."
>>> I think the current RFC people are doing a swell job but I would like us to give the LLC the latitude to structure things however makes sense.  At this point, we have a contractor which hires its staff but at some point it might make sense for the LLC to hire staff without an intermediary.
>>> Regards,
>>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
>>> Please consider the environment before reading this e-mail. https://jl.ly
>>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20
>