Re: [Rfcplusplus] IRTF stream considerations (really)

John C Klensin <klensin@jck.com> Fri, 13 July 2018 20:52 UTC

Return-Path: <klensin@jck.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61623130E17 for <rfcplusplus@ietfa.amsl.com>; Fri, 13 Jul 2018 13:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 fN54GxaCG4FX for <rfcplusplus@ietfa.amsl.com>; Fri, 13 Jul 2018 13:52:40 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBDC130EDB for <Rfcplusplus@ietf.org>; Fri, 13 Jul 2018 13:52:27 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1fe53C-000GGX-EX; Fri, 13 Jul 2018 16:52:26 -0400
Date: Fri, 13 Jul 2018 16:52:20 -0400
From: John C Klensin <klensin@jck.com>
To: Allison Mankin <allison.mankin@gmail.com>
cc: Rfcplusplus@ietf.org
Message-ID: <A3DE5311DEF576F0DB522120@PSB>
In-Reply-To: <CAP8yD=vm+jRxdi3ZUncoFZNDYKOQKvFaphT7gxb5o1tDXWmumA@mail.gmail.com>
References: <CAP8yD=vm+jRxdi3ZUncoFZNDYKOQKvFaphT7gxb5o1tDXWmumA@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/66KRGqtYntc2xSMPO7E1wXu952E>
Subject: Re: [Rfcplusplus] IRTF stream considerations (really)
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 20:52:43 -0000

--On Wednesday, July 11, 2018 13:26 -0400 Allison Mankin
<allison.mankin@gmail.com> wrote:

> (IRTF Chair hat on)
> One of my goals as IRTF Chair is precisely to create a new,
> non-RFC stream for the IRTF. So, IRTF is very much an
> interested party in this BOF.
> 
> The most common response I get during outreach into academia
> is that RFCs aren't a good medium for most academics. This
> is despite researchers' wish eventually to have ideas
> deployed. We've been exploring what work product will best
> serve the research community, and . this does include
> distinguishing the work from the RFCs. 
>...

Allison,

I'd like to suggest a slightly different way to think about
this, one that might make things easier for you and the IRTF and
that might slightly reduce the complexity of the BOF discussion.
I have no skin in the IRTF or its situation -- this is just an
attempt to be constructive.

As far as I can tell, nothing prevents, or has ever prevented,
the IRTF, or individual IRTF participants, from publishing a
document wherever would best suit the purposes and content of
the document and their personal and professional goals (either
individually or in groups).  If you decide the best way to
accomplish that is to create a new journal, I don't know whose
permission you would need, but I'd hope that the IAB, IASA, and
ISOC would all be supportive.  Having been a bit involved some
years ago with a journal that had gotten a poor reputation and
whose management tried to re-label it in the hope of fixing
that, many of the people who make decisions about academic
credibility and impact are fairly smart and a completely new
journal is more likely to be effective in a reasonable period of
time than trying to relaunch part of the RFC Series under
different labels while carrying around some artifacts from the
old series, but that is your call, not mine.

It seems to me that none of that is a problem for the BOF - you
should just do your thing, presumably with the support of the
relevant community.  

Where there is an overlap (and maybe an issue for the BOF) is
when Research Groups want to publish documents that are, as
others have suggested, much more of the character of engineering
work that is pre-IETF or about ready to be pushing into the
IETF.    It isn't clear you would want that material in a
significantly more academic journal or that trying to hold such
work to a high academic journal standard would benefit either
the work or the journal.  But, with the understanding that I
have very little idea about what has been going on in the last
several years, my recollection is that RGs doing work like that
were typically developed in conjunction with the IESG and,
indeed, could often be said to be doing work that was more or
less commissioned by the IETF.  In those situations, tie
importance of a clear distinction between an Informational
document providing a description of preliminary, or
problem-space-defining, work produced by an RG or an IETF WG may
be relatively small and creating a document-labeling distinction
might actually be more misleading and confusing than simply
publishing the documents in the same series with appropriate
notes.  Indeed, if RGs of that sort were to be told that,
because they were RGs, they couldn't publish alongside the work
that would presumably follow based on the work they had done, I
have to wonder if we would see an upswing in requests for
AD-Sponsored publication of documents that really came out of
those RGs (AFAIK, we have no rules that would prevent such
requests).  Or those RGs might seek to recharacterize themselves
as IETF WGs with a problem exploration agenda -- the boundary
between the two was often, at least when I was closer to the
situation, always a little vague.

Be that is a may, it seems to me that the key question becomes
whether there are RGs whose output is not suitable for
publication in a high-quality academic journal (whether run by
"us"or by others and is still not suitable as direct input to
present or future IETF efforts.    If they exist, how would you
characterize them and would the effort of trying to do so inform
the distinctions you are trying to make.

best,
    john