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

"Leslie Daigle" <ldaigle@thinkingcat.com> Thu, 14 February 2019 17:29 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 8E96513119F; Thu, 14 Feb 2019 09:29:28 -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 0Wn1xYCjZieL; Thu, 14 Feb 2019 09:29:24 -0800 (PST)
Received: from palegreen.birch.relay.mailchannels.net (palegreen.birch.relay.mailchannels.net [23.83.209.140]) (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 7F6941310B4; Thu, 14 Feb 2019 09:29:23 -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 9B1FD6847D1; Thu, 14 Feb 2019 17:29:22 +0000 (UTC)
Received: from pdx1-sub0-mail-a50.g.dreamhost.com (unknown [100.96.30.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9603A684606; Thu, 14 Feb 2019 17:29:21 +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); Thu, 14 Feb 2019 17:29:22 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|leslie@oceanpurl.net
X-MailChannels-Auth-Id: dreamhost
X-Bottle-Descriptive: 050b13ac7d54413d_1550165362419_3232070962
X-MC-Loop-Signature: 1550165362418:595490594
X-MC-Ingress-Time: 1550165362418
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 25EF980593; Thu, 14 Feb 2019 09:29:21 -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=Z zYMHMdzUXdZ5E+tgL0F9dJh/FA=; b=ON+bGh3VwDHkNpuXwzn36WsGXmwiYhMU0 DS6j6P1GRlULaO/HoMmqk/ywa/r1NhV4uh7axF2tz2DU9g36+F0pewCpCqXJWGBN yUFVFeJlRZ9JBVV+0WP1Yv5cIJNDyrTicNlHuUde2T1LCHcpRh+D/7JCKkC1k/a2 3uI2mDbEpc=
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 C337C80598; Thu, 14 Feb 2019 09:29:18 -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: Thu, 14 Feb 2019 12:29:07 -0500
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <EE1DBF3E-17A6-4BB3-B544-2442AF2AA9A6@thinkingcat.com>
In-Reply-To: <1FF265D9-2A7F-44E5-A9A1-C3594845A719@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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_299EB819-9422-43BA-B1D1-DD03B6E9C558_="
Embedded-HTML: [{"HTML":[4787, 24478], "plain":[3644, 13719], "uuid":"96C51E24-6B76-4948-9ADE-A1A536A68AEC"}]
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledruddthedguddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffokfgjfhggtgfgsegrkehmreertdejnecuhfhrohhmpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghdpihgvthhfqdhirghsrgdvqdhrfhgtgedtjedusghishdrrghsnecukfhppedvudeirdeiiedruddtvddrkeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedruddrheejngdpihhnvghtpedvudeirdeiiedruddtvddrkeefpdhrvghtuhhrnhdqphgrthhhpedfnfgvshhlihgvucffrghighhlvgdfuceolhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomheqpdhmrghilhhfrhhomheplhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomhdpnhhrtghpthhtoheplhgurghighhlvgesthhhihhnkhhinhhgtggrthdrtghomhenucevlhhushhtvghrufhiiigvpedt
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/v9SvysFodUVLhPWTZLuugucxORU>
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: 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: Thu, 14 Feb 2019 17:29:34 -0000

Hi Alissa,

You ask if I am opposed to this:

[You wrote, earlier:]
> To solve the problem of discrepancies between 4844bis and 6635bis, 
> perhaps the easiest thing would be to replace the text in 4844bis 
> Section 3.3 with one sentence that says “The operational oversight 
> of the RFC Series and RFC Editor are described in 
> [draft-ietf-iasa2-rfc6635bis]”
>

To the extent that 4844 is outlining the overall architecture, and 6635 
is more focused on implementation, I think you’re right to suggest we 
leave details in 6635.

However, to my point about being crystal clear about responsibilities, I 
think the architecture (4844) needs to articulate responsibilities.

With no notion of what Russ thinks of this, I can suggest the update 
below (a few tweaks in the existing paragraphs, deleting some of the 
objectionable detail, and a new end paragraph pointing to RFC 6635).

OLD:
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].
    The IASA is tasked with providing the funding for and operational
    oversight of the RFC Editor.

    The IETF LLC Board provides oversight of the IASA, and the IETF
    Executive Director is the chief actor for the IASA.

    The IETF Executive Director works with the IAB to identify suitable
    persons or entities to fulfill the mandate of the RFC Editor.

    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 IETF Administration LLC Board approves a budget for operation of
    the RFC Editor activity, and the IETF Executive Director establishes
    and manages the necessary operational agreements for the RFC Editor
    activity.

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.

    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
-------------------------------------------------------------------

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> 
>> 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> 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> 
>> 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>>> 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>>>> 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>>>>
>> 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>>>> 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>>>
>>>>> 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>>>
>>>> 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>>
>>> https://www.ietf.org/mailman/listinfo/iasa20 
>>> <https://www.ietf.org/mailman/listinfo/iasa20>
>>>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa20 
>> <https://www.ietf.org/mailman/listinfo/iasa20>
>> _______________________________________________
>> iasa20 mailing list
>> 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