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

From: John C Klensin <[email-masked]>
Date: Sun, 16 Dec 2018 11:25:19 -0500

Hi.

I know this is very late and don't know how much (if at all) it
has been discussed rather than assumed, but, in reviewing
several documents in the last few days, I've started to wonder
whether support for the RFC Editor should be folded into the
IETF Administration LLC or left directly with ISOC.

In a world in which everything is going smoothly, everyone is
getting along with and trusting everyone else, and there is
general agreement about goals and priorities, I can't imagine it
making a difference, but it is rarely wise to make all of those
assumptions when specifying the details of arrangements like
this.  

Some considerations...

(1) The RFC Editor function predates the IETF and has never been
considered subsidiary to it.  It seems very clear from the IETF
Administration LLC agreement that the purpose of the IETF LCC is
to support the "activities related to" the IETF, IAB, and IRTF.
One could argue that the RFC Editor is an "activity" or the IAB,
but one could make a similar argument about the IRTF, which is
called out by name, while the RFC Editor is not.

(2) In practice, the only role the IAD had relative to the RFC
Editor was contract administration (of the RSE, ISE, and
Production Center contracts).   There was no sense in with,
e.g., the RSE "reported to" the IAD.  This is less clear in the
new arrangement where the IETF LCC Executive Director has some
responsibilities and authority that go well beyond that
authority of the IAD.

(3) I know nothing about recent years but I believe that at
least some years ago, ISOC was receiving some contributions
earmarked for the RFC Editor.  I wonder if we (IETF, ISOC, the
LLC Directors) should be concerned that such donors might a
little anxious about making a donation that would go into a
general pot for supporting the LLC and its activities with the
decision left up to the LLC Directors as to how to allocate
those funds.  That is especially relevant because, if there were
a financial crunch, the Directors, none of whom are appointed by
the RFC Editor function, might well feel obligated (even legally
obligated) to prioritize IETF activities over the RFC Editor
function. ISOC, by contrast, has explicit obligations to the
broader Internet community.

(4) We saw an effort at IETF 102 to have the IETF dramatically
restructure the RFC Editor function and its relations to the
IETF and the community. We've seen other efforts from time to
time to eliminate the Independent Stream or to be sure it didn't
publish anything with which the IESG (or IAB) disapproved.  The
conclusion at IETF 102, at least as I understood it, was that
any such changes were properly a function of, and should be
discussed with, the RSE and RFC Editor function directly, not
pushed through an IETF process.  That was, at least in part,
because of the historical independence of the RFC Editor
Function alluded to above.   Rearranging things so that the RFC
Editor Function could be rearranged, or forced to rearrange
itself, by action of a group of people (the IETF LLC Directors)
whose responsibility was almost entirely to the IETF community
and its consensus about its needs and priorities (and whose
accountability to anyone other than taxing authorities, ISOC,
and the State of Delaware is very limited does not seem
appropriate.

(5) There have been discussions from time to time about the RFC
Editor adding one of more Streams to take over the publication
function for other (non-IETF-related) bodies.  Perhaps we have
abandoned that idea completely and forever but, if we have not,
making the RFC Editor part of an IETF function (rather than  one
with a broader Internet community focus) would seem ill-advised.

So, an alternative is that the RFC Editor remains an activity of
ISOC, with the budget being a matter between ISOC and the RFC
Editor.   At least as I read the IETF Administration LLC
Agreement, Contract administration could still be delegated to
the LLC if that were acceptable to all parties but the future of
the RFC Editor Function -- which might become even more
important to the Internet if the IETF got into financial or
perception trouble-- would remain separate from the future of
the IETF.

Just a thought... or a handful of them.

    john

---

From: Bob Hinden <[email-masked]>
Date: Sun, 16 Dec 2018 09:23:29 -0800

Hi John,

> On Dec 16, 2018, at 8:25 AM, John C Klensin <[email-masked]> wrote:
> 
> Hi.
> 

The text in draft-ietf-iasa2-rfc4071bis-01 is:

   o  Unification: The IETF LLC is reponsible for providing unified
      legal, financial, and administrative support for operation of the
      IETF, IAB, IESG, IRTF, and RFC Editor.

It looks like RFC Editor was added in draft-ietf-iasa2-rfc4071bis-00, it was not in draft-ietf-iasa2-struct-06.

> called out by name, while the RFC Editor is not.

Fair point on the “struct” draft, but the RFC Editor is in the rfc4071bis draft.

I have sympathy for the argument you are making about the independence of the RFC Editor given recent history, but at least it is called out correctly in the IASA 2.0 defining document.

Bob

> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Dec 2018 08:03:27 +1300

John,

Firstly thanks for making us think about this. More below:

> I have sympathy for the argument you are making about the independence of the RFC Editor given recent history, but at least it is called out correctly in the IASA 2.0 defining document.

I think so. Also, BCP 39 is very clear that the IAB approves the RFC
Editor's "general policy", and rfc4071bis doesn't touch that. If
there's anywhere that the RFC Editor's independence should have been
documented, it's in BCP 39.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Dec 2018 14:34:58 -0500

Bob,

Thanks.
However, to say that this is in draft-ietf-iasa2-rfc4071bis-00
but it was not in draft-ietf-iasa2-struct-06 is to get precisely
at my core concern.  While I hope  (and believe) that there is
strong consensus for getting issues of who has responsibility
for, and authority over, what (and how or if they are
accountable and to whom) sorted out and written down, I do not
understand the decision-making process that is in action here.
If there has been a WG discussion about the RFC Editor and its
budget, it somehow passed me by.  If they IAB or RSOC made a
decision for the RFC Editor, I haven't seen a request for input,
much less a public announcement or the decision.  And there
certainly has not been an IETF Last Call on the question.  

Now, if the authors of 4071bis believe this was just an
accidental omission and that everyone assumed the RFC Editor
oversight and budget should and would go to the IETF LLC, then
dropping the new clause into this document would be a perfectly
reasonable decision on their part.   They can, and I hope will,
speak for themselves, but I observe that they did not mention
the RFC Editor Function in Section 3.2 and that reinforces the
hypothesis that they considered this an editorial adjustment
rather than a significant decision.

The problem is that not everyone made that assumption and it has
some downsides in terms of the accountability and
responsibilities associated with the organization change.   So I
suggest that the decision -- whichever way we make it-- could be
significant and it is reasonable to ask who or what process is
making the decisions and, more specifically, when and under what
conditions the community gets to discuss and resolve the
qusation.

best,
    john

--On Sunday, December 16, 2018 09:23 -0800 Bob Hinden
<[email-masked]> wrote:

>> I know this is very late and don't know how much (if at all)
>> it has been discussed rather than assumed, but, in reviewing
>> general agreement about goals and priorities, I can't imagine
>> it making a difference, but it is rarely wise to make all of
>> those assumptions when specifying the details of arrangements
>> like this.
>> 
>> Some considerations...
>> 
>> (1) The RFC Editor function predates the IETF and has never
>> been considered subsidiary to it.  It seems very clear from
>> the IETF Administration LLC agreement that the purpose of the
>> IETF LCC is to support the "activities related to" the IETF,
>> IAB, and IRTF.
> 
>    o  Unification: The IETF LLC is reponsible for providing
> unified       legal, financial, and administrative support for
> operation of the       IETF, IAB, IESG, IRTF, and RFC Editor.
> 
> It looks like RFC Editor was added in
> draft-ietf-iasa2-rfc4071bis-00, it was not in
> draft-ietf-iasa2-struct-06.
> 
>> One could argue that the RFC Editor is an "activity" or the
>> IAB, but one could make a similar argument about the IRTF,
>> which is called out by name, while the RFC Editor is not.
> 
> Fair point on the "struct" draft, but the RFC Editor is in
> the rfc4071bis draft.
> 
> I have sympathy for the argument you are making about the
> independence of the RFC Editor given recent history, but at
> least it is called out correctly in the IASA 2.0 defining
> document.
> 
> Bob
> 
> 
> 
>> 
>> e.g., the RSE "reported to" the IAD.  This is less clear in
>> the new arrangement where the IETF LCC Executive Director has
>> some responsibilities and authority that go well beyond that
>> authority of the IAD.
>> 
>> those funds.  That is especially relevant because, if there
>> were a financial crunch, the Directors, none of whom are
>> appointed by the RFC Editor function, might well feel
>> obligated (even legally obligated) to prioritize IETF
>> activities over the RFC Editor function. ISOC, by contrast,
>> has explicit obligations to the broader Internet community.
>> 
>> time to eliminate the Independent Stream or to be sure it
>> didn't publish anything with which the IESG (or IAB)
>> disapproved.  The conclusion at IETF 102, at least as I
>> understood it, was that any such changes were properly a
>> function of, and should be discussed with, the RSE and RFC
>> Editor function directly, not pushed through an IETF process.
>> That was, at least in part, because of the historical
>> independence of the RFC Editor Function alluded to above.
>> Rearranging things so that the RFC Editor Function could be
>> rearranged, or forced to rearrange itself, by action of a
>> group of people (the IETF LLC Directors) whose responsibility
>> was almost entirely to the IETF community and its consensus
>> about its needs and priorities (and whose accountability to
>> anyone other than taxing authorities, ISOC, and the State of
>> Delaware is very limited does not seem appropriate.
>> 
>> (5) There have been discussions from time to time about the
>> RFC Editor adding one of more Streams to take over the
>> publication function for other (non-IETF-related) bodies.
>> Perhaps we have abandoned that idea completely and forever
>> but, if we have not, making the RFC Editor part of an IETF
>> function (rather than  one with a broader Internet community
>> focus) would seem ill-advised.
>> 
>> So, an alternative is that the RFC Editor remains an activity
>> of ISOC, with the budget being a matter between ISOC and the
>> RFC Editor.   At least as I read the IETF Administration LLC
>> the LLC if that were acceptable to all parties but the future
>> of the RFC Editor Function -- which might become even more

---

From: "John Levine" <[email-masked]>
Date: 16 Dec 2018 14:50:27 -0500

>IETF Administration LLC or left directly with ISOC.

The RSE budget has been handled as part of the IAOC budget as long as
I was on the IAOC.  I suppose that theoretically it could go back to
ISOC but (wearing my ISOC board hat) we have no desire to do that.

As far as I know, there haven't been any contributions directed to the
RSE in recent years, but if someone wanted to do so, it wouldn't make
any difference whether it was through ISOC or the LLC since for tax
purposes they are the same.  The LLC can accept a directed
contribution as well as ISOC can.  

Finally, a lot of these arguments boil down to "what if the LLC goes
berserk?"  The way to prevent that is to choose non-berserk board
members but in the unlikely event that we fail, the IETF has a lot
more recourse against the LLC than against ISOC.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Dec 2018 14:54:49 -0500

--On Monday, December 17, 2018 08:03 +1300 Brian E Carpenter
<[email-masked]> wrote:

>...
> I think so. Also, BCP 39 is very clear that the IAB approves
> the RFC Editor's "general policy", and rfc4071bis doesn't
> touch that. If there's anywhere that the RFC Editor's
> independence should have been documented, it's in BCP 39.

Ah.  I wasn't clear... or wrote too many words, as usual.  I
think the RFC Editor's independence is reasonably well
documented in RFC 4844, in part in several other documents, and
in a good deal of tradition.  I suggest that, were the IAB to
suddenly take it on itself to change the general structure of
the RFC Editor Function around based on that "general policy"
provision and without careful consultation of the community, the
community would react and do strongly.   I think the approval
process for 4844 and 4846 certainly established the precedents
in that area -- even if the IAB had that ability to say "we are
not a consensus body" and move unilaterally on that sort of
subject, they haven't and shouldn't.

The important point, however, is that the establishment of the
IETF LLC, as I understand the plan and the Agreement, is not
supposed to change anything, at least anything vaguely
significant, by side-effect.  There are two changes being made
here, ones that I hope are not going to be significant in
practice but certainly are in structure.   One is that the
ultimate control of IETF Administrative Policy and budget move
from a body that is responsible to the broader Internet
community (ISOC and its Board) to a body that is responsible
only to the IETF (with some limits on that too).  The other is
that, under the IASA 1.x/ IAOC model, if the IAOC decided to cut
the RFC Editor's budget to save money and to do so without the
advice and consent of the IAB, it is clear that the IAB and the
community (and even the ISOC Board) would have appeal rights,
recourse, and, in the extreme case, a way to override the
decision if the IAOC could not be persuaded.  Under the new
regime, if the IETF LLC Directors (and maybe even just the IETF
LLC Executive Director) made such a decision, about all the IAB
and broader community can to is to ask them politely to
reconsider.  

Maybe that is ok and the community is fine with it.  I don't
like it, but, as you like, I tend to worry about what can go
wrong.  It also wouldn't be the first time I'm in the rough
about these decisions and it probably won't be the last.  But it
certainly does not impress me as a decision we should make by
someone slipping a few words into a document and no one's
noticing or questioning the implications of those words.

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Dec 2018 15:05:42 -0500

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.

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.

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.

Best regards,

A

-- 
Please excuse my clumbsy thums
----------

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Dec 2018 16:13:49 -0500

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
<[email-masked]> 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

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

---

From: Glenn Deen <[email-masked]>
Date: Sun, 16 Dec 2018 13:14:33 -0800

Sent from my iPad

> On Dec 16, 2018, at 11:50 AM, John Levine <[email-masked]> wrote:
> 

For what it’s worth - For 2019, the IETF LLC budget does include funds for the RSE. This was explicitly moved over from the ISOC budget and marked to cover the RSE cost.

Glenn

---

From: Bob Hinden <[email-masked]>
Date: Sun, 16 Dec 2018 15:06:28 -0800

Glenn,

> On Dec 16, 2018, at 1:14 PM, Glenn Deen <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPad
> 

The RFC Editor (RSE, RPC, etc.) has been in the IASA budget since around 2006.

Bob

---

From: Glenn Deen <[email-masked]>
Date: Sun, 16 Dec 2018 15:45:41 -0800

Hi Bob, 

You are correct, my mistake about the transfer as yes it was already in the budget all along and is currently still in the budget. I was mixing this with another item that was transferred over.  That’s what I get for replying while on break from hanging Christmas lights.

My point remains, the IETF LLC respects and supports the RSE arrangement, and frankly I can’t imagine that changing, given the deep importance of the RSE inside and outside the IETF.

Glenn 

Sent from my iPad

> On Dec 16, 2018, at 3:06 PM, Bob Hinden <[email-masked]> wrote:
> 
> Glenn,
>

---

From: Bob Hinden <[email-masked]>
Date: Sun, 16 Dec 2018 17:46:48 -0800

> On Dec 16, 2018, at 3:45 PM, Glenn Deen <[email-masked]> wrote:
> 
> Hi Bob,
> 

No problem, understood.

> My point remains, the IETF LLC respects and supports the RSE arrangement, and frankly I can’t imagine that changing, given the deep importance of the RSE inside and outside the IETF.

+1

Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Dec 2018 21:02:04 -0500

Hi John,

No hat.

On Sun, Dec 16, 2018 at 04:13:49PM -0500, John C Klensin wrote:
 
> with everything else.

Ok, I get the concern.  I would like to suggest that there are (at
least) three possibilities here:

1.  The point of the LLC evolution is to move, with minimal fuss, all
the functions that were previously overseen by the IAOC out of the
"ISOC parent" and into the LLC.  This follows from a principle that
the point of IASA 1 was to create a kind of functional subdivision of
ISOC that was to be managed by the IETF, and that that is what
happened (but that it turned out there were some unworkable parts to
that arrangement, so we're trying to fix it).  On this view, whatever
the RFC Editor's responsibility is, it had already some time ago
effectively become part of the management arrangements that the IETF
has, and therefore the RFC Editor just ought to move to the LLC like
everything else.

2.  The relationship between the whole of the Internet Society and the
IETF has long been badly confused, and this organizational change is
revealing that, so we need to go through carefully step by step and
make everything cleanly separated and well defined.  To do this, we
will need to look at the funding arrangements of every single thing
"the IETF" ever pays for (keeping in mind that this "pays for" is
mostly an accounting fiction, and has historically been extremely
badly documented in terms of money source and so on.)  Under this
view, the situation about the RFC Editor is not clearly enough
defined, so it is one of the unpicking places.

3.  The relationship between the RFC Editor, the Internet Society, and
the IETF has always been fully separate, and as a matter of fact the
RFC Editor was paid for by the Internet Society and not the IETF.  It
was only the convenient fiction of the IAOC that got in the way of
this, and now we are being led astray by that fiction and need to get
things clarified.  

My contention is that, given the history I have read and the budget
discussions for the IETF I've been in over the years, the only
plausible interpretation of the state of affairs is (1).  I think the
only reason the RFC Editor got explicitly called out in late versions
of the text is because someone noticed that it hadn't been explicitly
called out previously, I assume because most of the editors thought
the matter so obvious they forgot to include it.  I think the
arguments for either (2) or (3) are pretty weak, on historical
grounds, on which more below.
 
> overburdened it with appointments, etc.
[…]
> Does that make the ISOC Board any better?

I observe that this presents really no evidence that the outcomes on
the ISOC BoT are more likely to be good for the RFC Editor than the
IETF LLC.  I have not seen a "crazy index" that purports to decide
whether the IAB, the IESG, the IAOC, or the ISOC BoT is the "safest"
thing here, but I am dubious that hoping about it provides a lot of
strong reason to prefer one thing over another.

I also observe that the RSE and the RFC format change effort has
selected a format that is completely unique in the world, such that
only dedicated RFC-using groups will ever pick such a format.  That
effectively constrains the user population to those active in the IETF
and those who want to be, regardless of whether we think that
desirable.  (This point was made more than once during the Lesser
Format War, and I don't think it bears rehashing.)  So I am not too
sure what population we are even trying to defend.

> the question that has been ignored

This suggests to me that your position is a version of (2) I described
above.  Is that far?

> the folding process.

Well, if you _don't_, what do you propose is going to fund the RFC
Editor next?  Because if we're not moving it, and if the IAOC has gone
away, it's not clear to me that the funding base for the RSE is in
fact in existence any more.  We budgetted for this to be in the LLC,
for what it's worth.

> "no" ansewr; if that causes a "yes", so be it.

I'm not trying to be painful.  I'm just noting that, if the IETF is
really serious about saying that the RFC Series is not especially an
IETF thing and that its governance really ought to include the whole
Internet, then I predict that publication request queues are going to
get longer due to governance-model disagreements that will take a lot
of time and not resolve speedily.  For a possible view of that future,
I encourage people to have a look at the chapter model of the Internet
Society, and contemplate how likely the RFC Series is to emerge from
that tussle in good shape.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Leslie Daigle" <[email-masked]>
Date: Mon, 17 Dec 2018 10:42:58 -0500

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
[email-masked]
-------------------------------------------------------------------

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 17 Dec 2018 11:45:23 -0500

Hi John,

A few notes about the past process:

There were three legal documents needed to stand up the LLC: the LLC agreement, the transition and shared services agreement (TSSA), and the certificate of formation. All of these were first shared on the list on June 27 [1]. Since the LLC agreement had financial terms embedded in it about ISOC’s contribution, Portia and I worked on a sample preliminary LLC budget [2] that was posted at the same time, along with a narrative explaining it [3]. The sample preliminary budget highlights the expenses associated with the RFC services in detail (both RSE and RPC) and the narrative highlights them in the aggregate. The TSSA, in Section 2(e)(i), obliges ISOC to assign contracts to the LLC that are listed in TSSA Exhibit B [4]. Both the RSE contract and the RPC contract are listed in Exhibit B.

The legal documents went through multiple iterations that were posted to this list, culminating in an IETF-wide last call for comments [5] that was concurrent with the first WGLC on draft-ietf-iasa2-struct. The conclusion of the WGLC was that there was WG consensus to move forward [6], as was the conclusion of the call for comments on the legal documents [7].

In addition to having a couple of RSOC members who were active in the list discussion at the time, the IAB also did its own review of the legal documents before they were finalized.

Best,
Alissa

[1] https://mailarchive.ietf.org/arch/msg/iasa20/ItAyo6H11VJ70-rH1Tp60rVsgHQ
[2] https://github.com/IASA2/legal-and-finance/blob/master/Sample%20IETF%20LLC%20Prelim%20Budget%2027JUN18.pdf
[3] https://github.com/IASA2/legal-and-finance/blob/master/ISOC-LLC%20financial%20contributions.pdf
[4] https://ietf.org/documents/181/IETF-ISOC-TSSA-Redacted.pdf
[5] https://mailarchive.ietf.org/arch/msg/ietf-announce/jI6srLm89JSliaU0EgDfblPxudI# <https://mailarchive.ietf.org/arch/msg/ietf-announce/jI6srLm89JSliaU0EgDfblPxudI#>
[6] https://mailarchive.ietf.org/arch/msg/iasa20/aAyfDnAE69tPR6jZqoFYeJXUc24 <https://mailarchive.ietf.org/arch/msg/iasa20/aAyfDnAE69tPR6jZqoFYeJXUc24>[7] https://mailarchive.ietf.org/arch/msg/ietf/QmCM_ulUFHlmJO4ulDzA-NE0lM4 <https://mailarchive.ietf.org/arch/msg/ietf/QmCM_ulUFHlmJO4ulDzA-NE0lM4>

> On Dec 16, 2018, at 2:34 PM, John C Klensin <[email-masked]> wrote:
> 
> Bob,
> 
> Thanks.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 17 Dec 2018 20:06:00 +0000

Thanks everyone for the thoughtful discussion. As others have noted, budget for the RFC Editor has been handled by the IAOC for many years – so it was covered in IASA 1.0. This will carry over to the IETF LLC under IASA 2.0. This was documented in RFC 4071 in 2005 and RFC 4071-bis included that as well. Obviously, handling the admin/financial aspect of this is totally different from technical oversight/direction, which is not the LLC’s role. This was also touched on by RFC 6635-bis, which was approved by the WG at the end of September 2018 (https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc6635bis/).

Regards
Jason

From: iasa20 <[email-masked]> on behalf of Alissa Cooper <[email-masked]>
Date: Monday, December 17, 2018 at 11:48 AM
To: John C Klensin <[email-masked]>
Cc: "Heather Flanagan (RFC Series Editor)" <[email-masked]>, Bob Hinden <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Iasa20] IASA 2, the IETF LLC, and the RFC Editor

Hi John,

Best,
Alissa

[1] https://mailarchive.ietf.org/arch/msg/iasa20/ItAyo6H11VJ70-rH1Tp60rVsgHQ
[2] https://github.com/IASA2/legal-and-finance/blob/master/Sample%20IETF%20LLC%20Prelim%20Budget%2027JUN18.pdf
[3] https://github.com/IASA2/legal-and-finance/blob/master/ISOC-LLC%20financial%20contributions.pdf
[4] https://ietf.org/documents/181/IETF-ISOC-TSSA-Redacted.pdf
[5] https://mailarchive.ietf.org/arch/msg/ietf-announce/jI6srLm89JSliaU0EgDfblPxudI#<https://mailarchive.ietf.org/arch/msg/ietf-announce/jI6srLm89JSliaU0EgDfblPxudI>
[6] https://mailarchive.ietf.org/arch/msg/iasa20/aAyfDnAE69tPR6jZqoFYeJXUc24
[7] https://mailarchive.ietf.org/arch/msg/ietf/QmCM_ulUFHlmJO4ulDzA-NE0lM4

On Dec 16, 2018, at 2:34 PM, John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

Bob,

Thanks.

best,
   john

--On Sunday, December 16, 2018 09:23 -0800 Bob Hinden
<[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

On Dec 16, 2018, at 8:25 AM, John C Klensin
<[email-masked]<mailto:[email-masked]>> wrote:

Hi.

Some considerations...

Bob

  john

_______________________________________________
iasa20 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iasa20

_______________________________________________
iasa20 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iasa20