John, I had decided to stop posting this thread but this note and its immediate predecessor seem to call for comment. Inline below... --On Tuesday, July 07, 2015 10:09 +0000 John Levine <johnl@xxxxxxxxx> wrote: >... > A long time ago, somone added all of the RFCs up to that time > to the ACM digital library. They're still there. Here's a > typical one: > > http://dl.acm.org/citation.cfm?id=RFC0959&coll=DL&dl=GUIDE&CFI > D=690945111&CFTOKEN=66477025 > > Click on the "Get this RFC" link, and you will find a page > that offers to sell you a copy for $15. If we updated the > indexes and included DOIs, it'd be our DOI which links > directly to our free stuff. > If you dig through the archives of this list, you will find a > snarky thread in which someone found a power industry standard > that referenced an RFC, I think the one for TCP. It provided > a link to Global Engineering Documents, who would sell you a > printed copy for about $40. Again, now that our references > have DOIs, that's likely to show up when people reference > them, a robust way to let people get to our free resources. To the best of my knowledge, it has never been a goal of the RFC series to prevent people from selling paper copies of the documents to anyone who feels like paying for them. Are the DOIs that could help people avoid paying excessive amounts of money for what they could get for free likely to show up? Not Our Problem, I think, but note https://global.ihs.com/doc_detail.cfm?&item_s_key=00651593&item_key_date=840831, where the organization that succeeded Global Engineering Standards will be happy to sell you PDF and paper copies or RFC 7517 for $56 (or one or the other for $40). That RFC has DOIs in its references, was presumably assigned one at publication time, etc. It wasn't chosen as particularly relevant, I just went to iHS's IETF page (https://global.ihs.com/standards.cfm?publisher=IETF) and picked the highest number in their "new from IETF list". FWIW, RFC 793 TCP is still listed as one of their "best sellers". If we did care, we could change the policy about freedom to reproduce in whole and use the copies however wanted --a policy that predates not only the IETF Trust but the IETF -- and tell iHS that we'd like a royalty. I'm sure they would be happy to jack up the prices by 20% and give us half of it, and reasonably confident, given their market, that it wouldn't affect business significantly. I hope we don't go there. But it seems to me that is a separate issue from DOIs and that, in turn, is why a theory that putting "our" DOIs on documents will save some of the people who have been paying for RFCs for years from doing that is just not relevant to the present discussion. Your other note seems to illustrate my point: --On Tuesday, July 07, 2015 10:00 +0000 John Levine <johnl@xxxxxxxxx> wrote: > Here's a thought experiment. What sort of bad things would > happen if the RFC publisher were to add DOIs in the manner > described in this draft for a couple of months? > > Well, whatever they are, they've already happened, since all > RFCs published since early May have included DOIs. > > Surely we have something more useful to talk about. Ok, let's back up a little bit. The RFC Editor, RSOC, and IAB decided, in some combination, that DOIs would be a good idea. There were some announcements made at plenaries, a few comments from the floor microphone, an announcement of an SOW that asked for comments on the SOW itself but not on whether the idea was appropriate (reasonable - not the IAD or IAOC's job to get involved in the latter) and, apparently, some discussion on rfc-interest. With the possible exception of the last (which I have not reviewed), none of those discussions went into detail about formats, relationships, or possible side-effects and the "these are important to make the RFC Series legitimate" argument did not seem to have been tested in depth (nor were other arguments such as "these will prevent people who could have gotten RFCs for free from paying for them"). For those of us who are still a little concerned about identifier formats, opacity notwithstanding, your comment a few days ago: > In retrospect, rather than making them look like RFC numbers I should > have used a pseudo-random 10 digit hash of the date, authors, and > document title so people would stop complaining about RFC123 vs. > RFC0123. strongly implies that issue was never discussed in any of those contexts but simply left up to the discretion of the implementer. I believe there was also no public (i.e., on the IETF or IETF-Announce lists) call for comments on the contract with the DOI Registration Agency, but I could have missed it. That may violate the spirit of BCP 101 but that community may have, in practice, given up on those supposed requirements, so maybe no big deal. Incorporating several of Dave Crocker's comments by reference, that would have been fine were there no controversy involved in this and no procedural or public presentation implications that affect the entire community. The length of this thread and at least a subset of the comments seem to indicate that there is controversy and that there are broader issues. Separately from Dave's comments and concerns, at least some of us believe that, if the IAB is going to put out a document or call for comments on it, that document should be correct. In this case, if the reason for doing DOIs is that some people asked and no one saw a reason why not, then the document should say that, not try to provide more high-sounding justifications that cannot be supported by actually experience or broadly-accepted principles. Melinda's notes have been much more articulate on the accuracy subject than I can be. So, let's adopt what I infer to be your position -- DOIs are already deployed and there is no going back, so there is no point arguing about that; the identifiers used in the suffix are opaque so, if the community really doesn't like whatever has been assigned, it can always be changed (and anyone who infers by looking at the string that 10.17487/RFC0793 is actually more likely to point to RFC 793 rather than, e.g., RFC 7 is committing a grave error (and/or in a state of sin). It seem to me that leaves us with some questions that are fundamentally separate from whether DOIs for RFCs are deployed but that are important to the community and how things are managed: (1) If all of the important decisions have been made and can't be reversed, why it it necessary (or even desirable) to publish this document rather than making a clear statement of faces on some RFC Editor web page? (2) Why did the IAB make a tentative decision to publish the document in the IAB Stream and issue a call for comments that did not seem to be restricted to those topics on which comments are actually relevant? If that was an oversight, is the IAB having discussions about how to prevent similar oversights in the future? If the IAB thinks that all is well, does the community disagree strongly enough that consideration of remedies is in order? (3) Assuming the document is going to continue in the IAB Stream, what is going to be the mechanism for resolving issues about the accuracy of various statements? I hope "we hired a professional, she thought everything was ok, so it is" is not the answer to that question but, if it is, it would be good to know it immediately so that the rest of us can stop wasting our time (and that further calls into question the IAB's decision to issue a call for comment on the document). (4) Similarly and as a less technical example, given Joe Hildebrand's comments about other sorts of identifiers, it would seem appropriate, and to likely reduce several of the objections, if this document were modified to make it explicit the DOIs are members of a family and that incorporating them does not preclude incorporating others. If there isn't general agreement that would be a good idea, what is going to be the process for resolving the disagreement? (5) If the community actually does not believe that the review process followed before irreversible decisions were made was adequate (or doesn't like the answers to (3) or (4) above), what is being done to prevent similar inadequate sequences of reviews in the future? If the community believes it was not appropriate but the IAB (or RSOC, or RSE) believe it was reasonable and would do the same thing again, does the community really care enough to hold some combination of them accountable and, if so, how? best, john