Subject: Re: New Non-WG Mailing List: Ietf-and-github -- Discussion of using GitHub in IETF activities, particularly for Working Groups

From: Ross Finlayson <[email-masked]>
Date: Tue, 26 Jan 2016 14:02:01 -0800

Why are IETF Working Groups using a random ‘Mickey Mouse’ third party like ‘GitHub’?  Does the IETF not have its own servers (nor its own protocols for document collaboration)?

	Ross.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 26 Jan 2016 14:39:38 -0800

On 26 Jan 2016, at 14:02, Ross Finlayson wrote:

> Why are IETF Working Groups using a random ‘Mickey Mouse’ third 
> party like ‘GitHub’?

Because it is not a random third party. Huge swathes of significant open 
source development are done on GitHub, so many people already have 
accounts and understand some of how it works.

> Does the IETF not have its own servers (nor its own protocols for 
> document collaboration)?

Yes; no. Further, this goes well beyond "protocols": it is mostly about 
interface for WG participants.

--Paul Hoffman

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Jan 2016 13:50:48 -0900

> interface for WG participants.

I'm not sure it makes a lot of sense to be fussy about
this but fussy we are, so I'll add that I think this is
about working group tools rather than working group
"interfaces" (individual contributors already can
and do use pretty much whatever they want to get
their documents ready).

I am not a fan of making IETF processes dependent on
technologies that don't "belong" to the IETF and I don't
think it's a trivial concern, but if the IETF tools
aren't working for us it makes sense to look outside for
tools that do.

Melinda

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 26 Jan 2016 18:42:22 -0500

> aren't working for us it makes sense to look outside for
I don't disagree. But I have a slightly different perspective, and I'd
value feedback from the community.

It seems to me that it would be inefficient for the IETF to do everything
ourselves.

For instance we may choose to use applications that have their own APIs,
protocols, etc without requiring the IETF to standardize the whole stack.
(To illustrate my point: consider non-IETF standards from IEEE, W3C, etc
and/or tools like WebEx, YouTube, etc.) I don't think we should limit
ourselves to only using things that "belong" to the IETF if that means
limiting our productivity without good reason.

More to the point, it seems reasonable to outsource tools when doing so is
the best choice. Just because we /can/ run our own instance of some service
doesn't mean that we /should/. I'm especially cognizant of the economics of
these choices, given that the IETF budget is limited. There may be cases
where we need more control, exposure to the technology, etc, and thus
sometimes the "best choice" is not primarily driven by financial
considerations. But it's not rational to be steered by a bias for doing
things ourselves at the expense of other opportunities, productivity, etc.

My straw-man conclusion, for your consideration and criticism, is that we
should routinely consider "cloud based" tools as a first-class option.

For what it's worth, in my role on the IAOC I observe that we do consider
all of our options today. But I may also observe a bias in the community
that I'd like to understand better.

Thanks,
-Benson

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Jan 2016 14:55:00 -0900

On 1/26/16 2:42 PM, Benson Schliesser wrote:
> It seems to me that it would be inefficient for the IETF to do
> everything ourselves.

Absolutely, and there can be (and have been) issues with
doing it ourselves.  My only real concern about using
other people's tools is that there's the possibility that
they can fold up shop, change the terms of use, etc. -
we have no control over that.  The likelihood of that
happening with Github is vanishingly small (although it's
not out of the question that they might start charging for
what are now free accounts).

I use Github pretty heavily for both work and hobbies, and
I like it.  But I back up my own stuff locally - just saying.

> For what it's worth, in my role on the IAOC I observe that we do
> consider all of our options today. But I may also observe a bias in the
> community that I'd like to understand better.

I don't know too many people who aren't currently using
Github for various projects.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Jan 2016 18:56:55 -0500

I have no objection to people using github for internet draft preparation.
I have some concerns with working groups requiring it, in part because I 
like our tradition of allowing folks to use whatever tooling they are 
comfortable with.  This is counter-balanced to some degree by the 
importance of making it easy for the working group to have control over 
the draft content.

I ntoe tht the rtgwg includes in its recommendations that authors may, 
but are not require to, use github.  That makes good sense to me.

And if we are going to allow it, and encourage where suitable use for 
improved collaboration, having good ways to explain how to use github 
and how to use it working with the IETF processes makes good sense.

Yours,
Joel

On 1/26/16 6:42 PM, Benson Schliesser wrote:
> On Tue, Jan 26, 2016 at 5:50 PM, Melinda Shore <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> protocols, etc without requiring the IETF to standardize the whole
> stack. (To illustrate my point: consider non-IETF standards from IEEE,
> W3C, etc and/or tools like WebEx, YouTube, etc.) I don't think we should
> limit ourselves to only using things that "belong" to the IETF if that
> means limiting our productivity without good reason.
>
> More to the point, it seems reasonable to outsource tools when doing so
> is the best choice. Just because we /can/ run our own instance of some
> service doesn't mean that we /should/. I'm especially cognizant of the
> economics of these choices, given that the IETF budget is limited. There
> may be cases where we need more control, exposure to the technology,
> etc, and thus sometimes the "best choice" is not primarily driven by
> financial considerations. But it's not rational to be steered by a bias
> for doing things ourselves at the expense of other opportunities,
> productivity, etc.
>
> My straw-man conclusion, for your consideration and criticism, is that
> we should routinely consider "cloud based" tools as a first-class option.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Jan 2016 23:58:09 +0000

> I like it.  But I back up my own stuff locally - just saying.

Right, I think we want a clone of any repos we care about on
an IETF server but so long as that gives the full repo history
then we should be pretty much good to go.

Same thing should work for the next thing that comes after
github too, or even previous generations of things using hg,
svn or cvs.

S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Jan 2016 16:13:09 -0800

It's important to distinguish between archival platforms, versus 
collaboration platforms.  It's then important to distinguish between 
currently-popular platforms vs. ones with marginal use.

The topic, here, is collaboration.  That is, the activity of developing 
an I-D by a group.  So it only needs to be useful today.  It doesn't 
have to be useful tomorrow.  As noted, this is about an integrated 
service, not just a technology.

Today, there are only a small number of large-scale, highly popular 
collaborative platforms.  Github most certainly is one.

d/

ps. With respect to archiving, the IETF in fact does not do museum-level 
long-term protection of its data.  Nor should it.  But it /should/ plug 
its output into a place that does. Museum-quality archive is an entirely 
different animal from daily crash protection, which of course the IETF 
does do.

On 1/26/2016 2:39 PM, Paul Hoffman wrote:
>> Why are IETF Working Groups using a random ‘Mickey Mouse’ third party
>> like ‘GitHub’?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 13:25:38 +1300

Interesting discussion, but could y'all move it to [email-masked] please?

Regards
   Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Jan 2016 16:34:31 -0800

On 1/26/2016 3:55 PM, Melinda Shore wrote:
> My only real concern about using
> we have no control over that.

I think this point is worthy of the main IETF list, not just the github 
specialty forum.

What I meant to imply from my last posting is exactly that we aren't -- 
or at least shouldn't be -- strategically affected by having to switch 
to a different platform.  Some days of hassles, but not years of it and 
certainly no permanent loss.

I'm inclined to suggest that the only criteria for choosing a 
collaboration platform are:

    1.  Is it globally popular; that is, does it already have a large 
and diverse user base?

    2.  Is there anything about it that serves to restrict use, in ways 
that would damage the IETF requirement for supporting open participation 
by anyone who is interested?

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Jan 2016 21:40:19 -0500

Strongly agree with Joel.  If this is something individual
document authors and editors people want to use, great.   OTOH,
were it to evolve into a requirement, doing so would reduce the
range of people who could reasonably volunteer to act as
document authors and that would be a step in the wrong direction.

FWIW, I'm actually concerned about the trends toward making
xml2rfc a requirement rather a useful optional tool.  Again,
individual ways of working differ and, at least for I-Ds, I'd
prefer to maximize author efficiency rather than trying to force
everyone into the same mold.

best,
    john

--On Tuesday, January 26, 2016 18:56 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> I have some concerns with working groups requiring it, in part
> because I like our tradition of allowing folks to use whatever
> tooling they are comfortable with.  This is counter-balanced
> to some degree by the importance of making it easy for the
> working group to have control over the draft content.
> 
> I ntoe tht the rtgwg includes in its recommendations that
> authors may, but are not require to, use github.  That makes
> good sense to me.
> 
> And if we are going to allow it, and encourage where suitable
> use for improved collaboration, having good ways to explain
> how to use github and how to use it working with the IETF
> processes makes good sense.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Jan 2016 22:43:28 -0500

> everyone into the same mold.

https://sourceforge.net/projects/phb-build-tools/

See RFCTool.

I pushed the source for the version with the installer package but not
the installer itself yet. The code is complete enough to have been
used to produce one published RFC. There are some bugs in some code
paths.

Currently the code has only been tested on Windows but it is all in
.NET and should run on either mono or Netcore. The Word converter has
lost support for bulleted lists and tables since I moved to an open
source library for the file interface.

The tools allow drafts to be created in any of these formats

Word (.docx), Markdown (.md), HTML, XML2RFC (not the new schema yet).

Text can be output in any of the following formats

Word (.docx), Markdown (.md), HTML, XML2RFC, TXT

So if you have a collaborator who uses Markdown, you can convert the
file to Word, use it to find all his grammar and spelling errors and
then return the document in markdown.

At present I use Word as my source input and target XML. If you are a
Visual Studio user however, you can use Markdown, HTML or XML input in
one window and generate TXT, XML, etc in another. This does not work
for Word due to the library having a hardcoded dependency on reading
input from a file.

The tools also maintain references, [!RFC5822] creates a normative
reference. [~RFC822] creates an informative. The code will also build
concordances of occurrences of normative language
[MUST/SHOULD/MAY/REQUIRED/etc.].

You can also include text from files in other formats. So my protocol
compiler generates HTML output for describing reference sections and I
typically generate examples in Markdown and both can be included in a
Word Document.

The code is in C# if people want to edit. I probably won't do much on
it until the new RFC tools become available. My objective is to be
able to round trip from HTML source.

The only time I see the XML is when I upload stuff to IETF drafts.

Some stuff written using it:

https://tools.ietf.org/html/rfc7633
https://datatracker.ietf.org/doc/draft-hallambaker-json-web-service/
https://datatracker.ietf.org/doc/draft-hallambaker-udf/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-developer/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-reference/

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Jan 2016 11:43:23 +0100

> I'm not sure it makes a lot of sense to be fussy about this but fussy
> we are, so I'll add that I think this is about working group tools
> rather than working group "interfaces" (individual contributors
> already can and do use pretty much whatever they want to get their
> documents ready).
> 
> I am not a fan of making IETF processes dependent on technologies that
> don't "belong" to the IETF and I don't think it's a trivial concern,
> but if the IETF tools aren't working for us it makes sense to look
> outside for tools that do.

i use git, svn, slac, ... everything but paper and pencil.  and you and
your friends are welcome to use whatever works for you.

my issue is that the discussion, tracking of issues, ... must remain on
the mailing lists until we leave the mailing lists behind for a better
world.  imiho, git isn't it.

randy

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Jan 2016 10:46:14 +0000

> https://sourceforge.net/projects/phb-build-tools/

You should be aware that Sourceforge has a reputation for bundling
downloads with malware. The site is very risky to use.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Southwest veering west later, 5 or 6, increasing 7 to severe gale 9,
perhaps storm 10 later. Rough or very rough. Rain then showers. Moderate or
poor, becoming good.

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jan 2016 06:26:08 -0500

> Github for various projects.

--On Wednesday, January 27, 2016 11:43 +0100 Randy Bush
<[email-masked]> wrote:

> i use git, svn, slac, ... everything but paper and pencil.
> and you and your friends are welcome to use whatever works for
> you.

> my issue is that the discussion, tracking of issues, ... must
> remain on the mailing lists until we leave the mailing lists
> behind for a better world.  imiho, git isn't it.

I don't have nearly Randy's breadth of experience and do use
paper and pencil (but obviously not for community tracking).  As
those who have worked with me on documents know, I also use a
lot of intermediate versions of drafts (intermediate between
posted ones) that contain a lot of notes to myself that tend to
be cryptic and/or sharp.   Being forced to make those suitable
for general consumption or "it never goes away" archival use
would considerably slow down my work.

More important, I've found github, various versions of svn,
etc., far more suitable for code development and repositories
than for developing, writing, and tracking documents.  I've
found github tracking and development of complex documents in at
least one non-IETF context sufficiently frustrating that I'm
getting close to dropping out of a reviewer/ contributor role
there.  That may be just because I'm showing my age, but I think
there are real differences in requirements, differences that may
or may not be related to Randy's comment quoted above.  

So, again, I think people should do what works for them and
helps get the work done.  However, tracking and discussion
requirements should not change and we should stay focused on
submission formats and tracking/approval mechanisms, sticking
with things that have proven to work for the IETF until we have
something clearly better, and not the tools used to produce
things.

    john

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Jan 2016 10:50:41 -0700

> importance of making it easy for the working group to have control over

The IETF non-WG CodeMatch mailing list only seems to use the mailing
list to announce a new online or phone meeting. You *have* to go to
github in order to see anything of significance.

My fear is that a WG will start using github as the method of
communications and only announcing someone pushed information to github.
(like CodeMatch does now)

Hosting your own github like service is not that difficult.  Git comes
with a simple service that provides web interface for servers. I don't
care if its the IETF or github as both methods would allow for making
complete copies and public access.
-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Doug Barton <[email-masked]>
Date: Wed, 27 Jan 2016 13:51:33 -0800

> aren't working for us it makes sense to look outside for

The IETF is two decades behind on using revision control in a systematic 
way, nowhere more significantly than in the area of drafts. At this 
point, anything reasonable we can do to improve the situation should be 
embraced.

Github is well established, and well respected (as others have pointed 
out already). While git is not my favorite VCS, it has the advantage of 
being able to trivially clone the repo, making any IETF "investment" 
there a safe bet.

There is a different, longer term question about whether the IETF should 
host its own services in this area. Given the perpetually constrained 
resources of our organization I think that if we can safely "outsource" 
functions where the potential benefits are great, and the risks are 
small, we should do that.

As for the concern about needing to learn how to use revision control 
creating a new barrier to entry for ID authors, at this point it's a 
marginal cost compared to nroff, xml2rfc, etc. You can do everything you 
need to do for something like this with git in 5 or 6 commands. The 
basic instructions for cloning a repo, checking in changes, etc. will 
fit on one sheet of paper (speaking from experience).

We should be doing everything we can to make progress in this area.

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jan 2016 18:34:37 -0500

On Wed, Jan 27, 2016 at 4:51 PM, Doug Barton <[email-masked]> wrote:
> way, nowhere more significantly than in the area of drafts. At this point,
> anything reasonable we can do to improve the situation should be embraced.
>
> Github is well established, and well respected (as others have pointed out
> already). While git is not my favorite VCS, it has the advantage of being
> able to trivially clone the repo, making any IETF "investment" there a safe
> bet.
>
> functions where the potential benefits are great, and the risks are small,
> we should do that.
>
> need to do for something like this with git in 5 or 6 commands. The basic
> instructions for cloning a repo, checking in changes, etc. will fit on one
> sheet of paper (speaking from experience).
>

I find git a pain in the patootie. Every revision control system I
have ever used has had severe code NAZI issues. Git periodically gets
terminally confused and the only solution seems to be to blow
everything up.

No, you don't have to learn xml2rfc either. I haven't used it in ten
years. I moved to HTML, then people suggested Markdown instead so I
did that and then I found a package that extracts everything I want
from Word documents.

If the tools were really first class and well designed, I would have
no problem recommending people use them. But these are not tools I use
except on sufferance.

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 27 Jan 2016 21:30:07 -0800

Just a quick FYI, for those people out there who thought that I was being unrealistic and/or alarmist:

	http://www.theregister.co.uk/2016/01/28/github_outage/

Regardless of what protocols (‘git’ or otherwise) the IETF decides to use for document management, we should be using our own servers for this - not those belonging a third party.  We need to be confident that this is going to survive the next recession :-) :-(

	Ross.

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Jan 2016 01:23:08 -0700

> Regardless of what protocols (‘git’ or otherwise) the IETF decides to use for document management, we should be using our own servers for this - not those belonging a third party.  We need to be co…

github is down because of a massive DDOS attack from China. The details
are online. If anyone needs, I can locate the information again and post it.

Anyone, including the IETF could be the subject of a DDOS attack. So, in
this instance, the real problem is not because its a outside server.

--

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Jan 2016 09:57:20 +0100

> Regardless of what protocols (‘git’ or otherwise) the IETF decides to use for document management, we should be using our own servers for this - not those belonging a third party.  We need to be co…

Actually, what we really need is a plan B in case plan A folds.

For the git repositories themselves, the DVCS principles allow work to
continue nearly unimpeded in an outage, and make a switchover nearly
trivial once necessary (e.g. by putting the repos up in an IETF gitlab
instance, which can even be done as a regular precaution).  For me that
is the reason this even can be considered.

The bigger problem is the value-add in the form of proprietary web-based
workflows that github adds to the mix, such as the issue lists with the
discussions, the information around pull requests, the CI integration
etc.  We need to have backup strategies for
-- the relevant data themselves (data export),
-- the skills that the IETF people have acquired employing those workflows.

Ultimately, the latter is probably the bigger problem.

Committing some work to github workflows (or any other external
DVCS-based workflow with proprietary extensions) is a decision not to be
taken lightly, but with the right backup strategies it does not have to
end in disaster.

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Jan 2016 14:24:32 +0200

Benson,

> It seems to me that it would be inefficient for the IETF to do everything ourselves.

I share the original concern, but Benson has hit a key point here. We are a part of the ecosystem, and while the technology that we produce at the IETF is very much “bottom of the stack”, this isn’t necessarily the case for the tools that we use for our discussions, document sharing and other activities. There’s a wealth of collaboration tools where it is simply more effective to use what the rest of the world uses. Not so much because of possible costs, but because it is easier to use tools that are widely available.

But of course, the devil is in the details. It is important to what extent we retain control, how IETF participants get sufficient ability to choose their own tools, we have originals&information to switch other systems or as backups, etc. To take a non-github example, we share some of IETF material as YouTube videos, but we retain the original video files.

Dave,

> The topic, here, is collaboration.  That is, the activity of developing an I-D by a group.  So it only needs to be useful today.  It doesn't have to be useful tomorrow.  As noted, this is about an integrated service, not just a technology.

Right

> ps. With respect to archiving, the IETF in fact does not do museum-level long-term protection of its data.  Nor should it.  But it /should/ plug its output into a place that does. Museum-quality archive is an entirely different animal from daily crash protection, which of course the IETF does do.

Heather can talk you about that; we have made some progress in doing just that.

John,

> xml2rfc a requirement rather a useful optional tool.

What were you thinking here, specifically? Many of us work on xml2rfc, but we do indeed allow any working style as long as you can output text and submit that, for instance. If that is not the case for everything then maybe there’s an improvement opportunity.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Jan 2016 13:55:45 +0100

Jari,

I have no conceptual problem with github being used for draft
development or being integrated in our tools process for state changes,
or archiving of discussions, but I would maintain strong objections to
any approach that would lead to bifurcation of discussion on a topic. 
That is- the technology and our relationships with those providing the
service should be conducive to a single integrated conversation on a topic.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Jan 2016 05:31:35 -0800

On 1/28/2016 4:24 AM, Jari Arkko wrote:
>> >ps. With respect to archiving, the IETF in fact does not do museum-level long-term protection of its data.  Nor should it.  But it/should/  plug its output into a place that does. Museum-quality archive is an entirely different animal from daily crash protection, which of course the IETF does do.

Jari,

Yes, I've heard that Heather is indeed pursuing long-term archival for RFCs.

That's good, but not sufficient.  That series is a tiny fraction of the 
material that should be preserved according to museum-quality standards.

The IETF community produces very large quantities of other material, 
including Internet Drafts, mailing list messages, and web pages.

All of these also should be preserved.  Folk doing research need source 
materials about processes, not just (successful) results.

d/

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Jan 2016 14:17:08 +0000

> -- the relevant data themselves (data export),

Regarding this I recently found out about
https://github.com/joeyh/github-backup

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Southwesterly becoming cyclonic, 5 or 6, increasing 7 to
severe gale 9 later, perhaps storm 10 later. Very rough or high. Rain or
wintry showers. Moderate or poor, occasionally good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Jan 2016 09:33:32 -0500

There are really two separate issues:

1) Use of git protocol
2) Use of github

These are two separate issues. The second requires the first but not vice versa.

A DDoS against Github or IETF doesn't actually worry me too much
because the basic git protocol is pretty resistant to DoS. If one repo
is down, use another. The repos will sync anyway. I am now using
Github and Sourceforge for git hosting.

The trickier part is the non git part of the infrastructure. The
ticketing, the wikis, etc. Quite a few WGs are using those and I think
we have a real problem - that collaboration is not clearly within the
scope of Note Well for a start.

I would like to see IETF take these functions in house for a number of
reasons. First I think it important that IETF have visibility of the
entire conversation. But secondly, I would like to see us innovate on
top of git.

To do the archive job properly, we should construct an append only
archive log of all IETF activity and checkpointing the log on an
hourly basis using a hash chain that is then cross notarized with
other chains (Certificate Transparency, BlockChain, etc).

Git and SSH also need serious work. The current realization is really,
really kludgy. Configuring a repo to take an SSH key today requires
cut and paste of the keys themselves. That is really annoying when you
are using RSA2048 and not going to be that much better with Curve448.
If we eat the damn dogfood it might persuade us that it would be
tastier if the protocol allowed fingerprints of keys to be used
everywhere and pushed out the actual key in the protocol.

I would also like to see git re-architected to use a proper hash
function and to sign the repo data rather than just hash it. Further,
it should be easy for developers to maintain separate keys on every
device they use. The reason for that is that we are starting to see
attacks on open source projects as a vector for injecting backdoors.
And current practice doesn't necessarily mean we know for sure whose
account was the source of the bogus data or which machine. The most
likely attack vector is that the attacker targets a contributor to a
project and compromises one of their machines. Laptops and other
mobile devices tend to be more vulnerable than desktops.

No, this isn't necessarily our core interest but this is the place
where we have the necessary expertise. And getting a handle on the
source code maintenance chain is going to be an essential part of any
plan to secure the network as a whole.

---

From: Theodore V Faber <[email-masked]>
Date: Thu, 28 Jan 2016 15:22:03 +0000

On 1/28/16, 05:31, "ietf on behalf of Dave Crocker" <[email-masked]

>material that should be preserved according to museum-quality standards.

Museum quality is a pretty high bar.  I would prefer that the IETF
preserve materials to the extent we need to do our work, and let
historians and curators decide what (if anything) is worth preserving at
higher quality and reliability.

I recognize difference of opinion on the matter.

>including Internet Drafts, mailing list messages, and web pages.

It seems to me that I-Ds are an interesting case.  They are a series of
documents whose stated purpose is to be ephemeral in order to promote
exchange of half-formed ideas.  Preserving them for the ages seems to
undermine that intent.

I understand that ship may have sailed, though, given the number of places
one can find archived I-Ds on the ‘net.

-- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Jan 2016 08:23:45 -0800

Ted,

On 1/28/2016 7:22 AM, Theodore V Faber wrote:
> Museum quality is a pretty high bar.

Indeed it is, which is why I've been careful to label the task so 
specifically.

> I would prefer that the IETF

Essentially, that reduces to requiring that future researchers act now 
to preserve ephemeral IETF materials that they might wind up needing.

That, of course, isn't going to happen.

> exchange of half-formed ideas.  Preserving them for the ages seems to

The confusion on this is mixing 'status' with 'availability'.  The fact 
that a document is no longer considered active does not mean that it 
should become inaccessible.

And indeed, that's the reason I-Ds remain available after the time out.

The same point should apply to all public IETF materials, IMO.

The materials are likely to become useful to future researchers.  But we 
cannot expect current researchers to do the archival work now, in 
anticipation of those needs.  The responsibility for helping those folk 
in the future lies with the IETF community itself, now.

d/

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Jan 2016 09:02:23 -0800

Eliot,

> On Jan 28, 2016, at 4:55 AM, Eliot Lear <[email-masked]> wrote:
> 
> Jari,
> 

To say this another way, using github (or other collaboration tools) is great for authors or a design team to work together to develop an Internet draft.  I do this myself.  I think the dividing line is that drafts should continue to be submitted via the datatracker as they are now and working groups be using the datatracker to do their work.  I would be very concerned if working groups started to do their work outside of the datatracker.

Bob

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jan 2016 19:52:35 +0100

> higher quality and reliability.

+1.  For example, I cannot find this on IETF's site:
https://web.archive.org/web/20070707120539/http://tools.ietf.org/html/draft-ietf-drums-smtpupd-00

Historians and curators may need incentives or coordination.  See:
https://archive.org/about/faqs.php#Archive-It

Ale

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jan 2016 08:15:30 +1300

> https://web.archive.org/web/20070707120539/http://tools.ietf.org/html/draft-ietf-drums-smtpupd-00

Then you didn't look in the right place:

https://tools.ietf.org/id/draft-ietf-drums-smtpupd-00.txt

However, there are missing I-Ds from 1994 or earlier, from the days when
ftp was the only method and expired drafts were taken off line immediately.
The Wayback machine also only goes back so far.

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Jan 2016 14:31:53 -0500

I have noticed that when the term 'museum quality' is used in this
type of discussions it usually ends up meaning 'apply some unknown and
unknowable criteria that purport to ensure that the data will be
readable when the planet fries to a crisp when the sun expires'.

Museums don't have any experience of keeping digital documents for a
century. Most have people who have considered the problem but so have
we. This is not an area where it makes sense to defer to the opinions
of unspecified experts in another field. It is one thing if we have
someone from that community with ideas who can engage and assist. But
deferring to the opinions of unspecified experts is quite another.
Deferring to the opinions of unspecified experts as recounted second
hand is worse still.

For example, an objection that was repeatedly raised against changing
the RFC format was the fear that future generations might forget how
to read HTML (or whatever). There are certainly some in the museum
archive community that raise that as a concern. But I don't think you
will find anyone in that community who would say that it is an
insurmountable one.

Right now there are people who are recovering all the CEEFAX data that
was broadcast on the BBC and ITV from old VHS tapes. This is quite a
feat as the tapes are not designed to provide the necessary bandwidth.
But people are doing reasonably well at it even so.

In short, just work out ways to preserve the bits. If you keep the
bits you can be reasonably confident that the technology will be there
to read them. For IETF purposes, keeping the bits means making sure
that all the data is backed up in multiple physical locations in ways
that ensure that it is highly unlikely that a common failure (or
attack) would compromise all of them.

Put in those terms, this looks like a networking problem to me.

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 28 Jan 2016 11:38:13 -0800

> On Jan 28, 2016, at 9:02 AM, Bob Hinden <[email-masked]> wrote:
> 

Agreed.  It’s also worth noting that any addition to a document - made in a ‘shared document repository’ that's available to the working group as a whole - is quite clearly an “IETF Contribution” as defined by RFC 3979.  We need to be sure that all such edits - including any subsequent deletions or modifications of added text - will get recorded in an ‘audit trail’, and can be made available in response to a subpoena.

There are people out there who think that I’m “stuck in the '90s” (yes, people’s IETF-related postings to social media are publicly-searchable; you live by the sword, you die by the sword :-), but there are real dangers if we start allowing collaborative work within IETF working groups to be conducted using third-party services.

	Ross.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 28 Jan 2016 20:41:11 +0100

On 28 Jan 2016, at 20:31, Phillip Hallam-Baker <[email-masked]> wrote:

> readable when the planet fries to a crisp when the sun expires’.

While the details vary from country to country - I guess that for the purposes of this discussion it is a useful term.

Dw.

PS: If you are curious (it is quite a profession & specialisation - with, like the IETF, an associated
      body of international experts collaborating and meeting in far flung places): 

	http://www.digitalpreservation.gov

is a good starting point for the US - specifically the normative resources on preservation standards.

	http://www.worldcat.org/title/long-term-preservation-of-digital-documents/oclc/262692324

is a fairly well known/neutral baseline.  The standards in europe, the UK and Asia are pretty much identical.

---

From: "John Levine" <[email-masked]>
Date: 28 Jan 2016 19:44:20 -0000

>to read them.

This probably seems pretty retro, but a good way to do that is to
print them out.  We know how to make quality paper that is stable for
centuries, and since the pigment in black laser toner is usually
carbon black, it's unlikely to fade.  You could print some sort of bar
code for binary stuff but for text, printing the text should be fine
since OCR is unlikely to disappear, and that makes it a lot easier for
future librarians to tell what it is they're looking at.

If we're archiving audio or video recordings, I concede that bar code
on paper would be bulky.  At this point the state of the art seems to
be to record it several times on whatever media seem like a good idea
today, and recopy them every decade.

R's,
John

---

From: Theodore V Faber <[email-masked]>
Date: Thu, 28 Jan 2016 19:50:13 +0000

>That, of course, isn't going to happen.

I’m curious what our goals are.  Are we trying to preserve the historical
record of this august body, or capture as complete a record as possible of
our meaningful accumulated professional knowledge, or something else?

There are not many fields who try to preserve an accurate historical
record.  (Meaning that I can’t think of one - even museum curators are not
required to curate their own working notes.)

My understanding is that historians expect both losses and obfuscation.
Governments are both obsessive hoarders of decision making documents and
distorters of the historical record.

If we’re preserving the knowledge, it’s not clear to me that museum
quality is required.  The process of doing work and being cited seems to
provide a natural winnowing and rating process.  I know I’ve sent e-mails
to this list that have not contributed to the progress of this field, and
I believe they’ve mostly been forgotten.  To the extent that anything in
our modern world is.

>And indeed, that's the reason I-Ds remain available after the time out.

Yeah, and I seem to recall some kind of rathole/vortex around what the
original intent of I-Ds was vs. what they are today.  I’ll stipulate the
position above rather than head anywhere near that.

>in the future lies with the IETF community itself, now.

Future networking researchers or future historians?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Jan 2016 14:59:40 -0500

I am sure the future historians would be much happier if we simply had
someone do interviews with current collaborators and find out what
they are up to.

Looking at the digital detritus is another dimension to the record of
course. But that only captures what people did, not why they did it.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jan 2016 17:32:39 -0500

> Github and Sourceforge for git hosting.

Agreed.

My "yeah but" on your proposal is that we should do something smaller.

Update datatracker to include a pointer to a URL where the archive of the
draft can be mirrored.   Have the IETF git pull it.

Whether or not we make that available by default someplace is secondary, the
point is to archive it.    That's a simple first step, and maybe it would
help with our blue-sheet equivalent.

The issues are another question, I believe that they can be retrieved by
RESTful interface from github, but I would not be surprised if they also live
in a magic git repo :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Jan 2016 15:29:01 -0800

On 01/27/2016 03:34 PM, Phillip Hallam-Baker wrote:
> I find git a pain in the patootie.

I'm not sure how to respond to that. :)

> Every revision control system I
> have ever used has had severe code NAZI issues.

I seriously don't know how to respond to this, as I have no idea what 
you mean here.

> Git periodically gets

Yes, git comes with a fully loaded, semi-automatic, foot-shooting gun. 
That's why it's not my favorite VCS.

That said, I have twice now successfully created and administered git 
repos which were aimed at people who are reasonably smart and 
technically proficient, and who had no previous experience with a VCS. A 
key element of our success was to publish clear instructions with the 
minimal command set that 99% of our users needed to do their jobs. 
Anyone venturing off-script was warned that they would not be supported, 
and would be responsible for cleaning up their own mess.

If I were creating a system for IETF I'd choose subversion instead of 
git, since it is in many regards simpler, and significantly less likely 
to succumb to "creativity" for the simple reason that there are 
dramatically fewer knobs to twist.

> did that and then I found a package that extracts everything I want

I think you missed my point, which was that ID authorship already comes 
with a choice of toolchain ... there is already a learning curve 
associated with it. The marginal cost of adding a VCS to that is small.

But requiring users to 'do' the VCS isn't our only option. If all we did 
was have the tracker check in the latest revision when submitted it 
would make so many things easier. I can elaborate if desired for anyone 
who isn't a software developer who hasn't experienced the many benefits 
of a modern VCS.

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Jan 2016 15:37:00 -0800

> 	http://www.theregister.co.uk/2016/01/28/github_outage/

It was reported on NANOG that this was the web interface only. The ssh 
interface (which is what developers use to actually update their repos, 
push changes, etc.) was still working.

It's also worth noting for those that are not familiar with git that one 
of its strengths is that you can trivially clone the repository itself, 
and work locally from your cloned copy. So the only thing that actually 
wasn't working was the ability to see things on the web, and the ability 
for folks to push their latest updates to github itself. Users who were 
taking advantage of git's distributed features would still have been 
able to share updates with each other.

> Regardless of what protocols (‘git’ or otherwise) the IETF decides to use for document management, we should be using our own servers for this - not those belonging a third party.  We need to be co…

I have no objection to us doing this in-house. What I do object to is 
continued inaction. For example an organized pilot program taking 
advantage of an "outsourcing" opportunity like github could bring 
tremendous insight and valuable operational experience; which could be 
used to formulate a longer-term plan (whether that ultimately is 
in-house or not).

Doug

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jan 2016 15:52:31 -0800

> position above rather than head anywhere near that.

IMO the confusion lies with the concept of "ephemeral" vs. "but I
*really* want it, even though I should have no right to it", which led
to a redefinition of the concept of "ephemeral" as it applies to IDs.
See below...

> Future networking researchers or future historians?

Or future litigation?

The redefinition of IDs in particular was driven by a concern that these
documents might be particularly useful in disproving patent claims.

I still firmly believe it remains a disservice to the community to have
changed the concept of ID expiration for the primary benefit of lawyers.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jan 2016 15:55:03 -0800

> The Wayback machine also only goes back so far.

Some IDs were written before the IETF asserted its right to archive and
provide access to them indefinitely through copyright transfer.

The original authors had the right to prohibit distribution of that
material, and some (myself included) have asserted that right
vigorously. I.e., it's not merely a matter of what was "lost" but also
"who has the right".

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jan 2016 13:10:53 +1300

> course. But that only captures what people did, not why they did it.

Oral history interviews are indeed a valuable resource, but they complement
(or contradict) the written record rather than replace it.

The problem future historians will have with the IETF (and the W3C, and ITU-T,
and ETSI, you name it) is probably not too little information, but the opposite.
When you work on the early history of electronic computing, or even the early
history of networking, there isn't actually a shortage of material and a lot
of it is on the web. But it's finite, because it depends on what was considered
worth keeping on paper in the 1940s-1960s. You can find pretty much everything
technical that Alan Turing wrote, but you can't find his shopping lists. For
more recent events (just take the IPng selection process as an example) you can
find more than any historian of IPng could ever want.

What I want to say is this: Archiving too much is just as bad as archiving
too little, from the future historian's point of view.

That's not to say that we shouldn't consider long-term archiving, but an
important aspect is deciding what not to archive.

    Brian

---

From: Theodore V Faber <[email-masked]>
Date: Fri, 29 Jan 2016 01:01:33 +0000

>to a redefinition of the concept of "ephemeral" as it applies to IDs.

Absolutely not.

This is me, going the other direction at Warp 9.8.

---

From: Randy Fischer <[email-masked]>
Date: Thu, 28 Jan 2016 20:34:37 -0500

Hmm.  I'm a little late to the party here.

On Thu, Jan 28, 2016 at 11:23 AM, Dave Crocker <[email-masked]> wrote:

> The confusion on this is mixing 'status' with 'availability'.  The
> fact that a document is no longer considered active does not mean
> that it should become inaccessible.

That's a great point; in fact, there are digital preservation folks
that champion dark archives, but my experience with them is that
they get full of cruft - when an archive is accessible then omissions,
repetitions, truncations etc. are more likely to be recognized and
corrected.

> Essentially, that reduces to requiring that future researchers act
> now to preserve ephemeral IETF materials that they might wind up
> needing.
>

Typically, digital preservationists require three or more copies, with
checksums, that are independently maintained (different administrators
and software suites), each with institutional plans for how materials
would be migrated if the institution fails.

> bits you can be reasonably confident that the technology will be there

Sadly, this is not the case - there's a recent podcast from 'On The
Media' that Interviews Vint Cerf among others about digital
preservation.  It's tricky.

You need to keep a bit of metadata, even for simple text files.  Here
are some encodings you can run into:

   $ iconv -l  | wc -w
     1173

However, that being said, IETF doesn't really have much in the way of
binary data (word perfect files, spreadsheet data, etc).

For the IETF data,, it's mostly about making sure the bits are periodically
migrated to up-to-date media.

On Thu, Jan 28, 2016 at 6:55 PM, Joe Touch <[email-masked]> wrote:

> vigorously. I.e., it's not merely a matter of what was "lost" but
> also "who has the right".

There are techniques for this among archivists, they can put embargoes
on the documents they archive.

An embargo can be open-ended, or it can have an explicit expiration date.

On Thu, Jan 28, 2016 at 7:10 PM, Brian E Carpenter <
[email-masked]> wrote:

> What I want to say is this: Archiving too much is just as bad as
> archiving too little, from the future historian's point of view.
>
> That's not to say that we shouldn't consider long-term archiving, but
> an important aspect is deciding what not to archive.

Well, the archivists have this saying: only 10% of what we archive is
ever of any use.  But we have no idea which 10%.

You might have language scholars studying this stuff, as well as
the expected technologists and social scientists.  Or next century's
version of post-modernists looking at g*d-knows-what.

Thanks for your attention.

-Randy Fischer

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jan 2016 15:17:06 +1300

On 29/01/2016 14:34, Randy Fischer wrote:
...
> ever of any use.  But we have no idea which 10%.

10% would be a fabulously good result for on-line material. Reality
is more like 0.1% if you look at what's already out there. I am not sure
that archivists have come to grips with this yet.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 29 Jan 2016 02:18:35 -0000

>vigorously. I.e., it's not merely a matter of what was "lost" but also

Given the history of the broad no-charge distribution of I-D's, should
anyone be so benighted as to try to take this to court, the issues
under 17 USC 107 and 17 USC 108 would be quite interesting.  (Yes, I
know those are US laws, but the IETF and ISI are both in the US.)

Have you registered the copyrights in these valuable documents?

R's,
John

---

From: <[email-masked]>
Date: Fri, 29 Jan 2016 05:33:33 +0000 (UTC)

> there's a recent podcast from 'On The 
> preservation. 

Couldn't find it.

Shrug.

________________________________
From: Randy Fischer <[email-masked]>
To: ietf <[email-masked]> 
Sent: Friday, 29 January 2016, 12:34
Subject: Re: long-term archiving

   $ iconv -l  | wc -w
     1173

-Randy Fischer

---

From: <[email-masked]>
Date: Fri, 29 Jan 2016 05:36:28 +0000 (UTC)

Registering US copyrights hasn't been necessary since 1978.

Berne Convention, rest of planet, etc.

 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: John Levine <[email-masked]>
To: [email-masked]
Sent: Friday, 29 January 2016, 13:18
Subject: Re: long-term archiving

R's,
John

---

From: Randy Fischer <[email-masked]>
Date: Fri, 29 Jan 2016 00:46:24 -0500

> Couldn't find it.

I think google can help with that:

http://www.onthemedia.org/story/vint-cerf-and-our-uncertain-digital-future/

---

From: "John R Levine" <[email-masked]>
Date: 29 Jan 2016 00:55:33 -0500

> Registering US copyrights hasn't been necessary since 1978.

Under US law, for unregistered works, you can only sue for actual damages 
and the infringer's profits attributable to the intfringement, which for 
an I-D would be pretty hard to show.

Once they're registered, you can sue for statutory damages which can be 
substantial.  See 17 USC 504.

Regards,
John Levine, [email-masked], Junior Lawyer 2nd class
Please consider the environment before reading this e-mail.

---

From: Tony Finch <[email-masked]>
Date: Fri, 29 Jan 2016 11:29:17 +0000

John Levine <[email-masked]> wrote:
> carbon black, it's unlikely to fade.

The worry with laser printers is adhesion of the toner to the paper, e.g.
http://www.naa.gov.au/records-management/agency/preserve/physical-preservation/photocopies-and-laser-prints.aspx

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Southwesterly gale 8 to storm 10,
occasionally violent storm 11 in Viking. Rough or very rough, becoming high or
very high. Rain then wintry showers. Good, occasionally poor.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Jan 2016 15:11:50 +0100

Hi Bob,

All the way down...

> To say this another way, using github (or other collaboration tools) is great for authors or a design team to work together to develop an Internet draft.  I do this myself.  I think the dividing li…

Yes, and. Discussion of technical issues should remain normatively
within a single platform.  If we want that to be github, okay. But today
it's email.  Doing both would at first glance sound like reaching out to
people who prefer different modes of communications, but at the end of
the day proves quite difficult for those who are actually trying to keep
track of multiple threads in a conversation.  Also, any platform should
be able to support our processes, particular those that help us address
abuse.

Eliot

---

From: Jim Gettys <[email-masked]>
Date: Fri, 29 Jan 2016 09:53:18 -0500

As to how to digitally preserve bits in a fully reliable way, with
geographic backup and access, used widely in the library community, look at:
http://www.lockss.org/

It is a pretty much solved problem, at least at the scale of anything the
IETF does, and the technological problems and challenges in preservation
are more subtle than most understand.

Dave Rosenthal is the expert....
                               - Jim

---

From: Theodore V Faber <[email-masked]>
Date: Fri, 29 Jan 2016 15:44:10 +0000

>> Media' that Interviews Vint Cerf among others about digital

I suspect you’re making a joke as the Google-Fu needed to locate the
episode was minimal, but just to save some typing:

Transcript:

transcript/

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 29 Jan 2016 10:44:33 -0500

The IETF’s primary collaborative tool is email. Right now it’s very easy to
find the email archive for any WG, and to come up to speed on the WG
discussion. This would be much more difficult if WGs used github or other
third party tools for discussions that might otherwise have used the WG’s
email list. Any public discussions regarding WG business should remain on
the current email lists unless and until they are formally replaced or
augmented so that people still only have to go to one place to stay current
with WG discussions. I don’t mind an eventual replacement of email lists
for WG business, as long as the change is formal, supported, and consistent
across all WGs.

And stay off of my lawn!

Curmudgeonly yours,
Andy

On Fri, Jan 29, 2016 at 9:11 AM, Eliot Lear <[email-masked]> wrote:

> > To say this another way, using github (or other collaboration tools) is
> great for authors or a design team to work together to develop an Internet
> draft.  I do this myself.  I think the dividing line is that drafts should
> continue to be submitted via the datatracker as they are now and working
> groups be using the datatracker to do their work.  I would be very
> concerned if working groups started to do their work outside of the
> datatracker.
> >
>

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 29 Jan 2016 11:28:29 -0500

I've changed the To: to point to the ietf-and-github@ mailing list for this
discussion, and moved the ietf@ list to a BCC: header for this message. I
think it's more appropriate for talking about this specific issue...
-Benson

On Fri, Jan 29, 2016 at 10:44 AM, Andrew G. Malis <[email-masked]> wrote:

> The IETF’s primary collaborative tool is email. Right now it’s very easy
> to find the email archive for any WG, and to come up to speed on the WG