Re: New Non-WG Mailing List: Ietf-and-github -- Discussion of using GitH

Benson,

> It seems to me that it would be inefficient for the IETF to do everything 
> ourselves.
I share the original concern, but Benson has hit a key point here. We are a 
part of the ecosystem, and while the technology that we produce at the IETF is 
very much “bottom of the stack”, this isn’t necessarily the case for the tools 
that we use for our discussions, document sharing and other activities. There’s 
a wealth of collaboration tools where it is simply more effective to use what 
the rest of the world uses. Not so much because of possible costs, but because 
it is easier to use tools that are widely available.

But of course, the devil is in the details. It is important to what extent we 
retain control, how IETF participants get sufficient ability to choose their 
own tools, we have originals&information to switch other systems or as backups, 
etc. To take a non-github example, we share some of IETF material as YouTube 
videos, but we retain the original video files.

Dave,

> The topic, here, is collaboration.  That is, the activity of developing an 
> I-D by a group.  So it only needs to be useful today.  It doesn't have to be 
> useful tomorrow.  As noted, this is about an integrated service, not just a 
> technology.
Right

> ps. With respect to archiving, the IETF in fact does not do museum-level 
> long-term protection of its data.  Nor should it.  But it /should/ plug its 
> output into a place that does. Museum-quality archive is an entirely 
> different animal from daily crash protection, which of course the IETF does 
> do.
Heather can talk you about that; we have made some progress in doing just that.

John,

> FWIW, I'm actually concerned about the trends toward making
> xml2rfc a requirement rather a useful optional tool.

What were you thinking here, specifically? Many of us work on xml2rfc, but we 
do indeed allow any working style as long as you can output text and submit 
that, for instance. If that is not the case for everything then maybe there’s 
an improvement opportunity.

Jari

signature.asc
Description: Message signed with OpenPGP using GPGMail