Subject: Re: [Ietf-and-github] WG documents and pull requests, issues, and WG mail

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Oct 2016 18:14:12 -0400

That description seems to allow for asubstantive technical issue to be 
raised, discussed, resolved, documented, and closed antirely on the 
github issue tracker.

that seems to me to violate a cardinal rule.  Technical issues have to 
be resolved by the WG on the WG email list.

Much as with a design team, the design team can use any process it 
wants, and it is nice when that process is more public.  But technical 
issue finalization needs to be on the WG list.

Yours,
Joel

On 10/28/16 6:01 PM, Mark Nottingham wrote:
>
>> On 28 Oct. 2016, at 10:08 pm, Salz, Rich <[email-masked]> wrote:
>>
>>
>>> 1) Just follow the WG mailing list, and become aware of things that happened
>>> in Github through the drafts and on-list change summaries / notifications
>>> 2) #1 + following the WG issues mailing list (generated from Github
>>> comments)
>>> 3) Just engage on Github (e.g., by filing issues, commenting and making pull
>>> requests)
>>
>> Not clear to me where you intend/want discussions to happen.
>
> See:
>   https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Oct 2016 09:24:51 +1100

> On 29 Oct. 2016, at 9:14 am, Joel M. Halpern <[email-masked]> wrote:
> 
> That description seems to allow for asubstantive technical issue to be raised, discussed, resolved, documented, and closed antirely on the github issue tracker.
> 
> that seems to me to violate a cardinal rule.  Technical issues have to be resolved by the WG on the WG email list.
> 
> Much as with a design team, the design team can use any process it wants, and it is nice when that process is more public.  But technical issue finalization needs to be on the WG list.

It's been said by others a few times here in a few different ways, but I'll repeat in a slightly different way.

The issue tracker is for the benefit of the chair(s) and editors, and interested observers, to see the state of the draft production, and manage the discussion. It does not track consensus (in the sense that all closed issues are *not* assumed to have unassailable consensus). 

Even if someone chooses to ignore Github, and refuses to subscribe to the mailing list set up for people who don't want to use GitHub, they will be informed of the changes when the new draft comes out, and have an opportunity to question them, the motivation behind them, etc. -- in the venue (mailing list or issues list) that they prefer. 

If there's contention between two parties that can't be resolved in an issue, discussion always gets popped to the mailing list, as the canonical place for "real" discussion. 

As such, consensus is established on the mailing list. And, of course, consensus is also confirmed in WLGC and IETF LC.

This process has been discussed extensively with and cleared by multiple ADs. Offing a means for people to contribute *other* than the mailing list has proved invaluable, in that it allows people who aren't full-time standards participants to more effectively engage, often using a toolchain that is more comfortable for them.

Regards,

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 28 Oct 2016 17:08:32 -0700

It seems to me that there needs to be a link between github and WG mailing lists. 

Unless github Issue and PR notifications are forwarded to the WG mailing list, the WG will have no archive of when Issues were raised or changes were proposed. Without forwarding Merge notifications there will be no WG archive of when changes were made. Without close notifications there will be no archive of when Issues or PRs were closed.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 28 Oct 2016 20:32:30 -0400

On Fri, Oct 28, 2016 at 8:08 PM, Bernard Aboba <[email-masked]>
wrote:

> Unless github Issue and PR notifications are forwarded to the WG mailing
> list, the WG will have no archive of when Issues were raised or changes
> were proposed. Without forwarding Merge notifications there will be no WG
> archive of when changes were made. Without close notifications there will
> be no archive of when Issues or PRs were closed.
>

Sure there is: the git reflog tracks all the changes and commit messages
along with the commit date. Starting with a single invocation of "git log",
you can then correlate changes and discussions by date between the mailing
list and github similarly to how you'd have to correlate discussions across
threads on the mailing list. Auditing or determining what was decided when
should be quite straightforward.

Furthermore, integrity guarantees are even better than those for a mailing
list because if someone attempts to modify the commit history, everyone
who's pulled a copy of that repository will notice the next time they try
to pull the latest commits. Changes in git are protected cryptographically.

Would copying the mailing list on changes to the master branch be too much
noise relative to whatever value there is in doing so? I don't personally
see much value since I know how to view the commit log.

Kyle

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 30 Oct 2016 01:16:43 -0500

> This process has been discussed extensively with and cleared by multiple ADs. Offing a means for people to contribute *other* than the mailing list has proved invaluable, in that it allows people w…

Does it also allow a means for people to contribute that is not subject
to the NOTE WELL?

-Ben

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Oct 2016 17:33:40 +1100

No, the repo's contributing.md includes NOTE WELL, and github puts up a notice about it when you create an issue or submit a pull. 

Sent from my iPhone

> On 30 Oct. 2016, at 5:16 pm, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 30 Oct 2016 19:46:32 +0200

Do we have a canonical contributing.md? Can you provide a link?

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Oct 2016 18:21:20 +0000

> Do we have a canonical contributing.md? Can you provide a link?

The IESG asked the IAOC legal folks for such text. I think we're
waiting to get the final version back after a bit of iterating.

S.

>> No, the repo's contributing.md includes NOTE WELL, and github puts up
>> a notice about it when you create an issue or submit a pull.
>>
>> Sent from my iPhone
>>
>>>> This process has been discussed extensively with and cleared by
>>>> multiple ADs. Offing a means for people to contribute *other* than
>>>> the mailing list has proved invaluable, in that it allows people who
>>>> aren't full-time standards participants to more effectively engage,
>>>> often using a toolchain that is more comfortable for them.
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Oct 2016 09:09:02 +0000

I suppose it was obvious that people would use git-hub for IETF work, I 
have certainly been using it as a way of managing the drafts that I 
write, but the thread that just started causes me to ask a couple of 
questions:

Firstly whether the IETF should more formally adopt Git technology as 
its in-house draft management system once a document becomes a WG document?

Secondly with the move to .md isn't it time that we allowed the markdown 
files to be uploaded with the draft in a similar way to .xml. I used to 
do the .xml upload just as a way to recover the source if I lost it 
locally, however for a number of us, .xml is no longer the source, but 
an intermediate file is on of no real use until the RFC Editor ask for it.

Stewart

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Oct 2016 10:45:27 +0100

The issue has more to do with where one finds a record of important
decisions AND discussions and under whose control that resides.  The
fates of the IETF and Github are not shared.  That's a solvable problem,
but it should be solved.

Eliot

On 10/29/16 2:32 AM, Kyle Rose wrote:
> On Fri, Oct 28, 2016 at 8:08 PM, Bernard Aboba
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Unless github Issue and PR notifications are forwarded to the WG
>     mailing list, the WG will have no archive of when Issues were
>     raised or changes were proposed. Without forwarding Merge
>     notifications there will be no WG archive of when changes were
>     made. Without close notifications there will be no archive of when
>     Issues or PRs were closed.
>
>
> Sure there is: the git reflog tracks all the changes and commit
> messages along with the commit date. Starting with a single invocation
> of "git log", you can then correlate changes and discussions by date
> between the mailing list and github similarly to how you'd have to
> correlate discussions across threads on the mailing list. Auditing or
> determining what was decided when should be quite straightforward.
>
> Furthermore, integrity guarantees are even better than those for a
> mailing list because if someone attempts to modify the commit history,
> everyone who's pulled a copy of that repository will notice the next
> time they try to pull the latest commits. Changes in git are protected
> cryptographically.
>
> Would copying the mailing list on changes to the master branch be too
> much noise relative to whatever value there is in doing so? I don't
> personally see much value since I know how to view the commit log.
>
> Kyle
>

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 31 Oct 2016 10:37:05 +0000

+1 to uploading markdown directly

- - Jaime Jiménez

> On 31 Oct 2016, at 11:09, Stewart Bryant <[email-masked]> wrote:
> 
> 
> I suppose it was obvious that people would use git-hub for IETF work, I have certainly been using it as a way of managing the drafts that I write, but the thread that just started causes me to ask a couple of questions:
> 
> Firstly whether the IETF should more formally adopt Git technology as its in-house draft management system once a document becomes a WG document?
> 
> Secondly with the move to .md isn't it time that we allowed the markdown files to be uploaded with the draft in a similar way to .xml. I used to do the .xml upload just as a way to recover the source if I lost it locally, however for a number of us, .xml is no longer the source, but an intermediate file is on of no real use until the RFC Editor ask for it.
> 
> Stewart
>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 31 Oct 2016 12:48:53 +0000

> +1 to uploading markdown directly

Which version, or don't we care?

I use Kramdown.  I know others use Miek Gieben's version.

Ray

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Oct 2016 12:56:33 +0000

> I use Kramdown.  I know others use Miek Gieben's version.

I also use Kramdown, but why not accept both?

Stewart

---

From: thomas nadeau <[email-masked]>
Date: Mon, 31 Oct 2016 09:37:26 -0400

As you might imagine, the IETF is not the first to use git hub in this way so there are many options.

Github has a built in issue tracker that can also be linked with specific versions of the file.

If the IETF is uncomfortable with github being external, there are both free and commercial options for running it locally.

Its not a matter of if, but how and when. 

tom

> On Oct 31, 2016, at 5:45 AM, Eliot Lear <[email-masked]> wrote:
> 
> The issue has more to do with where one finds a record of important decisions AND discussions and under whose control that resides.  The fates of the IETF and Github are not shared.  That's a solvable problem, but it should be solved.
> 
> Eliot
> 
> 
> 
>> On Fri, Oct 28, 2016 at 8:08 PM, Bernard Aboba <[email-masked]> wrote:
>> Sure there is: the git reflog tracks all the changes and commit messages along with the commit date. Starting with a single invocation of "git log", you can then correlate changes and discussions by date between the mailing list and github similarly to how you'd have to correlate discussions across threads on the mailing list. Auditing or determining what was decided when should be quite straightforward.
>> 
>> Furthermore, integrity guarantees are even better than those for a mailing list because if someone attempts to modify the commit history, everyone who's pulled a copy of that repository will notice the next time they try to pull the latest commits. Changes in git are protected cryptographically.
>> 
>> Would copying the mailing list on changes to the master branch be too much noise relative to whatever value there is in doing so? I don't personally see much value since I know how to view the commit log.
>> 
>> Kyle
>> 
>

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 13:49:11 -0400

I am firmly opposed to the use of GitHub or any tool that does not support IPv6.

Another Git repository that does support IPv6 would be acceptable, although I question whether we really need to add another tool newcomers have to learn in order to contribute.

Discussion of ways to author is probably appropriate on rfc-interest https://www.rfc-editor.org/mailman/listinfo/rfc-interest
The initial block of documents is approaching publication, and will form the basis of experiments for expected revisions. The current cluster calls for the XML version to be canonical, with publication in HTML, PDF, and text, but of course you can create XML any way you choose. 
I have no opinion on document creation languages, as long as the barrier is as low as possible for newcomers to contribute to the IETF.

Lee

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Oct 2016 17:53:59 +0000

> I am firmly opposed to the use of GitHub or any tool that does not

Not unreasonable. But I think maybe the better way to try address
that is to hassle the service provider to add v6.

> 
> Another Git repository that does support IPv6 would be acceptable,
> although I question whether we really need to add another tool
> newcomers have to learn in order to contribute.

Some (many? most?) newcomers will be familiar with github but
won't ever have heard of xml2rfc. I'm not sure of the numbers
there, but would not be surprised to hear that github is far
far more widely known than any IETF tooling.

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Oct 2016 13:58:41 -0400

> that is to hassle the service provider to add v6.

And one way to hassle them, of course, is to make it clear that the
IETF might consider their services as a fully-supported part of our
system if there were v6 connectivity, but that they're off the list
until such time.

(Of course, people can use whatever tools they want informally.  It's
None of Our Business).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 31 Oct 2016 11:15:36 -0700

On Mon, Oct 31, 2016 at 10:53 AM, Stephen Farrell <[email-masked]

> that is to hassle the service provider to add v6.
So, if I am reading dig's output correctly, github is hosted by aws, which
only added support for IPv6 to S3 in August:
https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/
and the support requires moving to dual-stack endpoints.

So let's not hassle the service provider, but gently indicate that their
taking advantage of this would be appreciated, eh?  If we are going to
spend money with them, I'm happy to make this a requirement, but if we are
not, encouragement would be in order.

regards,

Ted

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 14:20:13 -0400

>system if there were v6 connectivity, but that they're off the list

I have hassled them. 
https://twitter.com/GitHubHelp/status/771071358147133441

(And yes, I know Twitter also doesn't support IPv6; I have also hassled them).

Lee

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Oct 2016 18:25:02 +0000

> I am firmly opposed to the use of GitHub or any tool that does not support IPv6.

I just want to use the tool suite that gives us the best Internet 
protocol designs. That is a tool suite that is forgiving of mistakes, 
and takes almost no concentration, so that the author can focus entirely 
on getting the design right and expressing that clearly, and give zero 
thought to the tools.

Stewart

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Oct 2016 15:15:25 -0400

> I am firmly opposed to the use of GitHub or any tool that does not

I agree strongly with this sentiment. I've had to installed a NAT64/DNS64
for some of my v6-only backend infrastructure could clone from github...

Would it be acceptable to you in the short/middle term if all repos were
cloneable from another site (within tools.ietf.org) that supported IPv6?
That's the brilliance of git...

    > newcomers have to learn in order to contribute.

The rational for using github is that it's a tool that newcomers already
know.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Oct 2016 19:16:54 +0000

>     > I am firmly opposed to the use of GitHub or any tool that does not

Yeah, and while we're at it, let's make sure they only use TLS 1.2 and OCSP stapling and HTML5, and ...

No.

---

From: Kyle Rose <[email-masked]>
Date: Mon, 31 Oct 2016 15:26:27 -0400

> That's the brilliance of git...

Having given this additional thought over the weekend, Bernard's statement
to which I replied:

> Without close notifications there will be no archive of when Issues or
PRs were closed.

isn't quite precise enough. With git, we will absolutely know when they
were closed. What won't be in the git log is the discussion in the pull
request: the comments on individual diffs that would be helpful in
exploring the background of, and justification for, a change by someone who
wasn't involved at the time.

This probably argues for an IETF-owned github instance, where all of this
data would be subject to our data retention requirements. I suppose we
could alternatively copy the comment log to a mailing list, but probably
the nicest feature of github is the organization of the metadata into
self-contained threads of discussion that are tied directly to commits:
demuxing this into individual emails is a step backward.

> The rational for using github is that it's a tool that newcomers already

Strongly agreed. Github and markdown are at worst no barrier to
participation, and at best (and likely) encourage it.

Kyle

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 15:37:06 -0400

>Yeah, and while we're at it, let's make sure they only use TLS 1.2 and OCSP stapling and HTML5, and ...

There's a fundamental difference between IPv4, where a middlebox is required to munge packet headers to provide base connectivity to a substantial number of hosts, and the improved security offered by TLS and OCSP stapling [1] in the course of public conversation. HTML5 requires backward interoperability.

IPv4 is going away, and patches to keep it going will become less acceptable. Adopting a tool that requires it will hold us back.

Lee

[1] Although how a host knows cert status is a concern. Not to mention that few OCSP servers support IPv6.

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 15:39:07 -0400

From:  Kyle Rose
Date:  Monday, October 31, 2016 at 3:26 PM
To:  Michael Richardson
Cc:  Time Warner Cable, WG Chairs
Subject:  Re: use of Git-hub

Strongly agreed. Github and markdown are at worst no barrier to participation, and at best (and likely) encourage it.

Interesting assumption.  As a network engineer, I have never used either.

Lee

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Mon, 31 Oct 2016 15:56:16 -0400

> Interesting assumption.  As a network engineer, I have never used either.

Have you used XML? :-)  Markdown is much easier to read and write, even if
you know XML.

Git is just one tool among many for tracking changes, and Github a superset
of that for encapsulating the entire change control process. There's no
theoretical advantage to using git over hg or SVN or CVS or flat text files
in Dropbox or morse code via smoke signal or text diffs on a mailing list:
they can all express the same things, with varying degrees of difficulty.
There is, however, a practical advantage to standardizing on a fairly
complete set of tools that are easy to learn, allow changes to be made
quickly after a decision is reached, permit focused discussion around each
point of contention so there's less noise for everyone else, and that are
already quite popular in the software development community.

Kyle

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 31 Oct 2016 16:30:30 -0400

On Mon, Oct 31, 2016 at 2:15 PM, Ted Hardie <[email-masked]> wrote:

> On Mon, Oct 31, 2016 at 10:53 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>>
> only

I think only the DNS for github is on AWS, I think because of the dyn
fiasco last week :( I say this because I see the NS rr-set change from
everydns -> dynect -> awsdns in some passivedns databases (with dynect
disappearing and aws appearing about the time of the attack(s) last week).

the github clients I have all have a remote like:
origin  github.com:google/rpki-mgmt.git

that hostname resolves to an address routed by AS36459, that ASN announces:
2620:112:3000::/44
into the dfz... all the github.com targets I see in passive dns go back to
their 192.30.252.0/22 address space.
 -chris