idnits 2.17.00 (12 Aug 2021) /tmp/idnits25609/draft-handley-doc-market-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 M. Handley 3 University College London 4 INTERNET-DRAFT E. Rescorla 5 draft-handley-doc-market-00.txt RTFM, Inc. 7 A Market for RFC Publication and Review 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 We describe a market mechanism for providing incentive for the review 31 of IETF documents. Reviewers would be "paid" by the IESG to for their 32 reviews. In turn, document authors would need to "pay" the IESG to 33 take up their documents. This mechanism rewards reviewers for their 34 reviews, thus (hopefully) increasing the quantity and quality of 35 reviews. 37 1. Introduction 39 The IETF process depends critically on peer review of documents. How- 40 ever, it is notoriously difficult to get quality review of documents. 41 Most documents receive few if any Last Call comments and it's quite 42 common to see that almost noone has read the documents at IETF meet- 43 ings. We believe that much of the reason for this lack of review is a 44 lack of incentives. Since reviewers are not compensated, it is not 45 surprising that the IETF process lacks sufficiently detailed early 46 review. 48 In this memo, we describe a system for compensating reviewers for 49 reviews. Although the IETF is not in a position to pay reviewers 50 actual money, that does not mean that there is nothing of value to 51 offer them. The most obvious thing to offer is the right to publish 52 documents. We propose to use this right as the source of our incen- 53 tives. 55 2. An IETF Currency 57 We propose to use the common tactic of introducing an internal IETF 58 currency, the "Itil", based on the right to publish documents. The 59 source of the Itil's value is that the IESG charges individuals and 60 working groups for the right to publish documents. The IETF can then 61 pay individuals for specific activities judged to be useful. 63 2.1. Charging for Publication 65 The central idea is that the IESG charges for admission to the publi- 66 cation queue. When a document is submitted to the IESG, the authors 67 must also provide a certain number of Itils. This admission fee is 68 what gives the Itil its value. Since no document can be published 69 without paying the fee, it's therefore desirable to be in possession 70 of Itils. It is not necessary that the authors of the document per- 71 sonally have the appropriate number of Itils. Rather, they merely 72 need to convince enough people to "chip in" so that they can collec- 73 tively pay the fee. This allows people to pay for the publication of 74 documents they consider valuable. 76 Note that the idea is not to circumvent the IESG quality review pro- 77 cess. One cannot simply pay one's fee and publish. Rather, the fee is 78 simply for admission to the queue. Once the fee has been paid, the 79 IESG review process proceeds as normal. Similarly, Area Director 80 approval would be required to submit documents, as per usual. The 81 purpose of this fee is purely to create the proper incentives. 83 The publication fee is intentionally left unspecified here. It is the 84 intent that the IESG could adjust the fee as necessary to keep the 85 queue of appropriate depth. We envision the IESG publishing a price 86 list and adjusting it on a periodic basis. 88 2.2. Issuing Itils 90 The basic way in which IETF members obtain Itils is that they perform 91 services judged to be socially useful. These services might include: 92 * Reviewing documents. 93 * Chairing working groups. 94 * Serving on area directorates. 96 We envision that the IESG would publish a price list of the value of 97 various services. Thus, IETF members could know what they were going 98 to be paid for various services. 100 2.3. Transferability 102 In the proposed system, the only built-in way to obtain Itils is to 103 get them from the IESG. The only built-in way to spend them is to pay 104 the IESG for publication. However, in practice, a system of fungible 105 tokens will usually end up being used for private transactions as 106 well. Rather than discouraging this, we think it better to encourage 107 it. Thus, for instance, members of the WG might pay an external (to 108 the WG) expert to assist them in developing their system. The exis- 109 tence of such a secondary market for Itils means that the IESG needs 110 to set the price on fewer quantities since the market will automati- 111 cally adjust them to their efficient values. 113 3. Practical Issues 115 In this section we discuss a number of practical issues relating to 116 our proposed system. 118 3.1. Ensuring Quality 120 One obvious objection here is that reviewers will submit low quality 121 reviews in order to accumulate Itils. This is easily solved by 122 requiring reviews to be accepted by a member of the IESG. If reviews 123 are not judged to be of sufficient quality then they simply would not 124 be paid for. 126 In practice the IESG might simply accept reviews by default, and 127 withdraw the payment after the fact if a valid complaint about a 128 review were received. As most reviews would be public, kept online, 129 and attributed to an individual, we expect social pressures would 130 prevent people trying to game the system. 132 3.2. Accounting 134 The conventional method of providing a currency is to have actual 135 physical tokens. This is inconvenient in the IETF. However, it's rel- 136 atively simple just to keep electronic accounts of everyone's Itil 137 balance on a web site somewhere. 139 The third-party transfer of Itils poses a minor authentication prob- 140 lem. However, unlike cash, Itils are not anonymous. Thus if someone 141 asserts that someone else has transfered one of their Itils without 142 their authorisation then it is relatively simple to audit what really 143 happened. Again, we expect that as the IETF is a relatively small 144 organization of peers, social pressure will mean that we shouldn't 145 need strong authentication mechanisms. 147 3.3. Undesirable Incentives 149 If the IESG changes a per-document fee, then there is an incentive 150 for document authors to merge what should be multiple documents into 151 a single document. However, if the IESG charges a per-page fee, then 152 there's a risk of the system quickly getting very complex, with pos- 153 sibilities like paying more for better reviews. A per-page fee also 154 provides disincentive for properly explaining the background to an 155 idea. Clearly it's undesirable for documents to be excessively long, 156 but it's also undesirable for documents to be excessively brief. 158 We believe the system has to be simple to work well. Thus we propose 159 a flat fee per document as a starting point. The IESG can always 160 require a document to be re-submitted if they believe that it would 161 be better as multiple separate documents. Charging a re-submission 162 fee would then provide a disincentive to submitting merged documents 163 in the first place. 165 3.4. Priming the Pump 167 In the initial stages of this system, there will be an undersupply of 168 Itils relative to the demand. We propose to prime the pump by simply 169 issuing a modest number of Itils initially. A number of criteria 170 could be used for ths initial grant, including a lottery, a minimal 171 bar (everyone who's published an RFC), or delaying charging for pub- 172 lication until a sufficient number of Itils had been earned. 174 4. Some Initial Prices 176 Although the IESG needs to periodically adjust prices, it is useful 177 to have an idea of an initial starting set. We propose the following 178 starting price list. Negative numbers are paid to the IESG, positive 179 numbers are paid by the IESG. 180 Activity Price 181 ------------------------------------------------- 182 Admission to the IESG queue -5 183 Resubmission of a revised document -3 184 Review of a document +1 185 Chairing a WG +2/yr 186 Serving on the IESG +5/yr 187 Serving on the IAB +2/yr 188 Serving on a directorate +1/yr 189 Author's Addresses 190 Mark Handley 191 Department of Computer Science 192 University College London 193 Gower Street 194 London 195 WC1E 6BT 196 UK. 198 Eric Rescorla 199 RTFM, Inc. 200 2064 Edgewood Drive 201 Palo Alto, CA 94303 202 USA 203 Phone: (650)-320-8549