Subject: IETF, IAB, & RFC-Editor

From: RJ Atkinson <[email-masked]>
Date: Fri, 26 May 2006 07:47:34 -0400

Previously, someone wrote:
> I finished reading the RFC editor document and have one major concern.
>
> Ultimately, the rfc-editor function needs to be accountable to the
> IETF community because we're the ones paying for it.

Incorrect.  As I pointed out some weeks ago, and Leslie has
recently repeated, IETF has never paid for the RFC-Editor.

Historically, RFC-Editor was created by (D)ARPA and paid by
(D)ARPA.  More recently, some large commercial firms have
donated substantial funds to ISOC -- with the understanding
that the RFC-Editor would be among the functions paid for
from those funds. [1]

> In particular I believe that the IETF should be able to pass a BCP
> placing requirements on an rfc-editor stream.  We've done this with
> RFC 3932 for example, and I think that was a good thing.
>
> In effect, community consensus within the IETF should trump anything
> else.

It has NOT been the case in the past that IETF was the community
in control of RFC-Editor.  In fact, that would represent a major,
and in many people's view highly undesirable, change.

Historically, RFC-Editor has served the broader Internet community,
including but not limited to the IETF.   In fact, the RFC-Editor
has existed since the late 1960s, yet the IETF did not even exist
until the middle 1980s.

> Now, we need to be careful about how to use that consensus.  Several
> RFC streams serve communities broader than the IETF.  Unless we have
> good reason to do so, we should not step on those communities by
> overriding their requirements.

Indeed, it would be a gross assumption of non-existent authority
for the IETF to over-ride the broader Internet community.  In
the narrow situation of preserving the integrity of the standards
process, existing procedures ensure that the standards process
is not bypassed by some 3rd party.  There is not a problem here,
nor a reason for IETF to shut down the very important non-IETF
uses of the RFC publication process.

Despite the best efforts of new technologies (e.g. combining
Google Scholar and institutional technical reports), there are
still numerous RFCs each year that are not published by IETF
and yet are important for the broader Internet community
(which by definition includes, but is not limited to, the IETF).

There are roughly 3 categories of such documents:
	- independent submissions to the RFC Editor relating
	  to technology, research, or other (non-standards) issues.
	- IRTF submissions to the RFC Editor
           (as a reminder to newcomers, the IRTF also reports
           to the IAB, NOT to the IETF).
	- publications by IAB or ISOC

All 3 of those categories are important.  Generally speaking,
none of those categories are within the purview of the IESG
or the IETF -- and NEVER have been historically (with the
narrow and important exception, both historically and now,
that the IESG has a chance to object to publication of
something that is trying to make an "end run" around
the IETF standards process).

My long-standing personal hope is that the IRTF would have
its own document describing its own processes for submission,
review, and approval of IRTF documents -- rather than treating
IRTF documents as individual submissions as has been done
historically.  In the extremely unlikely case that the IESG
would try to object to publication of some IRTF document,
I would think it VERY important that the IRTF document get
published -- in the interest of intellectual integrity and
openness.

> I also have specific concerns about how this document interacts with
> the IAOC and IASA.
>
> 1) The document gives the IAB the authority to terminate the
>     rfc-editor contract.  Depending on when we do that, there may be
>     significant budget impacts and it may not be consistent with
>     ISOC's carrying out its financial responsibilities to terminate
>     the rfc-editor contract at an arbitrary point in time.

The RFC Editor has reported to the IAB since about 1992 -- this
was documented (if I recall correctly) in the revised process
RFCs after the Cambridge Tea Party.   The RFC-Editor normally
has a liaison attending IAB meetings, for example.  The choice of IAB
was very deliberate -- to ensure that the RFC-Editor did NOT
become limited in scope to just the IETF or to IETF-related
documents.

It is not an accident that the ISOC BoT are the ones who have
to approve or disapprove appointments to the IAB.  The IAB and
ISOC are connected and have worked well together over the past
10+ years.

So a better way to think about this is that ISOC has been paying
for the RFC-Editor for years, with IAB as ISOC's manager for that
function.  This is remaining the case.  IAB is connected to ISOC,
so there is no real danger that IAB would get out of sync with ISOC.

The RFC Editor has *never* reported to the IESG or IETF,
though RFC-Editor has done a good job of coordinating with IESG
and ensuring that IETF's interests were properly looked
after.  There is no real danger that this would change.

> 2) The document allows the IAB to create new streams of rfcs on its
>    own authority.  It seems that we need ISOC and IAOC approval at
>    least on the budget question to do so.

The IAB has had this authority at least since circa 1992
(the reorganisation after the Cambridge Tea Party).  This
is not a new situation.  Further, IAB has shown that it is
responsible in this regard -- nothing silly has happened
in this area.  So there is no change here -- and no real
cause for concern or anxiety.

The main conclusion that I draw from this thread so far is
that the we all need to do a better job of explaining how
things are currently organised to newcomers -- along with
enough of the history that people don't end up with
misunderstandings of how we got where we are organisationally.
(And I am a relative newcomer here myself, having only
participated since around 1990; a number of folks still in
IETF go back to the days of NCP, before IPv4 even :-)

Finally, I don't particularly care to get caught up in any
quagmire that might erupt, so I don't intend to post further
on this thread.  Lack of response by me to other notes does
not imply that I agree with -- or disagree with -- whatever
those notes might claim.

Yours,

Ran
[email-masked]

(former IAB member)

[1] Several IAB members, including me, were told this directly
in plain language by representatives of at least 2 large firms
(during the time I was serving on IAB).

Disclaimer: I am not speaking for my employer in this note.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Phil Maceri" <[email-masked]>
Date: Mon, 5 Jun 2006 12:01:35 -0400

Can someone please explain to me how to remove my email address from the ietf mailing list?  Can I just go to ietf.org?Phil Maceri 10247 Barlow CrossingPerrysburg, OH 43551Cell: 248-250-1194Home: 586-435-9542

> Date: Mon, 5 Jun 2006 15:35:41 +0200> To: [email-masked]; [email-masked]> From: [email-masked]> CC: [email-masked]; [email-masked]> Subject: Re: IETF, IAB, & RFC-Editor> > Dear Franck,> the reference is not ISOC nor the IETF. The reference is the user. > Hence, the networking solution people may use on the digital > ecosystem they built and own in common. The difficulty is to evaluate > from past and present IETF/ISOC contributions their future cons and > pros; and the methods for their pros to keep being efficient and > their cons to be corrected. This concerns the time proven/dusted > approach of their "affinity group" (RFC 3774) - among the billions > mentionned by Brian. Can they still deliver? Not easy as those who > think "no", or are confused (the users?) are not available for > comment, or PR-actionned.> > Some questions are:> - what are the users' needs which are solved, and not solved?> - why was the IETF good as solving them, poor at not solving them?> - what should be the resulting architecture we should support and how > should we support it?> - is the IETF/IAB/IESG/IASA/ISOC adapted to produce the deliverables > this architecture requires?> - what about users' QA?> > Please reread RFC 3774, 3935, 3968. This kind of self-analysis is > impressive. It should help. They all tell what is to be corrected. > Starting with the mission and purpose of the IETF. It is not to make > the Internet work better in influencing people (where legitimacy, > capacity and competence would come from?). But it is to tell people > how they can better build, manage and interopate their own system.> jfc> > > > At 14:34 05/06/2006, Franck Martin wrote:> > >-----BEGIN PGP SIGNED MESSAGE-----> >Hash: SHA1> >> >All,> >> >I suppose you are aware of the next ISOC board meeting in Marrakesh is> >on the 1/2 July 2006 (www.isoc.org)> >> >While I have kept an eye on the IETF list for qite some time, I still> >consider myself a newbie in the relationship ISOC/IETF. I'm trying to> >better understand it especially with this reform process, so any point> >of view is interesting for me.> >> >I also find the IETF is doing a great job but not sure how to best> >help it.> >> >IETF is 20 years old, I also hope to learn more during a workshop at> >www.egeni.org on the historic role of IETF (22 June 2006, Paris).> >> >Cheers> >> >Brian E Carpenter wrote:> >> >| Ran,> >|> >| RJ Atkinson wrote:> >|> >|> Previously, someone wrote:> >|>> >|>> I finished reading the RFC editor document and have one major> >|>> concern.> >|>>> >|>> Ultimately, the rfc-editor function needs to be accountable to> >|>> the IETF community because we're the ones paying for it.> >|>> >|>> >|>> >|> Incorrect.  As I pointed out some weeks ago, and Leslie has> >|> recently repeated, IETF has never paid for the RFC-Editor.> >|>> >|> Historically, RFC-Editor was created by (D)ARPA and paid by> >|> (D)ARPA.  More recently, some large commercial firms have donated> >|> substantial funds to ISOC -- with the understanding that the> >|> RFC-Editor would be among the functions paid for from those> >|> funds. [1]> >|> >|> >| I would like to suggest a qualification to this. Things have> >| changed over time. When DARPA stopped funding ISI to perform the> >| RFC Editor function, ISOC stepped in to fill the gap. Subsequently,> >| ISOC also provided a discretionary fund for the IETF Chair, and> >| extended its liability insurance to cover the IETF leadership. (At> >| some point, the discretionary fund was split between the IETF Chair> >| and the IAB Chair.) In 2000/2001, ISOC consolidated these> >| expenditures in its "standards pillar" accounting. Subsequently,> >| and most recently, ISOC agreed to host IASA, which is now the> >| funding agency for all of the above plus meeting expenses and the> >| Secretariat. So whatever the historical situation, the *current*> >| situation is that a single budget is fed by ISOC member> >| contributions, ISOC donations, and IETF attendance fees, and the> >| RFC Editor contract is just one item in that budget.> >|> >| This doesn't contradict Ran's statement of the history in the> >| least.> >|> >| With reference to Ran's note [1], my recollection of numerous> >| meetings of the ISOC Advisory Council of organizational members is> >| that representatives there consistently stated support of the> >| "standards pillar" as their primary motivation for supporting ISOC.> >| Of course they knew that historically the bulk of the money in that> >| pillar was going to support the RFC publication process, prior to> >| the creation of IASA.> >|> >|> >> >- --> >- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> >Franck Martin> >[email-masked]> >"Toute connaissance est une réponse à une question"> >G. Bachelard> >-----BEGIN PGP SIGNATURE-----> >Version: GnuPG v1.4.2 (GNU/Linux)> >Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org> >> >iD8DBQFEhCTlvnmeYIHZEyARAtTBAJwLUb5A7+mdSjDPGxaVY/9LGSDMlACeIYxh> >MWceB9CzA8a/Wr6V7oZZSfM=> >=vYIH> >-----END PGP SIGNATURE-----> >> >> >_______________________________________________> >Ietf mailing list> >[email-masked]> >https://www1.ietf.org/mailman/listinfo/ietf> >> >> > > _______________________________________________> Ietf mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Phil Maceri" <[email-masked]>
Date: Mon, 5 Jun 2006 12:04:09 -0400

nevermind.  figured it out.Phil Maceri 10247 Barlow CrossingPerrysburg, OH 43551Cell: 248-250-1194Home: 586-435-9542