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

Dave Crocker <dhc@dcrocker.net> Tue, 07 July 2015 15:43 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31FC1A892F for <ietf@ietfa.amsl.com>; Tue, 7 Jul 2015 08:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 Ei0SEL89KWhJ for <ietf@ietfa.amsl.com>; Tue, 7 Jul 2015 08:43:41 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9881A8899 for <ietf@ietf.org>; Tue, 7 Jul 2015 08:43:41 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t67FhVRO031159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Jul 2015 08:43:35 -0700
Message-ID: <559BF398.3020801@dcrocker.net>
Date: Tue, 07 Jul 2015 08:43:20 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>, ietf@ietf.org
Subject: Re: Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs)
References: <20150704002936.1550.qmail@ary.lan> <F927BA40-802C-41F4-824C-DF9C2710F176@frobbit.se> <55978F22.8060409@cisco.com> <175C1388-1239-444A-82A8-69563C931843@frobbit.se> <alpine.OSX.2.11.1507042128170.5867@ary.local> <5B2D846C-D6A9-4EA2-A4D0-64CED277D134@frobbit.se> <91BB42DD71AD5F746CFDF51F@JcK-HP8200.jck.com> <48A70E7D-B93D-4DC3-8A68-43964C0BAF8C@mnt.se> <A9F6C47A5BEB302A8C256264@P5> <m2bnfrd24z.wl%randy@psg.com> <28735CA0-5A7B-4912-B375-97F96114A78A@mnt.se> <CAAQiQReE0oZJW2fTntF1hFYdW1TB0gs-c3qSA0p2SgMSfJxmZA@mail.gmail.com> <C17E477A-1739-4B14-941D-2F5F91906A5B@mnt.se> <559AD26C.3050701@gmail.com> <559B818F.2060003@cisco.com> <559B8D73.9060906@gmail.com> <559B8FC7.5010106@cisco.com>
In-Reply-To: <559B8FC7.5010106@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 07 Jul 2015 08:43:36 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YJhMoEaSKRy-rHrSnkXDCWU-GyY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 15:43:43 -0000

On 7/7/2015 1:37 AM, Eliot Lear wrote:
> On 7/7/15 10:27 AM, Melinda Shore wrote:
>> On 7/6/15 11:36 PM, Eliot Lear wrote:
>>> There goes the whistle.  Unsupported assertion while claiming same,
>>> Offense.  5 yard penalty.  How about instead pointing out the incorrect
>>> statements and test your assertion?
>> I assume that this is some sort of sports metaphor?
>>
>> I've pointed this out several times but the justifications
>> presented in the intro are largely false, and if they're
>> not false it's because they're hedged.  Statements like
>> "organizations that use DOIs can have trouble locating
>> documents that don't have DOIs" are true only because of
>> the presence of the word "can"; I think you'd be extremely
>> hard-pressed to find an organization that can't track down
>> a publicly-available document that doesn't have a DOI
>> assigned.
> 
> That seems like a fair criticism, and at the very least calls for some
> justification for that particular sentence.  Thank you for being specific.

Actually, her comment points to a need to review the approach and
language of the entire Introduction, not just that sentence.

To whit:


> Introduction
...
>    Each DOI is associated with bibliographic metadata about the object,
>    including one or more URIs where the object can be found.  The DOI
>    system also provides many features not relevant to RFCs, such as the
>    ability to update the metadata after the DOI is assigned, and for

We change post-publication RFC meta-data all the time.  Using my obvious
example:

   RFC 822 --
        Obsoleted by RFC2822
        Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156
        Errata

That's three kinds of post-publication meta-data changed and the details
are common to many RFCs.

And this error in the Introduction suggests that the use of DOI's has
not been considered all that thoughtfully -- which would be ok if the
document took a more modest approach to its justification and expected use.


>    The wide use of DOIs suggests that even though RFCs can be downloaded
>    directly from the IETF for free, organizations that use DOIs can have
>    trouble locating documents that don't have DOIs.  DOIs with metadata
>    that points to the existing free online RFCs would make RFCs easier
>    to find and use.  Some scholarly publishers accept DOIs as references
>    in published documents, and some versions of bibtex can automatically
>    retrieve the bibliographic data for a DOI and format it.  Hence DOIs
>    would make RFCs easier to cite.

The 'can have trouble' suggests an approach here that is trying to
over-sell the need.


>    The benefits of DOIs apply equally to documents from all of the RFC
>    submission streams, so all RFCs are assigned DOIs.
> 

DOIs are popular.  DOIs are flexible.  DOIs are inexpensive to obtain
and use.  They are helpful to many potential consumers of IETF documents
to bring its publications under the DOI scheme for the convenience of
those consumers.

Really, that's all the Introduction needs to say.


>> There have also been suggestions that since the local part
>> of a DOI is opaque its structure doesn't actually matter.
>> I would argue that its structure doesn't matter to the
>> IDF but should matter to us, much in the same way that
>> a protocol that carries an encrypted blob of something
>> doesn't care about what's inside that blob but the blob's
>> sender and recipients care a very great deal.  That's
>> a feature of plain old layering and encapsulation.  At
>> this point we have enough experience with naming to be
>> reluctant to adopt flat namespaces when avoidable, I think.
> 
> Do we have any reason to believe that we will be scaling a DOI to beyond
> the use of RFC such that a flat name won't suffice?  Additional
> hierarchy comes with its own complexities.

We all tend to underestimate scaling effects.  As an example, we used to
maintain the myth that internet-drafts had short-lived utility.  I
submit the question asked here suffers the same problem:  The IETF has
quite a few different document series.  While the RFCs are the
pre-eminent example, the entire body of explicit publications (RFCs,
internet-drafts, "Statements", ...) are worthy candidates for citation
and therefore for inclusion under DOIs.  (BTW, this list of additional
document series the IETF issues is why I suggest saying "IETF documents"
rather than just "RFCs".)

Global opacity of the left-hand side of email addresses proved to be a
strategic benefit in the Internet's extensibility, and in ways that I
believe were entirely unanticipated.  Melinda's point represents, in my
view, a foundational issue in the development of any naming scheme.


>> I'm not opposed to putting DOIs on RFCs despite seeing scant
>> benefit from doing so.  I am opposed to putting out documents
>> that provide justifications that are not actually correct.

+1

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net