Re: [Iasa20] 6635bis

[Brian E Carpenter <[e-mail]>]

Hi Andrew,

Replying to you, and also to Joe's message saying much the same:

On 27-Apr-19 02:07, Andrew Sullivan wrote:
> Hi Brian,
> 
> No hat.
> 
> On Fri, Apr 26, 2019 at 03:40:51PM +1200, Brian E Carpenter wrote:
>>
>> Specifically, I would regard that as a broken promise: not lightweight, not cheap.
>>
> 
> I don't understand this claim.

Before the consensus was declared to be abolishing the IAOC and
creating the LLC, you certainly recall that a number of us were
very doubtful about this, and about its complexity and overhead,
compared to making the IAOC function as originally intended. We 
were definitely led to believe that the LLC would be lightweight,
would have a minimum number of staff, and would clarify rather
than obscure who does what.

Now, that isn't explicitly stated in draft-dt-iasa20-proposal-00.
Perhaps it should have been. It was certainly always my understanding.
For example, see the model sketched by Richard Barnes at
https://mailarchive.ietf.org/arch/msg/iasa20/fRyoi3fnQNLAGtOqEi4NNp78I2M
where all operations are shown as subcontracted and what we now
call the LLC has a very simple structure. I like that picture, and
that's what I thought we were getting.

> As near as I can tell, we are talking about a couple different options
> for a function that, regardless, needs to be provided.  The cost of
> doing this on an employee vs. a contract basis is, I'd say, quite
> clearly an empirical matter that changes over time and that is
> something best determined by an excecutive director in a position to
> make that managerial decision.  So the "cheap" part does not seem to
> be something you can assert in this way.

If the LLC grows to the point where it has many employees, some of whom
are working as part of an operational team with subcontractors, it will
become less and less clear whether it's a "cheap" operation or not.
Responsibilities will become unclear, exactly as they were in the
old regime. 

> Similarly, we are talking about a couple different options for a
> funciton that, regardless, needs to be provided, and provided through
> the LLC in some way.  The way that minimizes the overhead of
> provision, which is what I think "lightweight" means, seems to me to
> be the sort of thing that only the relevant management can evaluate
> based on (again) empirical factors before him or her.
> 
> So it seems to me that the promise can only be fulfilled by actually
> permitting this flexibility.
> 
> Our experience with the old IASA design was precisely that too many
> things were overspecified in the RFCs, and it seems to me that setting
> things up this way so that the IASA2 function can proceed according to
> sound and flexible management would be good.

Point taken, but in this specific case (the RFC Editor function) we
already have a well understood and well operating solution based
on subcontracting. Retaining this solution for this case doesn't
constrain the LLC in general.

Regards
    Brian
> 
> What am I missing that you're seeing?
> 
> Best regards,
> 
> A
>