Subject: Re: paperless journals, was IETF Journal - November 2017

From: John C Klensin <[email-masked]>
Date: Sat, 02 Dec 2017 04:09:18 -0500

--On Friday, November 10, 2017 11:48 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> Do any libraries actually keep paper newsletters any more?
> 
> Very few. I'm not sure it will turn out to be such a good
> decision 100 years from now - historians often use ephemera of
> this kind - but that's the way things are going.
> 
> Now that SM has set me straight, I am not suggesting any action
> at all.

With apologies for the lateness of this comment, but prompted by
both your comment above and Phillip's more recent one, I am.

I suggest that ISOC consider the function of the IETF Journal
and do so in the light of the plenary session of Internet
history of a few years ago.  I note that it is called "IETF
Journal" and not "IETF Random and Transient Musings".  If the
content is of any value, even as a snapshot of thinking about
the IETF by people that ISOC and whomever is advising it
consider interesting and/or important, then I think ISOC needs
to assume some explicit responsibility for preservation.   

That does not need to be paper but, in addition to the
considerations Phillip mentions, I think we need to be concerned
about bit rot and issues of, not only difficulties recovering
bits from media but easily interpreting the bits once received.
One advantage of paper (and stone tablets, etc.) over modern
digital forms is that we a few thousand years of demonstrated
and successful experience with preservation.    I wish I were
optimistic that today's HTML or PDF, with bits distributed
around the network, would be as reliably accessed even a few
hundred years in the future, but I'll bet a single-density 5.25
inch floppy disk that no one can successfully prove it will be.

Or ISOC (and the IETF) could conclude that the IETF Journal is
really a newsletter of no lasting value.  However, if that is
the conclusion, I wonder whether even more money and other
resources could be saved and put to better use by discontinuing
it entirely

    john
.

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2017 09:44:00 -0500

> bits from media but easily interpreting the bits once received.

The RSE recently made an arrangement with the Computer History Museum to 
archive RFCs in a way that is intended to be stable over the long term.

I expect that we could easily add a one-sentence addendum to that 
agreement to include the IETF J and anything else we might want to keep in 
the long term, such as the meeting minutes and (if they still exist) 
proceedings.

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Dec 2017 10:11:27 -0500

--On Saturday, December 2, 2017 09:44 -0500 John R Levine
<[email-masked]> wrote:

>> considerations Phillip mentions, I think we need to be
>> concerned about bit rot and issues of, not only difficulties
>> recovering bits from media but easily interpreting the bits
>> once received.
> 
> The RSE recently made an arrangement with the Computer History
> Museum to archive RFCs in a way that is intended to be stable
> over the long term.
> 
> I expect that we could easily add a one-sentence addendum to
> that agreement to include the IETF J and anything else we
> might want to keep in the long term, such as the meeting
> minutes and (if they still exist) proceedings.

Yes, although handling that as an "addition" would, IMO, require
very clearly sorting out the IETF-ISOC relationship, including
some "who is in charge" issues.  Especially for publications,
those issues would include some of the ownership and
responsibility ones that we thought we had sorted out with the
IETF Trust setup and agreements.

Not only IANAL, but I suspect that for other reasons as well, it
would be lots better (and less time-consuming) to deal with
these things on a "one publisher/ copyright owner, one
agreement" basis.  If the Computer History Museum folks were
willing, that would not prevent extending the existing
arrangement to include minutes, etc. because the IETF Trust has
its hooks into them too, but ISOC publications would seem to be
crossing some line.   On the other hand, if ISOC were to make an
agreement with someone that included  not just the IETF Journal
but all of the educational materials, policy documents, exchange
point discussions, etc., I'd think that would be a service to
the community and its history.

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Dec 2017 14:20:56 -0500

I think we could use a small piece of technology to make this sort of thing
easier to manage.

The thing about formats is that if one person uses the format, the means of
processing can be lost. But if you can get any sizable number of people to
use a format, maybe as few as 10,000, and sufficient information encoded in
it, then there will be sufficient incentive to decode it.

I have been working on a Web Service for sharing information stores for
things I call 'catalogs'. Think 'passwords', 'bookmarks', 'contacts'. The
type of data that users enter on multiple devices but want to be able to
retrieve from any of them as if they were one device.

At the moment, I have mostly been considering the problem from the point of
view of a set of devices that have an unreliable connection to a Web
Service. So I have been considering cases like 'Alice adds Bob to her
contacts on one device while it is offline and then to another that is
online, how are these synchronized'. The type of problem that OneDrive etc.
face.

There is the converse of the problem in which a repository is maintained by
multiple Web Services with some sort of voting mechanism to maintain
consistency. Folk who remember DECNET clusters will remember the Quorum
scheme they used.

I developed a prototype of a container format using Merkle Trees for
integrity checking and random access:

http://www.prismproof.org/Documents/draft-hallambaker-jbcd-container.html

The scheme is purposefully designed to separate integrity checking on the
data content, integrity checking on content metadata and unchecked data. It
also supports fast random access to arbitrary records in an append-only log.

We could wrap a simple Web Service around it with operations such as:

* Add item
* Retrieve item with key X having value Y
* Obtain best proof of integrity for record Z

As with all these block-chainy sort of schemes, it is easy enough to check
prior data values if you have an output digest that you can rely on.
Establish trust in an output digest is rather more tricky.

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Dec 2017 05:12:45 -0500

--On Saturday, December 2, 2017 14:20 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

> I think we could use a small piece of technology to make this
> sort of thing easier to manage.
> 
> The thing about formats is that if one person uses the format,
> the means of processing can be lost. But if you can get any
> sizable number of people to use a format, maybe as few as
> 10,000, and sufficient information encoded in it, then there
> will be sufficient incentive to decode it.

I think it depends on the time frame.  Let me give two examples
within the life spans of at least many of the people reading
this list.  At one time, there were a widely-used set of word
processing and calculation products made by Wang Corporation and
its imitators.  Their earliest generations that used demountable
storage media used 8 inch floppy disks; IIR Wang led the charge
for what because the nominal 5.25 inch format because the eight
inch ones were just too big for the devices.  For more than
10,000 people used them.   I would guess that it would be rather
hard to find a way to read and interpret those disks today and
that it isn't getting any easier.

A perhaps more interesting example was a somewhat more recent
device called, more or less, the IBM Magnetic Card Selectric
Typewriter.  The medium used had the same form factor as paper
punched cards, but had magnetic material on one side.  It was
almost exactly what the name sounds like: a typewriter with a
memory device attached that permitted storing (and, more
important, correcting) a document on those magnetic cards, and
then playing them back on the typewriter mechanism, a mechanism
that was also used in a few popular computer terminals of the
period.  The device could be seen as evolutionary from ASR
teletypes, but the advantages of magnetic media for test that
needed to be corrected and revised over punched paper tape were
obvious.  Even ignoring the question of bits dropping out, care
to speculate on devices to read those cards and decode the
formats (I don't recall if the latter were ever made public)
today.

If you want to look at formats, rather than storage media,
consider WordStar or first-generation runoff and its non-U**x
immediate successors.  Ever hear of "Compose"?   Usage of each
of those things almost certainly far exceeded your 10K.  If one
can recover the bits (want to borrow a spare 6250 BPI 9 track
tape drive or the earlier and lower density 7 and 9 track
versions?), those formats are recoverable because the are
basically known character encodings of the text (many, but not
all, ISO 646 variations) with a relatively small amount of
format markup that is easily parsed out.  

What all of the above share is that the most stable and
efficient ways of recovering and using the documents they
produced is to find paper copies of their output and scan them
rather than trying to fuss with the magnetic media and native
formats.   It is not a coincidence that, when the community set
out to recover the earlier RFCs and made them machine-readable
-- documents of which many had been prepared using a variety of
those early systems -- the mechanisms used were "scanning" and
"typing in and proofreading", not attempts at recovery of the
digital forms.  

And that is all less than, or about, 50 years.   I do believe we
are getting better at this sort of thing, as John and others
have pointed out.   However, I think the issues need to be taken
seriously and that neither use by a lot of people or procedures
to periodically recopy or widely distribute copies of the bits
are sufficient, even though they may be important steps or
tools.  As to standard and widely-used formats, I continue to
believe in them too, but the success record so far is not
grounds for long-term optimism.

best,
   john

---

From: "John R. Levine" <[email-masked]>
Date: 3 Dec 2017 10:28:13 -0500

> have pointed out. ...

No kidding, and actual librarians have given this far more thought than we 
dilettantes ever will.  The reason PDF/A is a good format for archiving is 
not that 10K random people might use it, but that a lot of archival 
librarians who understand the issues use it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Warren Kumari <[email-masked]>
Date: Sun, 03 Dec 2017 18:31:24 +0000

> both your comment above and Phillip's more recent one, I am.

Me too.

I'd initially been staying out of this thread, but if the journal goes
paperless I'll stop reading it -- I get enough mail that I'll plan to read
it later, and then will just archive it.

Paper journals / magazines get read on the plane, while on the phone, etc.
Electronic ones get ignored / deleted.

This might just be me, but figured I'd share my data point,

W

> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 03 Dec 2017 10:51:57 -0800 (PST)

> This might just be me, but figured I'd share my data point,

Warren,

That's what 2/3s of my susbcribers tell me too. It is slowly shifting, 
and I suspect it would shift faster towards "online" if I also 
provided the journal in more table-friendly formats. That's on the 
to-do list for sure.

But still, the majority of my readers prefer paper, and that's 
especially true in the developing world where reliable (and free) 
access to the Internet and to printers is less common. Other reasons 
include the ability to write notes in the margins, pass copies around, 
read "anywhere" and so on.

Ole

Ole J. Jacobsen 
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Docomo: +81 090 3337-9311
E-mail: [email-masked]
Skype: organdemo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Dec 2017 08:10:50 +1300

On 04/12/2017 07:31, Warren Kumari wrote:
... 
> This might just be me, but figured I'd share my data point,

Thank you for saying that. I'm enough of an old fogey that I didn't
want to be the first to say it.

I understand that it takes money and bother to ship hard copy. But
there is value in it.

    Brian

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2017 14:34:56 -0500

>> Electronic ones get ignored / deleted.

Alternative fogey here -- my Kindle goes with me on the plane and 
whatever's on it tends to be what I read.  For the IETF J it's not really 
a fair comparison since the electronic version is full page PDFs which are 
hard to read on anything smaller than a notebook computer or a very large 
tablet.

The IEEE (most likely at vast cost) does a good job of publishing journals 
in multiple formats.  They publish their journals in three electronic 
formats, EPUB, MOBI, and AZW3, as well as page image PDF that matches the 
printed version.  Getting them onto the Kindle is about three clicks, one 
to download the MOBI, one to open it with the Send to Kindle program, one 
to tell it to send to the Kindle rather than (or in addition to) my phone.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Sun, 03 Dec 2017 20:57:01 +0000

> to tell it to send to the Kindle rather than (or in addition to) my phone.

Yup, have a Kindle, and love it -- but the process for paper journal is:
Step 1: stuff in bag
Step 2: ???
Step 3: profit

Reading it inline at airports / on the loo / while waiting for code to
finish compiling is much much more convenient for me than Kindle (which
lives next to bed / in travel bag) - if I drop the paper version it doesn't
really matter...

I've also given away a number of the paper versions to people on planes -
while I could mail an electronic version, somehow the paper experience is
very different (for me).

I read Usenix Security / ACM / IEEE mags in paper - while these are all
available in electronic versions I've never read them in this format (other
than when I've searched for a specific article and read that article).

W

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Dec 2017 19:20:41 -0500

Warren Kumari <[email-masked]> wrote:
    > paperless I'll stop reading it -- I get enough mail that I'll plan to
    > read it later, and then will just archive it.

    > Paper journals / magazines get read on the plane, while on the phone,
    > etc. Electronic ones get ignored / deleted.

Same for me.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Dec 2017 07:48:30 +0000

> On 3 Dec 2017, at 19:10, Brian E Carpenter <[email-masked]> wrote:
> 

Fogey +1

After I’ve read it, I also often leave a paper copy somewhere where I think other people will see it and have a browse themselves.

Tim

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 9 Dec 2017 10:08:21 +0100

Phillip,

I think the IETF is about a million miles away from considering intelligent
distributed electronic abilities for archival when they do for example
make IETF content such as IETF 100 plenary video recordings only available
via a commercial video streaming provider called youtube that does prohibit
downloading and therefore makes any form of mirroring or other methods of
multi-party, voluntary long term availability of IETF video content impractical.

How about RFC would also be put exclusively on commercial platforms without free 
download options.

Sorry, but i am quite irritated about youtube being used exclusively given that
services licensing conditions vs. the intent of IETF content.

Btw: If the IETF wants to save money by making live streaming supported by
advertisements via commercial platforms, then it should offer the content
openly to any such platform and suggest users to go to any such platform.
But primarily there needs to be platforms for free download of IETF content.

Once those rules of access are agreed on, intelligent software to support this
would definitely be great.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 9 Dec 2017 11:19:40 -0500

> services licensing conditions vs. the intent of IETF content.

I'm reasonably sure that the videos are on Youtube because it's easy to 
upload them and they don't charge us.  If you have other suggestions that 
aren't unduly labor-intensive and expensive, I'm sure they'd be welcome.

Regards,

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 10 Dec 2017 11:46:09 +0100

I like the single point of access: agenda on datatracker.
The audio recordings are hosted on www.ietf.org. Usually there
are also meetecho video recordings hosted from a meetecho site,
except seemingly for this plenary (not sure what other pieces
are missing).

I would suggest to have from that agenda page video downloads of
videos stored on www.ietf.org (aka: copy them there like the
audio recordings), but also preferentially streaming
button from youtube (figure out the right URL so folks who want
to stream go to youtube or meetecho first).

Especially because ietf.org/live only points
to the last IETF and one might want to wach videos of older IETFs.
And its unclear to me if/how long-term guaranteed the availability
of meetecho recording URLs is. Given how meetecho is "only" a contractor,
it could change.

Of course it would also be great to ask youtube if they could
give permission for folks to download IETF videos from youtube
(even if they technically don't change anything. Just make it legal
for IETF videos on youtube to be downloaded with those otherwise
"illegal" downloaders. Might even have a script on www.ietf.org
to make this easy). If youtube would allow download, then it might
be sufficient to not hav video copies on ietf owned storage, but
rely on those two locations (youtube, meetecho) for the time being
(and copy stuff over once one of them goes away).

Cheers
    Toerless

On Sat, Dec 09, 2017 at 11:19:40AM -0500, John R Levine wrote:
> I'm reasonably sure that the videos are on Youtube because it's easy
> to upload them and they don't charge us.  If you have other
> suggestions that aren't unduly labor-intensive and expensive, I'm
> sure they'd be welcome.
> 
> Regards,

-- 
---
[email-masked]