Subject: Long-term IETF evolution thoughts

From: IETF Chair <[email-masked]>
Date: Sun, 12 Jun 2016 12:07:49 +0300

Hi,

In the midst of a day’s discussion about particular issue that troubles us with technology or something else, it can be difficult to focus on topics that have a longer timescale. As you probably remember, I had asked a design team to write a draft about various trends around us that affect the IETF.

We got some feedback on that draft, but the draft stopped short of making specific statements about what the IETF should do. And unless we bring the thoughts to a bit more practical level, the discussion stays abstract and remote. So, I thought I’d try to state my view about what we should focus on in the future, in the hopes that it will generate discussion. Feel free to suggest alternate views or question these!

https://www.ietf.org/blog/2016/06/long-term-ietf-evolution/

Jari Arkko, IETF Chair

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 12 Jun 2016 08:31:21 -0600

"The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet."

tl;dr: I feel sometimes that the IETF mission should be more truthfully restated as "The goal of the IETF is to make the IETF work better", which is not a bad goal in itself, as long as there is a causal relationship between that goal and IETF current goal of "...making the Internet work better".

Firstly I would point out the discrepancy between the recent level of activity in the ietf@ mailing list, and the difficulty we have to get reviews and support for works that are WG items (I am not even talking about new work).  I am not saying that we should not have the kind of discussion we recently had about Singapore, quite the opposite.  It is well established that race, gender, nationality, sexual orientation, etc... are absolutely no indicators of competence in our line of work, so any attempt to exclude members of one of these groups should be actively fought because they are counter-productive to the main goal of the IETF (I left out religion in that list because I have personal difficulties to understand how multiple alternate realities can coexist in the same brain without negatively affecting the one that matters for our job.  I'd like to be educated on that subject, but that's not the place for that).

Now let's look at some of the things listed in the blog entry:

1. Make it easier for people to be involved in the IETF.

I think that it is incomplete.  The goal should be something like "Make it easier for people that can produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet to be involved."

Personally I think that the barrier of entry to contribute to the IETF is already very low.  Effort should be made to be sure that we do not exclude people that meet these criteria, not trying to make things easier for people that cannot contribute to that goal, and ultimately would waste our time.

2. Be even better positioned to use online collaboration.

I am personally not sure that there is a link between increased online collaboration and increase in sustained output quality, but any pointer to peer reviewed studies on that subject will be welcomed.

I understand that increasing of online collaboration, when applied to the IETF, is in fact two different things.  The first one is replacing good old email collaboration by web-based collaboration.  I would use the Linux kernel project, arguably one of the most successful collaborating project, as a counter-example of that trend, as is entirely managed through email, and seems to thrive is spite of having very little other kind of online collaboration.  But I admit that this a high barrier of entry (purposefully so) , so at the very least online collaboration should be seen as a path to the more boring but more efficient way of collaborating which is email, in the same way that Eclipse is the natural path to vim/emacs and Word to WriteRoom (boredom being one of the most powerful force in the universe).

The second one is about replacing or reducing the IETF meetings.  My personal experience is that the IETF meetings are invaluable - my most productive meeting was Dallas 92 which was also the one where I probably attended the lowest number of sessions.  Although it is expensive - the budget to go to all 3 meetings is around $10K per year - I believe it is worth it.  I should note that it takes some time to establish the personal connections that makes it worth spending that kind of money, so any opinion on that subject from people would did not attend at least 4 meetings should be taken with the proverbial grain of salt.

So we should first be sure that online collaboration (as a replacement for email and/or as a replacement for IETF meetings) would really be to attract more people that can produce high quality, relevant technical documents, especially the people that would give up before they can see the advantage of our way of doing things.  But not simply to attract more people for the sake of attracting more people.  This is not Facebook.

3. Focus on linking open standards to code, operationals, and interoperability.

My view on this evolved these last years.  Few years ago I was convinced that developing a reference implementation at the same time than a specification and testing it against other people implementations was the right way to to find bugs in the specification.  I even applied that idea when RFC 6940 was developed.  Sure I found hundred of issues in the draft (and got "punished" for it by becoming - with Dean Willis - informal editors of the draft).  But, in spite of my best efforts, my implementation could not cover 100% of the specification, so if on the one hand that made the specification better, on the other hand it certainly did not made the specification good by any of my standards.  Basically a reference implementation is to a specification what a unit test suite is to a program:  It was a great new technology 15 years ago, and everybody should do it today, but time has passed and there is now good solutions to cover 100% of a specification (or a program).  That is what formal specifications and theorem proving are meant to achieve, and what I have being working on these last 3 years (talk to me in Berlin if that interest you).

So here I think that these goals are good, but insufficient to "make the Internet better."

4. Evolve IETF sponsorship models to focus more on our work than meetings.

Here again, let start looking at what works and what does not work in producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.  That in turn should be cost evaluated.  Then, and only then we can talk on how to finance these.  That's the "technology is at our service, not the other around" principle in action: Let's discuss what we need; then we can find, extend or invent the technologies that are needed to fulfill these needs; finally we can search for ways to pay for that technology.

I would like to add one point to this list.  I believe that small and medium size enterprises are under represented at the IETF.  One of reason would be because of the cost involved in participating - not even the cost of the meetings, but the cost of assigning an engineer to work part or full time on these topics.  But I think that the main reason is hubris - i.e. all startups out there believe that their API/protocol will become the de facto standard, and that they will rule the market because of this superiority.  That, and the fear that collaboration with other people in the same area will make them loose customers, are in my opinion the main reasons for their very low involvement.  I'd like to see ISOC working on a marketing campaign or something like that to try to convince these companies to participate more in the IETF standardization process (disclaimer: as an individual paying out-of-pocket for attending the IETF meetings, I would profit from having more enterprises willing to contract me and my colleagues to work on their behalf at the IETF).

On 06/12/2016 03:07 AM, IETF Chair wrote:
> Hi,
> 
> In the midst of a day’s discussion about particular issue that
> troubles us with technology or something else, it can be difficult to
> focus on topics that have a longer timescale. As you probably
> remember, I had asked a design team to write a draft about various
> trends around us that affect the IETF.
> 
> We got some feedback on that draft, but the draft stopped short of
> making specific statements about what the IETF should do. And unless
> we bring the thoughts to a bit more practical level, the discussion
> stays abstract and remote. So, I thought I’d try to state my view
> about what we should focus on in the future, in the hopes that it
> will generate discussion. Feel free to suggest alternate views or
> question these!
> 

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

---

From: <[email-masked]>
Date: Sun, 12 Jun 2016 15:26:11 +0000 (UTC)

Jari,
Thank you for doing this.  I think that having community input on our path forward (as well as actually having a thoughtful path forward!) is very important.
My first comment is about the involvement of other communities.  You had mentioned Open Source.  That is great but I feel there are some other communities which are under-represented:
1.  Large enterprise operators / other operators2.  Implementors (other than open source)3.  Startups (I believe this was brought up before)
The reason I believe that these are important is because there has to be a feeback loop between standards, implementation and usage.   All too often, this loop does not exist.  
What sometimes happens is, for example, the "end user" of the standard, say the large enterprise, is shocked to find that a feature they had relied upon is now gone with a new version of a standard.   Of course, they were never at the IETF meetings where this was even discussed five years before.   Otherwise, they would have known or been able to give feedback.  I am actually involved in such a case at this very moment.   Some quite lengthy emails have gone back and forth in the last couple of days between a major U.S. corporation and one WG about changes in an upcoming standard.
The larger question, though, is why such people are not involved.  I suspect, that partially, it is similar to the "tragedy of the commons".   Enterprises feel that this affects many of them, so why should they be the ones paying for someone to go?  Why doesn't someone else?  Of course, when everyone feels this way, then no one goes.  Which is where we find ourselves.  I don't want to get completely distracted by numbers but I would bet I could count the number of large enterprises at the IETF on the fingers of my hand.
This is not a winning proposition for the IETF either.   The more people who actually are directly impacted by the standard are involved in providing comments, the better and longer lasting standards we will create.
Any organism (including the IETF) needs an effective feedback loop to thrive.   I hope we can better involve such people in the IETF.  Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jun 2016 08:24:38 +1200

Hi Nalini,
On 13/06/2016 03:26, [email-masked] wrote:
...
>... there are some other communities which are under-represented:
> 1.  Large enterprise operators / other operators

This has been a chronic problem for >20 years. When I first came,
I was in that camp (running the networking group at CERN) but it
was a fight to justify travel funding and to be away from the shop
whenever anything went wrong. Most operations people are two steps
downstream from RFCs (via implementors and salespeople).

At least, we make efforts to reach this community via NANOG, APRICOT,
RIPE and the like.

> 2.  Implementors (other than open source)

If you mean the people actually writing the code, indeed. I don't want
to insult anybody but most vendors don't send coders to standards meetings.
And as somebody commented recently in another context, coders themselves
often don't rely on RFCs, they go look on stackoverflow.com.

> 3.  Startups (I believe this was brought up before)

Most startups focus on getting to revenue and see standards work as unjustified
expense.

So, yes, these are problems but I'm quite pessimistic about solving them.

   Brian

---

From: Melinda Shore <[email-masked]>
Date: Sun, 12 Jun 2016 12:35:59 -0800

On 6/12/16 6:31 AM, Marc Petit-Huguenin wrote:
> I think that it is incomplete.  The goal should be something like
> "Make it easier for people that can produce high quality, relevant
> technical documents that influence the way people design, use, and
> manage the Internet to be involved."

Not to split hairs but Jari didn't say that the goal is to
have more people involved in the IETF.  My reading of his
post was that he'd identified four things in service of the
goals of the IETF, which were left unstated.  Not sure if
that's a good thing or a bad thing - I'd hate to see us
rabbit hole on IETF goals while trying to have this discussion.

> Personally I think that the barrier of entry to contribute to the
> IETF is already very low.

I think the formal barriers are low but it really is difficult
for people outside the current process to know where to start.
I've talked with people who have points they want to raise and
who aren't getting anywhere on the mailing list, and when I
suggest the write it up as an internet draft a number of them
have reacted as if I was asking them to write a paper for
submission to a refereed journal - they see it as a very big
deal indeed.  So, I think there are opportunities to socialize
how the IETF works to lower the perceived barriers to
contribution.

> My view on this evolved these last years.  Few years ago I was
> convinced that developing a reference implementation at the same time
> than a specification and testing it against other people
> implementations was the right way to to find bugs in the
> specification.  I even applied that idea when RFC 6940 was developed.
> Sure I found hundred of issues in the draft (and got "punished" for
> it by becoming - with Dean Willis - informal editors of the draft).
> But, in spite of my best efforts, my implementation could not cover
> 100% of the specification, so if on the one hand that made the
> specification better, on the other hand it certainly did not made the
> specification good by any of my standards.

I think this is a fair point but I'd like to mention what I
thought was one of the more interesting things to happen at an
IETF hackathon, which is that one group found they couldn't
implement a draft in its current form because it was wrong, and
they needed to go back and fix the specification.  I understand
that you're arguing that formal methods would provide greater
coverage, and I agree (and I hope you'll set up a small side
meeting or some such on this in Berlin), but I don't think
it's a minor point that an implementation gives you an implementation.
Ultimately we're not publishing standards just to publish
standards (well, not usually, and we shouldn't be) but because it
bears some relationship to what's going on in the world and
because these documents reflect an actual need (and given the
amount of work being done in the IETF these days I'd like to
see us become a little more rigorous about rejecting work of
questionable utility).

Melinda

---

From: <[email-masked]>
Date: Sun, 12 Jun 2016 20:54:58 +0000 (UTC)

...

>At least, we make efforts to reach this community via NANOG, APRICOT, RIPE and the like.
Let me address the NOG part first.  I think that is true that there is an effort to reach the operator community but the large enterprises that I am talking about do not usually go to the NOG.meetings.   Not that the people who ARE at the NOGs shouldn't be reached out to.   
Now, who exactly am I talking about and why is it important?
I am talking of the large banks, financials, insurance, etc. (in the U.S., we call them the Fortune 1000) as well as the major government agencies who are users of Internet protocols.  The reason I feel this is important is because although their number may be relatively small, they are the backbone of our economies.   Changes to Internet protocols have a huge impact on their operations.   This, of course, in turn impacts all of us who use their services.
In the past, I tried for a number of years to get some of these companies to come to IETF.  (My life has been mis-spent living in that world!  )   They would let me make presentations to quite a high level of management, but I was unsuccessful for the most part.   I made the presentations because I thought it was in THEIR interest to be involved with what was happening at the IETF so they could plan strategically for the future.   They usually ended up saying, "You go and tell us what happened."    I actually had given up on trying to get them to attend for about two years.
Having said that, I am very much getting the sense that things may be changing.   I think this may be because of the impact in particular of security and the related protocols.  I have spent the weekend in lengthy conversations between people in a particular WG and the network operations manager of a major U.S. corporation.   The network ops manager is trying to get funding to come to Berlin.  I hope he can.   The changes that will happen because of a particular change to a standard will have a MAJOR impact on their operations and he certainly sees that.
I am wondering if the time is right for some outreach to this community.   I think the story above may resonate with other enterprises.   
Nalini

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jun 2016 20:15:39 -0400

IETF Chair <[email-masked]> wrote:
    > making specific statements about what the IETF should do. And unless we
    > bring the thoughts to a bit more practical level, the discussion stays
    > abstract and remote. So, I thought I’d try to state my view about what
    > we should focus on in the future, in the hopes that it will generate
    > discussion. Feel free to suggest alternate views or question these!

> 4. Evolve IETF sponsorship models to focus more on our work than meetings.

and I really could not agree more.
I agree with you that our model should change from meeting focused to work focused.

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Jun 2016 13:55:52 +0300

Marc, Nalini, Melinda, Michael — thanks for your comments.

All good points.

I wanted to send a few quick responses on some parts, leaving the rest for further thinking:

First, I did not indeed start out by stating what I think the goals of the IETF should. But FWIW, I was mostly thinking of them from the perspective of the existing mission statement. That is, improving the Internet is the bigger goal, and any other steps that we might strive for are intermediate steps that support that higher goal.

> how the IETF works to lower the perceived barriers to

I agree this is an opportunity.

I’d like to add that while the formal and initial bar for submitting a draft and participating in mailing list is low, that is not necessarily true of the whole process. People might look at the process of creating a new working group through BOFs etc with some apprehension, for instance.

Marc wrote:

> I think that it is incomplete.  The goal should be something like "Make it easier for people that can produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet to be involved.”

Yes

> Personally I think that the barrier of entry to contribute to the IETF is already very low.  Effort should be made to be sure that we do not exclude people that meet these criteria, not trying to m…

Fair point as well. See above for the barrier part though.

> The second one is about replacing or reducing the IETF meetings.  My personal experience is that the IETF meetings are invaluable

I do too.

> But I think that the main reason is hubris - i.e. all startups out there believe that their API/protocol will become the de facto standard, and that they will rule the market because of this superiority.  That, and the fear that collaboration with other people in the same area will make them loose customers, are in my opinion the main reasons for their very low involvement.  I'd like to see ISOC working on a marketing campaign or something like that to try to convince these companies to participate more in the IETF standardization process

The small and medium sized enterprises are indeed underrepresented.

I do have two comments though. First, different companies have of course different strategies on how they plan to succeed. Some believe collaboration and standards are part of that; others simply build on top of the Internet and do not need standards. Both modes of operation are quite reasonable. I don’t think we can make companies collaborate and standardise when they don’t have an internal reason to do. But I think there’s enough companies that have that drive, for us to work with them and improve the Internet…

Nalini wrote:

> The more people who actually are directly impacted by the standard are involved in providing comments, the better and longer lasting standards we will create.
> 
> Any organism (including the IETF) needs an effective feedback loop to thrive.

Very well put! +1

Jari

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 13 Jun 2016 10:37:25 -0600

> On 6/12/16 6:31 AM, Marc Petit-Huguenin wrote:
[...]
> meeting or some such on this in Berlin), 
 
Yes hackathons are great, and that and rfc6982 are a huge improvements.  But that's short term, on the long-term we'll have to prove that our protocols works as expected (i.e are verifiable), not just randomly guess that they may work for the cases we know about.  That's also why I think that writing a draft should be simpler than it is today - not to attract more authors, but because soon we'll have to add a whole new layer of complexity on top of it.

The plan is to present my work in March in Chicago.  Meanwhile I'll be attending the reception in Berlin on Sunday, so if there is enough interest then we can setup a place and time during the week to discuss that.

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 13 Jun 2016 14:36:08 -0400

On Sun, Jun 12, 2016 at 08:31:21AM -0600, Marc Petit-Huguenin wrote:
> I understand that increasing of online collaboration, when applied to
> the IETF, is in fact two different things.  The first one is replacing
> good old email collaboration by web-based collaboration.  I would use the
> Linux kernel project, arguably one of the most successful collaborating
> project, as a counter-example of that trend, as is entirely managed
> through email, and seems to thrive is spite of having very little other
> kind of online collaboration.

That's because email is STILL the very best collaboration tool available:
nothing else even comes close.

1. It's low-bandwidth.
2. It can be utilized offline.
3. It's asynchronous.
4. It can be used with the UI (mail client) of the participant's choice,
	as long as that mail client is reasonably well-behaved.
5. It automatically builds an archive.
6. Individual participants can build their own archives.
7. Which means that they can also search those archives with the
	mechanism of THEIR choice rather than one forced on them.
8. Which means that (taken as an aggregate) there are numerous ways
	to ensure the completeness and integrity of the archives.
9. It scales magnificently.
10. Privacy/security issues are minimized.
11. Attacks/abuse/etc. against it are well-understood and easy to handle.
12. It's extremely fault- and delay-tolerant.
13. It's push, not pull.
14. It's highly portable, e.g., list-rehosting and list software upgrading
	or changing are all relatively painless processes.
15. There are some very good choices for well-supported, mature,
	stable, open-source software to manage it.
16. (more which I'll omit for now)

Moving to web-based collaboration would be a massive downgrade: it's
a truly horrible idea. 

---rsk

---

From: Dave Taht <[email-masked]>
Date: Mon, 13 Jun 2016 11:55:51 -0700

On Mon, Jun 13, 2016 at 11:36 AM, Rich Kulawiec <[email-masked]> wrote:
>> good old email collaboration by web-based collaboration.

All the cool kids are using slack, and what matrix.org has pulled off
is quite impressive.

> I would use the

Um, er, ah, no - a HUGE amount of interaction also takes place,
invisibly, over irc. Email is where the work surfaces, but irc is
where the bits get polished.

Ironically the irc vs jabber gaps were never crossed in most
subprojects because most older open source development started in irc
and email, and jabber was not a significant enough  improvement. That
said, jabber is heavily used also. The output is mostly just not
logged - which is a good thing -

Much of the linux processes are migrating over to git's methods, but
each new wave of development tends to adopt new means of
communication. There was a skype generation... a jabber generation...

As an example where I was utterly shocked at suddenly becoming an old
fart  - every presenter at the recent distributed web conference used
a twitter handle, rather than an email address.

https://bitcoinmagazine.com/articles/decentralized-web-initiative-aims-to-reinvent-web-with-peer-to-peer-and-blockchain-technology-1465574954

> nothing else even comes close.

Evaluate slack... pretend that you sit in front of a web browser all
day and your native language is node.js.....

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 13 Jun 2016 21:26:50 +0200

> Moving to web-based collaboration would be a massive downgrade: it's

Ripe is experimenting with a system which combines email with a web
forum: <https://www.ripe.net/participate/mail/forum/>. The first
reactions are positive. It might be something to consider.

	jaap

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Jun 2016 21:24:22 +0100

Yeah? This isn't more than a threaded email archive is it?

But...

"The RIPE NCC uses cookies. Some of these cookies may have been set already.
More information about our cookies can be found in our privacy policy. You can
accept our cookies either by clicking here or by continuing to use the site." 

Nice?

Adrian

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 13 Jun 2016 13:46:36 -0700

> Moving to web-based collaboration would be a massive downgrade: it's

Absolutely.  There’s no way in hell that I’m going to move from email to an ‘improved' system that would require me to have a web browser window open (or, more accurately, multiple web browser windows open - one for each ‘forum’ that I’m at least vaguely interested in), and hope that these windows update properly (without sending my browser’s CPU usage into the stratosphere) so that I don’t miss any notifications.

Although many ‘hipsters’ these days might not like email, an email address seems like a very low bar to require for participation in the IETF.

	Ross.

---

From: Dave Taht <[email-masked]>
Date: Mon, 13 Jun 2016 14:00:35 -0700

> Absolutely.  There’s no way in hell that I’m going to move from email to an ‘improved' system that would require me to have a web browser window open (or, more accurately, multiple web browser wind…

https://matrix.org/docs/projects/client/vector.html has a relevant blurb.

the matrix ecosystem happens to be partially built around the webrtc
standards, be encrypted, and well distributed.

> Although many ‘hipsters’ these days might not like email, an email address seems like a very low bar to require for participation in the IETF.

I'm not even sure a pulse should be required at this point, given the
rise of AI.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Jun 2016 16:21:40 -0400

Dave Taht <[email-masked]> wrote:
    >>> the IETF, is in fact two different things.  The first one is
    >>> replacing good old email collaboration by web-based collaboration.

    > All the cool kids are using slack, and what matrix.org has pulled off

which is just an HTML interface to an XMPP server.

---

From: Randy Bush <[email-masked]>
Date: Wed, 15 Jun 2016 07:51:29 +0900

> which is just an HTML interface to an XMPP server.

so xmpp done good.  and your point was?

randy

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jun 2016 12:01:32 -0400

> so xmpp done good.  and your point was?

The "cool kids" are just using XMPP, they just aren't cool enough to know it.
I think that slack is a walled-garden, but maybe I'm wrong.

Maybe it could be told to send XMPP traffic to jabber.ietf.org.
So, before someone says we should use "slack", they might want to just
realize that we already "do"

---

From: Dave Taht <[email-masked]>
Date: Wed, 15 Jun 2016 09:28:16 -0700

> I think that slack is a walled-garden, but maybe I'm wrong.

Well, it federates. And honestly, I was pointing more to what matrix
was pulling off rather than slack. Actual micro-home-servers, for
example, written in more accessible language than erlang. apis in json
rather than xml. security and webrtc integration, so messaging, longer
documents, and voice/video are integrated.

And so on...

http://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp

> realize that we already "do"

Vs with "email" which the ietf is only getting around to sort of
fixing the security of, which, in particular, looks always to be too
hard to be able to run inside the home, starting with the reverse dns
requirement and the basic need for public ipv4 addresses, and ending
with controlling spam (I would like to see "email over some better
transport to natted nodes" happen somehow. https://darkmail.info/
getting anywhere?)

Given the state of the law nowadays, I do not think enough protections
in the cloud exist or can ever exist, and efforts to move data back
closer to the actual owner of it, I applaud, in addition to good
crypto of it wherever it may rest or be exchanged.

Security starts with physical security.

...

Please note that I started this portion of the thread as one example
of how the next generation is or could be interacting, where a major
touchdown point is not a keyboard and screen at a desk, but over a
phone or tablet, where the increase in interactivity makes typing a
seem lame, and the typewriter plain text spec of a RFC, less useful
than html and links to actual, complex code.

There are other encouraging things out there (like tox) - in addition
to the discouraging issues with xmpp (example:
https://wiki.bitlbee.org/HowtoFacebookMQTT )

Isoc uses "fuze", which has a handy ability for participants to record
(and notify others you are recording). Can you do that with webrtc?

someday, perhaps, we'll be able to ask our personal copy of siri to
search our text and personal audio/video logs to find whenever the
heck we'd discussed some thorny issue or another, and/or be able to
query the sousveillance and surveillance infrastructure for it.

Or we can just wait for clippy to do all that for us.

https://twitter.com/dantz/status/742336999084961792

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 15 Jun 2016 11:09:34 -0600

In my opinion, it does not really matter what kind of collaboration tool is used, as long as there is a clear path that still permit to collaborate, but without using them.

As an example, I am currently trying to learn how to program an FPGA.  As I have *absolutely* no idea what I am doing, I am using an all graphical design suite, which help me to concentrate on learning the minimum skill set to reach my goals.  Currently a lot of what happen underneath is a complete mystery (to paraphrase A.C. Clarke, for a beginner any kind of technology is indistinguishable from magic).  But the more I learn things, the more I am looking into replacing them by Vim and a couple of scripts, because this is what makes me more productive in the long term.

So all these collaboration tools are great, as long as people who choose to use them as a transition to more productive tools can still do this.  That means for example a RESTFul API available before the website, text formats, source code available for modification, etc...

To summarize, web based tools are important if we want beginners to join, are certainly useful for casual users, are completely useless for advanced users and will probably be detrimental to the IETF future if they are the only mean to collaborate.

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 16 Jun 2016 18:21:12 -0400

> day and your native language is node.js.....

I *have* evaluated it, and it lacks the functionality, privacy, security,
stability, scalability, and usability features that mailing lists have.
(See partial enumeration in previous message.)  It's just another
attempt to convince Internet users to surrender their privacy/security
to a third party so that data can be collected on them and subsequently
monetized.  It will probably be successful, since no doubt its operators
have observed other such data collection operations (e.g., Twitter,
Meetup, Facebook, LinkedIn) and learned from them.  But it's not suitable
for the IETF or for any other entity that actually cares about its users
and participants.

---rsk