Re: [Iasa20] IASA 2, the IETF LLC, and the RFC Editor

["Livingood, Jason" <[e-mail]>]

John: In reviewing the end of WGLC on your consolidated update draft at https://datatracker.ietf.org/doc/draft-ietf-iasa2-consolidated-upd/ it seems one minor issue raised during WGLC that you need to address in a quick update is to remove the language to update 4844.

Thanks in advance for doing so!
Jason



From: iasa20 <[e-mail]> on behalf of Leslie Daigle <[e-mail]>
Date: Monday, December 17, 2018 at 10:43 AM
To: John C Klensin <[e-mail]>
Cc: IASA 2 WG <[e-mail]>rg>, Andrew Sullivan <[e-mail]>
Subject: Re: [Iasa20] IASA 2, the IETF LLC, and the RFC Editor


I’m certainly sensitive to the fact that the IETF participant population world view changes over time, and so things that were “obvious” a decade ago are not necessarily part of the current or future ethos. I think that’s what got us that wretched RFCplusplus BoF, and it causes me to share some of your concern about being clear about the RFC Editor’s place in the world.

That said, having tried to draw diagrams of “the IETF” over the years, and always gotten tripped up about which bubble is “in” versus “out”, or should be “above” or “beside” another, it seems it’s never going to be straightforward. For IASA 1.0, we took the broadest perspective, and worked on the notion that IASA supported the IETF and the IAB, and thereby included the IAB’s activities, such as the RFC Editor function.

The then-current CEO of ISOC reframed the contracts to reflect that move of RFC Editor support, and as others have noted, RFC Series budget has shown up on the IAOC/IASA budget since then.

So, I’m in agreement with Andrew’s interpretation (1), that the RFC Editor function is naturally part of what is moving from ISOC-IASA1.0, to IETF-LLC-IASA2.0. That’s part of why I think RFC4844 is worthy of a standalone update, and why https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4844-bis/ needs careful review to make sure Russ & I got the lines of responsibility and authority correctly updated.

Leslie.

--

________________________________

Leslie Daigle
Principal, ThinkingCat Enterprises

[e-mail]<mailto:[e-mail]>

On 16 Dec 2018, at 16:13, John C Klensin wrote:

Andrew,

Thanks for responding in both your bareheaded and
ISOC-hat-wearing capacities. A few comments.

First, my main concern is that this be seen as a decision that
should be made explicitly rather than one that sort of slips in
without any special consideration because it seems to go along
with everything else. I am less concerned about what that
decision turns out to be, only that, if something goes in a
direction with which the community later turns to see as
unfortunate --no matter how unlikely that is-- we all look back
on an explicit decision and take responsibility for it.

A few other comments inline below.

--On Sunday, December 16, 2018 15:05 -0500 Andrew Sullivan
<[e-mail]> wrote:

No hat.

There's not only the "more recourse" argument John makes
below. There's also the question of why "LLC goes berserk" is
more probable than "ISOC BoT goes berserk". I observe that
this community, at least, has less direct and much less
accountable influence over the whole ISOC BoT than it is
supposed to have over the LLC board.

Absolutely. At the same time, "supposed to have" is a
complicated matter that interacts with a whole series of
questions about how well or poorly the Nomcom functions, who
volunteers for it and their skill sets, whether we have
overburdened it with appointments, etc. Somewhat similar
questions may arise wrt IAB and IESG appointments. All of
those questions are out of scope for the current discussion, but
that doesn't make them less real. Those of us who believe that,
from time to time, the IAOC and surrounding structure did rather
poorly at openness and transparency perhaps have reason to be
concerned that an LLC Board, populated by essentially the same
mechanisms and with a similar pool of volunteers will be much
better, especially given that it has fewer legal or operational
reasons to do so. Does that make the ISOC Board any better?
I'd like to thing so, but perhaps that is just a matter of the
devil we (in the IETF) know versus the one we don't.

There is, however, an underlying question that is more
important: that is the question of, regardless of how it is
organized or overseen, whether the RFC Editor is fundamentally
an Internet community function (probably with "technical" in
there somewhere) or an IETF function. In practice, the RFC
Editor function was coordinated with the IAB but did not, in the
usual line management and authority senses, report to it. When
ISOC was assembled largely to provide a home for the IEST, the
RFC Editor was not part of the story -- it was separately
funded, separately organized and managed, and separately
operated. Even after the US Government funding for the RFC
Editor disappeared, the latter was managed (and policy
directions set) out of ISI with coordination with the IAB but
not management by it. At the time the original IASA was
created, RFC 4071 says (Section 7 under "Unification") that the
ISOC "sponsorship" of the RFC Editor ... was to be "managed as
part of the IASA under the IAOC", but that was still at a time
when "home for the IETF" (and related activities) was a key
part, perhaps the key part, of ISOC's mandate.

Well, things have changed (I hope "evolved") and probably this
new structure is needed to serve the needs of both IETF and
ISOC. However, that the reorganization and (even partial)
separations those changes imply suggest that it is time to ask
the question that has been ignored (for good reason, starting
with there being no need to answer it) about whether the RFC
Editor is a community function or an IETF one. Not a simple
question and not one that would need to be addressed, even now,
if we could guarantee the ISOC, the IETF, the IETF Trust, and
the RFC Editor would all last forever or at least sail off into
the sunset holding hands.

Moreover, I am struggling to imagine the case in which the
interests of the Internet community in the RFC series diverges
badly from that of the IETF, but somehow ISOC is unaffected.
Frankly, I believe that if we get to that eventuality things
are going to be broken enough that the RFC Editor function is
going to be well down our list of emergencies.

Very possible. And I don't think my getting into scenarios I
can imagine would be helpful here.

Finally, putting my ISOC hat back on, I will say that I think
it'd be messy to pull the RFC Editor money path far away from
the RFC Editor oversight, yet moving the money path through
ISOC would in fact do that. If the WG wants to open such
negotiations, I am prepared to do so, but I could easily
imagine some changes to the entire RFC Series oversight in
exchange for taking on the task. If you want to make this an
Internet Society function, the discussion needs to move to the
Internet Society community & include a number of
considerations that are not today an obvious part of what is
happening.

Indeed. I would, however, like to proceed one step at a time.
The first step, I think, is to try to figure out whether the
IETF Community wants the RFC Editor Function folded into the
IETF LLC and, if so, what constraints it would like to put on
the folding process. There might be a parallel issue about how
the broader Internet community thinks about RFC Editor and these
functions but, if you and your Board are disinclined to ask that
question (for any of a number of probably-good reasons), I think
that is the end of that particular question, at least unless the
IETF's answer to the first question is "no". If the first
answer is "yes" and, especially if the second is "probably not",
then I don't think we need to put energy into figuring out how
to negotiate with ISOC, what other changes that might imply, and
so on. I think it is reasonable that people consider what you
have written as part of the pain that would be associated with a
"no" ansewr; if that causes a "yes", so be it.

thanks again.

best,
john

_______________________________________________
iasa20 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iasa20