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

"Leslie Daigle" <ldaigle@thinkingcat.com> Fri, 15 February 2019 15:34 UTC

Return-Path: <ldaigle@thinkingcat.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 7A7BE124D68; Fri, 15 Feb 2019 07:34:24 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=thinkingcat.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 Ux79NYgbdCnX; Fri, 15 Feb 2019 07:34:20 -0800 (PST)
Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (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 D0E1612008F; Fri, 15 Feb 2019 07:34:19 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|leslie@oceanpurl.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 95A39683589; Fri, 15 Feb 2019 15:34:17 +0000 (UTC)
Received: from pdx1-sub0-mail-a50.g.dreamhost.com (unknown [100.96.29.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D6359682A20; Fri, 15 Feb 2019 15:34:16 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|leslie@oceanpurl.net
Received: from pdx1-sub0-mail-a50.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 15 Feb 2019 15:34:17 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|leslie@oceanpurl.net
X-MailChannels-Auth-Id: dreamhost
X-Grain-Chief: 5e7568f82967d218_1550244857449_2064675988
X-MC-Loop-Signature: 1550244857449:500034623
X-MC-Ingress-Time: 1550244857448
Received: from pdx1-sub0-mail-a50.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTP id 67A9F80684; Fri, 15 Feb 2019 07:34:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=K wOChiJnGaxfMGEZ6JlpbljapUE=; b=AM3Kb2INf7qNFrY4aChkYxdaQjMKxyrs1 wiDGLkd+Esdn/Cj0zeyXpNQ+PyN9EDUH33BRMi5VVcmK4facMm5oxWUfSEIRWZkf GgBUz+MIsNNpbMSFWf1BCMd0LXueTvrQ2b6ogAXAzDmGvqzx0RR8EBlinfg/Gdbi QPCNhdyUKw=
Received: from [192.168.1.57] (vtelinet-216-66-102-83.vermontel.net [216.66.102.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 017CF8067A; Fri, 15 Feb 2019 07:34:13 -0800 (PST)
X-DH-BACKEND: pdx1-sub0-mail-a50
From: "Leslie Daigle" <ldaigle@thinkingcat.com>
To: "Alissa Cooper" <alissa@cooperw.in>
Cc: "Richard Barnes" <rlb@ipv.sx>, draft-ietf-iasa2-rfc4844-bis@ietf.org, "IASA 2 WG" <iasa20@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Date: Fri, 15 Feb 2019 10:34:02 -0500
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <9B77B409-49CE-4CA6-AE82-20AA8A549D5F@thinkingcat.com>
In-Reply-To: <B98BC7A3-49BB-49A9-864C-3325E54DBF2C@cooperw.in>
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> <AF8CFC90-9EA7-4B33-A548-202EBBF656CF@thinkingcat.com> <1FF265D9-2A7F-44E5-A9A1-C3594845A719@cooperw.in> <EE1DBF3E-17A6-4BB3-B544-2442AF2AA9A6@thinkingcat.com> <B98BC7A3-49BB-49A9-864C-3325E54DBF2C@cooperw.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_9A85841A-631C-403A-A854-FADB6CC15D6E_="
Embedded-HTML: [{"HTML":[1208, 29333], "plain":[622, 17117], "uuid":"2F3F140C-F07B-483D-B61C-481C85193A71"}]
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledruddtjedgjeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgpdhivghtfhdqihgrshgrvddqrhhftgegtdejudgsihhsrdgrshenucfkphepvdduiedrieeirddutddvrdekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehjegnpdhinhgvthepvdduiedrieeirddutddvrdekfedprhgvthhurhhnqdhprghthhepfdfnvghslhhivgcuffgrihhglhgvfdcuoehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmqedpmhgrihhlfhhrohhmpehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmpdhnrhgtphhtthhopehluggrihhglhgvsehthhhinhhkihhnghgtrghtrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ZUCVxKs3jt0yvDuxkAoddYHrVIY>
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: Fri, 15 Feb 2019 15:34:24 -0000

Alissa,

I think those are fair points, and best considered, as suggested, after 
6635bis is reviewed, too.   I think the second para in my proposed text 
is the more substantive.  In the first para quoted, it might be simple 
enough to s/operational oversight/contract oversight/.

Again — let’s revisit that when 6635bis settles somewhat.

Leslie.


-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------

On 15 Feb 2019, at 10:21, Alissa Cooper wrote:

> Hi Leslie,
>
> Thanks for drafting text. Some comments below.
>
>> On Feb 14, 2019, at 12:29 PM, Leslie Daigle <ldaigle@thinkingcat.com> 
>> wrote:
>> PROPOSED:
>>
>> 3.3. Operational Oversight
>>
>> The IETF Administration Limited Liability Company (IETF LLC), as part
>> of the IETF Administrative Support Activity (IASA), is responsible
>> for administrative and financial matters for the IETF, the IAB, and
>> the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis].
>> As such, the IASA is tasked with providing the funding for and 
>> operational
>> oversight of the RFC Editor.
>>
>>
>
> Perhaps the resolution of this just needs to wait until the issue with 
> the definition of “IASA” is resolved in 4071bis, because based on 
> my understanding of what “IASA” includes and who performs 
> operational oversight over the RFC Editor, the above is not accurate. 
> For example, over the last few weeks I’ve been discussing with 
> Heather, the IAB, and the RSOC what the process is for updating the 
> RPC SLA and whose expectations about the RPC’s performance against 
> the SLA are meant to inform evaluations of the RPC contract. It sounds 
> like those processes are not clearly defined, but that in the past 
> both the RSOC and the stream managers have been involved in this piece 
> of operational oversight. If we intend to carry those roles forward, 
> and if IASA ends up being defined as the LLC staff and board, I 
> don’t think it is accurate to imply that IASA exclusively conducts 
> operational oversight of the RFC Editor.
>
> I’ll save my comments on the rest until I get through a re-review of 
> 6635bis.
>
> Thanks,
> Alissa
>
>> The IETF Executive Director establishes appropriate contractual
>> agreements with the selected persons or entities to carry out the
>> work that will satisfy the technical publication requirements defined
>> for the various RFC input streams (see Section 5.2). The IETF
>> Executive Director may define additional operational requirements and
>> policies for management purposes to meet the requirements defined by
>> the various communities.
>>
>> The specific details of how the IAB engages in the process of 
>> approving
>> an RFC Editor apopintment, and how IASA and IETF Executive Director
>> carry out these operational responsibilities is detailed in RFC6635
>> (and its successors).
>>
>> Leslie.
>>
>> --
>>
>> Leslie Daigle
>> Principal, ThinkingCat Enterprises
>>
>> ldaigle@thinkingcat.com <mailto:ldaigle@thinkingcat.com>
>> On 13 Feb 2019, at 21:27, Alissa Cooper wrote:
>>
>> Hi Leslie,
>>
>>> On Feb 11, 2019, at 11:55 AM, Leslie Daigle <ldaigle@thinkingcat.com 
>>> <mailto:ldaigle@thinkingcat.com>> wrote:
>>>
>>> So, I agree with this characterization 100%:
>>>
>>> [Bob Hinden wrote:]
>>>
>>> The process is: the IAB decides who it want’s to be the RSE, it 
>>> then asks the [was IAOC | will be LLC] to negotiate a contract with 
>>> that person and report the results of that negotiation back to the 
>>> IAB. If the LLC can’t negotiate a contract, then the IAB will need 
>>> to pick someone else. The IAB decides who it wants for the RSE, and 
>>> the LLC implements that via a contract.
>>>
>>> I think Richard’s later clarification works [*], but will note 
>>> that’s an update to 6635bis (Alissa’s note was commenting on the 
>>> seeming discrepancies between 4844bis and 6635bis, and the 
>>> hiring/firing text was in the latter).
>>>
>>> But, to make a larger point: it’s not just 
>>> hiring/firing/designating as a single decision point. Every question 
>>> of responsibility for the contract and the contractor lies, legally, 
>>> with the LLC (e.g., if some future RSE turns out to be a serial 
>>> killer, the LLC might take issue with continuing employment…). ED 
>>> involvement is non-optional.
>>>
>>> What we have to get clear in these documents is that the contract is 
>>> the LLC’s, and that it’s the tail. The IAB owns the 
>>> responsibility to ensure that the RFC Series continues to meet its 
>>> mission, including the responsibility of identifying an appropriate 
>>> RSE. That responsibility is the dog. (<difficult sentence about IAB 
>>> wagging contract tail omitted for clarity>).
>>>
>>> The fact that the IAB undertakes the fulfillment of the 
>>> responsibility by working with the RSOC is 1/ smart and 2/ an 
>>> implementation.
>>>
>>> Both 4844bis and 6635bis might do with some clarification, but I 
>>> don’t think the text is actually at odds between them, even now.
>>>
>>>
>>
>> Does this mean you’re opposed to my suggestion to replace the text 
>> in 3.3 with a one-sentence reference to 6635bis? Just trying to 
>> figure out what the path forward is here.
>>
>> Thanks,
>> Alissa
>>
>>> Leslie.
>>>
>>> On 10 Feb 2019, at 0:21, Bob Hinden wrote:
>>>
>>> Richard,
>>> On Feb 9, 2019, at 6:22 PM, Richard Barnes <rlb@ipv.sx 
>>> <mailto:rlb@ipv.sx>> wrote:
>>>
>>> To the extent that the RSE is defined as "the person the IAB calls 
>>> the RSE", then yes, you are undoubtedly correct. The IAB has 
>>> unquestionable authority to choose that person.
>>>
>>> To the extent that the RSE is the party of the RSE contract who is 
>>> contracted and paid to act as RFC Series Editor, then no, the IAB 
>>> and RSOC do not have the authority to choose that person, as long as 
>>> they are not the other party to that contract.
>>>
>>> I don’t think that is the right way to describe it. The process 
>>> is: the IAB decides who it want’s to be the RSE, it then asks the 
>>> [was IAOC | will be LLC] to negotiate a contract with that person 
>>> and report the results of that negotiation back to the IAB. If the 
>>> LLC can’t negotiate a contract, then the IAB will need to pick 
>>> someone else. The IAB decides who it wants for the RSE, and the LLC 
>>> implements that via a contract.
>>>
>>> Another reason why it good to have the IETF Executive Director be 
>>> liaison to the RSOC inorder to make this handoff go smoothly.
>>>
>>> Bob
>>> --Richard
>>>
>>>
>>> On Sat, Feb 9, 2019 at 8:45 PM Joel M. Halpern <jmh@joelhalpern.com 
>>> <mailto:jmh@joelhalpern.com>> wrote:
>>> Not quite.
>>> While the IETF LLC (or, before that, the ISOC and the IASA) can sign
>>> contracts with whomever they want, they do NOT have the authority to
>>> make that person the RSE. That authority resides with the IAB, and 
>>> the
>>> primary responsibility for it is delegated to the RSOC, as an arm of 
>>> the
>>> IAB.
>>>
>>> the RSOC does not now, and has not ever, report to the IETF LLC, the
>>> IASA, or the ISOC. The RSOC has made its performance reviews 
>>> available
>>> to the IAD (and presumably will make them available to the eD). 
>>> Because
>>> to do otherwise wouldn't work.
>>>
>>> This whole house of cards we are building relies on cooperation 
>>> between
>>> the various entities. To date, everyone has been very careful NOT to
>>> rock that boat. We want this to work.
>>>
>>> Please do not attempt to insert larger structural changes into these
>>> document revisions.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/9/19 8:27 PM, Richard Barnes wrote:
>>>
>>> The text that's in IETF process docs does not matter here. I'm 
>>> talking
>>> about the raw legal facts.
>>>
>>> The RSE contract is an agreement between some legal entity and the 
>>> RSE..
>>> That entity has decision power over the contract, no matter what we 
>>> say
>>> on this mailing list or in an RFC. That entity was ISOC; it is now 
>>> the
>>> LLC, since the contract has been reassigned. In neither case does 
>>> the
>>> IAB have decision authority, nor did they ever.
>>>
>>> --Richard
>>>
>>> On Sat, Feb 9, 2019 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com 
>>> <mailto:jmh@joelhalpern.com>
>>> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote:
>>>
>>> Richard, as far as I can tell you have this backwards.
>>> The responsibility for the RFC Series, and for the RSE, rests with 
>>> the
>>> IAB.
>>> The IAB, as a practical matter, does not have the ability to 
>>> contract.
>>> So the IAD was the person to handle the contract with the RSE. And 
>>> the
>>> ISOC provided the money.
>>>
>>> The only say Ray had in the RSE process was if there was a problem 
>>> and
>>> the contract could not be agreed.
>>>
>>> For the IASA2 working group to change the authority over the RSE 
>>> would
>>> be a major structural change. The ONLY reason we are revising 6635 
>>> is
>>> to update the references to the IASA. Bob has been careful about 
>>> that.
>>>
>>> Do NOT attempt to make this change under this rubric.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/9/19 7:23 PM, Richard Barnes wrote:
>>>>
>>>>
>>>> On Sat, Feb 9, 2019 at 6:59 PM Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie> 
>>>> <mailto:stephen.farrell@cs.tcd.ie 
>>>> <mailto:stephen.farrell@cs.tcd.ie>>
>>> <mailto:stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>
>>> <mailto:stephen.farrell@cs.tcd.ie 
>>> <mailto:stephen.farrell@cs.tcd.ie>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 09/02/2019 23:48, Richard Barnes wrote:
>>>>> On Sat, Feb 9, 2019 at 1:44 PM Russ Housley
>>> <housley@vigilsec.com <mailto:housley@vigilsec.com> 
>>> <mailto:housley@vigilsec.com <mailto:housley@vigilsec.com>>
>>>> <mailto:housley@vigilsec.com <mailto:housley@vigilsec.com> 
>>>> <mailto:housley@vigilsec.com <mailto:housley@vigilsec.com>>>>
>>> wrote:
>>>>>
>>>>>> Alissa:
>>>>>>
>>>>>> I think we want the hiring/firing of the RFC Series Editor to
>>>> stay with
>>>>>> the IAB, but the funding to stay with IASA.
>>>>>>
>>>>>
>>>>> This is not a reasonable thing to ask.
>>>>
>>>> I'm way behind in being up to speed on this wg's stuff, so I
>>>> may be off base here, but I reckon I strongly agree with Russ.
>>>> The IAB are picked by the community and ought be the ones to
>>>> hire a new RSE if one is needed. With no disrespect meant to
>>>> trades-persons, I'd be fine with the hiring of electricians
>>>> being handled internal to IASA; but not an RSE - the context
>>>> here means those are utterly different.
>>>>
>>>>
>>>> When the IAB wants to take legal responsibility for the RSE
>>> contract,
>>>> they can control it. If they don't, then they can't.
>>>>
>>>> That doesn't mean they can't be extensively consulted, but they
>>> can't
>>>> have ultimate authority over the contract, since they aren't a 
>>>> party.
>>>>
>>>> --Richard
>>>>
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> PS: I'd have said the above even were I not an incoming IAB
>>>> member and hope not to be involved in picking a new RSE whilst
>>>> on the IAB:-)
>>>>
>>>>> One of the key driving factors for
>>>>> this whole endeavor it makes no legal sense for an
>>> organization
>>>> to delegate
>>>>> its hiring / firing / contracting decisions to people
>>> external to
>>>> that
>>>>> organization.
>>>>>
>>>>> By all means, the IASA should work with the IAB on the
>>> RSE, but
>>>> since the
>>>>> IASA is ultimately the responsible party, it can't totally
>>> cede
>>>>> responsibility. The "operational oversight" text that's
>>> in there
>>>> now seems
>>>>> like it captures this accurately.
>>>>>
>>>>>
>>>>>
>>>>>> The decision whether the ED serves on the ROC should not be
>>>> determined by
>>>>>> this document. If the IAB wants the ED to be part of
>>> RSOC, they
>>>> can make
>>>>>> that appointment..
>>>>>>
>>>>>> Perhaps it would be best to make this change:
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>> The IASA is tasked with providing the funding for and
>>> operational
>>>>>> oversight of the RFC Editor.
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>> The IASA is tasked with providing the funding for the
>>> RFC Editor.
>>>>>> The IETF Executive Director is tasked with overnight
>>> of contracts
>>>>>> and operational agreements related to the RFC Editor.
>>>>>>
>>>>>
>>>>> I don't see how this accomplishes what you claim above.
>>> The IETF
>>>> ED is
>>>>> part of the IASA. And especially given that, the second
>>> sentence
>>>> here is
>>>>> really just micromanagement of the LLC.
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Russ
>>>>>>
>>>>>> On Feb 8, 2019, at 8:11 PM, Alissa Cooper
>>> <alissa@cooperw.in <mailto:alissa@cooperw.in> 
>>> <mailto:alissa@cooperw.in <mailto:alissa@cooperw.in>>
>>>> <mailto:alissa@cooperw.in <mailto:alissa@cooperw.in> 
>>>> <mailto:alissa@cooperw.in <mailto:alissa@cooperw.in>>>> wrote:
>>>>>>
>>>>>> Earlier this week the IAB discussed whether to
>>>>>> put draft-ietf-iasa2-rfc4844-bis-01 out for community
>>> review. In
>>>> reviewing
>>>>>> it I felt there were some clarifications needed before it
>>> would
>>>> be ready
>>>>>> and the IAB thought the most appropriate path would be to
>>> bring
>>>> those to
>>>>>> the WG for resolution first.
>>>>>>
>>>>>> I haven’t started my AD review of 4071bis yet (hope to next
>>>> week), but I
>>>>>> think 4071bis has a problem in that the definition of
>>> “IASA” in that
>>>>>> document is broken (it refers to the definition in 4071,
>>> which
>>>> it itself is
>>>>>> obsoleting). And until it is clear how we are defining
>>> “IASA,” I
>>>> have
>>>>>> trouble with statements such as the following from
>>> Section 3.3
>>>> in 4844bis:
>>>>>>
>>>>>> "The IASA is tasked with providing the funding for and
>>>> operational oversight
>>>>>> of the RFC Editor.”
>>>>>>
>>>>>> Is the RSOC part of IASA? It’s pretty hard to tell
>>> without a good
>>>>>> definition of IASA, which we do not currently have IMO.
>>> (I think
>>>> there is a
>>>>>> further problem with the sentence above, which is that the
>>>> funding comes
>>>>>> from the LLC, and it would be better to be that specific.)
>>>>>>
>>>>>> While looking at Section 3.3, I don’t think this text belongs
>>>> there since
>>>>>> this document is about the RFC series and editor, not IASA
>>>> generally:
>>>>>>
>>>>>> "The IETF LLC Board provides oversight of the IASA, and
>>> the IETF
>>>> Executive
>>>>>> Director is the chief actor for the IASA.”
>>>>>>
>>>>>> I also find lack of clarity between 4844bis Section 3 and
>>>> 6635bis Section
>>>>>> 3. For example, 4844bis says:
>>>>>>
>>>>>> "The IETF Executive Director works with the IAB to identify
>>>> suitable persons
>>>>>> or entities to fulfill the mandate of the RFC Editor.”
>>>>>>
>>>>>> While 6635bis says:
>>>>>>
>>>>>> "For all decisions that affect the RSE individually (e.g.,
>>>> hiring and firing),
>>>>>> the RSOC prepares recommendations for the IAB, but the final
>>>> decision is
>>>>>> the responsibility of the IAB.”
>>>>>>
>>>>>> But under the current model (which I presume we plan to
>>> keep),
>>>> the ED is a
>>>>>> member of the RSOC. So does the ED work directly with the
>>> IAB? Or
>>>>>> indirectly with the IAB through the RSOC? Or both?
>>>>>>
>>>>>> 4844bis also says:
>>>>>>
>>>>>> "The IETF Executive Director may define additional
>>> operational
>>>>>> requirements and policies for management purposes to meet the
>>>>>> requirements defined by the various communities.”
>>>>>>
>>>>>> I wonder if this is really consistent with what is
>>> envisioned in
>>>> 6635bis.
>>>>>>
>>>>>> I also find it odd that the budget for an RSE search is
>>> discussed in
>>>>>> 6635bis, while the budget for the RFC Editor function
>>> overall is
>>>> discussed
>>>>>> in 4844bis — is the separation meaningful? Since the LLC
>>> Board
>>>> approves the
>>>>>> whole IETF budget, presumably what 4844bis says about the RFC
>>>> Editor budget
>>>>>> applies to the search budget mentioned in 6635bis as
>>> well, but
>>>> since it’s
>>>>>> not explicit it isn’t totally clear.
>>>>>>
>>>>>> Thanks,
>>>>>> Alissa
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> iasa20 mailing list
>>>>>> iasa20@ietf.org <mailto:iasa20@ietf.org> <mailto:iasa20@ietf.org 
>>>>>> <mailto:iasa20@ietf.org>>
>>> <mailto:iasa20@ietf.org <mailto:iasa20@ietf.org> 
>>> <mailto:iasa20@ietf.org <mailto:iasa20@ietf.org>>>
>>>>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>>>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> iasa20 mailing list
>>>>> iasa20@ietf.org <mailto:iasa20@ietf.org> <mailto:iasa20@ietf.org 
>>>>> <mailto:iasa20@ietf.org>>
>>> <mailto:iasa20@ietf.org <mailto:iasa20@ietf.org> 
>>> <mailto:iasa20@ietf.org <mailto:iasa20@ietf.org>>>
>>>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> iasa20 mailing list
>>>> iasa20@ietf.org <mailto:iasa20@ietf.org> <mailto:iasa20@ietf.org 
>>>> <mailto:iasa20@ietf.org>>
>>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>>>
>>> _______________________________________________
>>> iasa20 mailing list
>>> iasa20@ietf.org <mailto:iasa20@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>> _______________________________________________
>>> iasa20 mailing list
>>> iasa20@ietf.org <mailto:iasa20@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>> --
>>>
>>> Leslie Daigle
>>> Principal, ThinkingCat Enterprises
>>>
>>> ldaigle@thinkingcat.com <mailto:ldaigle@thinkingcat.com>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20 
>> <https://www.ietf.org/mailman/listinfo/iasa20>