Re: RSOC name

Michael StJohns <mstjohns@comcast.net> Tue, 30 July 2019 04:35 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DDD120025 for <ietf@ietfa.amsl.com>; Mon, 29 Jul 2019 21:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AP1M2bNJ12L for <ietf@ietfa.amsl.com>; Mon, 29 Jul 2019 21:34:58 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1246E12000F for <ietf@ietf.org>; Mon, 29 Jul 2019 21:34:58 -0700 (PDT)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id sJmBhOHKcpYaRsJqjhl7Xj; Tue, 30 Jul 2019 04:34:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1564461297; bh=25jGj0/ZPPla5v4FwkKbuwIhXTNmDnXu01GY5R4KkfU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GCHESoOUZwfgMpx8UvwespAeVwTbzhkRgm7Zgvx+dniIK+Z378yqGDAgMiv/gA4SJ FT9DFAOlW0ILgd0ae4YAARzXCB1lyY02E7JHAhwPY+G570LyrixQoogg0XmrUyvI5p p7aKquow/N5ZGl3G3I9aMhQULzkAclR4ggYV+MPvVcqzfc1HPKyZLFJhUtzWlex+WO bGGx9+9MdW/H5rWr+9piK+Y8e5GLTRGi4vRGuo5/iAiglY1Iq/tJw0pcS/1hmqdMda NFOgxyHx1tPGf6/SATj96cN5165ru9Bp9ramstyTDgoxYztxVf0jarglRj33JeJnLN xuUcrRpwpF2Dg==
Received: from [IPv6:2601:152:4400:437c:cd48:3080:fe30:3ec0] ([IPv6:2601:152:4400:437c:cd48:3080:fe30:3ec0]) by resomta-ch2-04v.sys.comcast.net with ESMTPSA id sJqihlgt5SfLWsJqihWD5b; Tue, 30 Jul 2019 04:34:57 +0000
X-Xfinity-VMeta: sc=0;st=legit
Subject: Re: RSOC name
To: ietf@ietf.org
References: <CAF4+nEGw2vk9wG3RLsfmY1XgDO8PYtHbbHSrph=L4XqWW33e+A@mail.gmail.com> <20190730030410.x6kwlvz5qoy4jbt5@mx4.yitter.info>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <a7cf2cd3-d552-facf-b887-c0fd2a16e75f@comcast.net>
Date: Tue, 30 Jul 2019 00:34:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190730030410.x6kwlvz5qoy4jbt5@mx4.yitter.info>
Content-Type: multipart/alternative; boundary="------------33CFDAA6B83E8FABF4F8F673"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NYpPMhQzqyRC4uAb1Esxa7qjXSc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 04:35:01 -0000

I'm currently TL;dr most of Andrew's message because I think I've 
already made the points I need to make and I don't think anything he's 
said in those sections needs me to stir anything in.  But I will list 
some of  my own relevant "experiences" lest anyone think I'm not 
familiar with the history:

100 IETF meetings including meeting 1
Nomcom chair
twice IAB member
one of the original program chairs for the IETF 87 time frame
contract manager for the NIC contract (funding RFC publication, IANA 
services)  85-89
contract manager for the ISI contract (funding Jon, Bob and Joyce) 92-96
Defense Data Network Program contract oversight MITRE (original IETF 
secretariat services).


On 7/29/2019 11:04 PM, Andrew Sullivan wrote:
>
> Elsewhere, Mike StJohns has claimed, "This is a senior person who
> really should be co-equal with the IAB and IESG."  I do not find the
> documented tradition that suggests this is true.  On the contrary, I
> can find documents stretching back to at least 1992 (where I stopped
> digging) suggesting that the RSE is in fact subordinate to the IAB.

It's too bad you didn't check out the '92 IAB charter then:

RFC 1358, Section 8:

> Section 8  <https://tools.ietf.org/html/rfc1358#section-8>.
>
>     The chair of the IAB, with the approval of at least two-thirds of the
>     IAB membership, shall have the authority to appoint an Editor for the
>     Request for Comments (RFC) publication series (the "RFC Editor"), who
>     shall be responsible for the editorial management and publication of
>     the RFC series.  If the RFC Editor is not a member of the IAB, he or
>     she shall serve ex officio as a member of the IAB unless and until
>     made a regular member of the IAB.  The RFC Editor may be removed at
>     any time by the affirmative vote of two-thirds of the members of the
>     IAB.

Basically, the IAB has existed in roughly three forms:

  * A group of heads of US DOD ARPA research task forces - approximately
    from inception to 1992 both self-selected and contract driven.
  * A technical committee of the ISOC - from 92-94 (RFC1358) and
  * the current structure from approximately 94 on.

The RFC editor has existed in roughly 7 forms (I wasn't around in the 
Steve/Jon transition time so that part is anecdotal - inception was ~69):

  * Inception - Steve Crocker - primarily as an adhoc record keeping
    system for the ARPANet related research.
  * The early years - Jon Postel - primarily as a more formal record
    keeping system including some outsider protocol contributions.
  * The early IETF years - Jon Postel - on a handshake between him and
    Phill Gross to act as the publication stream for the IETF standards
    and documents (this is also the inception point for the ID series),
    roughly around the IETF meeting at NCAR.
  * The post-Jon/pre RFC Series model - from Jon's death in '98 to Bob
    and Joyce's retirement
  * The interregnum - Glenn's term mainly looking at how do we adopt
    Jon/Bob/Joyce's precious child and do it justice
  * The regency - Olaf's term while we're looking for a professional
  * The modern era - A professional RSE.

Jon (and Bob for that matter) were members of the first incarnation of 
the IAB as DOD/NSF contractors.  Jon, as RFC editor remained on the IAB 
during the technical committee period, and was only taken off due to the 
Kobe reorganizations that caused the current structure to come into 
being (but remained as liaison for the rest of his service AFAICT - 
although I don't remember him saying much during my first IAB term).  
The DOD/NSF/DOE and NASA continued to provide funding to the RFC editor 
(and to the IETF for that matter) until at least 1997 or so, and I 
believe were responsible for funding at least part of Bob and Joyce's 
time through their tenure.   At no time during Jon or Bob or Joyce's 
tenure would anyone have had the nerve to suggest that the RFC editor 
was subordinate to the IAB and in fact, it wasn't until the change in 
how we dealt with the RFC editor (RFC model 1, 2009), that there was 
anything more than these paragraphs in the IAB charter: (RFC 2850):

>   (d) RFC Series and IANA
>
>     The RFC Editor executes editorial management and publication of the
>     IETF "Request for Comment" (RFC) document series, which is the
>     permanent document repository of the IETF.  The RFC series
>     constitutes the archival publication channel for Internet Standards
>     and for other contributions by the Internet research and engineering
>     community. RFCs are available free of charge to anyone via the
>     Internet._*The IAB must approve the appointment of an organization to act as 
> RFC Editor and the general policy followed by the RFC Editor*_.
>
>     The Internet Assigned Numbers Authority (IANA) administers various
>     protocol parameters used by IETF protocols, delegating this
>     administration as appropriate. The IAB must approve the appointment
>     of an organization to act as IANA on behalf of the IETF. The IANA
>     takes technical direction on IETF protocols from the IESG.

I listed both of these, because of the juxtaposition of the IANA and RFC 
Editor.  While the charter says that the IAB appointed the RFC editor 
that was an error. In fact it was more correct to say that the IAB 
appointed an organization/individual to act as the publication stream 
for IETF standards documents (similar to the language related to the 
IANA).  The RFC series at the time of both this (RFC2850) document and 
previous IAB charter documents was a contract work product of the ISI 
paid for in whole or in part by the US Government and had existed in 
that form since the transition from Steve Crocker to Jon at ISI.  When 
we stood up the RFC Model 1, I believe ISI ended up writing the IETF a 
quit-claim for the RFC Series name and IPR.

In other words, the RFC editor prior to 2009 was not subordinate to the 
IAB, even if the RFC Editor had been "demoted" to just a liaison due to 
the Kobe changes.


> That is not to suggest the relationship is some sort of
> directive-management one.  In my current job, I have plenty of
> colleagues who know more about their area than I do (i.e. all of
> them), yet I am responsible for their direction and in this formal
> sense they are "subordinate" to me.  If any of them messes up, they
> are not responsible to my board: I am.  Co-equal suggests that perhaps
> the RSE ought to be picked by nomcom.  I'm not too sure that is
> desirable.

This is a either-or fallacy argument that I hope won't be repeated.   It 
makes even less sense for the Nomcom to make the RSE selection than what 
the IAB is currently proposing.  I won't repeat for the third or fourth 
time why I think what the IAB is currently seems to be suggesting is 
probably also not the right approach.

In any event, until we turned this position into a contractor, I think 
the "co-equal to the IAB and IESG" pretty much described the 
relationship.  I think we need something like that going forward, even 
if it gives the current I* leadership some pause.

Later, Mike



>
> Best regards,
>
> A
>