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

[John C Klensin <[e-mail]>]

Alissa, Joel,

While I complete agree with Alissa's reasoning and conclusion
below (including the desirability of citing rfc6635bis --both to
nail things down and to provide a pointer for those trying to
understand what is happening), I think it is important that we
keep one change in the back of our collective minds.

Under the IASA 1.x model, the IAB could come to the IAD and IAOC
and say "we are designating Donald Duck as the RSE, please
negotiate an appropriate contract".  In principle, the IAD/IAOC
could say "completely inappropriate to have a duck as RSE so
'no' and please make another choice".   The IAB could then send
a polite note suggesting that the IAD and IAOC members either do
what they are asked or step down.  But, if they declined to do
that, the IAB could presumably manage to initiate a recall of
the IAOC members who were subject to appointments from the IETF
community and, if that recall were successful, lobby the Nomcom
to appoint new IAOC members who would agree to overrule or fire
the IAD if that seemed necessary.

Under the new model, at least as I understand it, the LLC
Directors could, in principle, decline to be recalled -- the
community's only recourse would be to decline to reappoint them
when their terms ran out.

I don't think this is a particularly big deal because, if the
community is dumb enough to appoint LLC Directors (a majority of
them, not just one or two) who would reject an IAB direction
without even being willing to negotiate in good faith about it,
we probably deserve the results and have far larger problems
than what happens to any particular appointment.  In addition,
to the extent to which we don't have a recall procedure that it
capable of working, the reasons why it is unworkable are
probably unimportant.   However, I think it is unwise to lose
track of the fact that there actually is a difference.

best,
    john



On Mon, 11 February 2019 13:41 Alissa Cooper <[e-mail]>
wrote

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