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
- [Rfcplusplus] IRTF stream considerations Allison Mankin
- Re: [Rfcplusplus] IRTF stream considerations Eliot Lear
- Re: [Rfcplusplus] IRTF stream considerations Allison Mankin
- Re: [Rfcplusplus] IRTF stream considerations Aaron Falk
- Re: [Rfcplusplus] IRTF stream considerations Aaron Falk
- Re: [Rfcplusplus] IRTF stream considerations Diego R. Lopez
- Re: [Rfcplusplus] IRTF stream considerations Allison Mankin
- Re: [Rfcplusplus] IRTF stream considerations Allison Mankin
- Re: [Rfcplusplus] IRTF stream considerations John C Klensin
- Re: [Rfcplusplus] IRTF stream considerations Aaron Falk
- Re: [Rfcplusplus] IRTF stream considerations Eric Rescorla
- Re: [Rfcplusplus] IRTF stream considerations Peter Saint-Andre
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Adam Roach
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Adam Roach
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Adam Roach
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Adam Roach
- Re: [Rfcplusplus] IRTF stream considerations Ted Hardie
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Ted Hardie
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Ted Hardie
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Ted Hardie
- Re: [Rfcplusplus] IRTF stream considerations (rea… John C Klensin
- Re: [Rfcplusplus] IRTF stream considerations Brian E Carpenter
- Re: [Rfcplusplus] IRTF stream considerations Jari Arkko