Subject: Should IETF stop using GitHub?

From: Stewart Bryant <[email-masked]>
Date: Mon, 29 Jul 2019 16:58:33 +0100

This report suggests to me that the IETF should move its work off GitHub 
so that we own our own decision on who can and cannot take part in our work.

https://eandt.theiet.org/content/articles/2019/07/github-restrictions-introduced-to-comply-with-us-sanctions

- Stewart

---

From: Michael StJohns <[email-masked]>
Date: Mon, 29 Jul 2019 12:12:10 -0400

On 7/29/2019 11:58 AM, Stewart Bryant wrote:
>
> This report suggests to me that the IETF should move its work off 
> GitHub so that we own our own decision on who can and cannot take part 
> in our work.
>
I'm not the biggest fan of using Github in IETF work, but fair is fair.  
Read the article.   The gist is that "commercial" accounts and private 
repositories associated with Crimea (Russian occupied Ukraine), Cuba, 
North Korea, Iran and Syria or their persons are restricted due to trade 
laws.   AFAICT from the article, there is no restriction on these people 
using public repositories and contributing to open source activities 
such as the IETF.

So let's not go non-linear here.

More complete info is here - 
https://twitter.com/natfriedman?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1155311122137804801&ref_url=https%3A%2F%2Feandt.theiet.org%2Fcontent%2Farticles%2F2019%2F07%2Fgithub-restrictions-introduced-to-comply-with-us-sanctions%2F

Mike

---

From: Leif Johansson <[email-masked]>
Date: Mon, 29 Jul 2019 18:17:09 +0200

Skickat från min iPhone

> 29 juli 2019 kl. 18:12 skrev Michael StJohns <[email-masked]>:
> 
>> This report suggests to me that the IETF should move its work off GitHub so that we own our own decision on who can and cannot take part in our work.
>> 
> I'm not the biggest fan of using Github in IETF work, but fair is fair.  Read the article.   The gist is that "commercial" accounts and private repositories associated with Crimea (Russian occupied Ukraine), Cuba, North Korea, Iran and Syria or their persons are restricted due to trade laws.   AFAICT from the article, there is no restriction on these people using public repositories and contributing to open source activities such as the IETF.
> 
> More complete info is here - https://twitter.com/natfriedman?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1155311122137804801&ref_url=https%3A%2F%2Feandt.theiet.org%2Fcontent%2Farticles%2F2019%2F07%2Fgithub-restrictions-introduced-to-comply-with-us-sanctions%2F
> 
> Mike
> 

fwiw I read it the same way & agree.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 29 Jul 2019 18:32:09 +0000

I may suggest we not rush to judgment. US compliance & export controls is part of any org operating from US, including ISOC and the IETF LLC. The IETF LLC's responsibility here is touched on in 11.a.viii of the agreement with ISOC (https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf). See also the draft IETF LLC Code of Conduct, Sanctions section at (https://github.com/ietf-llc/policies-consultation/blob/master/Code-of-Conduct-00.md). 

Jason 

On 7/29/19, 11:59 AM, "ietf on behalf of Stewart Bryant" <[email-masked] on behalf of [email-masked]> wrote:

    
    - Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2019 08:30:11 +1200

The IETF rule is still that consensus is established on the mailing list, so it's clear that what happens on GitHub is not definitive - it's just a tool, which we can use for convenience as long as it remains convenient.

Regards
   Brian

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jul 2019 15:57:38 -0500

On Mon, Jul 29, 2019 at 12:12:10PM -0400, Michael StJohns wrote:
> repositories associated with Crimea (Russian occupied Ukraine), Cuba, North
> Korea, Iran and Syria or their persons are restricted due to trade laws.  
> AFAICT from the article, there is no restriction on these people using
> public repositories and contributing to open source activities such as the
> IETF.
> 

+1

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Jul 2019 10:02:07 +0200

Le 29/07/2019 à 17:58, Stewart Bryant a écrit :
> GitHub so that we own our own decision on who can and cannot take
> part in our work.
> 

Thanks for the article, it is good to know.

> Should IETF stop using GitHub?

Another reason I complained once about github use at IETF is
its lack of IPv6 access.  I dont know whether that changed recently.

(I do use github for other professional matters).

Alex

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 30 Jul 2019 14:14:41 +0200

On 29 Jul 2019, at 22:30, Brian E Carpenter wrote:

> The IETF rule is still that consensus is established on the mailing 
> list, so it's clear that what happens on GitHub is not definitive - 
> it's just a tool, which we can use for convenience as long as it 
> remains convenient.

A git repo is IMO useful for many things in IETF/IRTF work processes 
(version control, collaborative editing, project directory 
synchronization, issue tracking etc.). In the groups I am co-chairing, I 
haven’t used GitHub.com as much as we possibly could have, because we 
didn’t want to introduce too many dependencies on IETF-external 
platforms.

If we think it’s generally useful (I think it is), should we consider 
including a self-maintained gitlab server in the tools collections (and 
use the data tracker login for that)?

Dirk

>> I may suggest we not rush to judgment. US compliance & export 
>> controls is part of any org operating from US, including ISOC and the 
>> IETF LLC. The IETF LLC's responsibility here is touched on in 
>> 11.a.viii of the agreement with ISOC 
>> (https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf). See also 
>> the draft IETF LLC Code of Conduct, Sanctions section at 
>> (https://github.com/ietf-llc/policies-consultation/blob/master/Code-of-Conduct-00.md).
>>
>> Jason
>>
>> On 7/29/19, 11:59 AM, "ietf on behalf of Stewart Bryant" 
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>
>> GitHub

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 30 Jul 2019 12:58:21 +0000

>    If we think it’s generally useful (I think it is), should we consider 
    including a self-maintained gitlab server

Or someone could talk to github about donating an on-premise instance.

In either option, bringing it in-house greatly reduces the benefit of being visible to non-IETF'ers, which is (per the thinking of WUGH the BoF, etc) a major goal.  I'd say reduces it to basically zero, but YMMV.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jul 2019 09:25:21 -0400

Also, the IETF would have to follow the same rules github has to follow. 

Sent from my iPhone

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 30 Jul 2019 13:46:20 +0000

>    Also, the IETF would have to follow the same rules github has to follow. 
 
As a US entity, it has to anyway.  Bringing it on-prem doesn't mean we take on additional requirements.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Jul 2019 06:54:20 -0700

On 7/30/19 5:14 AM, Dirk Kutscher wrote:
> A git repo is IMO useful for many things in IETF/IRTF work processes (version control, collaborative editing, project directory synchronization, issue tracking etc.). In the groups I am co-chairing, I haven’t used GitHub.com as much as we possibly could have, because we didn’t want to introduce too many dependencies on IETF-external platforms.
> 
> If we think it’s generally useful (I think it is), should we consider including a self-maintained gitlab server in the tools collections (and use the data tracker login for that)?
> 

+1, if only because then the IETF will be able to keep in its archives most of the discussions (including the ones that happened outside the mailing-lists) related to the creation of a standard, for IPR purposes.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jul 2019 14:58:59 +0100

> As a US entity, it has to anyway.  Bringing it on-prem doesn't mean we take on additional requirements.

Well that in turn begs the question of whether IETF should remain a US 
entity, or become an entity of a country that an official position of 
neutrality.

- Stewart

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Jul 2019 07:18:35 -0700

> On Jul 30, 2019, at 1:02 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Not as far as I can tell.  I can’t ping it with IPv6, nor does https://github.com/ work with IPv6.

I think that all IETF tools should support IPv6.  For personal use, I don’t care, but if the IETF is developing tooling that integrates with github, I think that is a big problem.

Bob

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 08:08:15 -0700

> Or someone could talk to github about donating an on-premise instance.

git != github

git-with-gooey ⊇ github

e.g. i use gogs, https://gogs.io/

randy

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 30 Jul 2019 19:06:32 +0200

> e.g. i use gogs, https://gogs.io/

Right, I was mentioning gitlab — as an example for a non-github git 
platform that can be self-hosted and that people use productively, but 
there are others of course.

Dirk

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Jul 2019 12:21:24 +1000

On Wed, Jul 31, 2019, at 03:07, Dirk Kutscher wrote:
> a non-github git platform that can be self-hosted and that people use productively

The reasons to use GitHub aren't limited to hosting of git repositories.

Foremost is the low friction for contributions, which is made possible by having a large, existing community of people with accounts and knowledge of the system.  There are also other advantages, like support for continuous integration services.

This isn't to say that other services aren't useful, and I wouldn't dare suggest that other people can't use those tools, but they are not sufficient for my ends.  Even if significant investment of time and money bring another service up to the same level of quality, a community can't be bought in the same way.  So, v6 or not, I'll stick with GitHub.

---

From: George Michaelson <[email-masked]>
Date: Wed, 31 Jul 2019 12:24:26 +1000

I beieved we had an exclusion from the order, because international
standards were understood to be a higher goal. If in fact, the current
US administration wants to politicize access to technology facing
standards development and exclude nation-states I think we have a
bigger problem.

Can IETF not find a git backed engine in a Jurisdiction less likely to
accede to this (IMNSO ludicrous) decision? Are there no viable sources
of reliable, backed up. Gitlabs service hosted in e.g. Geneva, or Dare
I say it, Ireland, or perhaps even Russia?

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Jul 2019 12:33:14 +1000

> I say it, Ireland, or perhaps even Russia?

As a DVCS, git offers us many of the tools we need for business continuity in the case the GitHub service is no longer able to provide service.  Source of documents (and their history) is preserved in every copy of the repository, even if we can no longer benefit from some of the more advanced features.

But this is more a matter for draft-ietf-git-github-wg-configuration, which has a section addressing this specific concern.  That document is under discussion in the git working group.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Jul 2019 09:44:09 +0300

On 2019-7-31, at 5:21, Martin Thomson <[email-masked]> wrote:
> Foremost is the low friction for contributions, which is made possible by having a large, existing community of people with accounts and knowledge of the system.

+100

As someone said earlier in the thread, of course we can stand up our own instance of pretty much anything based on git. But we'd instantly loose the community already on the public platform.

Lars

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Jul 2019 10:21:53 +0200

> I say it, Ireland, or perhaps even Russia?

Do you mean in Russia's autonomous Internet?

Lada

> > Foremost is the low friction for contributions, which is made possible by
> > having a large, existing community of people with accounts and knowledge of
> > the system.  There are also other advantages, like support for continuous
> > integration services.
> > 
> > This isn't to say that other services aren't useful, and I wouldn't dare
> > suggest that other people can't use those tools, but they are not sufficient
> > for my ends.  Even if significant investment of time and money bring another
> > service up to the same level of quality, a community can't be bought in the
> > same way.  So, v6 or not, I'll stick with GitHub.
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 31 Jul 2019 10:43:22 +0200

> As someone said earlier in the thread, of course we can stand up our 
> own instance of pretty much anything based on git. But we'd instantly 
> loose the community already on the public platform.

I can see the benefits of enabling low friction for contributions. It 
just seems that with the recent restrictions that GitHub was forced to 
introduce, the frictions are not quite as low for some parts of the 
community.

You can of course say that this does not matter that much yet in 
practice — IMO it’s prudent for the IETF community to rethink our 
dependencies on external platforms.

Dirk

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Jul 2019 13:01:03 +0200

> As someone said earlier in the thread, of course we can stand up our own instance of pretty much anything based on git. But we'd instantly loose the community already on the public platform.

I don't think this is an issue, as long as Github projects are used primarily as development tools by IETF working groups. In fact, with GitLab it should be possible to use the same authentication service as for, e.g. IETF tools website.

Lada

---

From: Simon Leinen <[email-masked]>
Date: Wed, 31 Jul 2019 13:44:11 +0200

Ladislav Lhotka writes:
>> [...] of course we can stand up our own instance of pretty much
>> anything based on git. But we'd instantly loose the community already
>> on the public platform.

> I don't think this is an issue, as long as Github projects are used
> primarily as development tools by IETF working groups. In fact, with
> GitLab it should be possible to use the same authentication service as
> for, e.g. IETF tools website.

Yes, GitLab supports external authentication via SAML, OAuth, LDAP etc.
This includes GitHub - so it would be easy to (have someone) set up a
GitLab instance that allows anyone with an existing GitHub account on.

Note that there would still a burden on existing GitHub users who'd have
to adapt their workflows.  But at least the "onboarding" part could be
relatively painless.

Multiple authentication sources are supported as well, and a GitLab
account can be linked with multiple identities.  So with a little care
avoiding/cleaning up duplicate accounts, it should be possible to
smoothly move from GitHub-dependent accounts to some other "SSO"-ish
system, e.g. IETF tools accounts.

(We've been running a few GitLab servers for the Swiss academic sector
for several years... not in Geneva, sorry, but in Lausanne and Zurich.
If there's serious interest in setting something up for IETF, contact me
and I can try to work something out with my management.)
-- 
Simon.

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 31 Jul 2019 08:29:44 -0400

On Wed, Jul 31, 2019 at 09:44:09AM +0300, Lars Eggert wrote:
> > Foremost is the low friction for contributions, which is made
> > possible by having a large, existing community of people with
> > accounts and knowledge of the system.
> 
> +100
> 
> own instance of pretty much anything based on git. But we'd
> instantly loose the community already on the public platform.

Git is a distributed system.  As such, the same git repository can
be made available on multiple git servers.  For example:

https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
https://github.com/tytso/e2fsprogs.git
https://repo.or.cz/e2fsprogs.git

Are all mirrors of each other.  So even if/when github.com were to cut
off access to some country, people still have access from the other
two git repos.

Furthermore, *nothing* says that you have to use github's pull
requests as the only way to request changes be made to a git
repository.  You can just as easily send a request that a change be
made to a git repo via:

	git send-email -1 --to=[email-masked]

... and then the document editor can use "git am" to apply e-mail
message to the repository, if she chooses.

Cheers,

					- Ted

P.S.  This is also something individual working groups can do on their
own.  The repo.or.cz site is a public service which charges no fees
(although they do accept donations) in the Czech Republic which, while
part of NATO and the EU, might have somewhat different ideas of
international relations than the Orange Haired One currently gracing
the US White House.

So if an IETF working group has a valued contributor which is getting
blocked by github, an ietf wg chair (or anyone on the working group,
for that matter) could establish a unofficial mirror of the wg's git
repo on repo.or.cz without needing to ask permission from the IESG,
IAB, RSE, RSOC, etc.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2019 08:43:42 -0400

> As someone said earlier in the thread, of course we can stand up our own instance of pretty much anything based on git. But we'd instantly loose the community already on the public platform.

By that logic, IETF should move all of its discussions to Facebook.

IMO it is dangerous for IETF to be dependent on an externally-run 
platform that is subject to change at a whim.

(actually s/IETF/Internet/)

Keith

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Jul 2019 15:15:26 +0200

> off access to some country, people still have access from the other

For the git part, yes. What's more problematic are extra things that are not
replicated, e.g. issues.

> .... and then the document editor can use "git am" to apply e-mail

Well, being a Czech citizen, I wouldn't be so optimistic :-)

However, it is not only about political pressures. A provider of any such
service can cease operation, or change its conditions, policies and pricing. I
think that if such a tool is perceived as important for the IETF community, than
it should be run by the IETF.

Lada

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jul 2019 14:28:49 +0000

Hi,

As far as I know, each WG can decide to use whatever git service, hosted in whatever country, or choose to not use git. And, when making the decision to use a service I assume the WG will take into consideration whether contributors will have access to it (depending on in which country they live etc).

Or am I wrong?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: ietf <[email-masked]> Puolesta Ladislav Lhotka
Lähetetty: keskiviikko 31. heinäkuuta 2019 16.15
Vastaanottaja: Theodore Y. Ts'o <[email-masked]>; Lars Eggert <[email-masked]>
Kopio: [email-masked]
Aihe: Re: Should IETF stop using GitHub?

On Wed, 2019-07-31 at 08:29 -0400, Theodore Y. Ts'o wrote:
> Git is a distributed system.  As such, the same git repository can be 
> made available on multiple git servers.  For example:
> 
> https://protect2.fireeye.com/url?k=d6a0fdb9-8a74f4df-d6a0bd22-8610d8a7
> 62ca-add26f8f2e400655&q=1&u=https%3A%2F%2Fgithub.com%2Ftytso%2Fe2fspro
> gs.git 
> https://protect2.fireeye.com/url?k=4b4ec9c9-179ac0af-4b4e8952-8610d8a7
> 62ca-c63d549d97f5cc61&q=1&u=https%3A%2F%2Frepo.or.cz%2Fe2fsprogs.git
> 

For the git part, yes. What's more problematic are extra things that are not replicated, e.g. issues.

However, it is not only about political pressures. A provider of any such service can cease operation, or change its conditions, policies and pricing. I think that if such a tool is perceived as important for the IETF community, than it should be run by the IETF.

Lada

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2019 11:15:58 -0400

> On Jul 31, 2019, at 10:28 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Perhaps this is currently the case, but should it be?  In other words, should a WG’s leaders be able to impose whatever geographic/political restrictions, software requirements, and privacy violations they wish, based on who they think can and should be able to effectively participate?

To be clear, I’m not accusing anyone. In IETF of malice or impropriety.  But requiring WG participants to use particular software and/or external web services does, in general, have such implications.

I don’t think a WG should be able to impose such requirements.

Keith

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Jul 2019 11:31:45 -0400

I would encourage people with an interest in the topics raised in this thread to review the two WG drafts currently active in the GIT WG:

https://tools.ietf.org/html/draft-ietf-git-using-github-00
https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-01

as well as the minutes from the last WG meeting that describe some planned changes to the documents that have not been made yet:

https://datatracker.ietf.org/doc/minutes-104-git/

Please send comments on the drafts to the [email-masked] mailing list. The drafts discuss topics such as WG decision process to use GitHub, back-up, archival, etc. If people encounter difficulties with restricted access to private repos or paid accounts that affect their ability to participate in IETF WG discussions, it would also be useful to share those experiences with that list (or I’d be fine to learn about them privately if people prefer).

Thanks,
Alissa

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Jul 2019 11:04:08 -0500

On Wed, Jul 31, 2019 at 03:15:26PM +0200, Ladislav Lhotka wrote:
> > [...]

It's easy enough to host issues within a normal Git repo.  In fact,
there are tools out there for doing just that[0].  Typically an issue's
"number" then becomes a commit hash, an abbreviated commit hash, since
there's no easy way to generate sequential issue numbers in Git, but I
think that's quite fine.  Really, each issue can be its own ref, and you
can have one periodically-rebuilt ref to list all known issues so they
are easy to find.

One can even run such a Git-based issues system even while using GH/GL/
whatever, and one could even have a bi-di issues sync with the GH issues
so as to still be able to use the GH BUI while being able to access
issues via Git alone and w/o reference to the GH APIs or BUIs.

Wikis too can be hosted inside Git, as can web pages.  Indeed, GitHub
does that for both.  Oddly they chose to use the same repo for the web
pages (on a branch named gh-pages) but a different repo (with related
URI) for the wiki.  Odd choices, but the point remains.

All of a WG's work can be hosted in a Git repo in a way that is
independent of the enhanced-Git GitHubs/GitLabs/Bitbuckets/... of the
world.  All we need is Git.  And since some of these tools exist
already, we may not even need to invest much in IETF-specific tooling.

Nico

[0] E.g., https://github.com/dspinellis/git-issue -- note the "related
    work" links at the bottom.

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Jul 2019 11:23:42 -0500

>     work" links at the bottom.

Also (in no particular order):

 - https://docs.gitea.io/en-us/
 - http://www.bugseverywhere.org/
 - https://gogs.io/
 - http://gitblit.com/

I'm sure there's many more, and plenty of them open source.

Fully hosting all the things we need within Git repos seems entirely
plausible.  Even the Data-Tracker, I-D repository, RFCs, the RFC-Editor
queue, and IANA registries could all be managed along these lines :)
I'm not proposing quite that.

As to the Subject:, I don't think the IETF needs to get away from GH.  My
related point is that GH/GL/etc cannot really lock us in either, so
they're all ok.  My biggest concern is about ensuring that IETF-run
mailing lists and their archives are properly hooked up to any GH/GL/etc
Git repos so that notifications of pushes, PRs, issues, and anything
else get recorded in an IETF-hosted service.

I would also advise that whatever Git-hosting service a WG or
participants choose to use, the IETF should mirror them.  It's not a
huge step from running our own mirrors to running our own hosting,
naturally, but that's not the intention -- the intention is to ensure
archival and access (but not necessarily convenience) via IETF-hosted
resources.

Nico
--

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Jul 2019 20:13:48 +0200

> there are tools out there for doing just that[0].  Typically an issue's

Of course, but in my experience it is not how IETF WGs use GitHub. As a matter
of fact, draft-ietf-git-using-github-00 describes the use of GitHub's issues.

> already, we may not even need to invest much in IETF-specific tooling.

Personally, I would be absolutely fine with such a simple solution. But then, I
am also happy with editing xml2rfc XML directly in emacs. :-)

Lada