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

[Alissa Cooper <[e-mail]>]

Hi Joel,

> On Feb 10, 2019, at 6:36 PM, Joel M. Halpern <[e-mail]> wrote:
> 
> 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.

As I noted in my original email, there is a lack of clarity about what 4844bis is saying about oversight and responsibility. As the charter of this working group explains, lack of clarity about oversight and responsibility were some of the key problems identified in draft-haberman-iasa20dt-recs, and they are some of the problems that the documentation coming out of this working group is supposed to fix. The overall IASA structure did indeed work well for some years, and in more recent times began to show some stress, which is why we chartered this working group to make updates to it.

As you pointed out to me off-list, RFC 4844 was written before the RSOC existed. Since we are updating RFC 4844 now, though, I don’t think we can make drop-in replacement updates and pretend as though it doesn’t exist. 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]” or something along those lines. I think we still want a crystal-clear view of what the community’s expectations are for that in 6635bis given the new legal structure (might already be there, I haven’t done a close review yet), but at least from a documentation perspective we could settle on that view in one document rather than two.

Alissa

> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>    Eliot Lear <[e-mail] <mailto:[e-mail]>> 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   [
>>    ] [e-mail] <mailto:[e-mail]>
>>    http://www.sandelman.ca/        |   ruby on rails    [
>>    --
>>    Michael Richardson <[e-mail]
>>    <mailto:[e-mail]>>, Sandelman Software Works
>>      -= IPv6 IoT consulting =-
>>    _______________________________________________
>>    iasa20 mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/iasa20
>> _______________________________________________
>> iasa20 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/iasa20
> 
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20