Re: [Rfcplusplus] Conversation as metaphor
"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 11 July 2018 08:58 UTC
Return-Path: <ietf@trammell.ch>
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 C243A130EDF for <rfcplusplus@ietfa.amsl.com>; Wed, 11 Jul 2018 01:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ecDK1EvTfa2W for <rfcplusplus@ietfa.amsl.com>; Wed, 11 Jul 2018 01:58:09 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6455130DEA for <rfcplusplus@ietf.org>; Wed, 11 Jul 2018 01:58:08 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 741CB340EB4; Wed, 11 Jul 2018 10:58:05 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.2198); Wed, 11 Jul 2018 10:58:05 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 11 Jul 2018 10:58:05 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 61016642; Wed, 11 Jul 2018 10:58:04 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <68DDBAD8-F4B9-4ECD-A1B9-C1C3A23E0128@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_990663F6-2399-4DD8-89A7-34A672F4950A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Wed, 11 Jul 2018 10:58:03 +0200
In-Reply-To: <9cc8662e-fe1e-f26f-a55e-1f654309917d@gmail.com>
To: rfcplusplus@ietf.org
References: <CA+9kkMBVC82qy0hbUbQKm=OsFPsaJUPndtVaxd782au6Qy0w6Q@mail.gmail.com> <a4b50286-5c54-e6cf-9087-7171030b7fca@juniper.net> <CA+9kkMB7rJ7KHkpMxu5wUzQwva=qZ02-7C71YttQ5upXvjB5oQ@mail.gmail.com> <9cc8662e-fe1e-f26f-a55e-1f654309917d@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/xGmNSmm2BKF4A41TEiOjyVP_YZE>
Subject: Re: [Rfcplusplus] Conversation as metaphor
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: Wed, 11 Jul 2018 08:58:13 -0000
'Morning, all, pseudoacademic here (waves). > On 11 Jul 2018, at 01:46, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > On 11/07/2018 06:15, Ted Hardie wrote: >> Howdy, >> >> On Tue, Jul 10, 2018 at 11:06 AM, Eric C Rosen <erosen@juniper.net> wrote: >> >>> Maintaining the current publication process for RG output but changing the >>> name from "RFC" to "IRTF-Masterpiece" is not going to make any difference >>> in how the academic community values the work. >> >> That's not what others are saying. The problem as it has been explained to >> me is that tenure committees and similar academic assessments look at the >> output of the individual in part by looking at where the output has >> appeared. When it appears in a series which looks to them to be primarily >> engineering specifications, it is not valued as highly. A differently >> labeled series which was entirely composed of research output might be >> valued differently. It depends on the committee and the question before them, but it's not quite so cut-and-dried, at least outside the US. Engineering work is valued (as impact) when there's also "more serious" academic work next to or behind it; exclusively engineering work is generally not. > That's highly unlikely. Although the whole business of journal impact factors > and the value of conference publications is mainly pseudo-science, Indeed, one of the nice things about Google Scholar (for us pseudoacademics who have been fortunate enough to be able to play in the space between Internet science and Internet engineering) is that it's good enough for these pseudoscientific purposes (i.e. people who want a number that allows them to classify a person as "a serious academic"), while being quite a bit less picky about the label on the publication or on the publications citing it. > and the > whole question of open-access journals (where the author's institution pays) > versus traditional journals (where the reader's institution pays) is very > contentious, the chance of a brand new series from the IRTF breaking into > that game is vanishingly small. (IMNSHO, of course) > > RFCs have a 50 year history and are in fact widely cited in academic > publications. My own 2nd highest citation count** is 422 for RFC1958 > (unfortunately, most indexes have me as author, not editor). My highest > non-RFC citation count is 153. The case of RFCs-as-peer-reviewed-academic-work is one on which someone could almost do academic work on. (Indeed, Brian co-authored an [article on this for CCR][1], though it's an editorial note and therefore, strictly speaking in the manner of caring about the difference between Standards Track and Informational RFCs, does not count). On the one hand, they are usually often cited, because they're often used as a citation when an academic work needs to refer to an Internet protocol, which they often do. My own most-cited non-patent in [Google Scholar][2] is an tutorial that was designed to be a more useful cite than 5101/7011 for IPFIX and than 3954 for Netflow in these contexts; number four is RFC 5103, usually cited as "this study uses bidirectional flow data [RFC5103] as input...", i.e. it's most often used as academic citation shorthand for the *problem* 5103 addresses, not the particular solution therein described. On the other hand, protocol specifications are generally not academically rigorous, in the sense that the decisions that they document are sometimes (often?) made for accidental reasons as opposed to essential ones (i.e. tradition or politics, not a rigorous theoretical or empirical evaluation of the solution space). The criteria for evaluation of a protocol are different than those for most academic work in networking. (Whether *that's* a good thing is another question, and one that in part MAPRG was set up to provide a venue to address.) On a, um, third hand, in academia there's a complete lack of understanding (or interest in understanding) the work that goes into an RFC. They're often thought of as equivalent to tech reports (maybe in part because that's how you cite them in bibtex), but academics I've explained the process to generally comment with surprise something like "oh, so it's kind of like a big journal article", at least in the terms of the amount of review. > **according to Google Scholar. The ** here is, if I recall correctly, the work of Heather, who worked to get RFCs correctly indexed in Scholar. (Thanks, Heather!!) Back toward being on topic, what does the value of the brand mean in academia? Different things to different academics. Do I support the use of alternate stream labels and/or alternate publication venues for IRTF output? Depends on the RG and the type of output, but I don't see that a new label would automatically be a less-useful brand than RFC. (With respect to the IETF use of alternate labels specifically and the future of the stream more generally, ISTM that the proposed experiment has started a a useful conversation, and that converging on a problem statement or statements would be a good outcome for Monday's BoF. I'm still forming my own opinions on the relative importance of the various problems with the series. "Unsuitability of RFCs as a publication stream for Internet-related research" is not a big one, though.) [1]:http://delivery.acm.org/10.1145/1680000/1672315/p31-carpenter.pdf [2]:https://scholar.google.ch/citations?user=vTA2dL0AAAAJ&hl=en > > Brian > >> I agree with Eliot's earlier point that this is a "might", and that the >> value ascribed to it depends not just on its output but on the work done to >> highlight the stream's output. >> >> regards, >> >> Ted >> >> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus
- [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Eliot Lear
- Re: [Rfcplusplus] Conversation as metaphor Eric C Rosen
- Re: [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Bob Hinden
- Re: [Rfcplusplus] Conversation as metaphor Andrew Sullivan
- Re: [Rfcplusplus] Conversation as metaphor Bob Hinden
- Re: [Rfcplusplus] Conversation as metaphor Eric C Rosen
- Re: [Rfcplusplus] Conversation as metaphor Eric Rescorla
- Re: [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Aaron Falk
- Re: [Rfcplusplus] Conversation as metaphor Andrew Sullivan
- Re: [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Aaron Falk
- Re: [Rfcplusplus] Conversation as metaphor Eric C Rosen
- Re: [Rfcplusplus] Conversation as metaphor Aaron Falk
- Re: [Rfcplusplus] Conversation as metaphor Melinda Shore
- Re: [Rfcplusplus] Conversation as metaphor Aaron Falk
- [Rfcplusplus] What would the ISE publish [Was: Co… RFC ISE (Adrian Farrel)
- Re: [Rfcplusplus] Conversation as metaphor Brian E Carpenter
- Re: [Rfcplusplus] Conversation as metaphor Brian E Carpenter
- Re: [Rfcplusplus] Conversation as metaphor Brian E Carpenter
- Re: [Rfcplusplus] Conversation as metaphor Brian E Carpenter
- Re: [Rfcplusplus] Conversation as metaphor Brian Trammell (IETF)
- Re: [Rfcplusplus] Conversation as metaphor Ted Hardie
- Re: [Rfcplusplus] Conversation as metaphor Peter Saint-Andre
- Re: [Rfcplusplus] Conversation as metaphor RFC ISE (Adrian Farrel)
- Re: [Rfcplusplus] Conversation as metaphor Peter Saint-Andre
- Re: [Rfcplusplus] Conversation as metaphor S Moonesamy
- Re: [Rfcplusplus] Conversation as metaphor Peter Saint-Andre
- Re: [Rfcplusplus] Conversation as metaphor Eric Rescorla
- Re: [Rfcplusplus] Conversation as metaphor Eliot Lear
- Re: [Rfcplusplus] Conversation as metaphor S Moonesamy
- Re: [Rfcplusplus] Conversation as metaphor Brian E Carpenter
- Re: [Rfcplusplus] Conversation as metaphor Martin Thomson
- Re: [Rfcplusplus] Conversation as metaphor Joel M. Halpern
- Re: [Rfcplusplus] Conversation as metaphor Martin Thomson
- Re: [Rfcplusplus] Conversation as metaphor Eliot Lear
- Re: [Rfcplusplus] Conversation as metaphor S Moonesamy
- Re: [Rfcplusplus] Conversation as metaphor Aaron Falk