Subject: Re: [Last-Call] Last Call: <draft-ietf-git-using-github-04.txt> (Working Group GitHub Usage Guidance) to Best Current Practice

From: S Moonesamy <[email-masked]>
Date: Mon, 09 Mar 2020 17:03:33 -0700

Hello,
At 07:23 AM 18-02-2020, The IESG wrote:
>The IESG has received a request from the GitHub Integration and Tooling WG
>(git) to consider the following document: - 'Working Group GitHub Usage
>Guidance'
>   <draft-ietf-git-using-github-04.txt> as Best Current Practice
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2020-03-03. Exceptionally, comments may

This intended BCP recommends a sole provider.  I don't consider it as 
a good idea for a standards development organization to make such a 
recommendation when the organization argues against centralization 
and single points of failure in its RFCs and statements.

The draft acknowledges that the recommended provider only supports 
IPv4.  That is correct:

   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52462
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

   ;; QUESTION SECTION:
   ;github.com.                    IN      AAAA

   ;; AUTHORITY SECTION:
   github.com.             60      IN      SOA     ns1.p16.dynect.net.
   hostmaster.github.com. 1583613295 3600 600 604800 60

If I am not mistaken, the reason for "dogfooding" is that it provides 
some evidence that the IETF has confidence in its specifications will 
work, as designed, for the services which complies with those 
specifications.  Is the choice of GitHub based on a market-driven approach?

There is the following in Section 1: "Use of this service has been 
found to reduce the time that Working Groups need to produce 
documents and to improve the quality of the final result".  Is there 
any data from different IETF Areas to back that claim?

In Section 2.1:

   "The owner team for a Working Group repository MUST include responsible
    Area Directors."

Isn't there only one Responsible Area Director per Working Group?

In Section 4.1.3:

   "Issues that have reached a resolution that has Working Group
    consensus MUST NOT be reopened unless new information is presented."

Shouldn't that be "rough consensus" as per RFC 2418?

There is a citation to RFC 2026 in Section 7.  Shouldn't that be RFC 2418?

What is the meaning of "selection biases" in Section 7?

Regards,
S. Moonesamy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2020 18:05:44 -0700

> and single points of failure in its RFCs and statements.

This is what is known as "paving the cowpaths". Github is what people have
voted with their feet to use. I don't think that the arguments against
centralization
and SPOF really apply here: it's not like a temporary outage in people's
ability
to write Pull Requests is going is going to bring the Internet down, and of
course the IETF services themselves are already centralized.

Moreover, all of this was extensively litigated when the WG was formed
and it's quite clear that the intent was to focus on Github.

  The GitHub Integration and Tooling (GIT) working group will select a
  set of such practices and document policies that support those
  practices. The policies will each detail how work is conducted by
  working groups that opt to follow the work practice. The goal is to
  provide both process and tooling support for working groups that
  choose to adopt the practices.

It's even right there in the name of the WG.

>    hostmaster.github.com. 1583613295 3600 600 604800 60

This seems like more of a statement about IPv6 than about Github.

> specifications.  Is the choice of GitHub based on a market-driven approach?

I'm not sure what you mean by a "market driven approach", but as I said,
the choice of Github is one based on people voting with their feet.

-Ekr

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Mar 2020 02:00:22 +0000

*   the choice of Github is one based on people voting with their feet.

Yes.  We see many docs and WG’s using GitHub, and having a BCP on how to do that is a good thing.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 09 Mar 2020 21:14:26 -0700

Dear Mr Rescorla,
>the choice of Github is one based on people voting with their feet.

It is an approach where the customers decide which products or 
services they wish.  It is similar to the "people voting with their 
feet" in the above.

Regards,
S. Moonesamy

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 10 Mar 2020 13:16:19 +0000

Hello SM,

Thank you, as usual, for your comments.

As an IESG member, I balloted an ABSTAIN [1] on this document mainly for two issues that you also listed:
- IPv4-only in 2020 for the IETF? Really ?
- relying / advising to use a single commercial company web site (even if Microsoft won't go bankrupt any time soon but their 'free access to everyone' rule can be changed anytime)

I am still amazed by those 2 documents even if I am a daily users of github.com (for personal use) and of a corporate bitbucket (for business).

Regards

-éric

[1] ABSTAIN as in "I oppose this document but understand that others differ and am not going to stand in the way of the others." Per https://www.ietf.org/standards/process/iesg-ballots/

-----Original Message-----
From: last-call <[email-masked]> on behalf of S Moonesamy <[email-masked]>
Date: Tuesday, 10 March 2020 at 01:09
To: "[email-masked]" <[email-masked]>
Subject: Re: [Last-Call] Last Call: <draft-ietf-git-using-github-04.txt> (Working Group GitHub Usage Guidance) to Best Current Practice

    Hello,

    
       ;; Got answer:
    
       ;; QUESTION SECTION:
       ;github.com.                    IN      AAAA
    
       ;; AUTHORITY SECTION:

    
    In Section 2.1:

    
    In Section 4.1.3:

    

    Regards,
    S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Mar 2020 17:17:45 -0700

Hi Eric,
At 06:16 AM 10-03-2020, Eric Vyncke (evyncke) wrote:
>- relying / advising to use a single commercial company web site 
>(even if Microsoft won't go bankrupt any time soon but their 'free 
>access to everyone' rule can be changed anytime)
>
>I am still amazed by those 2 documents even if I am a daily users of 
>github.com (for personal use) and of a corporate bitbucket (for business).

Microsoft could decide that GitHub no longer fits in its 
strategy.  It could decide that the current "free access to everyone" 
offer is no longer viable.  I also have some experience of problems 
... I prefer not to recommend or rely on a single commercial company 
because of that.

I took a quick look at the other draft from the working group.  The 
document is intended to spur discussion.  It is debatable whether it 
achieved the intended purpose.

Regards,
S. Moonesamy

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Mar 2020 08:23:18 +0100

On Tue, 2020-03-10 at 17:17 -0700, S Moonesamy wrote:
> > As an IESG member, I balloted an ABSTAIN [1] on this document
> > mainly for two issues that you also listed:
> > I am still amazed by those 2 documents even if I am a daily users
> > of github.com (for personal use) and of a corporate bitbucket (for
> > business).
> 
> strategy.  It could decide that the current "free access to
> everyone" offer is no longer viable.  I also have some experience of
> problems .... I prefer not to recommend or rely on a single
> commercial company because of that.

I have the same skepticsm about naming a specific commercial provider. 
the draft would do well to just use Github as an example of such a
service.  the advice in the draft is mostly generic for a) version
controlled maintenance and b) (non-)reliance on a third-party site.

the *ideal* solution, in my opinion, would be a self-hosted
gitlab.ietf.org.  the open source version of Gitlab ("community
edition") is very capable and easy to set up and maintain.

gitlab.com is also IPv4 only, but it supports IPv6 nicely, e.g., here's
my employer's installation:

;; ANSWER SECTION:
gitlab.redpill-linpro.com. 3600	IN	AAAA	2a02:c0:400:12::5
gitlab.redpill-linpro.com. 3600	IN	A	87.238.60.92

-- 
regards,
Kjetil T.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Mar 2020 11:52:40 +0100

> gitlab.redpill-linpro.com. 3600	IN	A	87.238.60.92

Sounds as a good idea gitlab.ietf.org and IPv6.

Alex

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Mar 2020 18:26:18 -0700

Hi Kjetil,
>controlled maintenance and b) (non-)reliance on a third-party site.

This is from the Introduction Section:

   "The main purpose of this document is providing guidelines for how
    Working Groups might integrate the capabilities provided by GitHub
    into their processes for developing Internet-Drafts."

That is far from generic.  There is also a similar statement in 
Section 1.4.  The "Organizations" (Section 2.1) may be specific to 
the commercial provider.

>gitlab.redpill-linpro.com. 3600 IN      A       87.238.60.92

I don't know whether that was considered by the working group in the 
discussion of Section 1.2.

Did the working group also consider recommending that IESG members 
file their comments and other issues as per Section 4.1?  That would 
enable a working group to implement Section 4.1.3.

Regards,
S. Moonesamy

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Mar 2020 02:43:18 +0100

> Section 1.4.  The "Organizations" (Section 2.1) may be specific to 

no objection there.  what I meant is that the advice itself applies
more broadly than stated in the introduction and elsewhere.  it is
quite doable to rewrite these references and descriptions of mechanisms
so that they are less locked into the terminology of a single provider.

> enable a working group to implement Section 4.1.3.

I have not followed the work of the WG, so I do not know.

-- 
regards,
Kjetil T.