On Mon, Mar 9, 2020 at 5:09 PM S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
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
>last-call@xxxxxxxx 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.
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.
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.
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
This seems like more of a statement about IPv6 than about Github.
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?
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
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
