Subject: Re: Should IETF stop using GitHub?

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Aug 2019 11:31:24 +0200

Le 31/07/2019 à 20:13, Ladislav Lhotka a écrit :
> On Wed, 2019-07-31 at 11:04 -0500, Nico Williams wrote:
>> On Wed, Jul 31, 2019 at 03:15:26PM +0200, Ladislav Lhotka wrote:
>>> 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:
>>>>
>>>> [...]
>>>>
>>>> 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.
>>>
>>> For the git part, yes. What's more problematic are extra things that are not
>>> replicated, e.g. issues.
>>
>> 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
> 
> 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.
> 
>> "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.
> 
> Personally, I would be absolutely fine with such a simple solution. But then, I
> am also happy with editing xml2rfc XML directly in emacs. :-)

I also use emacs to edit the xml and process on xml2rfc.ietf.org, and
some times I store the file on github.

In the process I loose accents from peoples' names: ä from Harri, ø from
Troan and the entire 神明 達哉.  I cant figure out where's the error:
xml2rfc.ietf.org, github or emacs encode-coding-region utf-8.

I have tried a few different values for encode-coding-region (utf-16,
jp-*, iso-8859-*) but to no avail.

Alex

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 1 Aug 2019 12:54:21 +0000 (UTC)

I've noticed that github use is an effective way to kill
discussion of an issue in a draft that is raised on a
mailing list.

Don't respond on the list. Just say you've opened a github
comment item about it.

Later, mark the comment item, which no-one has commented
on, as closed. Job done. (The alternative, having lots
of technical discussion outside the list, is perhaps
worse.)

Has github replaced list discussion?

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2019 11:38:08 -0500

> of technical discussion outside the list, is perhaps

I've noticed this too.  If I had a comment I did not want ignored I'd
raise some heck if this treatment was applied to my comment, but the
fact that I'd have to might discourage me (I've other priorities too).

Obviously this doesn't happen during LCs, certainly not IETF LCs.  But
by IETF LC the community is presented with a huge body of work and in
some cases a fait accompli.

> Has github replaced list discussion?

In some WGs, prior to LC, yes, it seems that way.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Aug 2019 20:10:45 +0300

In which WGs have you observed this?

Lars

-- 
Sent from a mobile device; please excuse typos.

> On Aug 1, 2019, at 19:38, Nico Williams <[email-masked]> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2019 12:20:13 -0500

> In which WGs have you observed this?

TLS, I think.  But I may be wrong -- I wasn't a core participant.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 01 Aug 2019 12:58:21 -0700

> TLS, I think.  But I may be wrong -- I wasn't a core participant.

If possible, can you please elaborate on this claim?

Thanks,
Chris

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Aug 2019 13:28:56 -0700

"[email-masked]" <lloyd.wood=[email-masked]>

> Don't respond on the list. Just say you've opened a github

I think the biggest issues with ticket systems is that not everyone
reads them.  At least on a mailing list the issues brought up (and the
huge comment chains that result from them) are highly visible, and give
people the visual indication that "this may be important to follow".
Unfortunately, people don't follow every ticket in github or similar and
there is a serious concern with discussions that take place only in
issue trackers.  Issue trackers are great for ensuring everything is
handled, but less great as a place for discussion.  IMHO, of course.
-- 
Wes Hardaker
USC/ISI

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2019 15:50:28 -0500

> If possible, can you please elaborate on this claim?

I looked through the archives, but it's a lot to look for.  I think it
was early on in the 1.3 work, so it's not really fair to say that
discussion on the list was being discouraged -- I can see that later
lots of discussion was had on-list.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Aug 2019 20:56:18 +0000

>    I think the biggest issues with ticket systems is that not everyone
    reads them. 

There are tools to summarize issues and send mail.  See for example the QUIC one, at https://mailarchive.ietf.org/arch/msg/quic/kj0Zx-U9wj9xm3XZVEufY-DGCko which uses github-notify whose link can be found at https://github.com/ietf-gitwg/wg-materials/blob/master/TOOLING.md

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 2 Aug 2019 07:35:01 -0400

On Wed, Jul 31, 2019 at 08:43:42AM -0400, Keith Moore wrote:
> IMO it is dangerous for IETF to be dependent on an externally-run platform
> that is subject to change at a whim.

I strongly concur with this.  The IETF should run its own repository,
subject to its own policies/procedures/etc.  Yes, that's more work,
but it assures autonomy and it's much less work than frantically
trying to adapt to a sudden change imposed by an external platform --
whose agenda is not the IETF's agenda.

---rsk

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Aug 2019 10:14:09 -0700

My experience is very much the opposite. It's easy to lose a bit of feedback in a tumult of e-mail; threads don't have any formal closure unless you impose an unrealistic amount of structure onto mailing list discussions.

In contrast, using an issues list forces you to make a deliberate decision about the fate of a particular bit of feedback; if the person raising it disagrees with the disposition of the issue, they can complain there, to the mailing list, or to the chairs directly.

In other words - issues have explicit states ("open", "closed"), owners, and tags ("editorial", "design"). In practice that I've seen, this means that issues get more scrutiny, and there is more accountability -- not less.

Cheers,

> On 2 Aug 2019, at 4:35 am, Rich Kulawiec <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 13:17:33 -0400

> In other words - issues have explicit states ("open", "closed"), owners, and tags ("editorial", "design"). In practice that I've seen, this means that issues get more scrutiny, and there is more ac…

Keeping track of "issues" can be appropriate when a document is in a 
fairly mature state.   Before that point, however, if discussion must be 
couched in terms of "issues", whoever gets to define the "issues" wins 
the battles.

It's a bit like working group scope - if the scope is defined poorly the 
whole output of the WG is likely to be useless or worse.

Keith

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Aug 2019 10:23:16 -0700

> On 2 Aug 2019, at 10:17 am, Keith Moore <[email-masked]> wrote:
> 
> Keeping track of "issues" can be appropriate when a document is in a fairly mature state.   Before that point, however, if discussion must be couched in terms of "issues", whoever gets to define the "issues" wins the battles.

In the WGs I'm involved in, anyone can define an issue (at least for the first part of the work). It causes a certain amount of noise, but it's worth it.

> It's a bit like working group scope - if the scope is defined poorly the whole output of the WG is likely to be useless or worse.

That never happens around here, surely?

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 13:25:55 -0400

> In the WGs I'm involved in, anyone can define an issue (at least for the first part of the work). It causes a certain amount of noise, but it's worth it.
Yeah, it's not that having the ability to track issues is bad, it's just 
that additional discipline is required to make it work.
> That never happens around here, surely?

LOL.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Aug 2019 08:49:54 +1200

Mark,

> In other words - issues have explicit states ("open", "closed"), owners, and tags ("editorial", "design"). In practice that I've seen, this means that issues get more scrutiny, and there is more ac…

I fully agree that an issues list is necessary when things get complicated. But IETF rules
*require* consensus to be formed on the mailing list. That creates a bit of a problem
for any issues list technology, not just GitHub. So far, I haven't seen a perfect
solution.

I made up a solution a couple of years ago, which needed no extra technology:
https://tools.ietf.org/html/draft-ietf-anima-grasp-15#appendix-A

   Brian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Aug 2019 13:52:32 -0700

Brian,

> On 2 Aug 2019, at 1:49 pm, Brian E Carpenter <[email-masked]> wrote:
> 
> Mark,
> 
> *require* consensus to be formed on the mailing list.

I think "formed" is stated too strongly; we often "form" consensus in a meeting, and confirm it on-list.

> That creates a bit of a problem

If we hold perfect as a bar to using something, we won't get anything done; as many have pointed out, both in-person meetings as well as mailing lists are far from perfect.

Cheers,

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2019 17:15:54 -0400

>whose agenda is not the IETF's agenda.

This sort of argument quickly runs down a rathole of hosting our own
servers, generating our own power, and fabbing our own chips.  There
is always some risk associated with using outside providers, but there
is considerable cost and risk of running stuff ourselves.  We are
stretched very thin supporting the software tools we have now, and the
fact that you need to use our strange toolchain to write an I-D is a
significant hump for new participants to get over.  Github has the
huge practical advantage that to a first approximation everyone
already knows how to use it.  A self-hosted git package would not
be the same as github, which has a lot of its own stuff on top
of the git version control.

If we were to host our own stuff, as a US entity we'd be subject to
the same rules as github's owner Microsoft.  The usual next step is to
say that the IETF should move to some other country.  Having briefly
looked into this, I can say that even though the US is really screwed
up these days, on the whole it's still as stable a place to do
business as anywhere else, and moving would be unbelievably expensive.

Also, be careful what you wish for.  What if five or ten years ago
we'd decided to move to the UK for its stable politics and finances
and its deep integration with the EU?

R's,
John

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 2 Aug 2019 14:35:31 -0700

> https://tools.ietf.org/html/draft-ietf-anima-grasp-15#appendix-A

If I understand correctly in that solution the appendix contains a snapshot of the open and closed issues.

As I-Ds are actually kept forever, I think that's a great idea to use that as a way to document the development process of a standard.

In fact I would (and probably will) store all the discussions from the previous draft until that draft (i.e. replacing completely the appendix from the previous draft) in the appendix:

- For all *external* discussions, copy the whole thing (that can be automatized for GitHub, GitLab, etc...)
- For *internal* discussions (basically emails, jabber, minutes, audio and video recording), just store an url to that piece of data.

This way we create an immutable record of the creation of a standard without changing the process.  And as it is an appendix at the end of the document which is anyway removed before publication, it does not matter if it is multiple 100s of pages long.

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

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 3 Aug 2019 00:50:58 +0200

On Fri, Aug 02, 2019 at 05:15:54PM -0400, John Levine wrote:
> servers, generating our own power, and fabbing our own chips.

I don't think it should. Leveraging external resources where beneficial
is always good. I just don't think we should necessarily standardize
on a particular vendor of version management repository.

Do we even have anything that would NOT allow any WG or smaller unit
to pick whatever type of repository they wanted ? Is there any mandatory
use of repository ? Sorry, i am still not on top of all processes the
IETF has come up with.

I also like to note that i do prefer to have a simpler way to maintain
version history of IETF output in a simpler to diggest fashion than
any git tool. 

Cheers
    toerless

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 19:13:07 -0400

> servers, generating our own power, and fabbing our own chips.

No, I don't think so.

- In my experience, outsourcing servers works very well and comes with 
few compromises other than cost.    I can run any software I like on the 
servers I rent, and if I decide to do so, I can move that software to 
other providers' servers fairly easily.   I assume the same is true for 
IETF.

- There are usually not many ways of obtaining power in a particular 
location, but at least power is fairly standardized in an area (the same 
equipment runs no matter who supplies the power) and regulated in such a 
way that prices are reasonable.   In other words, utility power is cheap 
enough in comparison to other ways of generating that few customers find 
it advantageous to generate their own power full-time.   (This is 
changing somewhat due to the reduced cost of photovoltaic panels.  But 
as long as customers are free to choose between utility power and 
self-supplied power [*], the utilities will have to keep their prices 
competitive.)

- It's a little hard to understand why we'd want to fab our own chips - 
unless perhaps all of the available chips have built-in back doors 
(which is rumored).    Even then if we fabbed our own chips we'd still 
have to outsource some of that, which would make our own chips 
vulnerable to the same kinds of compromise.

(and I realize you were trying to employ /reductio ad absurdum/ but the 
analogy simply does not hold.)

I don't think the same applies to github.   Use of github carries 
several risks for IETF and its participants, including the risk of 
lock-in to a provider that cannot be assured to act in either IETF's or 
the Internet community's interests, and also risks to the privacy of 
IETF participants who use it.    Yes, a git repo can be mirrored to 
other locations, and this might be part of the solution, but it's not 
just the git repo that is being used.

(I'm less concerned about the requirement that github follow insane US 
laws; as you point out, so does IETF.   And I share your assessment of 
the difficulty of moving IETF to another country, though it is probably 
something that should be examined from time to time as the US becomes 
more and more hostile to the unfettered exchange of information.)

Keith

[*] Granted, this is not true everywhere.

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 19:19:13 -0400

> I think "formed" is stated too strongly; we often "form" consensus in a meeting, and confirm it on-list.

If the consensus reached in a WG meeting is a good one, one that 
accommodates the diversity of concerns from the wider WG, the in-person 
consensus will usually carry over to the list without many changes.    
However, if the list is pressured to accept a consensus that was reached 
in a meeting, I'd argue that it's a process violation.

> If we hold perfect as a bar to using something, we won't get anything done; as many have pointed out, both in-person meetings as well as mailing lists are far from perfect.
Use of avian carriers isn't perfect either - so should we replace 
mailing lists with avian carriers?   (with or without QoS)

Just because neither X nor Y is perfect does not mean we should replace 
X with Y.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Aug 2019 01:31:16 +0200

On Aug 3, 2019, at 01:13, Keith Moore <[email-masked]> wrote:
> 
> (and I realize you were trying to employ reductio ad absurdum but the analogy simply does not hold.)

Right.  A better analogy would be eating only animals you have slaughtered yourself.

Grüße, Carsten

(And the answer to the question in the subject line can be reduced to “No.  But use it with care.”  For which we have a whole WG.  Why are we discussing this here?)

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Aug 2019 18:31:21 -0500

> on a particular vendor of version management repository.

The simplest thing to do is to have existing IETF mailing list archive
infrastructure also implement git mirroring, with read-only service to
the public.

> use of repository ? Sorry, i am still not on top of all processes the

This is all informal.  At the end of the day the outpug of WGs is
Internet-Drafts, and the medium for consensus calls is the WG mailing
lists.

> version history of IETF output in a simpler to diggest fashion than

That remains: Internet-Draft submission history.

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 19:37:08 -0400

> (And the answer to the question in the subject line can be reduced to “No.  But use it with care.”  For which we have a whole WG.  Why are we discussing this here?)

Strongly disagree.  I think the answer is "yes, as soon as 
practicable".   And I'd argue that that WG should not exist with its 
current charter - there should be no presumption that GitHub is 
appropriate for IETF or that it should be favored in any way. The very 
fact that IETF is favoring a commercial provider of any service seems 
both dangerous to IETF and completely inappropriate.

(though I suppose the right thing to do procedurally is file an appeal, 
it seems to make more sense to discuss it here first in case my concerns 
can be addressed.)

Keith

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Aug 2019 19:05:41 -0500

Hi Keith,

> appropriate for IETF or that it should be favored in any way. The very 

I'm a bit puzzled by this.  Are you arguing that all the WGs that
organically started using github before we had a GIT WG were/are behaving
inappropriately?  As for "favored in any way", my understanding is that the
GIT WG talks about github because there were lots of people that wanted to
talk about how to use github most effectively, not because anyone decided
on behalf of the IETF that github is the best thing ever.  Does that kind
of "voting with their feet" count as favoritism to you?

> both dangerous to IETF and completely inappropriate.

I recall the BoF that led to the GIT WG presenting its desired output as
"here are a set of pre-baked procedures that your WG can choose to use, if
your WG decides to use github".  Is that favoring github, or just reduction
of duplicated effort?

> it seems to make more sense to discuss it here first in case my concerns 

Fair enough.

-Ben

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 03 Aug 2019 10:50:18 +1000

> couched in terms of "issues", whoever gets to define the "issues" wins 

Having used github as a chair for tracking issues, it's been very valuable to be able to tag specific items from the mailing list as issues such that authors remember to address all the comments. I've done this by taking reviews from the mailing list and extracting issues raised, e.g.:

https://mailarchive.ietf.org/arch/msg/jmap/MSZim31q9VphrJbG0gfvaAwiAUQ

And likewise Authors have used it themselves to track issues from the list:

https://mailarchive.ietf.org/arch/msg/jmap/7sV0agYm8xQPqgYBaCYPHoxqMTY

Similarly, when people have nits on the text, it can be much easier to open a merge request against the source markdown document and ask the Author to review that rather than having the author need to apply the changes, particularly when it's a bunch of related changes throughout a document. E.g.

https://github.com/jmapio/jmap/pull/206

The nice thing about this workflow is that it doesn't require github specifically, any system which allows issue tracking and git pull requests would work just as well - and the key synchronisation points are still the individual drafts which are published on the IETF systems.

---

One of the biggest challenges that the IETF has is bringing in new blood, and one of the biggest advantages of Github in particular is that it has a lot of mindshare right now, so there are many people who know how to use it and allowing them to interact with in-progress IETF documents using tools they understand is a good way to bring them in.

Having the process of joining the IETF be entirely learning a custom workflow and custom tooling which only the IETF uses is a recipe for isolation, and I would much rather see the IETF embracing the tooling that the rest of the world is using rather than running everything in isolation.

Cheers,

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 20:21:42 -0400

On 8/2/19 8:05 PM, Benjamin Kaduk wrote:

> inappropriately?

I'm not going to fault groups that organically started using github.  
(Though I hope they got AD approval before doing so.) Broadly speaking 
I'm supportive of groups looking for better tools and better ways to 
conduct discussions, though it's imperative that they follow process 
(e.g. decisions are made on the mailing list) and that they maintain 
openness and neutrality (e.g. github users should not be favored.)

I'm also saying that the risks of using github may now be more obvious, 
than they were before several WGs started using it.

> As for "favored in any way", my understanding is that the
What bothers me is not that there's a group discussing use of version 
control software by IETF WGs.  What bothers me is that there's a 
presumption in the WG's charter that github is appropriate to use, and 
that it's favored in the charter simply by singling it out.   The 
wording of the charter also means that it's problematic to go to that WG 
and argue why using github is a bad idea.   The chairs could quite 
legitimately rule that argument out-of-scope. And anyway, the deck is 
already stacked.   The way the charter was written it is much more 
likely to attract github proponents than people who prefer other systems 
or services.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 21:33:14 -0400

On 8/2/19 8:50 PM, Bron Gondwana wrote:

> One of the biggest challenges that the IETF has is bringing in new 
> blood, and one of the biggest advantages of Github in particular is 
> that it has a lot of mindshare right now, so there are many people who 
> know how to use it and allowing them to interact with in-progress IETF 
> documents using tools they understand is a good way to bring them in.
Understood.  And I'm very glad to see more interest in IETF from the 
open source community.
>
> Having the process of joining the IETF be entirely learning a custom 
> workflow and custom tooling which only the IETF uses is a recipe for 
> isolation, and I would much rather see the IETF embracing the tooling 
> that the rest of the world is using rather than running everything in 
> isolation.

But this raises a problematic question - whose mindshare should be 
favored?   Should IETF favor github users over users of other tools?

What about 10-20 years from now when some other tool is in vogue?   
Should IETF then favor the new tool, or the one that its 
then-established participants already know?

IETF originally had a history of trying to use tools that are accessible 
to a wide potential participant base, but has been departing from this 
for awhile:

  * Email had the advantage of near-universal accessibility (at least by
    people on the Internet, and even by some not on the Internet).   And
    it was/is easy to use.
  * The web had a similar characteristic, once high-quality web browsers
    became available on all major platforms.
  * xml2rfc was and remains problematic.   Sure, anyone can use a web
    interface to the tools, but there's a significant learning curve and
    often a lot of fighting to get the XML to conform to the latest fad.
  * Github not only imposes a learning curve for those who don't already
    use it, there's also the risk of lockin to a tool that we don't
    control, and potential privacy risks that at least need to be
    evaluated (now, and in the future).

I very much want to attract open source developers (among many other 
groups that could bring new energy).    But to me there's something very 
odd about IETF trying to /favor/ github users, especially at the expense 
of existing IETF participants and at the expense of users of other 
systems.  It's not like everybody already uses git.   Really, it's 
not.   Lots of companies have investment in other ways of maintaining 
source code, that either pre-date or post-date git.

I'm not saying there's an easy or obvious answer, I'm just saying that 
we shouldn't presume that github is the solution just because it's 
currently popular, any more than we should presume that Word is the 
solution for document editing or that meetings should consist of 
Powerpoint presentations.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Aug 2019 21:58:33 -0400

The nice thing about organic is that it is organic. That’s how github became popular at the IETF. That’s how it’s successor will become popular too. When it does there will be a new git hotness working group. There is no need to figure this out now. 

Sent from my iPhone

> On Aug 2, 2019, at 9:33 PM, Keith Moore <[email-masked]> wrote:
> 
> Understood.  And I'm very glad to see more interest in IETF from the open source community.
>> 
> But this raises a problematic question - whose mindshare should be favored?   Should IETF favor github users over users of other tools?
> 
> What about 10-20 years from now when some other tool is in vogue?   Should IETF then favor the new tool, or the one that its then-established participants already know?
> 
> IETF originally had a history of trying to use tools that are accessible to a wide potential participant base, but has been departing from this for awhile:
> 
> Email had the advantage of near-universal accessibility (at least by people on the Internet, and even by some not on the Internet).   And it was/is easy to use.
> The web had a similar characteristic, once high-quality web browsers became available on all major platforms.
> xml2rfc was and remains problematic.   Sure, anyone can use a web interface to the tools, but there's a significant learning curve and often a lot of fighting to get the XML to conform to the latest fad.
> Github not only imposes a learning curve for those who don't already use it, there's also the risk of lockin to a tool that we don't control, and potential privacy risks that at least need to be evaluated (now, and in the future).
> I very much want to attract open source developers (among many other groups that could bring new energy).    But to me there's something very odd about IETF trying to favor github users, especially at the expense of existing IETF participants and at the expense of users of other systems.  It's not like everybody already uses git.   Really, it's not.   Lots of companies have investment in other ways of maintaining source code, that either pre-date or post-date git. 
> 
> I'm not saying there's an easy or obvious answer, I'm just saying that we shouldn't presume that github is the solution just because it's currently popular, any more than we should presume that Word is the solution for document editing or that meetings should consist of Powerpoint presentations.
> 
> Keith
> 
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Aug 2019 21:03:48 -0500

> (e.g. decisions are made on the mailing list) and that they maintain 

I would hope that everyone would agree with that!

> openness and neutrality (e.g. github users should not be favored.)

I think I need to drill down into what "favored" means.  It will presumably
be multifaceted and subtle, but are you thinking along the lines of "feel
more comfortable with the tools" or "'vote's get more weight" or "issues
raised get more prompt attention" or "non-github-users get ignored" or
other things?  In particular, if we somehow could limit what happens to
"feel more comfortable with the tools", would that be problematic?  (I make
no claim yet about how practical such a scenario would be to attain.)

> likely to attract github proponents than people who prefer other systems 

I'm still trying to understand where things went wrong (in your
perception): should we have instead chartered a WG to consider how WGs
could use VCS in general (without prejudging as to external services or
self-hosted), with an early task being to determine whether external
services, and github in particular, are appropriate for use in the IETF?

In a later reply you say "we shouldn't presume that github is the solution
just because it's currently popular", but I'm not sure that that matches up
what is happening.  My perception is that yes, there is a presumption, but
that github is *a* solution, one of potentially many, and with a further
presumption that the WG cannot override existing BCP-documented procedures,
including that work is ultimately taken to the mailing lists.  This one
got a WG because the people showed up to do the work.

If we had two other WGs, one to discuss using tooling for using vim to
write XML sources for I-Ds directly, and another discussing tooling for
using emacs to write Markdown sources for I-Ds, is the main difference from
the GIT WG just that the tooling in question involves an external service?
I'm not sure if I'm missing anything from your argument/stance.

Thanks,

Ben

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 22:41:15 -0400

On 8/2/19 9:58 PM, Ted Lemon wrote:

> The nice thing about organic is that it is organic. That’s how github 
> became popular at the IETF. That’s how it’s successor will become 
> popular too. When it does there will be a new git hotness working 
> group. There is no need to figure this out now.

We should not presume that something is good in the long term just 
because it's popular.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 22:58:46 -0400

> no claim yet about how practical such a scenario would be to attain.)

I think it's problematic if people have to use github to participate 
effectively in a WG, or even if github users have significant advantages 
at providing input to the WG, especially if the privacy risks haven't 
been evaluated and addressed.

It's one thing to ask people to learn new tools once in awhile.    It's 
another thing entirely if IETF participants are expected to have their 
privacy compromised as a consequence of being able to participate.

> services, and github in particular, are appropriate for use in the IETF?

Closer to that, I think.   And if I were writing the charter I think I 
would specifically task the group with identifying and evaluating risks 
to IETF resulting from use of externally-hosted VCSs vs. self-hosted VCSs.

> got a WG because the people showed up to do the work.
Yes, but again, just because people showed up to work on github first 
doesn't mean it's a good choice for IETF, and the charter of the git WG 
does seem to presume that.
> I'm not sure if I'm missing anything from your argument/stance.

There are certainly additional risks (to both IETF in general and WG 
participants) that result from IETF using and depending on an external 
service that it does not control, and for which the terms and conditions 
of use are subject to change at a whim, so that's part of my concern.    
For a self-hosted service presumably IETF can establish terms which are 
reasonable and consistent with its interests; if the service is 
external, this is more difficult.

There are even more risks to IETF with depending on a vendor that has a 
lot of influence in the market, and quite plausibly, a significant 
conflict of interest with IETF's purpose.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Aug 2019 23:00:43 -0400

I unless you have some better suggestion, I would say that this is a pointless discussion. 

Sent from my iPhone

> On Aug 2, 2019, at 10:41 PM, Keith Moore <[email-masked]> wrote:
> 
> We should not presume that something is good in the long term just because it's popular.
> 
> Keith
> 
>

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2019 23:00:59 -0400

>We should not presume that something is good in the long term just 

Indeed, but we should not chase people away by forbidding them to use
the tools they like and are familiar with.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 23:02:58 -0400

> the tools they like and are familiar with.

The question is not whether they should be able to use tools that 
they're familiar with, the question is whether they should be able to 
impose those tools on IETF and participants as a condition of effective 
participation in a working group.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Aug 2019 23:07:30 -0400

> I unless you have some better suggestion, I would say that this is a pointless discussion.

I'd like to see the git WG's charter amended to (a) not specifically 
favor github, and (b) require the WG to identify and evaluate risks 
associated with various VCSs (both self-hosted and externally-hosted).

Keith

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 02 Aug 2019 21:11:37 -0700

> to IETF resulting from use of externally-hosted VCSs vs. self-hosted VCSs.

The GIT WG was chartered primarily to guide other WGs that wish to use GitHub. Whether or not it's the right tool (for some definition of right) is orthogonal to group's purpose. 

Best,
Chris

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 07:03:27 -0400

> The GIT WG was chartered primarily to guide other WGs that wish to use GitHub. Whether or not it's the right tool (for some definition of right) is orthogonal to group's purpose.

Yes, that's what I (mostly) get from the charter.  And yet, having a WG 
that produces output that tells WGs how to use GitHub has the effect of 
encouraging GitHub over other tools, and encouraging its use without due 
consideration for the risks that it appears to present, and this 
concerns me.

I think we need to be asking ourselves as a broader community whether 
GitHub is an appropriate tool to use, and the same questions should be 
asked of any new tool that we expect people to use.   Maybe the easiest 
way to do that is to tweak the git WG's charter.  Or maybe not, but 
having a group that is effectively promoting use of GitHub without 
asking those questions somewhere, seems to me to  be a Bad Idea.

Some people have been saying that that such discussion should occur in 
the git WG rather than on the ietf list.  I'm not sure about that.  But 
if such discussion were to happen in the git WG, it seems like the 
charter would also need to be tweaked to make that clear.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Aug 2019 13:47:06 +0200

On Aug 3, 2019, at 13:03, Keith Moore <[email-masked]> wrote:
> 
> Some people have been saying that that such discussion should occur in the git WG rather than on the ietf list.  I'm not sure about that.  But if such discussion were to happen in the git WG, it seems like the charter would also need to be tweaked to make that clear.

The general discussion is meaningless without considering *how* github is being used.
(Please see this thread if you haven’t noticed yet.)

So we need the output of that WG.

But the WG would be missing its mark if it were to deliver modes of use that don’t fit the constitution of the IETF.  So it *has* to have at least some elements of that discussion, but focused to the mode of use under consideration (which may allow the discussion to be meaningful).  There is no doubt that any discussion that concludes in no or rough consensus will then leak back to this list.  I’m looking forward to that, *if* (and when) it is needed.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 07:55:24 -0400

> The general discussion is meaningless without considering *how* github is being used.

There appear to be risks that depend on how github is used, and there 
also appear to be risks that are independent of this.

Keith

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Aug 2019 11:56:51 +0000

Hi,

>I'd like to see the git WG's charter amended to (a) not specifically favor github, and (b) require the WG to identify >and evaluate risks associated with various VCSs (both self-hosted and externally-hosted).

Regarding (b), for GitHub, shouldn't that be covered in the Security Considerations of the github-usage-draft?

Regards,

Christer

---

From: Lars Eggert <[email-masked]>
Date: Sat, 3 Aug 2019 16:29:30 +0300

> On Aug 3, 2019, at 14:03, Keith Moore <[email-masked]> wrote:
> 
> I think we need to be asking ourselves as a broader community whether GitHub is an appropriate tool to use,

I think a significant part of the broader community has asked itself this question, and has answered it positively.

> and the same questions should be asked of any new tool that we expect people to use.  

Why only ask this about new tools? Hell, I would like us to stop using email. It’s insecure, attracts spam, viruses and phishing, has archaic formatting and quotation functionalities that are ill-suited to dynamic communication and isn’t used by anyone under 30.

(And while I’m at it, XMPP is dead, too.)

Lars

Lars

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 10:19:00 -0400

> I think a significant part of the broader community has asked itself this question, and has answered it positively.
I think it's been found to be useful, but evaluation of the risks has 
been sorely lacking.   Especially in light of our mostly-newfound 
awareness of privacy risks.   Again, these are questions we should ask 
ourselves about any new tool, particularly one using the web, 
particularly if externally hosted and not under IETF control, and 
particularly if there is significant potential of conflict of interest 
between IETF and that tool's operator.
> Why only ask this about new tools? Hell, I would like us to stop using email. It’s insecure, attracts spam, viruses and phishing, has archaic formatting and quotation functionalities that are ill-s…

And yet, it's still superior, at least for IETF purposes, to every other 
form of group communication currently in existence. It's standard, 
widely implemented, universally available, extremely fault tolerant, and 
does not impose central control (at least over private messages).  It 
doesn't impose silly length constraints, it actually has extensible 
metadata, it's easily archived and easily searchable, etc.   And any 
decent MUA is more usable than anything that relies on a web browser.

(Though it could certainly be improved on, and I was just thinking this 
morning that email would be MUCH better if we used some variant of 
markdown rather than HTML or anything XML-based. Good luck getting 
everyone's user agent to adapt to it though.)

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Aug 2019 07:32:49 -0700

> associated with various VCSs (both self-hosted and externally-hosted).

I would not be in favor of either of these changes.

As Chris says, the purpose of the GIT WG is to build best practices that
help WGs who want to use Github for their work. If you want to form a WG
that is neutral and tasked with comparing the risks of various VCSes,
you're free to submit a BOF proposal, etc. However, having that work in the
GIT WG would, IMO get in the way of what the intended purpose of that group.

-Ekr

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Aug 2019 18:04:04 +0200

> (And while I’m at it, XMPP is dead, too.)

… which leads us into another set of proprietary tools.

Different from git services, there is no 362.8739 kg Gorilla here, but some people seem to like Slack.
Others use Telegram groups (which would be my personal choice at this point).

This is probably less of a WG decision than within author teams, open-source teams etc., but a little bit more of convergence would help.

(XMPP usage during WG meetings is less of a problem, because that can be channeled through meetecho — people increasingly have trouble joining the rooms without that.)

Grüße, Carsten

---

From: [email-masked]
Date: Sat, 03 Aug 2019 09:00:05 -0700 (PDT)

> I would not be in favor of either of these changes.

Nor would I. This whole thing seems to be a lot of worry about a problem
that hasn't happened yet and which has an obvious remedy if it does happen.

> GIT WG would, IMO get in the way of what the intended purpose of that group.

The flexibility of modern VCSes means it's really important to have a good
usage model. This is a far greater risk to participation IMO.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2019 13:25:26 -0400

>consideration for the risks that it appears to present, and this 

It's pretty clear that you're not persuading anyone else of the risk
that you believe github presents.  We know that Microsoft had a rather
casual approach to standards compliance 10 or 20 years ago, but that
was then, and the people involved now are all different.

Perhaps it would be more useful to try to make a better case rather than
just repeatedly telling everyone to stop.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 13:46:46 -0400

> just repeatedly telling everyone to stop.

What I've concluded (independently) is that I've pretty much said 
everything about this that I can reasonably say in a mailing list 
discussion, and that if I still want to try to convince people, I should 
set out the argument in an Internet-Draft where I can address the 
subject comprehensively and in more detail.   So I'll think about 
whether I want to do that, but unless someone raises some new point 
here, I'm probably done with this thread.

Keith

p.s. I do want to thank everyone for keeping this discussion respectful, 
which seems like a pleasant change from the recent past.

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Aug 2019 14:48:27 -0400

--On Friday, August 2, 2019 13:52 -0700 Mark Nottingham
<[email-masked]> wrote:

>> I fully agree that an issues list is necessary when things
>> get complicated. But IETF rules *require* consensus to be
>> formed on the mailing list.
> 
> I think "formed" is stated too strongly; we often "form"
> consensus in a meeting, and confirm it on-list.

Mark,

This is really not part of the GitHub topic (hence the changed
subject line) because it applies whether a versioning or
tracking systems is used or not, but it may be worth noting that
there is a slippery slope attached to your comment above.
While I don't want to split hairs over what "form" might mean,
we used to insist that significant issues be aired in sufficient
detail that decisions were actually made and consensus
determined on those mailing lists.  I've seen situations in the
last few years in which a discussion occurs and decisions are
essentially made in a meeting and made with or without adequate
attention to the views of those who are not in the room.  After
that, the request to the list takes a form not much different
from "anyone who doesn't agree with the meeting decision needs
to speak up".  That request may come before there are minutes or
a good summary of the meeting other than the recording of the
video feed (if that isn't delayed too, as it sometimes has
been).  The subsequent near-silence from the combination of
those who agree and those who don't feel informed enough to have
an opinion can be construed as confirmation on the list, but it
certainly is not within the spirit of those rules.

Perhaps it is time to change those rules but, if so, let's do it
explicitly rather than silently drifting from "determined and
confirmed in the mailing list" toward "determined in a meeting"
followed by pro forma mailing list confirmation.   And, if we do
so, let's incorporate the content of several other threads by
reference and consider the tradeoffs of making f2f meeting
attendance more important.

best,
    john

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Aug 2019 11:56:58 -0700

> certainly is not within the spirit of those rules.

I haven't been involved in the IETF as long as you, but in my
experience the general pattern of "Issues are discussed and decided at
the meeting and then a mail is sent to the list asking for objections"
has been common for at least 20 years. While it's certainly possible
to do this badly (e.g., asking for consensus before the minutes are
up), as long as the list is given sufficient time and context to
weigh in, then this practice seems to me to be in line with both
the letter and spirit of 2418 S 3.4.

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Decisions reached during a face-to-face meeting about
   topics or issues which have not been discussed on the mailing list,
   or are significantly different from previously arrived mailing list
   consensus MUST be reviewed on the mailing list.

-Ekr

---

From: Melinda Shore <[email-masked]>
Date: Sat, 3 Aug 2019 15:00:23 -0400

On Sat, Aug 3, 2019, 14:49 John C Klensin <[email-masked]> wrote:

> followed by pro forma mailing list confirmation.
>

Hear, hear.  I feel very strongly about this, and its clear ties to the
discussion of meeting modalities.  It seems that we've got a number of
threads converging on the possible need for a major reexamination of how
the IETF accomplishes our work.  We tend to do poorly at this kind of navel
gazing but it may be time.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Aug 2019 15:09:07 -0400

--On Saturday, August 3, 2019 11:56 -0700 Eric Rescorla
<[email-masked]> wrote:

> experience the general pattern of "Issues are discussed and
> decided at the meeting and then a mail is sent to the list
> asking for objections" has been common for at least 20 years.
> While it's certainly possible to do this badly (e.g., asking
> for consensus before the minutes are up), as long as the list
> is given sufficient time and context to weigh in, then this
> practice seems to me to be in line with both the letter and
> spirit of 2418 S 3.4.
> 
>    Each working group will determine the balance of email and
> face-to-    face sessions that is appropriate for achieving
> its milestones.    Electronic mail permits the widest
> participation; face-to-face    meetings often permit better
> focus and therefore can be more    efficient for reaching a
> consensus among a core of the working group    participants.
> In determining the balance, the WG must ensure that    its
> process does not serve to exclude contribution by email-only
> participants.  Decisions reached during a face-to-face meeting
> about    topics or issues which have not been discussed on the
> mailing list,    or are significantly different from
> previously arrived mailing list    consensus MUST be reviewed
> on the mailing list.

Ekr,

See Melinda's note, which seems to me to get to the core of the
comment/ concern and suggestion I was trying to make.  

However, in the context of your response above, what I'm
concerned about is slipping quietly and in slow, frog-boiling,
increments toward what you describe as doing it badly.  And,
fwiw, there is, at least IMO, a significant difference between
"reviewed on the mailing list" in the last sentence you quoted
and some sort of "does anyone object to what was agreed at the
meeting" question, especially one that covers multiple decisions
and issues.    If we agree that the latter constitutes doing
things badly and that we shouldn't encourage doing things badly,
then we are probably in complete agreement about the current
situation.

best,
    john

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 15:09:28 -0400

On 8/3/19 3:00 PM, Melinda Shore wrote:

>
> On Sat, Aug 3, 2019, 14:49 John C Klensin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hear, hear.  I feel very strongly about this, and its clear ties to 
> the discussion of meeting modalities. It seems that we've got a number 
> of threads converging on the possible need for a major reexamination 
> of how the IETF accomplishes our work.  We tend to do poorly at this 
> kind of navel gazing but it may be time.

Perhaps related to this, I'm really bothered by what seems like an 
increasingly widespread belief that WGs should be able to do whatever 
they want, use any tools they want, etc., no matter how this affects 
process or openness.    So I think having a community-wide 
re-examination of how we do our work might be useful at either tweaking 
existing practice or re-affirming it, as appropriate.

(of course, it could also be an invitation to second-system effect, but 
we can't let that scare us.)

I also think we could stand to look at other aspects of how we do our 
work, such as how we use email, how we conduct face-to-face meetings, etc.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Aug 2019 21:15:10 +0200

On Aug 3, 2019, at 20:48, John C Klensin <[email-masked]> wrote:
> 
> I've seen situations in the
> attention to the views of those who are not in the room.

Sounds like you are describing BOFs.

These can have the special characteristic that they are populated by people who are still learning about the subject at hand and therefore have to make decisions based on gut feeling.
The emotional balance of the room tends to be more important in the end than technical arguments.

(I have also seen discussions like this in established WGs as well.  An interesting observation is that in such decision situations the room tends to be filled by more people than the regulars, which recreates the “I’m a tourist and still need to learn about this but I will still make the decision for you” effect that is so familiar from BOFs.)

As with consensus judging in general, this is mitigated significantly by the leadership (ADs for BOFs, WG chairs for WG decisions) applying some merit-based weighting of opinions witnessed.  But the problem remains that we can’t start work or make important decisions that need more than 90 minutes of explanation before one can form an opinion.

I don’t know how to fix this, as something like BOFs are a necessary threshold for establishing new work in the IETF, and F2F meeting is the only reasonable way to create emerging consensus that leads out of a contentious situation.  But it is too *easy* (yes, I mean that!(*)) to prevent work, and this repeated observation is a significant dent in the otherwise quite high quality of output of the IETF.

Grüße, Carsten

(*) Of course, we already have way too much work on our plates.  
Some of which is managing the distortions created by prevented but ultimately necessary work.
Or by wasting a lot of time preparing for these “at sea and in BOFs you are in god’s hands” events.
Instead of miring new work in process until it suffocates and implodes by itself, we need to say “no” more often.  We don’t have the criteria for that.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Aug 2019 12:15:49 -0700

> then we are probably in complete agreement about the current

I guess I'd need some clarity to know whether we agree.

In an attempt to get that, I think an email containing a list of decisions
at the meeting and asking for objections on those is totally reasonable.
Are you disagreeing with that?

It's worth noting that the letter of 2418 only requires that decisions be
reviewed on the list if either

(a) they have not been discussed on the mailing list
or
(b) or are significantly different from previously arrived mailing list

So, for instance, something discussed on the list extensively but with
no consensus which is then decided in a meeting (a fairly common
situation) is, by my reading, not required to be reviewed on the list,
though that is no doubt good practice.

-Ekr

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Aug 2019 13:10:45 -0700

i think that wg charters should mandate emacs. :)

we have a variety of tools, a variety of people, and a variety of needs.
there are no perfect tools, perfect people (present company excepted, of
course), and unsophisticated needs do not match our unbounded desire for
corner cases.

we have a work-product funnel with a fairly wide mouth and a well-
defined end.  this is a feature, not a bug.

i use nekked git, gogs, github, and still a remnant of RCS <blush>.  i
use emacs and xml2rfc.  i do not feel a need to tell you what [not] to
use; and will not take seriously your telling me what [not] to use.
it's hard enough to get substantive work done without being
over-processed and/or micromanaged.

i recently co-authored a draft where a major contributor still uses
nroff.  i focussed on the content, and only snarked once.

and i deeply appreciate the tool-makers who have given us a fairly rich
variety from which to choose.  and i am in awe of the makers and fellow
users who help when i do a st00pid or hit a bug.  thank you.

randy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 3 Aug 2019 16:18:36 -0400

> users who help when i do a st00pid or hit a bug.  thank you.

Well said.
Joel

---

From: Nico Williams <[email-masked]>
Date: Sat, 3 Aug 2019 17:32:43 -0500

> there is a slippery slope attached to your comment above.

However consensus is formed, it certainly is to be confirmed on mailing
lists.

Sometimes confirmation doesn't happen, or it isn't noticed, then people
get upset.

I wouldn't want to insist that consensus can only form on the lists
because a) that's not gonna fly, b) it would be very limiting of
face-to-face meetings.

>                             [...].  I've seen situations in the

Indeed.  Consensus confirmation might look nothing like a call for
consensus, in which case it's very hard to miss, and deadlines -implicit
or otherwise- easily pass without comment.

What we could do is have something like a Consensus Call that we might
call "Consensus Confirmation Call".  WG chairs would need to get good at
making these calls.

> attendance more important.

Pro forma confirmation is fine, provided it's _noticeable_.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Sat, 3 Aug 2019 15:53:21 -0700

> On Aug 3, 2019, at 3:32 PM, Nico Williams <[email-masked]> wrote:
> 
> face-to-face meetings

That then biases heavily towards those can attend in person.

I agree with Keith - some preliminary notion of consensus can be “sampled” at a meeting, but ought to occur on the list for actual decisions.

And no, I’m not interested in a debate here - I’m asking to know whether to bother at all.

Joe

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Aug 2019 19:11:25 -0400

--On Saturday, August 3, 2019 16:18 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

>> we have a variety of tools, a variety of people, and a
>> variety of needs. there are no perfect tools, perfect people
>> (present company excepted, of course), and unsophisticated
>> needs do not match our unbounded desire for corner cases.
>> 
>> we have a work-product funnel with a fairly wide mouth and a
>> well- defined end.  this is a feature, not a bug.
>> 
>> i use nekked git, gogs, github, and still a remnant of RCS
>> <blush>.  i use emacs and xml2rfc.  i do not feel a need to
>> tell you what [not] to use; and will not take seriously your
>> telling me what [not] to use. it's hard enough to get
>> substantive work done without being over-processed and/or
>> micromanaged.
>> 
>> i recently co-authored a draft where a major contributor
>> still uses nroff.  i focussed on the content, and only
>> snarked once.
>> 
>> and i deeply appreciate the tool-makers who have given us a
>> fairly rich variety from which to choose.  and i am in awe of
>> the makers and fellow users who help when i do a st00pid or
>> hit a bug.  thank you.
>> 
>> randy
>> 
>> 
> 
> Well said.
> Joel

Indeed.  Excellent discussion and summary.
   john

---

From: Keith Moore <[email-masked]>
Date: Sat, 3 Aug 2019 19:51:45 -0400

On 8/3/19 6:53 PM, Joe Touch wrote:

>> On Aug 3, 2019, at 3:32 PM, Nico Williams <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> I agree with Keith - some preliminary notion of consensus can be 
> “sampled” at a meeting, but ought to occur on the list for actual 
> decisions.

I think meetings can be incredibly useful for working out details of a 
proposal that is likely to earn consensus of the list.   And sometimes 
it seems clear that consensus will be reached if a relatively few 
parties are satisfied and the face-to-face meeting affords an 
opportunity to rapidly converge on a proposal that satisfies those parties.

But there's an important difference between "we think we have a proposal 
that will reach consensus" and "we have already reached consensus at the 
meeting", and I hope that WG chairs recognize that.

Keith

---

From: Nico Williams <[email-masked]>
Date: Sat, 3 Aug 2019 19:17:17 -0500

> That then biases heavily towards those can attend in person.

There's remote participation.  Mind you, remote participants have time
zone issues and daily work-life things to schedule around.  The extent
of the bias will depend on the semantics of confirmation.

To me consensus confirmation means "consensus may change as if via de
novo consensus call".

That's practically indistinguishable from a consensus call, except that
it comes with details of what the consensus of the subset of
participants in the room was.

Perhaps the issue is the word "confirmation"?  That it tends to imply
that the we're looking for a rubber stamp?  That's just a matter of
definitions.

I'm open to saying it's a de novo consensus call, though obviously the
post should come with details of what the consensus in the room was.

> whether to bother at all.

I've been burned by "consensus called in the room and I wasn't there"
situations.  That should not happen again, to me, to you, or to anyone.
It seems that you agree.

"I'm not interested in debate" comes across very rough.  If I'm parsing
the above correctly, it sounds like you're saying that if we were to
call it a "consensus confirmation call" you'd take your ball and go
home.

There's no sense getting this upset about what to call the process by
which we make a particular kind of bad situation not happen again.

Nico
--

---

From: tom petch <[email-masked]>
Date: Sun, 4 Aug 2019 09:45:39 +0000

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
Sent: Saturday, August 03, 2019 8:00 PM

> Hear, hear.  I feel very strongly about this, and its clear ties to
the
> gazing but it may be time.

And while this discussion has been largely about meetings and their
utility, my perception is that most of the work of the IETF takes place
on mailing lists and so if we want to work better, smarter or whatever,
then a small improvement on the work done on mailing lists would do more
for us than a big improvement for the work done in meetings.

And here I am thinking of what WG Chairs do or do not do.  Before
adoption, the work gets driven by the authors of an I-D; after WG Last
Call, the work gets driven by the AD; in between, it is up to the WG
Chairs and it is there that I think there is most scope for changing
whatever it is we want to change, be it reducing mistakes, speeding up
the process or whatever.

Tom Petch

---

From: tom petch <[email-masked]>
Date: Sun, 4 Aug 2019 09:45:39 +0000

----- Original Message -----
From: "Nico Williams" <[email-masked]>
Sent: Thursday, August 01, 2019 9:50 PM

> lots of discussion was had on-list.

It could be Dave Garrett's post on Obscure ciphers 23sep15, which got
little reaction on the list, or Eric Rescorla Deprecate DH_anon 28aug15
or Eric Rescorla's Key hierarchy while Eric Rescorla's PSS support was
approved by Joseph Salowey based on prior list discussions - I did not
see any other reaction to the PR.   PR508 was 'Barring any objections
I'll merge this PR' -noone objected.

Eric Rescorla's 'Should we require implementations to send alerts' did
provoke a lengthy discussion on the list as did PR#209 or the PR for
anti-downgrade mechanism around the same time..

The TLS WG made extensive use of PRs, some generated discussion, others
did not; whether the PRs killed discussion I find hard to say - the TLS
list is probably the busiest list and that from many and expert
contributors (unlike some busy lists which seem more an exercise for
script kiddies and such like :-)

I note that
On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.

which seems to chime with some of this thread.  I don't know what the
view is now, four years on.

Tom Petch

---

From: Eliot Lear <[email-masked]>
Date: Sun, 4 Aug 2019 20:32:53 +0200

I mostly agree.  When people say that there is some value to using Github.com where the tooling use is marginal, that’s where the network effect gets me a little concerned, as to whether we’ll all have choices in the future.  And the IAB should be a little concerned about that as well, given all of their focus on market concentration.

Eliot

> On 3 Aug 2019, at 22:10, Randy Bush <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Aug 2019 14:58:28 -0400

tom petch <[email-masked]> wrote:
    > then a small improvement on the work done on mailing lists would do
    > more for us than a big improvement for the work done in meetings.

I agree with you: we need to improve our ability to use the lists.

If we could improve mailing list use, then we could make better progress.
There are a bunch of us who still know and remember how to Usenet quote well.
We have the right tools, and they are under our control (and don't change
randomly with upgrades).

I think that a difficulty we have between github issues and mailing lists
is that those that many that prefer github never learnt how to use mail
properly.  That's part of the gap, but not all of it.

My "peers" (45+-10yr) have mostly moved to Apple Mail (or Outlook on Mac),
have often (but not universally) forgotten to turn off HTML ("my comments are
on red"), and now quote paragraphs which leads to mangled attributions.

This pushes the newer people, who can not sort it out, to github.
Meanwhile, me and my peers live in email, not browser (not gmail).

I rather like github for DESIGN TEAMS, but I don't like it for reviews and
WGLC review.  Yes, I opened a 100+ issues (for BRSKI) based upon reviews, but it
was me that did that, not the reviewers.  I used github to keep track of my
work, and I recorded that to the mailing list.

I have not experienced the github integration that brings things more clearly
back to the mailing list.  I should do this for CELLAR and see how it works.

    > whatever it is we want to change, be it reducing mistakes, speeding up

If you are saying that we have a lack of uniformity in what level of
involvement WG chairs have with progressing documents, then I agree!

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

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 04 Aug 2019 12:09:55 -0700

> I mostly agree.  When people say that there is some value to using
> Github.com where the tooling use is marginal, that’s where the network
> effect gets me a little concerned, as to whether we’ll all have
> choices in the future.  And the IAB should be a little concerned about
> that as well, given all of their focus on market concentration.

you are talking to one of the many sysadmins who is in the "google
rejects email over ipv6" hell this week.  so i hear you, bigtime.

randy

---

From: Nico Williams <[email-masked]>
Date: Sun, 4 Aug 2019 15:48:53 -0500

> I'll merge this PR' -noone objected.

Yeah, that sort of thing.  Each case by itself might not terribly
concerning, and some may point out a benefit: we get version history.
But it raises some concerns:

 - does the WG not do enough consensus calls?
 - can that even scale for an effort like TLS 1.3?

   (I'm guessing "no", and "not sure".  Process scalability for
   fast-moving standards development efforts is a real concern.)

 - does this end up supplanting proper review during a WG LC?

   (Well, it's up to the reviewers to do a proper review.)

> anti-downgrade mechanism around the same time..

Maybe GH + list works.

> script kiddies and such like :-)

I think of the TLS WG list as a DoS on its participants but maybe it's
nothing like this list!

> view is now, four years on.

Provided we have an agent subscribed to e-mail notifications from GH
forwarding to the WG list, it can work, though I don't know what happens
to replies from non-GH users -- does GH show them in its UI?

GH's e-mail support is rather basic, and not really good enough for an
e-mail-based org like IETF.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Aug 2019 17:11:10 +0200

Apropos this very long thread, here’s an article about a lawsuit filed against GitHub for the Capital One break.  The article states that the plaintiffs have their facts muddled, but there’s a good chance that somewhere along the way, there will be a lawsuit that will win, leading to unpredictable changes.  This is not an argument to NOT use GH, but rather to simply not abandon our core methods so that we can survive that eventuality.

Eliot

https://www.zdnet.com/article/github-sued-for-aiding-hacking-in-capital-one-breach/?fbclid=IwAR2FtQZydp99QlcA859vTGaQo9xXEn3FzP-26Vr9VUrbNE90Pw2OHR36lAw

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2019 16:21:13 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>Apropos this very long thread, here’s an article about a lawsuit filed against GitHub for the Capital
>One break.  The article states that the plaintiffs have their facts muddled, but there’s a good chance
>that somewhere along the way, there will be a lawsuit that will win, leading to unpredictable changes. 
>This is not an argument to NOT use GH, but rather to simply not abandon our core methods so that we can
>survive that eventuality.

I read the complaint.  If I were Github, I would reply that this suit
against them is totally barred by 47 USC 230(a)(c)(1), and ask the
court to award costs and sanction the lawyers.  (That's the (in)famous
Communication Decency Act, for people who haven't been following along.)

They may have a plausible case against Capital One for negligence, but
suits against online services for hosting third party content are
specifically barred by the CDA, there is a mountain of case law saying
that the law means what it says, and I would have grave doubts about
the competence of a lawyer in this field who doesn't know that.
Usually suits like this have some sort of hand wave claiming that CDA
doesn't apply, but this one doesn't even mention it.

I'm not denying that something bad might happen to Github sometime but
this is not the path that badness is likely to take.

R's,
John

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 07 Aug 2019 10:31:42 +1000

That's a pretty big stretch.

Work the IETF does could be made illegal in any jurisdiction at any time, either by a court decision or by legislation. Our protocols could be declared illegal due to allowing bad people to communicate using encryption, for example. We can't predict the future with 100% accuracy.

Planning to be able to use more than one external service provider and change over time is basic prudence, but planning for the entire concept of how we might use GitHub to be made illegal in a decision that doesn't also seriously damage the ability for IETF's own tools to be used is not realistic threat modeling.

Bron.

On Wed, Aug 7, 2019, at 01:12, Eliot Lear wrote:
> *Attachments:*
>  * signature.asc