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(_at_)taugh(_dot_)com> 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(_at_)taugh(_dot_)com> 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