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

From: IAB Chair <[email-masked]>
Date: Wed, 1 Jul 2015 14:34:55 -0400

Dear colleagues,

This is an announcement of an IETF-wide Call for Comment on
draft-iab-doi-04.

The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection here:
http://datatracker.ietf.org/doc/draft-iab-doi/

The Call for Comment will last until 2015-07-29. Please send comments to
[email-masked].

Best regards,
Andrew Sullivan
IAB chair
On behalf of the IAB

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 2 Jul 2015 06:18:38 +0000

> This is an announcement of an IETF-wide Call for Comment on

Ship it.

Lars

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 2 Jul 2015 16:44:44 +1000

> > This is an announcement of an IETF-wide Call for Comment on

I agree, except for a small change to section 2: the preferred URI for
resolution now begins with "https://doi.org" instead of "http://dx.doi.org"
<http://www.doi.org/doi_handbook/3_Resolution.html#3.7.3>

Cheers

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 2 Jul 2015 16:51:14 +1000

Hrm... that link actually says "http://doi.org", but a little test shows
that https works too. In any case, I'll let the editors decide which URL to
use.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jul 2015 09:30:45 +0200

On Wed, Jul 01, 2015 at 02:34:55PM -0400,
 IAB Chair <[email-masked]> wrote 

> The document is being considered for publication as an Informational RFC

This RFC must not be published.

DOIs are the opposite of what the IETF works for: the technical
standard is not freely available (88 swiss francs and I cannot
redistribute it), not developed in an open way, and it is managed by
an opaque private corporation (what about <https://open-stand.org/>).

[If you ask me what identifier we shoulds use, I suggest that our dog
food - URIs - is fine. Otherwise, ARKs
<https://confluence.ucop.edu/display/Curation/ARK>
<https://en.wikipedia.org/wiki/Archival_Resource_Key>
<https://datatracker.ietf.org/doc/draft-kunze-ark/> are interesting,
too, if we want something widely recognized in the information and
documentation world.]

> Online databases and indexes that include RFCs should be updated to
> include the DOI, e.g., the ACM Digital Library.

That's the worst part of the RFC: going from an open and working system
(URLs) to a closed and privately controlled one. This sentence must
be removed even if the RFC is published.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jul 2015 19:48:29 +1200

Stephane,

Seriously?

"if we want something widely recognized in the information and
documentation world" the only realistic answer today is DOIs.

Regards
   Brian Carpenter

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 2 Jul 2015 08:52:38 +0000

> an opaque private corporation (what about <https://open-stand.org/>).

True. But DOIs are also widely used, esp. in the academic community. For example, some university tenure committees will only consider publications as relevant that have a DOI. If we want to retain (or attract) academic participation, it would be helpful if RFCs could be made to count more towards tenure. The cost is minimal. People who dislike them can ignore them. People who benefit from them will use them. Everyone wins?

Various people have tried to make the argument before that RFCs should be considered as equivalent to a journal pub (e.g., http://www.sigcomm.org/sites/default/files/ccr/papers/2010/January/1672308-1672315.pdf). But it's a difficult argument to make, and you need to make it time and time again. Biting the bullet and assigning DOIs is an easier solution.

Lars

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Jul 2015 11:17:50 +0200

> True. But DOIs are also widely used, esp. in the academic community. For example, some university tenure committees will only consider publications as relevant that have a DOI. If we want to retain…

Yes.  Academia sets the rules, not us.  Including the DOI is of value if
it brings in more academics.

Eliot

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 02 Jul 2015 10:21:46 +0100

Any chance of adding some words to the effect that RFCs are free both as
in gratis and in the freedom sense? That should dispel any views that
this is more than a metadata play for academic brownie points.

Funny though isn't it.. back with CNRI again.

Christian

> documentation world" the only realistic answer today is DOIs.

Christian de Larrinaga  FBCS, CITP,
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
[email-masked]
-------------------------

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Jul 2015 18:26:34 +0900

i would appreciate hearing from actual publishing academics on the
subject if doi would help them.

randy

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 2 Jul 2015 11:35:51 +0200

> subject if doi would help them.

In Italy, at the moment, not so much.  In order to be taken in account in
evaluation procedures, it must be published on an indexed journal.  (Yes,
even works published on conferences are not considered for evaluation
purposes)

Riccardo

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Jul 2015 11:40:14 +0200

Christian de Larrinaga <[email-masked]> writes:

> in gratis and in the freedom sense?

Makes sense, but be careful with words.  RFCs aren't free in all freedom
senses, for example you can't even include them in FOSS projects since
RFCs aren't licensed freely enough.

/Simon

> That should dispel any views that this is more than a metadata play
> for academic brownie points.
>

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 02 Jul 2015 11:19:44 +0100

inline

> RFCs aren't licensed freely enough.

Indeed a good clarification. I wasn't referring to the content but
access to and use of the RFCs.

C

--

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2015 11:22:39 +0100

On 1 Jul 2015, at 19:34, IAB Chair <[email-masked]> wrote:
> The Call for Comment will last until 2015-07-29. Please send comments to [email-masked].

I strongly support publication. DOIs are widely recognised and used in the library and academic communities, and are an essential piece of metadata that a modern publication series needs to provide. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2015 11:26:01 +0100

On 2 Jul 2015, at 10:26, Randy Bush <[email-masked]> wrote:
> i would appreciate hearing from actual publishing academics on the subject if doi would help them.

Yes, it helps. This is one of the standard pieces of metadata that libraries use, and being able to provide a DOI makes things easier and bring the RFC series into line with typical best practice for academic publishing. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Leif Johansson <[email-masked]>
Date: Thu, 02 Jul 2015 12:30:18 +0200

> an opaque private corporation (what about <https://open-stand.org/>).

So you would oppose the use of (say) ASN.1 in RFCs, not because of
its complexity but because the specification is not available under
comparable license to that of RFCs?

I'm curious to understand if your opposition to DOIs is fundamentally
different from similar discussions we've had in the IETF over the
years concerning reference to non-free specifications.

	Cheers Leif

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Jul 2015 19:51:34 +0900

> Yes, it helps. This is one of the standard pieces of metadata that
> libraries use, and being able to provide a DOI makes things easier and
> bring the RFC series into line with typical best practice for academic
> publishing.

really?  i am told by uk peers that it is similar to what Riccardo wrote.

Riccardo Bernardini <[email-masked]> wrote:
> In Italy, at the moment, not so much.  In order to be taken in account
> in evaluation procedures, it must be published on an indexed journal.
> (Yes, even works published on conferences are not considered for
> evaluation purposes)

randy

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2015 11:57:51 +0100

> really?  i am told by uk peers that it is similar to what Riccardo wrote.

It's possible that practises across different UK universities are not entirely homogeneous...

Is having a DOI critical? No, obviously not, but it does help in some cases, and does make some things easier. At negligible cost.

-- 
Colin Perkins
https://csperkins.org/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jul 2015 12:05:10 +0100

> The Call for Comment will last until 2015-07-29. Please send comments to

I think this is just fine - the draft documents what has been
done already and works already. I like that rfc1149 is used
as the example:-)

I dunno if having a DOI for all RFCs is a huge deal, but it's
at worst harmless and probably slightly helpful from my sort-of
academic perspective.

It seems a little odd that there'll now be a direct monetary
cost per new RFC, but there've been real costs per-RFC always
so that's not really new, just odd.

When the style guide is modified I might have comments about
"The RFC Style Guide will be updated to describe the rules
for including DOIs in the References sections of RFCs" as I
don't like new "rules" in general but that'll probably be fine
when we get there so long as the style guide has some new
advice for using DOIs and doesn't make spending time tracking
down a DOI a MUST for authors.

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Jul 2015 20:06:28 +0900

> it does help in some cases, and does make some things easier.  At
> negligible cost.

thanks

randy

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 08:49:42 -0400

--On Thursday, July 02, 2015 06:18 +0000 "Eggert, Lars"
<[email-masked]> wrote:

> This is an announcement of an IETF-wide Call for Comment on

I have sent comments separately to the IAB list, as requested,
but, since the IETF list seems interested in discussing this,
three high points (one of which was not in that earlier note):

(1) The use of the format 10.17487/RFC1149 is ill-advised on
internationalization and future-proofing grounds.  It would have
been far better to assign a code, say "1", to the RFC series,
reserve all other codes for future use, and use something more
like 10.17487/1.1149.

(2) While the IAB (and RFC Editor) are not required to ask the
community before making a change like this, making the change
(effectively irreversibly) and then asking for comments seems to
me to be in bad taste.  The RFC Editor has already modified the
index and published documents containing DOIs in this form (see
the References section of RFC 7504 for examples of post-approval
changes to that section).   Identifier stability considerations
suggest that their use, and that format, are now irreversible.
The format issue mentioned in (1) was decided on without an
opportunity for broad community input (it may have been raised
in the RSOC, a closed group, or on the rfc-interest list, but
neither constitutes the broad community).  The IAB or RFC
Editor, or the IAOC on their behalf, have presumably signed a
contract with a DOI-issuing entity that contains provisions the
community has not seen.   And now the IAB is asking for
comments?  If the intent was to have the community look for
editorial mistakes, the request should have said that.   

Probably, people who don't approve of this way of doing things
should challenge the IAB on that subject and/or seek to identify
the IAB members who pushed this through before irreversible or
contractual actions are taken and discuss that behavior with the
Nomcom.

(3) I am now aware of three important efforts to establish a
standard for persistent identifiers for documents and data that
are available electronically or referenced electronically: the
semantic web's "entity registration system" (ERS), DOIs, and the
IETF's URNs.  The three specs do not have the same scope, but
their scope overlaps significantly.  There may well be others.
To the extent to which this document constitutes having the IAB
pick a winner or deciding that the winner was picked elsewhere
and recognizing that, it raises some important issues with the
"eat your own dogfood" issue and the IAB's position on the
active URNBIS WG.  For those who have forgotten or aren't old
enough to remember, it may also be worth noting that the
so-called "Kobe incident" that set off the reorganizations that
produced the Nomcom and the current decision-making structure of
the IETF was essentially about the IAB making technology choices
for the community that the community did not support.

best,
    john

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 02 Jul 2015 15:33:03 +0200

> their scope overlaps significantly.  There may well be others.

I want to point out that in the early days of both DOI and URN there where significant discussions about whether/how DOI/Handles could be viewed from an IETF architecture perspective as a URN namespace.

See for example <http://www.ietf.org/mail-archive/web/urn/current/msg01071.html>

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 09:39:04 -0400

> the subject if doi would help them.

Too late.  The decision was made and implemented before the IAB
asked for a final review of these document.  So, whether
assigning DOIs to the RFC Series is a good idea or a bad one,
whether the format chosen for the DOI suffix is optimal or not,
etc., the discussion is essentially OBE.  At least as the IAB
has chosen to structure things, it needed to occur with the RFC
Editor and/or RSOC [1] many months ago.  

It seems to me that the only meaningful questions for the
community at this point are (i) whether the document should be
published in the RFC Series and (ii) whether it is satisfactory
from an editorial standpoint.  For example, I think a discussion
of tradeoffs, including those associated with effectively
endorsing a "pay per identifier" system, would be desirable and
that is an editorial issue.

See my earlier note for more discussion on the "things that it
is too late to undo" part.

     john

[1] Disclaimer:  I was a member of the RSOC until the IAB fired
me in mid-2013.  I obviously don't know why they made that
decision although I note that everyone who had been continuously
active on, and contributing to, the RSOC retired or was removed
at the same time.  While I was pleased to be relieved of the
additional area of responsibility, I was concerned that there
might be no one left who would spot the small issues (like the
i18n one) and downsides of proposals like this one and insist on
their being fully discussed and reviewed with the community (and
not just the rfc-interest list) before irreversible actions were
taken.  If anyone is concerned that I might be more upset about
the way this has been handled if it were not for that history,
you may be right but I don't think it changes anything.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Jul 2015 14:51:38 +0100

John,

> Editor and/or RSOC [1] many months ago.

The discussion with RFC Editor and RSOC has occurred. IAB asked to put 
the document on hold until after DOI were implemented by RFC Editor. 
This project just completed.

Best Regards,
Alexey

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jul 2015 16:06:18 +0200

On Thu, Jul 02, 2015 at 07:48:29PM +1200,
 Brian E Carpenter <[email-masked]> wrote 

> documentation world" the only realistic answer today is DOIs.

We don't live in the same world, then (where I live, ARKs are more
common).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jul 2015 16:34:18 +0200

On Thu, Jul 02, 2015 at 11:57:51AM +0100,
 Colin Perkins <[email-masked]> wrote 
 a message of 22 lines which said:

> At negligible cost.

How much? I don't remember having seen the actual cost mentioned
anywhere. And, as John Klensin noticed here, the agreement between the
RFC editor and the FIFA of DOI is secret.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 10:58:32 -0400

--On Thursday, July 02, 2015 14:51 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> Too late.  The decision was made and implemented before the
>> IAB asked for a final review of these document.  So, whether
>> whether the format chosen for the DOI suffix is optimal or
>> not, etc., the discussion is essentially OBE.  At least as
>> the IAB has chosen to structure things, it needed to occur
>> with the RFC Editor and/or RSOC [1] many months ago.
> 
> The discussion with RFC Editor and RSOC has occurred. IAB
> asked to put the document on hold until after DOI were
> implemented by RFC Editor. This project just completed.

Yes, I know all of that except that IAB decided to hold the
document --and the community review outside the RSOC and RFC
Editor -- until the DOIs were implemented and deployed.

To be very clear:

(1) If anyone thinks it is worthwhile for the community to have
reviewed this idea, either in the large ("should we be doing
this at all?") or the small ("should we use a DOI suffix that
contains alphabetical characters and that requires parsing if
there is ever more than one relevant series?"), then it is much
too late to have either discussion.  If anyone believes that not
allowing that community review represents bad judgment that is
serious enough, the remedies are discussions with the Nomcom,
calls for resignation, and/or recall petitions, not debates
about those aspects of this document that assume the action has
not already been taken.

(2) There may be circumstances in which "act first, apologize
later if needed" is an appropriate strategy.  If that is what
the IAB intended here, then the call for comments should be
clear that the decisions have already been made and deployed and
should identify just what sorts of comments the IAB is actually
interested in or would find helpful.  Even now, I think it would
be helpful if the IAB were to issue a revised/updated call for
comments that makes the circumstances clear.  Of course, if
someone believes that the IAB (or RSOC, or RFC Series Editor)
applied the "act first, apologize later" policy inappropriately
here, see above.

     john

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 11:08:12 -0400

--On Thursday, July 02, 2015 16:06 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

> We don't live in the same world, then (where I live, ARKs are
> more common).

Sorry, should have added ARKs to my list, making it at least
ARK, DOI, ERS, and URN (in alphabetical order) but that just
makes the point that there are a lot of these schemes.  

Other than the "eat your own dogfood" principle, it unclear to
me that any particular one of them is a clear choice.  Maybe the
choice of DOIs is more or less arbitrary or reflects a
too-narrow community of discussion (raising, again, the question
of why the community is being asked only now).  But, if this is
going to be posted as an IAB document, I think the IAB is
obligated to explain the decision, rather than putting up a
document that strongly implies that DOIs are the only plausible
choice.  

Or perhaps we should be publishing and using _all_ of these
identifiers, on theories usually described as "let the
marketplace decide" or "let a hundred flowers blossom".

    john

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 2 Jul 2015 15:23:40 +0000

> marketplace decide" or "let a hundred flowers blossom".

I don't mind if we did this, as long as we do DOIs now.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Jul 2015 11:11:05 -0700

The doc ought to eat its own dog food.

*Every* citation should include a DOI - including that of the DOI
Foundation handbook (DOI:10.1000/182).

I leave finding the rest of the DOIs, including that for the DOI
registration agency web pages, as an exercise to the author.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Jul 2015 20:39:52 +0200

Hi,

From the draft:

>    The
>    prices are fairly low, on the order of $660/year for membership, 15
>    cents per document deposit fees for a bulk upload of the backfile
>    (the existing RFCs), and $1/per document to deposit them as they are
>    published.

> document that strongly implies that DOIs are the only plausible

There's a reason why the IAB is vested with this responsibility.  A
bunch of engineers who know absolutely nothing about the publishing
industry and seemingly little about academia shouldn't make this
decision.  The professional the IAB hired made a recommendation based on
a lot of discussion with a lot of people.  Please let's make a mole hill
out of a mole hill, for once.

Eliot

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Jul 2015 21:01:21 +0200

On Thu, Jul 02, 2015 at 11:08:12AM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 35 lines which said:

> Maybe the choice of DOIs is more or less arbitrary or reflects a
> too-narrow community of discussion

There is a very aggressive marketing from the private comopany which
sells DOIs. Like most marketing, it relies partly on pure lies (for
instance FUD against the properties of the URIs). It seems to be often
successful.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 15:10:47 -0400

--On Thursday, July 02, 2015 20:39 +0200 Eliot Lear
<[email-masked]> wrote:

>> me that any particular one of them is a clear choice.  Maybe
>> the choice of DOIs is more or less arbitrary or reflects a
>> too-narrow community of discussion (raising, again, the
>> question of why the community is being asked only now).  But,
>> if this is going to be posted as an IAB document, I think the
>> IAB is obligated to explain the decision, rather than putting
>> up a document that strongly implies that DOIs are the only
>> plausible choice.  
> 
> There's a reason why the IAB is vested with this
> responsibility.  A bunch of engineers who know absolutely
> nothing about the publishing industry and seemingly little
> about academia shouldn't make this decision.  The professional
> the IAB hired made a recommendation based on a lot of
> discussion with a lot of people.  Please let's make a mole hill

Eliot,

In the interest of clarity, let me translate my comment into the
perspective you are expressing above.   I am not trying to get
the decision changed, much less argue that we should be doing
something else (or nothing) instead.  I am suggesting that, if
this is going to be produced as an IAB document and it is based
on professional advice that is, in turn, based on significant
research and input, then the document should contain an
explanation of the choices made, both because that is
professionally responsible and because educating this community
is not a bad idea (and that doing it through text is more
efficient than doing it by discussion on this list in response
to a call for comments).  

Given that the kind of skilled professional evaluation and
discussion t which you describe occurred, the document should
not suggest, as I think it does, that DOIs, or that particular
choice of format in the DOI suffix, were the only plausible
choices.  It should not suggest it because such an assertion
would be false and false assertions are inconsistent with the
level of professionalism and review that you assert occurred.
(For the record, I believe the first but am wondering about the
second.)

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jul 2015 15:46:59 -0400

--On Thursday, July 02, 2015 21:01 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

>> Maybe the choice of DOIs is more or less arbitrary or
>> reflects a too-narrow community of discussion
> 
> There is a very aggressive marketing from the private comopany
> which sells DOIs. Like most marketing, it relies partly on
> pure lies (for instance FUD against the properties of the
> URIs). It seems to be often successful.

Just in the interest of separating one sort of FUD from another.
DOIs (as distinct from Handle, Handle systems, and several other
things) are allocated at the top level by the International DOI
Foundation, acting as a Registration Authority under ISO
26324:2012.  The DOI Foundation accredits "registration
agencies" who. at least in theory, compete with each other (and
the I-D calls out the one of those that is being used by the
IAB/ RFC Editor).  

Yes, there has been some aggressive marketing.  I haven't seen
the FUD about URIs to which you refer.  Although I have no doubt
that it exists if you say it does, I've generally found the
senior people of the International DOI Foundation fairly open to
working with others to make different types of ideas and
identifiers more compatible (certainly no worse about that than
the IETF often is).  

However, there are enough organizations involved in the DOI
world that talking about, or making claims about, "the private
comopany which sells DOIs" is almost certainly misleading or at
least paints an unspecified entity with two broad a brush.

Finally, to address another FUD-like comment (I can't remember
by whom), while ISO 26324:2012 is, like most other ISO
Standards, associated with a restrictive copyright and a very
high sales/distribution charge, as far as I know, all of the
significant DOI documentation is available in the _DOI
Handbook_, which is available without charge at
http://www.doi.org/hb.html.

I think there may be reasons why DOIs are not an optimal choice.
The decision to use them was apparently made months ago and,
while I think it may be appropriate for the community to review
how that decision was made and who is accountable and for what,
I think it is much too late to say "don't do DOIs".   

I also think there are some other identifiers that might be
equally or more appropriate.  People who favor them should
probably have a discussion with the RSE (and, as needed, the
IAB), about whether it would be appropriate to support their
preferred identifiers too.  If the answer is "yes", start
writing.    If it is "no", then, well, that would make a much
more interesting discussion for this list, at least for me.

    john

---

From: Melinda Shore <[email-masked]>
Date: Thu, 02 Jul 2015 12:03:07 -0800

On 7/2/15 2:57 AM, Colin Perkins wrote:
> Is having a DOI critical? No, obviously not, but it does help in some
> cases, and does make some things easier. At negligible cost.

I've taken to staying out of IETF bibliographic discussions
because they tend to make me feel exceedingly peevish and
I'd rather not feel exceedingly peevish.  But, I read one
piece of email in this thread and that led to another and then
another, so here I am.

The DOI is useful for cataloging because it introduces a
structure that makes it easier to group things which are similar
and to locate specific instances of those things within
that group.  So, I'm thinking about that in the context of
the RFC series.  Personally, I can't see that they're much
use.  To the extent that the assignment of a DOI might lead
to us not using our own identifiers (eating our own dog food)
that's potentially a problem.  I don't see *much* harm here
but I don't really see much practical benefit, either.

Frankly, the whole thing reminds me of someone buying a
GoPro, recording their commute to work, and never taking it
out again.  I haven't seen evidence that we've got a
bibliographic problem here, and nothing (so far) in this
discussion suggests that we do.  But, we're going to do what
we're going to do, so given that I'd suggest that John's
concerns about format should be taken very seriously.  Given
that DOIs reflect, in some sense, the bibliographic structure
of a group of documents, and given that we'd like to be
adaptable to future changes to how we publish, using a flat
namespace seems to be clearly the wrong thing to do and would
seem to be a case where DOIs are considerably less useful
than they might otherwise be.

Melinda

---

From: "Joe Hildebrand" <[email-masked]>
Date: Thu, 02 Jul 2015 14:11:00 -0600

> more interesting discussion for this list, at least for me.

With both my RSOC and IAB hats on, I'm completely open to other 
identifier schemes being added in the future.  I think a similar bar to 
what we've set for DOIs would apply:

- A significant number of people would find value in the identifiers 
being assigned
- The cost is reasonable
- The technical approach is well-specified

For DOIs, the case made regarding the benefits was persuasive, 
particularly by the academic contributors to the IETF and IRTF.  Make a 
case for your identifier scheme roughly as good as that for DOIs, and we 
can explore from there.  I'll even help you frame your arguments if you 
like - send me a mail off-list or approach me in Prague.

-- 
Joe Hildebrand

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Jul 2015 22:29:14 +0200

Hi John,

> efficient than doing it by discussion on this list in response

It's fine to have such a discussion here now, but in the document?  No. 
I've been there.  People just get lost and tune out on the aspects that
we might want them not to.  Remember, this is not a PhD thesis: a survey
of existing work is not required.

> (For the record, I believe the first but am wondering about the
Can you explain where such a suggestion is made?  As to the form that
comes AFTER the prefix, THAT is worthy of discussion, but that indeed
may be too late.

Eliot

---

From: [email-masked] (Martin Rex)
Date: Fri, 3 Jul 2015 04:55:52 +0200 (CEST)

> RFCs aren't licensed freely enough.

Whooops.  I wasn't aware of any non-intuitive limits to distribution of
newer RFCs as-is.  The original waiver

   The distribution of this memo is unlimited.

seems to have been discontinued somewhere around late 2008.
(rfc5246 aka TLSv1.2 still carries it).

Where is the problem with including (newer) RFCs with implementation
source code for distribution?

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Jul 2015 16:29:16 +1200

> (rfc5246 aka TLSv1.2 still carries it).

It was stating the obvious, really.

> source code for distribution?

The copyright conditions for IETF documents don't allow derivative works
outside the IETF process. That appears to be incompatible with some
open source licences that do allow unconstrained derivative works, so
RFC text (apart from code components + their license text) can't be part
of such an open source package.

But nothing stops you including a pointer to an RFC, afaik.

IANAL, so please read http://trustee.ietf.org/copyright-faq.html

    Brian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 03 Jul 2015 09:25:42 -0700

(Resending now that my posting permissions have been fixed)

On 7/2/15 6:39 AM, John C Klensin wrote:
> asked for a final review of these document.  So, whether assigning 
> DOIs to the RFC Series is a good idea or a bad one, whether the 
> format chosen for the DOI suffix is optimal or not, etc., the 
> discussion is essentially OBE.  At least as the IAB has chosen to 
> structure things, it needed to occur with the RFC Editor and/or 
> RSOC [1] many months ago.

The IAB may wish to respond further, but just to correct a few points:
See
https://mailarchive.ietf.org/arch/msg/ietf-announce/Yj4nsEFwjg8cveeDm91K
tT8cA4g
for the initial call for review of this draft in March 2014. Also, see
https://mailarchive.ietf.org/arch/msg/ietf-announce/EQhxsU_csHe-9DjwEoou
FGypVKE
for the request to discuss the SoW/RFP to actually start work, posted in
September 2014.

There were other touch points with the community on the topic,
including mention at the last four technical plenaries, so
this work should not be a surprise.

Also, the use of DOIs is not exclusive to using URNs or other document
identification schema. As has been mentioned elsewhere in this thread,
DOIs were used first because discussions with members of the IRTF and
academics within the IETF suggested these would be quite useful. Since
they do not preclude other identification schemes and can be ignored
by people who have no use for them, I see no problem in assigning the
identifiers to RFCs.

- -Heather Flanagan, RSE

> of tradeoffs, including those associated with effectively endorsing
> a "pay per identifier" system, would be desirable and that is an 
> editorial issue.
> 
> See my earlier note for more discussion on the "things that it is 
> too late to undo" part.
> 
> john
> 
> [1] Disclaimer:  I was a member of the RSOC until the IAB fired me 
> in mid-2013.  I obviously don't know why they made that decision 
> although I note that everyone who had been continuously active on, 
> and contributing to, the RSOC retired or was removed at the same 
> time.  While I was pleased to be relieved of the additional area
> of responsibility, I was concerned that there might be no one left
> who would spot the small issues (like the i18n one) and downsides
> of proposals like this one and insist on their being fully
> discussed and reviewed with the community (and not just the
> rfc-interest list) before irreversible actions were taken.  If
> anyone is concerned that I might be more upset about the way this
> has been handled if it were not for that history, you may be right
> but I don't think it changes anything.
> 
> 
> 
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 03 Jul 2015 08:43:16 -0800

> by people who have no use for them, I see no problem in assigning the

This is a question: when a URN is encoded as a DOI, is that
DOI registered?  I'm wondering about a situation in which you
effectively end up with two DOIs, one issued under the proposal
described in this draft and the other being a URN encoded as
a DOI.  This clearly is not going to cause problems with their
function as stable identifiers, nor will it affect the uniqueness
of the identifiers (typically people who use these sorts of
identifiers for lookup don't pay much attention to the internal
structure of those identifiers), but it is a potential impact.
A document that describes DOI use in RFCs should probably
include recommendations for which DOI to include in citations.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 Jul 2015 12:58:21 -0400

> really?  i am told by uk peers that it is similar to what Riccardo wrote.

Getting tenure in the UK is impossible because it was abolished by Margaret
Thatcher's government in the 1980s. I was on the University Court and
Council at the time we were forced to change the statutes.

While there is a promotion system that is largely driven by publications,
that is going to have to make major adjustments over the next few years as
the Cameron Government decided to make publication in free to the public
journals a requirement of all government research grants.

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 00:14:09 -0000

><http://www.doi.org/doi_handbook/3_Resolution.html#3.7.3>

Good catch, thanks.

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 00:15:59 -0000

>this is more than a metadata play for academic brownie points.

If you think the current wording in section 3 is inadequate, please
send text.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 00:21:03 -0000

>RFC editor and the FIFA of DOI is secret.

A few seconds of googlage reveals Crossref's price list:

http://www.crossref.org/02publishers/20pub_fees.html

It's $1 per new document, 15c each for the bulk upload of the backlist.

If you divide the budget for producing RFCs by the number of RFCs
published, you'll get on the order of a thousand bucks per RFC. 

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 00:29:36 -0000

>comes AFTER the prefix, THAT is worthy of discussion, but that indeed

As I note in the draft, the part after the prefix is opaque.  The DOIs
that the ACM assigns are two numbers that have no connection to
anything else I can figure out.  The IEEE uses some combination of a
short abbreviation of the journal name, the year, and a sequence
number that does not tell you what issue the article is in.

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.

R's,
John

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 09:05:18 +0200

> document title so people would stop complaining about RFC123 vs.

Hmm...are DOIs _already_ allocated for [some] RFCs or not?

I felt at first that was NOT the case.

Then I understood this draft is documentation of existing practice.

Then now I see between the lines that is not the case, as it is questioned what the format should be.

Can someone please clarify?

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sat, 04 Jul 2015 09:45:38 +0200

This is what an entry in rfc-index.txt looks like these days:

7556 Multiple Provisioning Domain Architecture. D. Anipko, Ed.. June
     2015. (Format: TXT=59307 bytes) (Status: INFORMATIONAL) (DOI:
     10.17487/RFC7556)

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 11:12:36 +0200

>   2015. (Format: TXT=59307 bytes) (Status: INFORMATIONAL) (DOI:

Ok, then the format is already decided (although implicitly), and should not be changed.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 4 Jul 2015 21:29:36 +1200

> Ok, then the format is already decided (although implicitly), and should not be changed.

They're still opaque identifiers, so the format isn't important.  I don't 
know how to make that any clearer.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 11:34:25 +0200

On 4 Jul 2015, at 11:29, John R Levine wrote:

> They're still opaque identifiers, so the format isn't important.  I don't know how to make that any clearer.

Because they have been published, we immediately have a question about persistence. We can now, from my perspective, not change the format as they have already been included in the RFC Index. Its a persistence issue.

We COULD have changed the format, discussed it, or whatever, but that point in time is passed.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sat, 04 Jul 2015 13:34:12 +0200

I think what John is saying is that it is possible to update the format
for new docs, should people think that appropriate.  But John can say
what he is saying better than I can say what he is saying, so...

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Jul 2015 10:29:59 -0400

--On Saturday, July 04, 2015 11:34 +0200 Patrik Fältström
<[email-masked]> wrote:

>> They're still opaque identifiers, so the format isn't
>> important.  I don't know how to make that any clearer.
> 
> Because they have been published, we immediately have a
> question about persistence. We can now, from my perspective,
> not change the format as they have already been included in
> the RFC Index. Its a persistence issue.
> 

This is one of the points I've been trying to make.  The issue
for me is not, and hasn't been, whether we should assign DOIs to
the RFC Series or not -- I really don't care.  And it isn't
"surprise" because, as Heather points out, it wasn't hard to
know that a decision had been taken to "do DOIs" and that _some_
DOI arrangements were underway.  I am more concerned about the
decisions that lead to this "decide first, make irrevocable
decisions about details (or just let them happen), deploy, and
_then_ ask for review.   And that leads exactly to Patrik's
comment about what we "COULD" have done above.  

Picking just one example, Heather's note pointed to the
September 2014 SOW
(http://iaoc.ietf.org/documents/Announce-RFC-DOI-SOW-3Sep14.pdf
if anyone wants to look at the action text rather than the
announcement) but it does not contain a word about the choice of
the particular format for the suffix.  Similarly, not only was
that March 2014 call for review a call for comments to the
rfc-interest list (not even to the IAB) but there is nothing in
it that implies that it is a major decision point about the
details -- at that stage in the development of things, or even
at the time of the September SOW, it was reasonable (at least
IMO) to interpret the DOI format in the draft as a placeholder
to be discussed later.  

Normally, "comment to a WG list" or "comment to other than the
IAB or IETF lists" implies a request for review and comments but
that the community will get another chance to review before the
final decision point.  And normally we don't treat SOWs, even
SOWs that _do_ include the precise details, as decision
documents about issues that, once decide, have broad impact and
are irreversible.    If the intention here was to make those
announcements of decision points, then they should have been,
again IMO, much more clear about it.

Sure, people could have noticed those lines and said "I
certainly hope you are not planning to use DOI: 10.NNNNN/rfcNNNN
as the suffix format" but should have been no expectation that
not doing so was support for a final decision, any more than
failure to study an I-D that lies largely outside one's major
area of interest and comment, to a list associated with it,
creates a binding decision that cannot be questioned or even
reversed on IETF Last Call.

Had someone asked the community the question "does DOI:
10.17487/RFCnnnn look like a satisfactory suffix format", we
COULD have  had that review as Patrik suggests (and many others
of us have suggested in other ways).

I will defend a decision like that suffix format one as one that
the RFC Series Editor can make and announce to the community,
subject to whatever oversight the IAB (directly or via the RSOC)
chooses to apply.  But that implies that the RSE needs to be
accountable for such decisions -- both their substance and the
details of the analysis that went into them.  What I expected to
hear from Heather was "these are the tradeoffs we considered and
why the decision was made this way" not "this should not have
been a surprise".  

While it is not yet irreversible, I think one can have a very
similar discussion about the messaging involved relative to
other work and identifiers.   For example, I think some of this
discussion, including the RSOC and IAB openness to adding more
identifiers, ought to be in this document, making clear that
DOIs may be the first (actually second, given RFC 2648) in a
series rather than an IETF/ IAB/ RFC Editor commitment to one
particular system.   That sort of issue is what calls for
comment are supposed to be about.

       john

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 17:53:32 +0200

On 4 Jul 2015, at 13:34, Eliot Lear wrote:

> I think what John is saying is that it is possible to update the format for new docs, should people think that appropriate.  But John can say what he is saying better than I can say what he is saying, so...

Correct, for _new_ RFCs that have not yet got an allocation.

   Patrik

---

From: Leif Johansson <[email-masked]>
Date: Sat, 4 Jul 2015 19:28:38 +0200

> 4 jul 2015 kl. 16:29 skrev John C Klensin <[email-masked]>:
> 
> 
> 

Perhaps the RSE interpreted the lack of feedback on those announcements on rfc-interest as indication that nobody gave a hoot about the details. I certainly would have.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 4 Jul 2015 14:08:39 -0400

This discussion has been very informative!

Just as an example, Journal of Optical Communications and Networking uses
the volume number and page number. Here are two JOCN DOIs I used recently
in RFC informative references:

10.1364/JOCN.4.000001 (actually Vol. 4, Issue 1, pp. 1-14 (2012))

10.1364/JOCN.7.00A447 (actually Vol. 7, Issue 3, pp. A447-A458 (2015))

For RFCs, I actually don't mind:

10.17487/rfc1149

Since DOIs are opaque, that doesn't preclude future use of a numeric prefix
as well for something completely different.

The draft should be clear about whether or not leading zeros are used for
low-numbered documents.

Cheers,
Andy

---

From: "John R Levine" <[email-masked]>
Date: 5 Jul 2015 08:00:55 +1200

> as well for something completely different.

Right.  Now I see what the problem is -- opaque identifiers are jargon 
from databases (I did my PhD research on them) and many IETFers don't 
understand what they are.

The point of an opaque identifier is that you can make no assumptions 
whatsoever about what its structure or format is.  You can just find it 
somehow, and you can hand it back to services that use it to look up 
what it refers to.

At the moment, the code happens to use the database field published as the 
<doc-id> in the XML RFC index to create the DOI.  But tomorrow the code 
might do something else.  This week the DOI it assigned to RFC 7612 was 
10.17487/RFC7612 but next week the DOI it assigns to RFC 7613 might be 
10.17487/gazornplatz.

This isn't an idle threat.  The RFC production software stores the DOI for 
each document in a separate field in the database.  There is literally one 
line of code that creates new DOIs -- change that, and all future DOIs 
will have some other form.  (Existing DOIs are in the database and won't 
change.  That's what stable means.)

The only, and I mean *ONLY* way to find the DOI for an RFC is to look it 
up.  That's not a big deal, because the the DOIs are now included in the 
mechanically created RFC index and bibxml files, so anyone using the usual 
xml2rfc tools will get the correct DOIs automatically.

> The draft should be clear about whether or not leading zeros are used for

I hope it's now clear why that would be a bad idea, and also why you 
shouldn't make any assumptions about what the DOIs of RFCs after RFC9999 
will be.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Jul 2015 08:39:53 +1200

>      2015. (Format: TXT=59307 bytes) (Status: INFORMATIONAL) (DOI:

And just to be crystal clear:

0001 Host Software. S. Crocker. April 1969. (Format: TXT=21088 bytes)
     (Status: UNKNOWN) (DOI: 10.17487/RFC0001)

   Brian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 4 Jul 2015 16:51:30 -0400

John,

In general, I agree with you.

In particular, we COULD choose to openly publish the algorithm used to
generate DOIs for RFCs, and to not change it in the future. In which case,
while the DOI is opaque to anyone who hadn't seen that algorithm, it isn't
quite so opaque to anyone that has seen it.

That still doesn't preclude future documents under 10.17487/ that aren't
RFCs from using a different identification scheme, as long as it doesn't
start with the string "rfc" or "RFC".

In the current revision of the draft, the choice was made to not publish
the DOI generation algorithm. I'm not sure that I agree with that choice,
but I can live with it if that's the consensus.

Cheers,
Andy

On Sat, Jul 4, 2015 at 4:00 PM, John R Levine <[email-masked]> wrote:

> somehow, and you can hand it back to services that use it to look up what
> it refers to.
>
> line of code that creates new DOIs -- change that, and all future DOIs will
> have some other form.  (Existing DOIs are in the database and won't

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Jul 2015 17:41:05 -0400

--On Saturday, 04 July, 2015 19:28 +0200 Leif Johansson
<[email-masked]> wrote:

>> for me is not, and hasn't been, whether we should assign DOIs
>> to the RFC Series or not -- I really don't care.  And it isn't
>> know that a decision had been taken to "do DOIs" and that
>> _some_ DOI arrangements were underway.  I am more concerned
>> about the decisions that lead to this "decide first, make
>> irrevocable decisions about details (or just let them
>> happen), deploy, and _then_ ask for review.   And that leads
>> exactly to Patrik's comment about what we "COULD" have done
>> above.  
> 
> Perhaps the RSE interpreted the lack of feedback on those
> announcements on rfc-interest as indication that nobody gave a
> hoot about the details. I certainly would have. 

Heather can (and should) speak for herself, but I believe she is
quite aware that there are a number of people in the community
who have very specific expertise in some relevant areas but who
don't follow rfc-interest or who have stopped doing so.
Consider, as a possible analogy, a WG whose discussions involve
so much noise and trivia that people drift away on the basis
that they are busy and there is nothing happening on that list
that they care about.  Then something different is mentioned and
those mentioning it take silence from whomever is left as either
approval or justification to make decisions without asking the
WG because "nobody gave a hoot".  We normally don't consider
that as either consensus or even consultation and review.

    john

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Jul 2015 06:49:32 +0900

> there are a number of people in the community who have very specific
> expertise in some relevant areas but who don't follow rfc-interest or
> who have stopped doing so.

that is their choice.  but when one votes with one's feet, one kinda
relinquishes the right to ex post facto second-guess those who stay
home.

randy

---

From: Leif Johansson <[email-masked]>
Date: Sun, 5 Jul 2015 10:07:33 +0200

> relinquishes the right to ex post facto second-guess those who stay

+1

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Jul 2015 14:24:32 -0400

--On Sunday, 05 July, 2015 08:00 +1200 John R Levine
<[email-masked]> wrote:

>> Since DOIs are opaque, that doesn't preclude future use of a
>> numeric prefix as well for something completely different.
> 
> Right.  Now I see what the problem is -- opaque identifiers
> are jargon from databases (I did my PhD research on them) and
> many IETFers don't understand what they are.
> 
> The point of an opaque identifier is that you can make no
> assumptions whatsoever about what its structure or format is.
> You can just find it somehow, and you can hand it back to
> services that use it to look up what it refers to.
>...
> I hope it's now clear why that would be a bad idea, and also
> why you shouldn't make any assumptions about what the DOIs of
> RFCs after RFC9999 will be.

And the problem with opaque identifiers that happen to be
construed in a consistent way that humans can deduce related to
something else is that they will be used that way.  To be clear
about what follow, I'm far more concerned about the case of
"given DOI, find document" than I am about "given document
bibliographic reference, find and write down the DOI".

To use his example, Andy knows how to get from
10.1364/JOCN.4.000001 to a particular journal, volume, and page
number and he is almost certainly going to do that by using the
algorithm in his head.  Unless he is much more compulsive and
has far more time on his hands than I believe is the case, he is
unlikely to go to a DOI resolver system for each of the DOIs in
that form, resolver systems that will just tell him what he knew
already and that may point him through more indirection than he
would find useful if he wants the document.    You may know it
is formally an opaque identifier, he may know it is formally an
opaque identifier, but, in practice, he knows there is nothing
opaque about it and that it would be silly to pretend.

Now, suppose the journal publisher decides that, from volume 8
onward, they are going to add 100 times the first three digits
of Pi to the volume number field, eliminate the separating dot,
and add an extra zero to the page number field in case they were
to publish a lot that year.   Assuming I got the arithmetic
right, hat would give the next volume's first article a DOI of 

  10.1364/JOCN.3320000001

Andy (and hundreds of other readers who are behaving the same
way) would, I assume, be at least mildly irritated because the
new format is different and requires that they do something
different and perhaps a bit harder.   The curators of the system
would, no doubt, say "opaque identifier, you had no right to the
expectation that you could parse the DOI and translate it into a
volume and page number, and still don't have that right even if
you can figure out the new algorithm".  Both would be correct in
their positions, but knowing that is not especially helpful.

Now assume that, a few years in the future and perhaps to
commemorate volume 10 and to educate their readers, the
identifier were changed again to eliminate "JOCN." and the
algorithm and, instead, use some form of a hash on the article
contents (plus a database lookup to check for uniqueness and a
way to adjust if needed).  Again, it is an opaque identifier, so
Andy and his colleagues have, in the eyes of the
identifier-assigning folks and your comments above, no basis for
complaint even though this new identifier format forces them to
do a database lookup for each DOI.  From their point of view
that is unreasonable.  When publisher 1364 also raises the
subscription rates to cover the cost of the high performance and
redundant DOI servers that were not needed before because most
readers knew the algorithm and skipped the lookup, it would seem
even more unreasonable.  On the other hand, the DOI-assigning
database administrators just say "opaque identifier, what are
you complaining about".  And, again, both are right.

I think there are clear human factors preferences about whether
the use cases or the opaque identifier argument prevails, but
YMMD.

Now, restated more precisely and in the light of your
explanation, I objected (and object) to the choice of "rfc1149"
because it provides an opportunity for confusion if the format
of the identifier is changed in the future and because the use
of ASCII characters, especially as part of what will be
perceived as a field, rather than a dot-separated subfield, may
be inconvenient to our growing international community for no
good reason.    That doesn't mean "can't be changed in the
future" and I apologize for anything I may have said that was
interpreted that way.  But saying "opaque identifier" does not
make changes less inconvenient and disruptive for the reasons
described above.

Now my prediction, for reasons that parallel Melinda's comments,
is that no active participant in the IETF will ever (other than
experimentally or for demonstration purposes) locate and
retrieve an RFC, especially an RFC referenced from another RFC,
by looking up the DOI.  That probably means that, with the
exception of symbolic value and a tiny number of readers,
including the DOI for an RFC in references within RFCs is a
waste of time and bits, but see below.  Because we won't use
them, an opaque identifier, even 10.17487/gazornplatz, should be
just fine for direct IETF purposes.  If the goal for assigning
DOIs is symbolic, i.e., not that we expect anyone to use them
for find RFCs but to impress some group of people with the fact
that we have and assign DOIs because doing so adds prestige or
credibility.   But, the more we rely on the assumption that
RFC-related DOIs won't be used to find RFCs, the more important
it is that the suffixes be structured in a well-known, obvious,
and stable way in practice, even if they are opaque identifiers
in DOI theory.

  best,
    john

---

From: "John R Levine" <[email-masked]>
Date: 6 Jul 2015 08:08:43 +1200

I'm sorry, but this discussion has just taken a leap into the absurd.

> algorithm in his head.

I'm not Andy, and I use DOIs somewhat differently.  Keeping in mind that 
the D in DOI stands for Digital, and that everything with a DOI is 
supposed to be available online, if I want to read the article, I point my 
browser at https://dx.doi.org/10.1364/jocn.4.000001 which redirects me to 
a page that tells me that if I don't have a subscription, I have to pay 
$35.  (A little googlage easily finds it for free, but whatever.)

If I'm writing a paper using a program that does DOI expansion (bibxml 
for example), I stick the DOI into a reference and it expands to this:

Chiu, A. L., Choudhury, G., Clapp, G., Doverspike, R., Feuer, M., Gannett, 
J. W., … Xu, D. (2011). Architectures and Protocols for Capacity 
Efficient, Highly Dynamic and Highly Resilient Core Networks [Invited]. 
Journal of Optical Communications and Networking, 4(1), 1. 
doi:10.1364/jocn.4.000001

I got the DOI in the first place by looking it up somewhere, such as by 
typing the title into IEEE Xplore or Google Scholar, or by following
a reference from this paper:

https://www.osapublishing.org/oe/fulltext.cfm?uri=oe-21-1-469&id=248015#articleReferences

If Andy can do all this in his head, he is a much better man than I am.

Regards,

---

From: Andrew Newton <[email-masked]>
Date: Mon, 6 Jul 2015 10:10:20 -0400

> > relinquishes the right to ex post facto second-guess those who stay
I think John's point is that in the IETF we usually do not interpret lack
of feedback as passive approval but rather lack of any review.

-andy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jul 2015 07:12:09 -0700

> relinquishes the right to ex post facto second-guess those who stay

I think there is a more interesting issue, here, than might seem obvious.

Certainly 'if you didn't show up, you don't get to complain' is a core
IETF principle.  But it is predicated on a significant expectation of
isolated effect.  A mailing list defines the topic scope and work within
that topic is typically limited to that scope.  Yes, a change to TCP
affects everything sitting on top of it, but absent a disrupting change
to its functional interface, the stuff above can reasonably continue,
oblivious to the change.

However some actions have broad /direct/ effect, far beyond the
community formed by the normal list discussion group.  These notably
involve IETF infrastructure:  formal processes, tools, and mechanisms.
Including RFC publication.

For changes in this IETF fabric, we need to go beyond the core mailing
list and promote information about the anticipated change, to get a
broader range of feedback.  The change will affect the broader IETF
population and the 2-week IETF Last Call comment window is too little,
too late, in terms of substantive feedback.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Leif Johansson <[email-masked]>
Date: Mon, 6 Jul 2015 16:57:14 +0200

> 6 jul 2015 kl. 16:10 skrev Andrew Newton <[email-masked]>:
> 
> 
> 
> I think John's point is that in the IETF we usually do not interpret lack of feedback as passive approval but rather lack of any review.
> 
> -andy

We also depend on active participation.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 6 Jul 2015 16:59:00 +0200

> 6 jul 2015 kl. 16:12 skrev Dave Crocker <[email-masked]>:
> 

Does the format of DOIs affect the IETF as a whole? Really?

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Thu, 02 Jul 2015 06:46:45 -0700

On 7/2/15 6:39 AM, John C Klensin wrote:
> 
> 
> --On Thursday, July 02, 2015 18:26 +0900 Randy Bush <[email-masked]>
> wrote:
> 

for the request to discuss the RFP to actually start work, posted in
September 2014.

There were other touch points with the community on the topic, but
this work should not be a surprise.

- -Heather Flanagan, RSE

> 
> It seems to me that the only meaningful questions for the community
> at this point are (i) whether the document should be published in
> the RFC Series and (ii) whether it is satisfactory from an
> editorial standpoint.  For example, I think a discussion of
> tradeoffs, including those associated with effectively endorsing a
> "pay per identifier" system, would be desirable and that is an
> editorial issue.
> 
> time.  While I was pleased to be relieved of the additional area of
> responsibility, I was concerned that there might be no one left who
> would spot the small issues (like the i18n one) and downsides of
> proposals like this one and insist on their being fully discussed
> and reviewed with the community (and not just the rfc-interest
> list) before irreversible actions were taken.  If anyone is
> concerned that I might be more upset about the way this has been
> handled if it were not for that history, you may be right but I
> don't think it changes anything.
> 
> 
> 
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jul 2015 08:11:28 -0700

...
> Does the format of DOIs affect the IETF as a whole? Really?

The need to consider that question carefully is exactly that point.

It might well be that the answer for a specific case, such as this, is
that it has no effect on the installed base and therefore need not
concern the broader community.  But IETF infrastructure activities
always need to ask this sort of question honestly and answer it carefully.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Jul 2015 11:35:43 -0400

> Does the format of DOIs affect the IETF as a whole? Really?
It could be argued that by adopting DOIs for IETF documents we are
precluding the development of an IETF document identifier.

I don't think this is a valid concern though since we do not have the
resources to support a DOI type document registration model for free, nor
do we have the infrastructure to charge.

If we were going to do something of this type it would inevitably involve
SHA-2/SH-3 digests of the document and some form of human readability
gloss. Something like this for example:

https://tools.ietf.org/html/draft-hallambaker-udf-00

But what we are looking to do here is limited to allowing academics to get
some degree of tenure track credit for IETF work and in the short term DOIs
are the only game in town.

In the longer term schemes like UDF and ni:/nih: are going to be the way
forward. But those will only make sense after there is an infrastructure to
support persistent archiving.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 06 Jul 2015 11:09:32 -0800

On 7/6/15 6:57 AM, Leif Johansson wrote:
> 6 jul 2015 kl. 16:10 skrev Andrew Newton <[email-masked]
> <mailto:[email-masked]>>:
>> I think John's point is that in the IETF we usually do not
>> interpret lack of feedback as passive approval but rather lack of
>> any review.

> We also depend on active participation.

To be honest, I was completely ignoring the DOI discussion until
someone emailed me directly about it.  The reasons I was staying
away from it include:

1) The IETF is going to do what it's going to do, which tend to be
   whatever a few people in the leadership want it to do.  It's
   unlikely that participation and review is going to change outcomes
   on hobbyhorse projects

2) Bibliographic discussions in the IETF tend to be particularly
   frustrating because there are very few people who actually know
   anything about the subject matter, but everybody's got an
   opinion.  There's a tendency to fall into the "I'm a smart person,
   so perhaps I may not know anything about the field but hey, I'm
   a smart person" trap.  This document contains some incorrect
   statements, or statements so broad as to carry very little
   information, and there doesn't appear to be much interest among
   those participating in the discussion in seeing those corrected.
   That tends to lead to the conclusion that there's no point in
   participating in discussions about bibliographic matters within
   the IETF

I think problems 1 and 2 are pervasive throughout the IETF's work
and not isolated to this particular document, but the fact that this
is an area in which so few IETF participants have any expertise
tends to bring it out more strongly.  I suspect it has something
to do with the incredible volume of just plain bad drafts we're
facing these days, and the pressures associated with dealing with those.

Melinda

[BTW, as a (sort-of) side note, if you've read this document you're
aware that it not only contains a discussion of assigning DOIs
to RFCs but also contains a discussion of the use of DOIs within
RFCs, because assigning DOIs to our documents carries with it
the obligation to the issuing body to use DOIs within our own
documents.]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Jul 2015 09:26:05 +0200

> the obligation to the issuing body to use DOIs within our own

Ugh.  That seems painful to me.  Assigning DOI's to RFCs could happen
external to the RFC itself, and could be something that doesn't cause a
lot of friction.  But if we are polluting RFCs with these DOI numbers,
and that we are forced to make an effort to do so as part of the
agreement with the DOI vendor, I think this whole thing sounds like a
bad idea and contrary to what the IETF usually stand for.

/Simon

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jul 2015 09:36:47 +0200

Hi Melinda,

>    participating in discussions about bibliographic matters within

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?

> the obligation to the issuing body to use DOIs within our own

Where in the document does it state any such obligation?  This sort of
overstatement and misinformation is how we end up with a 100-message
sillyThread® on this mailing list.

Eliot

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Jul 2015 09:47:49 +0200

> sillyThread® on this mailing list.

The document says:

4.4. Use of DOIs in RFCs

   The DOI agency requests that documents that are assigned DOIs in turn
   include DOIs when possible when referring to other organizations'
   documents.
...
   The RFC Style Guide will be updated to describe the rules for
   including DOIs in the References sections of RFCs.

This goes beyond the alleged scope of _assigning_ DOIs to RFCs, and this
change in IETF processes is not covered by the abstract or introduction
section in this draft, nor the announcement regarding this draft.

/Simon

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jul 2015 10:01:27 +0200

Simon,

> section in this draft, nor the announcement regarding this draft.

It is not an obligation but a request, and there is a very big
difference.  Further, if what we are talking about is adding a DOI a
reference entry, what is the big deal?  In fact, if there is a known DOI
all the better to find the source, especially for external references. 
Why *wouldn't* we encourage that?

And it is *not* a change in IETF processes, but in the RFC Editor
process that almost nobody will notice when drafting their documents.

Eliot

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 7 Jul 2015 08:10:56 +0000

+1

And if we have to add a "no_doi" option to the xml2rfc vocabulary to appease those that don't want their references polluted by DOIs, that's a possibility. Kinda silly, because we'd be spending development cash on a feature that probably few folks would care to use, but we could.

Lars

---

From: Riccardo Bernardini <[email-masked]>
Date: Tue, 7 Jul 2015 10:17:04 +0200

> Why *wouldn't* we encourage that?

Let me reinforce this  with my +0.02. I already use DOI in the
bibliographies of my papers.  Several entries of my BibTeX file have a DOI
entry, so this is automatically added to the reference.  I have nothing
against it, actually, I like it because I think it like something that will
help the readers of my paper to find reference they are interested into.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 07 Jul 2015 00:27:31 -0800

> 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.  DOIs would not make RFCs easier to find and use.
RFCs already have stable, unique identifiers that are
widely known and understood by the community of people who
use RFCs.  In fact, there are effectively two - the RFC
number and the URN.  The relationship between the DOI
and URN is not discussed, which is a bit unfortunate because
while the draft does mention the expectation on the part
of the IDF that we'd start using DOIs in IETF documents,
it doesn't really describe how that would be referenced.
The IDF proxy server processes URNs into DOIs, so that
both https://doi.org/10.17487/RFC5280 and
https://doi.org/10.17487/urn:ietf:rfc:5280 would point to
the same bibliographic record or document.  Generally
there are implications throughout the document that
things we consider to be normal bibliographic processes
(uniquely identifying items, assigning metadata,
providing access mechanisms) are not available without a
DOI.

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.

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.

Melinda

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Jul 2015 10:27:46 +0200

Eliot Lear <[email-masked]> writes:

> difference.

If we intend to honor the request, and I assume the intention is to do
so, the practical results will be the same and any difference is purely
semantic.

> Further, if what we are talking about is adding a DOI a reference
> entry, what is the big deal?  In fact, if there is a known DOI all the
> better to find the source, especially for external references.  Why
> *wouldn't* we encourage that?

Why don't we encourage adding the IP address of hostnames in the URLs in
RFC references?  Someone who doesn't have access to the DNS may find it
easier to locate the resource if they knew the IP address of the host.

I'm not seriously suggesting this, but it appears to be the same kind of
argument for adding DOIs to RFCs.  Quoting the document: "organizations
that use DOIs can have trouble locating documents that don't have DOIs".

My point is that I don't believe that is a valid line of reasoning.

Instead of adding IP addresses or DOIs to references, we can teach these
organizations about how the Internet and URLs work.

There may be good reasons for DOIs, but "it can be added, so why not"
does not strike me as a good reason.  It is apathy.

/Simon

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jul 2015 10:37:27 +0200

On 7/7/15 10:27 AM, Melinda Shore wrote:
> 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.

> 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.

> that provide justifications that are not actually correct.

Fair enough.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2015 10:00:13 -0000

>bad idea and contrary to what the IETF usually stand for.

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.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2015 10:09:51 -0000

> I think you'd be extremely

Hi there.  

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&CFID=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.

R's,
John

PS: Thanks for the assertion that I have no idea what I'm
talking about.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 11:11:12 -0400

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
<[email-masked]> 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:
> 
> 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
<[email-masked]> 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.
> 

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

> document title so people would stop complaining about RFC123
vs.

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 11:42:15 -0400

--On Tuesday, July 07, 2015 10:37 +0200 Eliot Lear
<[email-masked]> wrote:

>   At
> 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.

Eliot,

Your question takes us to other questions to which I don't know
the answer... but they do have implications for the community.
I note that I would know the answers if I were privy to
international IAB discussions, RSOC discussions, and discussions
within the RFC Editor function but, by and large I'm not (and
you may know more about some of this than I do).  For example:

There were discussions for a while about the RFC Editor taking
on publications for some other bodies.  When I was last
involved, it wasn't clear whether, if that happened, it would be
as a fifth stream or a separately-named and identified document
series.  I also don't know whether idea is now completely deal
or might come back up some day soon.  I also don't know what the
contract with Crossref says or how they feel about assigning
multiple identifiers to the same publisher (or, if they will
allow it, what they charge for the second one).  For the reasons
that Melinda discussed (abbreviated above), I think that having
a different publication series use the same DOIs as the
IETF/IAB/IRTF/ISE RFC Series would be a decision that community
should be consulted on, with the option of using a little
apparent hierarchy as a better way to resolve the problem than
debates about opacity.

FWIW, my experience suggests that while I would agree that
"Additional hierarchy comes with its own complexities.",
providing for the possibility of cleanly adding additional
hierarchy often does not.  "1.1149" is no more complex than
"rfc1149".   It might involve more complexity (or make it easier
to have different staff maintain databases) when one adds
"2.54321" in association with a different document series or
subset.  And, course, for someone looking up a DOI through DOI
lookup mechanisms, they are all opaque strings and nothing makes
any difference.

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Jul 2015 08:43:20 -0700

> 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.

> 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.

+1

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 11:49:41 -0400

--On Tuesday, July 07, 2015 08:10 +0000 "Eggert, Lars"
<[email-masked]> wrote:

> And if we have to add a "no_doi" option to the xml2rfc
> vocabulary to appease those that don't want their references
> polluted by DOIs, that's a possibility. Kinda silly, because
> we'd be spending development cash on a feature that probably
> few folks would care to use, but we could.

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.

   john

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 7 Jul 2015 16:18:09 +0000

> 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.

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 07 Jul 2015 18:43:10 +0200

> 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…

If you are diligent about your bibliographies (and don't have to fight a
page count), you probably already have the DOIs in there.

(Which reminds me: I needed to add an example using a DOI to the README
on http://rfc.space -- fixed.)

Grüße, Carsten

---

From: Melinda Shore <[email-masked]>
Date: Tue, 07 Jul 2015 08:51:24 -0800

> show up when people reference them, a robust way to let people get to

Yeah, and you can buy them in published form for $$$.  That
some people are selling access doesn't mean that they're hard to find
for free.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 12:52:16 -0400

--On Tuesday, July 07, 2015 16:18 +0000 "Eggert, Lars"
<[email-masked]> 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.

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.

* 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.

      john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Jul 2015 10:04:29 -0700

On 7/7/2015 9:52 AM, John C Klensin wrote:
> iven Dave Crocker's recent comments about I-Ds, Statements,

Uh, no.  I want it to be /easy/ to expand into those other uses.  Not
'required' of course but easy if we wish to.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2015 13:28:33 -0400

--On Tuesday, July 07, 2015 10:04 -0700 Dave Crocker
<[email-masked]> wrote:

>> knows to assure us that the contract is strictly limited to
>> RFCs or RFC Editor projects and cannot be used to expand the
> Uh, no.  I want it to be /easy/ to expand into those other
> uses.  Not 'required' of course but easy if we wish to.

Wfm, modulo the observations you have already made about the
costs of making supposedly-transitory documents permanent.  You
didn't include, e.g., Jabber logs of WG meetings in your lists,
but we could, in principle, apply DOIs to those too.

What I would like to understand about the contract is whether it
would allow us to simply start issuing identifiers for other
types of documents or whether it applies only to documents of
which the RFC Editor is the publisher.  I haven't seen it and
IANAL, but that might hinge on whether publisher 17487 is
nominally the RFC Editor or the IETF Trust.  I'm not sure I care
what the answer is, but it would be interesting, and possibly
useful, to know, _especially_ if one wants to make expansion to
other uses easy.

More important, and where I hope we are in agreement given your
earlier comments, if we are going to expand DOI assignment into
other documents and uses, I'd like to be sure the community has
the opportunity to understand the issues (including any database
or document stability requirements and/or requests) and comment
on that (one use or carefully-identified cluster of uses at a
time) rather than having it be announced on, e.g., for the
far-fetched Jabber log example, some meeting arrangements or
tools list with the assumption that anyone who cares about
anything is monitoring that list carefully and that discussion
there is therefore sufficient to commit the community.

best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Jul 2015 10:41:46 -0700

> costs of making supposedly-transitory documents permanent.  You

Huh?  I did not make any comment about such a cost.

> but we could, in principle, apply DOIs to those too.

That was the reason for the ellipsis, John.  I wasn't trying to be
complete and in fact my point about that was that trying to be complete
right now is a mistake.

d/

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 07 Jul 2015 14:17:27 -0700

On 7/7/15 9:52 AM, John C Klensin wrote:
>>> 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 
> 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.

> 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:
> 
> 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

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 10:43:37 -0400

> draft for a couple of months?

Among other things, it creates the impression that IETF doesn't use its 
own standards for identifiers.

IMO, DOIs need to cease appearing in RFCs.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jul 2015 11:04:54 -0400

How about, if we have something better to include, we add that.  Then, 
if we find that the world is using what we produced, and not using DOIs, 
we can stop using the DOIs.  While some folks have commented on list 
that they do not need DOIs for academic purposes, other folks have been 
very clear that it is very helpful.

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jul 2015 11:19:07 -0400

RFCs should reference URNs whenever possible.  If there's no URN for a reference but there is a DOI, I have no objection to the DOI being included.  If both exist, I would consider it acceptable to reference both.

I fully support making it easy for RFC readers to access referenced publications.  But the RFC editor should not undermine IETF standards efforts.

Keith

Sent from my iPhone

> On Jul 9, 2015, at 11:04 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> How about, if we have something better to include, we add that.  Then, if we find that the world is using what we produced, and not using DOIs, we can stop using the DOIs.  While some folks have commented on list that they do not need DOIs for academic purposes, other folks have been very clear that it is very helpful.
> 
> Yours,
> Joel
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jul 2015 11:48:09 -0400

--On Thursday, July 09, 2015 11:04 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> How about, if we have something better to include, we add
> that.  Then, if we find that the world is using what we
> produced, and not using DOIs, we can stop using the DOIs.
> While some folks have commented on list that they do not need
> DOIs for academic purposes, other folks have been very clear
> that it is very helpful.

In addition to some other things for which it may be desirable
to round up proposals, we have something we allege to be better
in the form of "urn:ietf:rfc:2648" (as described in, RFC 2648).
When can we expect those identifiers to start appearing
explicitly in the RFC Index and metadata and in at least
references to RFCs within newly-issued documents in the RFC
Series?

    john

---

From: Leif Johansson <[email-masked]>
Date: Thu, 9 Jul 2015 18:22:10 +0200

> 9 jul 2015 kl. 17:19 skrev Keith Moore <[email-masked]>:
> 

Are you seriously claiming that the RSE is _undermining_ the IETF standards effort by adding an external reference to published RFCs or did I miss something (not being a native English speaker)?

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 12:22:24 -0400

> references to RFCs within newly-issued documents in the RFC
Seems like this should be a simple matter of updating the XML references 
that the xml2rfc tools use.   This should have been done years ago.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 12:23:30 -0400

> Are you seriously claiming that the RSE is _undermining_ the IETF standards effort by adding an external reference to published RFCs or did I miss something (not being a native English speaker)?
By using DOIs instead of URNs, absolutely that's what they're doing.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 12:27:29 -0400

On 07/07/2015 12:52 PM, John C Klensin wrote:
> represented by recently-published ones.
I strongly object to including DOIs in RFCs unless URNs are equally 
supported.   This is undermining IETF standards efforts and not 
something that's appropriate for the RSE to be doing.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jul 2015 12:33:51 -0400

Did anyone earlier ask the RFC Editor to change the reference format for 
RFCs from RFCxyzw to urn:ietf:rfc:xyzw?  (I gather you are asking now, 
but objecting because it was not done when it was not asked seems 
strange.  Remember that this has been brought to the communities 
attention several times in the past.)

And if the RFC Editor made such a change, would it help any user of the 
RFCs in understanding or following the reference?  As far as I can tell, 
it would not help at all.  Maybe I am missing something (just as I 
forgot RFC 2648 since it did not seem useful for anything.)

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 12:38:11 -0400

> Editor and/or RSOC [1] many months ago.

I don't think it's too late to undo any of these things.   Sure, 
identifiers already assigned should not be reassigned, but that doesn't 
mean that the process needs to continue for new RFCs, nor that 
identifiers for new RFCs should have to adhere to the same syntax as has 
previously been used, nor that existing RFCs cannot be assigned 
additional identifiers.

Keith

---

From: Sandy Wills <[email-masked]>
Date: Thu, 09 Jul 2015 12:41:00 -0400

I don't personally use French or Russian.  However, I don't believe 
that those languages should be outlawed.  Some other people appear to 
find them useful.
    In this case, _we_ may not need or use them and some of us may not 
want them to even be available, but we should play well with others.

    Anyone who becomes aware of an RFC can probably, if they have any 
internet access at all, find http://www.rfc-editor.org/rfc-index.html 
and locate what they need.  The DOI initiative appears to be in 
preparation for the day, far in the future, when the RFC Editor no 
longer exists.
    Perhaps we could support this external initiative by listing DOIs in 
our indexes and lists.  That way, if the world changes so much that 
there is no IETF/IESG live RFC repository with index available, anyone 
who can get a copy of the dead-file list will have access to the DOIs 
and can still get the RFCs.
    Although my personal opinion is that by the time we are no longer 
supporting that list we probably won't be using DOIs either.

On 7/9/2015 10:43 AM, Keith Moore wrote:
 > Among other things, it creates the impression that IETF doesn't use 
its own standards for identifiers.

-- 
Sandy Wills

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 12:47:49 -0400

On 07/09/2015 12:33 PM, Joel M. Halpern wrote:
> Did anyone earlier ask the RFC Editor to change the reference format 
> for RFCs from RFCxyzw to urn:ietf:rfc:xyzw? 

I don't know about "changing the reference format", but such references 
(both human- and machine-readable) should include the URNs.

> And if the RFC Editor made such a change, would it help any user of 
> the RFCs in understanding or following the reference? 

URN resolution services (several of which do exist) could add 'ietf' to 
the set of URN namespaces that they support.    The RFC Editor already 
makes the information available in machine-readable format, it just 
doesn't include the URNs.

Ideally IETF and/or RSE should operate an authoritative resolution 
service for the 'ietf' URN namespace.   I'd be happy to supply the code.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 13:04:49 -0400

> I don't mind if we did this, as long as we do DOIs now.

Strongly disagree.   The use of DOIs in RFCs should cease unless/until 
RFCs also support URNs.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jul 2015 13:12:52 -0400

--On Thursday, July 09, 2015 12:47 -0400 Keith Moore
<[email-masked]> wrote:

>> Did anyone earlier ask the RFC Editor to change the reference
>> format  for RFCs from RFCxyzw to urn:ietf:rfc:xyzw? 
> 
> I don't know about "changing the reference format", but such
> references (both human- and machine-readable) should include
> the URNs.

I don't even know what "references format means".  If you are
referring to the DOI suffix, I think it would be a less-and-good
idea, but see John Levine's comments about opaque identifiers.

>> And if the RFC Editor made such a change, would it help any
>> user of  the RFCs in understanding or following the
>> reference? 
> 
> URN resolution services (several of which do exist) could add
> 'ietf' to the set of URN namespaces that they support.    The
> RFC Editor already makes the information available in
> machine-readable format, it just doesn't include the URNs.
> 
> Ideally IETF and/or RSE should operate an authoritative
> resolution service for the 'ietf' URN namespace.   I'd be
> happy to supply the code.

New code is perhaps unnecessary: I note that a zone for urn.arpa
already exists.  The delegation or NAPTR records for
"ietf.urn.arpa" and "rfc.urn.arpa" don't seem to be there, but
the framework for DDDS resolution is certainty in place should
someone chose to task someone (presumably IANA) with creating
the zone and task someone (presumably the RFC Editor) with
populating the NAPTR records.

    john

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 13:17:18 -0400

> idea, but see John Levine's comments about opaque identifiers.

I'm referring to the RSE's failure to include URNs in RFC references 
that they publish.
I don't object to them including DOIs also, but I do object to them 
including DOIs without including URNs.

> populating the NAPTR records.

The code I was referring to is a web server or cgi program that would 
accept a request for an ietf URN and return either the actual document 
or its bibliographic information.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jul 2015 13:24:05 -0400

--On Thursday, July 09, 2015 13:04 -0400 Keith Moore
<[email-masked]> wrote:

> Strongly disagree.   The use of DOIs in RFCs should cease
> unless/until RFCs also support URNs.

Keith,

While I'm sympathetic to where you are coming from, there is
apparently a contract in place and a good number of RFCs have
been issued with DOIs in them.  Other than as a means to making
the RFC Editor feel slapped around -- an activity I have trouble
believing would be productive-- I have trouble believing that
the time and energy needed to undo whatever new tooling and
databases are there would have even significant symbolic value.

If putting explicit URNs next to those DOIs is seen as
beneficial, let's just move forward as quickly as possible with
getting that done and not force folks to take a step or two
backward first.

    john

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 13:25:17 -0400

On 07/09/2015 01:24 PM, John C Klensin wrote:
> If putting explicit URNs next to those DOIs is seen as beneficial, 
> let's just move forward as quickly as possible with getting that done 
> and not force folks to take a step or two backward first.
Fine with me.   I certainly think that's the best way forward.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 15:00:31 -0400

> at worst harmless and probably slightly helpful from my sort-of

On the contrary, having DOIs without having URNs does tremendous harm to 
an established IETF standard that is actually in wide use (though not 
widely used in the same circles that use DOIs).

I also think it's absurd, given IETF's longstanding commitment to free 
and open access, that IETF would favor an identifier scheme that 
effectively imposes a tax on document publishers.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 Jul 2015 11:16:23 -0800

On 7/9/15 11:00 AM, Keith Moore wrote:
> On the contrary, having DOIs without having URNs does tremendous harm
> to an established IETF standard that is actually in wide use (though
> not widely used in the same circles that use DOIs).

I'm not sure that I'd agree that it does "tremendous" harm but
it does look awfully peculiar.  How much effort would actually
be required for the IETF to provide a resolution service for URNs?

I am not opposed to adding DOIs to RFCs but I suspect that this
would all have gone much more smoothly if the RSE had simply said
"DOIs are widely-used bibliographic identifiers and we think we
should assign them, too" or if the draft had come from the RFC
editor herself.  Turning this into an IAB document and including
overblown claims about what's gained by adding them were unnecessary -
doing this in a straightforward way would, I think, have produced more
straightforward discussion and results.

The URN situation is a problem but I really don't think it should be
gating.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jul 2015 15:44:14 -0400

The draft is from the RFC Editor.  It is written by the person she 
commissioned to do the work.  It is coming from the IAB because the 
conclusion some time back was that the sensible place to publish RFC 
Editor RFCs was on the IAB stream.  As Heather said, we could create a 
separate stream for the RSE, but it seems rather odd.

So, the net is that what you ask for is exactly what is taking place.

No one asked the RSE to include URNs in the reference information.  So 
no effort was made to do so.  I have no objection to folks asking for 
such (I don't have an opinion one way or another about whether they are 
useful.)

Yours,
Joel

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Jul 2015 22:52:31 +0200

> such (I don't have an opinion one way or another about whether they are

Now if only there was a mailing list where such requests could be
discussed ...

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Jul 2015 15:59:27 -0700

> The URN situation is a problem but I really don't think it should be

It might be worth stating this in the affirmative:  The URN situation is
entirely independent of the DOI situation and it is important to handle
the two topics entirely separately.

> Editor RFCs was on the IAB stream.  As Heather said, we could create
> a separate stream for the RSE, but it seems rather odd.

I understand it is 'through' the IAB stream, but that does not
automatically mean it is 'from' the IAB, merely that the IAB is the
approving body for the document. (RFC 4844)

If this document really is intended to be 'from' the RSE, then her name
should be one of the authors and the document should declare it origin
of administrative authority.  Note that the document does not state any
of this IETF-community authority-related information.

d/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Jul 2015 19:05:12 -0400

Interesting comment on the authoring.  I believe that according to our 
own stated policies, it would be wrong to list the RSE as an Author. 
She did not write the words.

Yours,
Joel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Jul 2015 16:21:35 -0700

On 7/9/2015 4:05 PM, Joel M. Halpern wrote:
> own stated policies, it would be wrong to list the RSE as an Author. She
> did not write the words.

We list authors who did not 'write the words' all the time.

The policy I found is:

     RFC Series Editor statement on authorship

     http://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html

It has conflicting text.

The high-level policy text is:

     "responsible for the technical content of the document"

which is entirely reasonable language and matches long-standing
practice, whereas the text you are presumably citing is:

     "If the development of a document has been
delegated or subcontracted, the authors are the person(s) doing the
actual writing, not the person(s) delegating or subcontracting the work."

is not.  I think we are demonstrating a basic problem with this latter,
arbitrary and overly-fine-grained rule.

d/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 Jul 2015 15:24:18 -0800

> the two topics entirely separately.

I don't think they're entirely independent.  It seems to me
that the question of why we're not providing resolution
services or indexing URNs is somewhat different from the question
of why we're not providing resolution services or indexing URNs
when we're paying money and cycles to provide indexing and access
using some other bibliographic identifier.  One looks like an
oversight or constrained resources, the other suggests that
we're thinking about bibliographic identifiers and have the
money to support their assignment but are going with DOIs.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 19:58:46 -0400

> be required for the IETF to provide a resolution service for URNs?
I think the resolution service code could be written in a day. 
Documenting it in an RFC might take a bit longer.

The RFC Editor already exports their bib information in XML, so getting 
the information shouldn't be an issue.
(Though ideally, the RFC Editor would add the URN to their bib 
information.   How long it would take them to do so, I don't know, but 
it doesn't seem like it should be difficult.)

The other thing that should be done is to update the xml2rfc code/data 
to automatically include URNs in references.

> The URN situation is a problem but I really don't think it should be gating.

I guess we just disagree on this.   I see it as a huge problem when we 
refuse to eat our own dogfood.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 19:59:40 -0400

On 07/09/2015 03:44 PM, Joel M. Halpern wrote:
> No one asked the RSE to include URNs in the reference information. 

I actually did, in person.   If memory serves I did so more than once.   
I'm very disappointed that my input was not taken seriously.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Jul 2015 20:02:35 -0400

> the two topics entirely separately.

Strongly disagree.    But perhaps you'd care to explain why it's 
important for the RSE to continue undermining an IETF standard?

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jul 2015 13:37:38 +1200

> money to support their assignment but are going with DOIs.

I think it's something to do with this rough consensus and running code
business that I keep hearing about.

OK, sorry to sound sarcastic, but this isn't a computer science issue,
or a matter of hurt pride over http://dx.doi.org/10.17487/RFC2648
or https://datatracker.ietf.org/doc/draft-kunze-ark/. It's simply
what the world uses.

    Brian

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Jul 2015 08:01:13 +0200

Keith & John,

> Documenting it in an RFC might take a bit longer.

First, that doesn't sound like an offer of help, but a supposition.  If
you wanted to write the code, that would be nice.  Still, even if you
were kind enough to donate your time, then the code would need to be
maintained.  And even if the code were written and maintained, someone
would actually have to use it.  URNs have been out there for the better
part of two decades and yet they were not chosen by academia for this
purpose, even though, as John correctly points out, the concept of using
them for this purpose was articulated long ago.  DOIs were chosen.  That
infrastructure exists, and at least in some corners a DOI is necessary
for credit.  The RFC Editor is being responsive to academia with the
hope that in return they will more engage in IETF activities.  This
debate has lost sight of that goal.  We need to do what we can to bring
those people back to the IETF so that we can benefit from their
research.  The ANRP is something that ISOC does.  This could be
something that the RFC Editor can do, and it costs almost nothing.

I agree with Dave.  DOIs and URNs need to be considered separately. 
Before we go adding URNs into every RFC at the very least we should
understand the value of doing so, and whether it is either reasonable or
desirable to attempt to supplant/displace/compliment what is already
there.  I am sure you can find a myriad of examples of technology you
wish had been adopted but wasn't.

Therefore, before you answer the question above, ask yourself this one:
is this the best use of people's time?  Should the IETF focus on areas
that are closer to networking and not specific to a particular sector? 
Do we have bigger fish to fry?  I think we do, but that's me.

Anyway, I hope the IAB will take this as my input that I agree with the
approach specified in the draft, although I also agree with Melinda's
point about avoiding overstating the benefits of DOIs.  I view that as a
minor editorial change.

Regards,

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jul 2015 07:13:12 -0400

On 07/10/2015 02:01 AM, Eliot Lear wrote:
> you wanted to write the code, that would be nice.
I believe I've made that offer elsewhere.   But yes, I'm offering to 
write the code.
>   Still, even if you

This "almost nothing" cost is actually more than the cost of supporting 
URNs, because the technical effort of code writing and maintenance is 
essentially identical.

But I don't disagree with what you are saying above about the 
desirability of supporting academia.  But again, if the RFC Editor is 
undermining IETF standards, that's a serious problem.  (Note also that 
this is a standard that is actively being worked on by an IETF WG, so 
it's not like IETF has abandoned it.)   And that's why the issue of the 
RFC Editor supporting DOIs is inherently coupled with that of supporting 
URNs.

> there.
This does not appear to have been done for DOIs.

> Do we have bigger fish to fry?  I think we do, but that's me.
Perhaps we should be more concerned with the fact that we need to have 
this discussion at all.   This discussion is, after all, a significant 
use of people's time, and it shouldn't have been necessary.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jul 2015 07:39:03 -0400

> or a matter of hurt pride over http://dx.doi.org/10.17487/RFC2648 or 
> https://datatracker.ietf.org/doc/draft-kunze-ark/. It's simply what 
> the world uses.

"The world" uses URLs.   There are, in addition to that, communities 
that use DOIs, and communities that use URNs.   And relative to the 
expected useful life of either of the latter kind of names, only a tiny 
amount of time has elapsed.   These identifiers are intended to last 
centuries, but have been around for less than 20 years. There's only a 
tiny bit of buyin into either kind of name relative to their intended 
scope.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jul 2015 09:09:09 -0400

--On Friday, July 10, 2015 07:39 -0400 Keith Moore
<[email-masked]> wrote:

> "The world" uses URLs.   There are, in addition to that,
> communities that use DOIs, and communities that use URNs.
> And relative to the expected useful life of either of the
> latter kind of names, only a tiny amount of time has elapsed.
> These identifiers are intended to last centuries, but have
> been around for less than 20 years. There's only a tiny bit of
> buyin into either kind of name relative to their intended
> scope.

Keith and many others,

I think we are going around in circles.  We may not be
converging, but I don't think repeating variations on the same
theme or denouncing each other's positions, is going to help
much.    As you have pointed out, the discussion itself has
gotten expensive.  I hope that the IAB has whatever information
it needs from this list.  If that is not the case, I hope they
can come back with specific questions or other ways to focus the
discussion.

I think there is at least rough agreement that DOIs in RFCs are
here to stay.  Some wish they weren't, or that there had been a
different review process that might have led to a different
decision, but the question of how we got here -- including, for
those who believe it is a serious problem, who is accountable
and how--  is really separate from the ones of where we are and
where we are going.  

Part of the "how we got here" question does affect the document,
which is what claims it makes about why this is being done.
Some believe that adding DOIs will make RFCs academically more
credible; others consider that to be, at best, an untested
hypothesis.  There seems to be some agreement, even among those
who otherwise disagree, that the document should describe what
is being done and minimize the controversial explanation and
claims about why.

Similarly, some believe that use of DOIs in documents without
using URNs sends a powerful message and that either we need to
move to immediately incorporate URNs next to the DOIs or that we
need to document, somewhere, a clear and persuasive reason for
not doing so.    Some who don't believe that about URNs or the
relationship fundamentally don't like URNs or believe they have
had their chance and failed.  Others are convinced that there
are more URNs assigned and more use-instances of them in various
contexts than there are DOIs.  It is probably possible to
evaluate those particular claims only with a lot more agreement
about what and how to count.  

In any event, those who don't like URNs, or don't like them for
some specific set of functions, should be, at least IMO,
starting a serious discussion about whether the WG should be
shut down, or an applicability statement produced, or something
else, not complicating this DOI-in-RFCs discussion by using it
as a surrogate.  I note that there have been attempts to start
that discussion.  They have gone nowhere, perhaps because
starting it with assertions about, e.g., "useless prefix" or
even how other things have won in the marketplace are
sufficiently inflammatory to cause people to disengage or stop
thinking and start ranting.  Personal opinion based on
discussions with people very far outside the normal IETF
community: URNs are heavily enough deployed in some communities
that, while the IETF could abandon them or even denounce them,
the effect would be development elsewhere, very possibility
developments that would lead to incompatibilities or
interoperability issues, not making them go away.  It seems to
me that is as much a part of our reality as perceptions about
what other technologies are used, and where, and how dominant
they have become.

So I hope we can wind this discussion down.  And, again, if the
IAB needs information it doesn't think it has yet, I hope they
will tell us.

best,
    john

---

From: Bob Braden <[email-masked]>
Date: Thu, 09 Jul 2015 10:24:34 -0700

On 7/9/2015 9:33 AM, Joel M. Halpern wrote:
> for RFCs from RFCxyzw to urn:ietf:rfc:xyzw?  (I gather you are asking 
> now, but objecting because it was not done when it was not asked seems 

Joel, shouldn't that be urn:isoc:rfc:xyzw?

Bob Braden

-- 
Robert Braden
Internet and Networked Systems Division
USC Information Sciences Institute
310.448.9173

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 13 Jul 2015 10:28:58 -0700

On 7/9/15 4:59 PM, Keith Moore wrote:
> I actually did, in person.   If memory serves I did so more than
> once. I'm very disappointed that my input was not taken seriously.
> 

Just to respond to a particular point of yours: when you brought this
up, my response was exactly the same response I made when the request
came in to add DOIs: write and publish a draft describing what you
think this should look like, and then we can discuss if and how to
find the resources to make it happen.

- -Heather