ietf
[Top] [All Lists]

Re: Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs)

2015-07-07 16:17:53
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 7/7/15 9:52 AM, John C Klensin wrote:


--On Tuesday, July 07, 2015 16:18 +0000 "Eggert, Lars" 
<lars(_at_)netapp(_dot_)com> wrote:

Unless the IAOC and RFC Editor negotiated a particularly 
unusual deal with the chosen DOI Registration Agency, probably
not.  In general, signing up to issue DOIs carries with it not
only a set of charges but an obligation to use DOIs in one's
own documents.

As Eliot said, it seems to be a request, not an obligation. The
ACM and IEEE - both of which assign DOIs for all their 
publications - are not turning down papers because the authors 
didn't include DOIs in their bibliographies, and neither would 
we.

We haven't seen the contract and this question is presumably easily
answered by someone with the information rather than starting a
long thread of speculation.  In particular, even if it were a firm
obligation, all the above would prove is that ACM and IEEE are not
insisting that authors supply DOIs in references that they can
include in articles, something that would, in turn, require that
they not publish articles that contain references to document for
which no DOIs have been assigned.  The latter would be an
unsustainable requirement and an impossible one for non-digital
documents and documents whose publishers are no longer around.
While third-party assignment of bibliographic categories is
feasible (and common), DOIs have to be assigned by publishers or
surrogates for them.

Given Dave Crocker's recent comments about I-Ds, Statements, etc.
(better examples than mine about possible additional series, btw),
it would also be good for someone who actually knows to assure us
that the contract is strictly limited to RFCs or RFC Editor
projects and cannot be used to expand the obligation (or "request")
to other IETF publications.

The RFC Editor has been assigned a DOI prefix. It is up to us
regarding how that prefix is used. I do have a request in hand that
someone would like us to assign DOIs to the old IEN documents (see
http://www.rfc-editor.org/RFCoverview.html#history), but I'm holding
off regarding any decisions in that matter pending how the experience
with DOIs for RFCs go.

I strongly advise against DOI assignment for I-Ds, but that's up to
the IESG.


Let me say again what I think many others have said.  There is 
really no objection to including DOIs in RFCs on the basis 
represented by recently-published ones.  There is probably no 
objection to including the DOI identifier in the header or a new 
footer of newly-published RFCs at the discretion of the RFC Editor
(something I believe is covered by the obligation and/or request
and to make it easy to include them in references to an RFC someone
has in hand, even if retroactively-assigned ones have to be looked
up as metadata).

The objections are to:

* The review process that got us here, including the apparent 
request to have the community review and endorse something that has
already been done and won't be un-done.

This is an interesting problem, as a very similar process is being
done with the format work. We are working on drafts, testing
implementations, and at least at the moment, don't intend to finalize
the drafts until we have some running code to validate what we've
done. There is some discussion as to whether that model should change,
but at least the original plan was "discuss then code/implement then
publish".  I think, all things considered, that keeping the community
informed AND waiting for running code is a reasonable process. If you
have a suggestion on how to reorder this type of egg and chicken that
won't leave projects deadlocked, please let me know.


* A document that appears to make claims that are hard to justify
as completely accurate, most of all of which claims could be
eliminated by simply turning the document into a factual statement
as to what was (or is being) done whose justification is limited to
the obvious truth that some groups in the community wanted this and
no one saw evidence of harm. As Dave says, the document may be
trying to over-sell the need. I would add that we really don't need
to "sell" DOIs at all; if more or less lavish claims about either
utility or demand need to be made, let's leave them to the DOI
community and promoters.


I think some explanation is necessary for people who have no idea
around the context, but I'll reread with an eye towards determining if
it went overboard on that.

Thank you for the feedback,
Heather


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJVnEHnAAoJEER/xjINbZoGSl4H/05hZbT34Gb1uq6bah3FwkuF
06/lS5MIatEow/Mto/hkUB2CMXuigjJuLq/ssBre0nGkSuqbMonAg4NdA2lUggUQ
3P2vYY2iH7Iew6tySWYzu/jMQGMV67aF1cgKXGPs0E8zWTzHj/b+eewZcbvyDkwv
B3fao65ejQzYDvD/575ybIBPz4t+NVIxpmlkHMw/Ue9jH5POTZmhPTVnesBk18In
AinLBBhz8DNQasZdd+0DYlUU6NgKnr6s8qbyfZEY33QZJL3ahKivMF4O1lJyxan9
xlXR/0vES9n4COF3f4eyLdbBMTzlVjF6HdPR2gdelfZLOIKCkfEGne7sQvl0HW4=
=ibue
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>