Subject: Plenary questions

From: S Moonesamy <[email-masked]>
Date: Wed, 07 Nov 2018 06:24:58 -0800

Dear Chair,

Please refer to the email which was sent to the IETF mailing list on 
19 July.  Why did the mistake happen again?

Regards,
S. Moonesamy

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 8 Nov 2018 07:21:29 +0700

Hi SM,

> On Nov 7, 2018, at 9:24 PM, S Moonesamy <[email-masked]> wrote:
> 
> Dear Chair,
> 
> Please refer to the email which was sent to the IETF mailing list on 19 July.  Why did the mistake happen again?

Because I forgot to find a scribe. I’m very sorry about this. (I even added an item to my task manager to remind myself to do this after the last plenary, but it failed to trigger a notification. I already have one correctly set to fire an alarm before the IETF 104 plenary.)

Apologies,
Alissa

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Nov 2018 09:38:08 +0700

> Because I forgot to find a scribe. I’m very sorry about this. (I even added an item to my task manager to remind myself to do this after the last plenary, but it failed to trigger a notification. I…

There were hundreds of people in the room that didn’t notice either, so I think we should take this as a collective failure.

It is unfortunately quite common that remote participants are ignored when there such a big disproportinate number of local versus remote.
Apart from running a fully remote meeting, I don’t know what can fix that. Because those of us who are local, want to take advantage of the benefits of higher bandwidth communication. Body language, beer, hand waving...

Btw: I have experienced that finding working jabber clients for my OS is becoming harder and harder. Is this an indication of jabber in general failing? And if so what are we going to do about it?

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2018 09:42:45 +0700

Same.  There's a lot of innovation going on in the online meeting space, so
it's not deeply surprising that we're seeing Jabber languishing, although
it is unfortunate.   Of course, Jabber as a protocol suite has a
ludicrously high learning curve, which might explain this to some extent.

One frustration I have with this discussion is that there is actually a
great deal of understanding of this problem in the IETF, but we don't seem
to have the will to actually put that understanding into practice.   Could
we have a BoF on this in Prague?

On Thu, Nov 8, 2018 at 9:38 AM Ole Troan <[email-masked]> wrote:

> > Because I forgot to find a scribe. I’m very sorry about this. (I even
> added an item to my task manager to remind myself to do this after the last
> plenary, but it failed to trigger a notification. I already have one
> correctly set to fire an alarm before the IETF 104 plenary.)
>
> There were hundreds of people in the room that didn’t notice either, so I
> think we should take this as a collective failure.
>
> It is unfortunately quite common that remote participants are ignored when
> there such a big disproportinate number of local versus remote.
> Apart from running a fully remote meeting, I don’t know what can fix that.
> Because those of us who are local, want to take advantage of the benefits
> of higher bandwidth communication. Body language, beer, hand waving...
>
> Btw: I have experienced that finding working jabber clients for my OS is
> becoming harder and harder. Is this an indication of jabber in general
> failing? And if so what are we going to do about it?
>
> Cheers,
> Ole
>
>

---

From: S Moonesamy <[email-masked]>
Date: Wed, 07 Nov 2018 21:28:04 -0800

Hi Ole,
At 06:38 PM 07-11-2018, Ole Troan wrote:
>It is unfortunately quite common that remote participants are 
>ignored when there such a big disproportinate number of local versus remote.
>Apart from running a fully remote meeting, I don't know what can fix 
>that. Because those of us who are local, want to take advantage of 
>the benefits of higher bandwidth communication. Body language, beer, 
>hand waving...

What is the meaning of "higher bandwidth communication"?

>Btw: I have experienced that finding working jabber clients for my 
>OS is becoming harder and harder. Is this an indication of jabber in 
>general failing? And if so what are we going to do about it?

It may be an indication that the market for XMPP products is 
(relatively) small.  If you really need the software, you would have 
to maintain it.  The other alternative is to rely on Meetecho.

Regards,
S. Moonesamy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Nov 2018 14:14:40 +0700

> Btw: I have experienced that finding working jabber clients for my OS is becoming harder and harder. Is this an indication of jabber in general failing? And if so what are we going to do about it?

I've noticed that as well; AFAICT my only choices at the moment is to a) use an unsupported, seldom-updated bit of popular software with an unclear policy about how maintained it is, or b) use one of a number f very small, questionably-maintained clients with extremely poor user experience. Not a great choice.

Perhaps the IETF needs to admit defeat here...

--
Mark Nottingham   https://www.mnot.net/

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2018 14:41:57 +0700

> Perhaps the IETF needs to admit defeat here...

my memory is that xmpp was originaly brought into the ietf to be rubber
stamped.

randy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Nov 2018 14:45:39 +0700

> On 8 Nov 2018, at 14:14, Mark Nottingham <[email-masked]> wrote:
> 
> Perhaps the IETF needs to admit defeat here…

Sure. When something better’s available. I don’t think the Jabber session in a browser is it.

Yoav

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 08 Nov 2018 11:49:14 +0400

On 8 Nov 2018, at 11:41, Randy Bush wrote:

> my memory is that xmpp was originaly brought into the ietf to be rubber stamped.

Being Area Director of the time, my memory is the following:

Step 1:

- Work on coming up with a chat protocol

- Outcome: four proposals, most interesting based on BEEP

- People start using Jabber

Step 2:

- No agreement, allow all four to become RFCs (I think all four ended up being RFCs, I might be wrong)

- Discussion with Jabber, that did not want change control in IETF

Step 3:

- Jabber people came to IETF and said we can have a good constructive discussion

- Jabber discussed

Step 4:

- XMPP be finished

So, "rubber stamped" was a bit to brutal expression maybe ;-)

Jabber/XMPP was treated and was managed the same / similar way as all protocols that at first are dealt with outside of IETF and then brought to the IETF community. A quite successful example I must say. Although the understanding of how IETF works to start with was, also as always, a bit confusing.

   Patrik

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Nov 2018 15:11:50 +0700

> On 8 Nov 2018, at 14:49, Patrik Fältström <paf=[email-masked]> wrote:
> 

People often come to the IETF to get their document rubber stamped. They often get a rude awakening.

Yoav

---

From: Dave Cridland <[email-masked]>
Date: Thu, 8 Nov 2018 10:01:48 +0000

On Thu, 8 Nov 2018 at 07:49, Patrik Fältström <paf=
[email-masked]> wrote:

> Jabber/XMPP was treated and was managed the same / similar way as all
> protocols that at first are dealt with outside of IETF and then brought to
> the IETF community. A quite successful example I must say. Although the
> understanding of how IETF works to start with was, also as always, a bit
> confusing.
>
>    Patrik
>

I would also add:

Step 5:

- The XMPP community formed a standards group of its own, essentially
modelled on the IETF's processes.

Step 6:

- The XMPP community revised the specifications within the IETF.

I think the relationship has been generally successful.

Dave.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Nov 2018 10:33:30 -0500

--On Thursday, November 8, 2018 15:11 +0700 Yoav Nir
<[email-masked]> wrote:

>...

> People often come to the IETF to get their document rubber
> stamped. They often get a rude awakening.

While I agree that Jabber/XMPP was largely a success case, I
would have said that most such efforts don't get rude awakenings
nearly often enough :-(

   john

---

From: S Moonesamy <[email-masked]>
Date: Thu, 08 Nov 2018 08:05:00 -0800

Hu Aliisa,

Thank you for the explanation.

Regards,
S. Moonesamy

---

From: Mary B <[email-masked]>
Date: Thu, 8 Nov 2018 10:18:50 -0600

> would have said that most such efforts don't get rude awakenings

[MB] That awakening was overly rude, if you recall.  It went well beyond
letting them know how things are done at IETF. [/MB]

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 08 Nov 2018 20:31:35 +0400

On 8 Nov 2018, at 20:18, Mary B wrote:

> [MB] That awakening was overly rude, if you recall.  It went well beyond letting them know how things are done at IETF. [/MB] 

Yes, but the situation was double-complicated as I explained because we had already four other proposals, so instead of having IETF choose one, they would be one of five alternatives.

I do not blame anyone in that situation be surprised, chocked and whatever else.

IETF is not easy to participate in, I also notice quite a lot nowadays when I go to so few meetings and am participating on only specific topics, very specific topics.

   Patrik

---

From: Mary B <[email-masked]>
Date: Thu, 8 Nov 2018 11:04:06 -0600

On Thu, Nov 8, 2018 at 10:31 AM Patrik Fältström <[email-masked]> wrote:

> Yes, but the situation was double-complicated as I explained because we
> had already four other proposals, so instead of having IETF choose one,
> they would be one of five alternatives.
>
[MB] Right.  And, it was the folks that were champions of the 4th that were
the most inhospitable to these folks.  At that time, there was already lots
of water under that bridge.   Certainly, the proponents were folks that
could hold their own. But, it did do a great job of highlighting, as you
note, that IETF is a very tough environment to work in. And, I can
guarantee, it would have been impossible for anyone other than folks in
that demographic to make any headway.  [/MB]

> I do not blame anyone in that situation be surprised, chocked and whatever
[MB] From my viewpoint that was some of the most deplorable behavior I've
seen amongst that group - the only thing worse was some of the early
meetings with 3GPP folks.  But, I might be more sensitive than others since
I'd also been the target of some of those folks in earlier meetings.  And,
of course, from certain folks we tend to tolerate that behavior because of
who they are.  But, continuing to defend it as okay isn't a good thing.
[/MB]

>
> IETF is not easy to participate in, I also notice quite a lot nowadays
> when I go to so few meetings and am participating on only specific topics,
> very specific topics.
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Nov 2018 12:33:33 -0500

--On Thursday, November 8, 2018 10:18 -0600 Mary B
<[email-masked]> wrote:

>> would have said that most such efforts don't get rude
>> awakenings nearly often enough :-(
> 
> [MB] That awakening was overly rude, if you recall.  It went
> well beyond letting them know how things are done at IETF.
> [/MB]

I do recall, although only vaguely because the tone of some of
the discussions was more than sufficient to convince me that I
wanted to spend my available IETF  energy in other ways.  In the
IETF and in terms of affected individuals, that is often the
least harmful effect of toxic behavior because, while it may
damage us technically, the personal and psychological damage is
minimized.  On the other other hand, to the extent to which it
drives people with other views off rather than trying to engage,
mutually inform, and reach consensus, it is very bad for the
IETF because it results in WGs who reach consensus among the
survivors (those who have not been driven away) without full
information and serious consideration or other options.
Consensus by attrition, in turn, undermines the credibility of
all of our standards and makes the quality of our work
completely dependent on IETF Last Call.   If is also the reason
why I (and probably some others) make bad faces and rude noises
every time someone says "we should just trust the WG" during
either IETF Last Call or IESG discussions without clear evidence
that the WG was open in practice (not just theory) and took all
technically-grounded points of view seriously..

best,
   john

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Nov 2018 13:59:18 -0600

> my memory is that xmpp was originaly brought into the ietf to be rubber

So?  We "own" it anyways.  But the real question is: can we continue
using it for remote participation.  My impression was that Mark N. meant
that we should accept that XMPP is no longer viable for that purpose.

Meetecho is effectively yet another an IM w/ audiovideo platform.  There
are others (all proprietary, I think, but at least parts(?) of Discord
are open).  Like everything else in the IM space post-XMPP, it's a
symptom of the balkanization of IM in the absence of a widely adopted
and used IM standard.  More than that, I think this means that the
market does not want an IM standard.  Pity.  I'd rather have a standard.

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Thu, 8 Nov 2018 20:14:29 +0000

On 8 Nov 2018 7:59 pm, "Nico Williams" <[email-masked]> wrote:

The consumer market is dominated by a set of large, well-funded companies
with a vested interest in ensuring there is no standard.

This isn't the case in most - less visible - markets, although not all
markets have picked the same standard. The business/corporate world has
mostly picked Slack (with some Skype for Business - which is itself XMPP
and SIP/SIMPLE capable I think), the OSS project world still mostly
revolves around IRC, with a bit of Discord and others at the fringes.
Several markets have adopted XMPP, though, both for IM and for general
structured realtime messaging. Many more players have adopted it in part
(usually C2S only) to gain access to some market, and then dropped it
(witness Slack, Facebook, Google, etc).

Unless Meetecho has changed dramatically, it, too, is "just" another XMPP
implementation.

Dave.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Nov 2018 14:35:28 -0600

> with a vested interest in ensuring there is no standard.

The customers get some say, and they seem to be fine with that state of
affairs, I guess.

> revolves around IRC, with a bit of Discord and others at the fringes.

I quite like Discord.  I'm very happy with Meetecho for IETF remote
participation though.  But I would really like an XMPP text-based client
to run in a tty.

> Unless Meetecho has changed dramatically, it, too, is "just" another XMPP

Yes, but we all just use the web UI because the problem is the missing /
rotted XMPP clients.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Nov 2018 16:23:36 -0500

--On Thursday, November 8, 2018 20:14 +0000 Dave Cridland
<[email-masked]> wrote:

> Meetecho is effectively yet another an IM w/ audiovideo
> platform.  There are others (all proprietary, I think, but at
> least parts(?) of Discord are open).  Like everything else in
> the IM space post-XMPP, it's a symptom of the balkanization of
> IM in the absence of a widely adopted and used IM standard.
> More than that, I think this means that the market does not
> want an IM standard.  Pity.  I'd rather have a standard.
>...
> Unless Meetecho has changed dramatically, it, too, is "just"
> another XMPP implementation.

If you two are talking about the chat frame in Meetecho, sure
and no one has claimed otherwise.  To at least some extent it is
there because the IETF used Jabber and we are (or were) a major
customer.

If you are talking about Meetecho as a virtual meeting /
teleconferencing system, its competitors are GoToMeeting, WebEx,
Zoom, and a bunch of others, not traditional IM systems, even
those with "add people to conversation" options.  It may be
worth remembering that efforts to build teleconferencing systems
of that flavor predate Internet-based IM systems unless one
counts SMTP's SEND verb or the early, mostly-Unix-based, talk
protocol.  

Just a personal opinion but those more commercial virtual
meeting systems seem to be optimized (with differing priorities)
for scenarios that simulate a relatively small number of people
sitting around a table, a large meeting in which someone is
presenting or lecturing to a collection of remote people, or a
larger conference in which almost everyone is remote from each
other.   Meetecho, I assume at least in part because the IETF's
way of working influenced their design, is far better optimized
to our "big room with a lot of people in it, many of whom are
participating rather just listening, and a much smaller number
of widely-distributed remote participants, some of whom become
part of the discussions and others of whom may actually present"
model.  

Speaking as someone who is very dependent on it and who would
probably have to drop out if f2f meetings had the same
importance for the IETF they had 15 or 20 years ago, I'm really
grateful for Meetecho and the people who make it work, how much
it has improved over the last several years, and how superior it
is to those other systems (a couple of which I find myself using
regularly).

best,
   john

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 05:16:42 +0700

> with a vested interest in ensuring there is no standard.

Perhaps this is true, but that's not why XMPP failed.   XMPP failed because
it's really difficult to set up, even if you already have a client.   And
that in turn makes it hard to set up clients.   If I want to join an IETF
jabber room, I first need to set up a jabber account somewhere, and that
jabber account has to have federation working so that I can connect to the
IETF's jabber setup.

If we wanted jabber to actually work, we would get rid of the federation
requirement, which is totally superfluous for the case of participating in
the IETF.   In an IPv6 end-to-end network, federation for messaging doesn't
really add value—it's just a barrier to entry.   Maybe it made sense in the
land of NAT, but at this point I think we are more likely to have working
IPv6 than to have working Jabber.

---

From: Job Snijders <[email-masked]>
Date: Thu, 8 Nov 2018 22:22:05 +0000

Maybe instead of jabber rooms, we can use an IRC channel per working
group during the meeting session? There are plenty of well-maintained
IRC clients, and no account or federation is needed.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 05:24:32 +0700

On Fri, Nov 9, 2018 at 5:16 AM Ted Lemon <[email-masked]> wrote:

> Perhaps this is true, but that's not why XMPP failed.   XMPP failed
> because it's really difficult to set up, even if you already have a
> client.   And that in turn makes it hard to set up clients.
>

What I meant here is that this reduces the demand for clients.   Which is
why we don't see more clients, and why the clients we see aren't
particularly nice: there is simply no way to justify spending time making
them nicer.

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Nov 2018 23:12:15 -0600

> IPv6 than to have working Jabber.

Good points.  The IETF could, of course, just provide accounts in an
ietf-participants.org domain.  I could understand if it was reluctant to
do so perhaps even with a separate domain for participants.

Allow me to sketch wildly about federation for a moment.  I know, it's
not the place to do it.  But if federation was the issue (and I agree
that it was), then how about... using DANE for federation?  Then all one
has to do to federate is sign their zone and publish TLSA RRs for their
issuer.

Sketch #1:

 - use TLS with user certs (I know! bear with me)
 - with a client-side extension to carry the user certificate's
   *issuer*'s DANE DNSSEC chain
 - and with only rfc822Name SANs whose domainname is the issuer's from
   its TLSA RRset domainname (or xmppName, if we add such a SAN)

   (by using only SANs with a domainname component we can make DAN work
   for authenticating issuers implicitly constrained to those domains)

User certs in TLS just don't work because we can't use the WebPKI there,
but using DANE would get us down to a one-root PKI (DNSSEC).  As it
happens the DNSSEC PK is already used in email, and XMPP handles look
enough like email addresses that they might as well be (or we could add
a SAN for them).

User certs in TLS don't work also due to UI issues.  Those are much
more tractable than the XMPP account and federation setup, but still,
that brings me to the next sketch.

Sketch #2:

 - use SASL/GSS-API, perhaps via HTTP/Negotiate
 - with a TLS-based mechanism (like GSI's)
 - and user certs

The second one is a lot like the first in that user certs are involved,
but, unlike the first case, browsers today *do* have HTTP/Negotiate
support, and SASL libraries typically support GSS mechanisms, and the UI
issues can be factored out of the browsers/apps.  The only thing missing
is a GSS mechanism that internally uses TLS, but in fact there is such a
thing[0]!

Granted, the GSI mechanism[0] is non-standard, and could probably use a
lot of help besides standardization.  And standardization will be
somewhat tricky.

FYI, the GSI mechanism is a lot like SChannel, where SChannel is an SSPI
interface to TLS and the GSI mechanism is a GSS-API interface to TLS.

[0] https://github.com/globus/globus-toolkit/tree/globus_6_branch/gsi/gssapi/source

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Fri, 9 Nov 2018 07:54:09 +0000

On 8 Nov 2018 10:25 pm, "Ted Lemon" <[email-masked]> wrote:

What you say makes a degree of sense if you believe that markets are driven
purely by the needs of the end-user.

But the evidence is very much against that. Email is in a very similar -
though not as dire - case. MUAs have not significantly advanced on the
desktop, or indeed for open standards, in at least a decade.

The market, as I said before, is in a similar place - if you want an email
address, you go to Google, or Hotmail/Outlook/whatever, or perhaps Yahoo,
and have them set it up, and use whatever webmail client they give you. If
you still want to use an IMAP account, they might let you, but it'll be a
clunky experience made more so by bending the rules of the protocol to fit
their model. Your client will probably have to have specific support to
handle your provider.

Email's advantage is that its federation capability became rooted in user
expectations early on, and while it's become ever more complicated - in
part due to the efforts of the major providers - to make email federation
work, it's essentially impossible for the same providers to remove support.

In the IM world, whilst every major provider has provided XMPP support or
used XMPP directly in the past, open standard IM was never a consumer
market success prior to proprietary IM services taking off, so they don't
have to make any kind of effort here after an initial burst to gain some
cheap market access.

On the other hand, I don't think that setting up an XMPP server is any
harder than setting up an email server - and there are ways in which it is
significantly simpler. The main point of difficulty seems to be in
configuring SRV records and getting TLS right, but for trivial deployments
where the XMPP domain is equal to the server hostname those problems vanish.

Finally, I dispute that XMPP has failed. The major providers have avoided
federation, despite some early attempts by Google, due to the damage it
would do to their business models based on lock-in. Federation has failed
across the board, as non-federation and a lot of luck yields much better
results - look at Github, which is based around a fully-decentralised
version control system, yet has built a single silo'd platform.

But where federation is important, XMPP does very well indeed. Where rich
messaging, permissionless extension, and all the rest are needed, it really
does lead the field. There are several markets where it seems to dominate.

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 17:07:21 +0900

On Fri, Nov 9, 2018 at 4:54 PM Dave Cridland <[email-masked]> wrote:

> What you say makes a degree of sense if you believe that markets are
> driven purely by the needs of the end-user.
>

Yes.   The market for non-branded, generic jabber clients that can work to
connect me to IETF sessions gets smaller and smaller every IETF.   This is
because it is driven by end users.

Of course, there are places where Jabber is still used.   But how does that
help me to connect to IETF meeting jabber rooms?

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 9 Nov 2018 10:24:19 -0500

> version control system, yet has built a single silo'd platform.

I'd disagree on the first point.  For players who are don't dominate
the messaging space (e.g., !Facebook Messenger && !Apple Messages),
Federation makes an awful lot of sense from a business perspective.
The main problem was that there wasn't anyone to really federate with,
and the primary, most enthusiastic users of federation were spammers
trying to inject SPAM into the messaging systems.

>From the perspective of a major provider, if the costs to a major
provider outweigh the benefits of Federation, it's not really
surprising that they would give up on it.

E-mail is a good example where due to the early success of federation
that the costs of SPAM are large, but not nearly large enough compared
to the benefits of keeping a federated e-mail system.

And perhaps another good example of this is mailing lists and DMARC.
DMARC was an attempt to deal with a certain class of spam, and it had
a horrendous effect on mailing lists.  But there was enough federated
mailing lists that were of high value that just telling people, "so
sorry, you can't use mailing lists if you are using Yahoo mail; you
should use are walled-garden web forums instead" wasn't going to fly.
And so at great expense, the major providers agreed to work on ARC.

But make no mistake, if there weren't sufficient high-value mailing
lists that the major providers cared about losing as "collateral
damage, oh well", it's pretty clear they wouldn't lift a finger.  In
fact, they tried that strategy at first.  And while it had everything
to do with business, I really don't think it was due to a malicious
attempt to promote walled-garden web fora.

							- Ted

---

From: Dave Cridland <[email-masked]>
Date: Fri, 9 Nov 2018 18:44:53 +0000

> Federation makes an awful lot of sense from a business perspective.

I agree. Note that I said "non-federation and a lot of luck" - the survivor
bias is strong in this particular argument. The ideal ground for federation
is a space where there are no dominating providers, but the moment a few
gain significant market share the equations rapidly shift.

> trying to inject SPAM into the messaging systems.

Well, that was certainly the rhetoric used at the time. However, XMPP has
always had relatively strong server authentication, which Google never
bothered implementing. It is, of course, perfectly possible that Google
genuinely were seeing vast amounts of spam that, somehow, the rest of the
network simply weren't experiencing - but if that was indeed the case, it
suggests that better adherence to the standards might have strongly
mitigated the problem. It's possible, of course, that the spam was entirely
directed to gmail.com addresses, which would be easily identifiable - but
strangely, I never saw any spam on any Google address or any other XMPP
address back then. One can only assume that Google had the situation well
under control, at least for my accounts.

Since Google dropped federation, spam has actually risen on the network in
my experience - but it has also been largely kept under control by improved
use of security that was available at the time - although it's become
cheaper thanks to Let's Encrypt etc.

> surprising that they would give up on it.
Well, sure. But the benefits of non-federation include market capture -
unless there are at least two major providers federating, it doesn't appear
that there would be many benefits to a dominating provider that would
outweigh that. Even when a handful of major providers do federate, it works
best when they limit that federation (or other cooperation) to other large
providers, to maximize capture effects.

> And so at great expense, the major providers agreed to work on ARC.
I suspect that had less to do with mailing lists in general, and much to do
with the IETF mailing lists in particular. DMARC itself was a clear attempt
to side-step the standards process, and a successful one at that. It's
mirrored by other activities, like WHAT-WG. This again is an overt move by
dominant providers to cement their control over the standards. And yes, I'm
well aware that is not what it says on the WHAT-WG website - but it is,
however, literally what the Steering Group is there to enforce.

DMARC has had the effect of raising the bar further for smaller service
providers and self-hosting of email. It has disproportionately affected
providers other than those involved in its creation. Unfortunately, one of
those other providers was the IETF itself, and so it became strikingly
obvious, and the providers were forced to compromise.

Sadly, I suspect there'll be a poignantly regretful decision to actively
restrict federation over time, for reasons of performance, security, and so
on. Spam is an excellent excuse, too - it's worked before, after all.

> attempt to promote walled-garden web fora.

Well, they did indeed try that strategy first. I'm glad it failed this
time, don't get me wrong, but I don't think it was performed with market
capture as entirely a happy coincidence.

Dave.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Nov 2018 08:14:54 +1300

On 2018-11-09 18:12, Nico Williams wrote:
...
> The IETF could, of course, just provide accounts in an

Isn't that effectively what we do, with the meetecho chat window,
which requires a meeting registration number?

I wonder whether meetecho-lite, with restricted features, would be
an option.

   Brian

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Nov 2018 22:20:58 -0500 (EST)

On Fri, 9 Nov 2018, Dave Cridland wrote:

> DMARC has had the effect of raising the bar further for smaller service providers and self-hosting of email. It has disproportionately affected providers other than
> those involved in its creation. Unfortunately, one of those other providers was the IETF itself, and so it became strikingly obvious, and the providers were forced to
> compromise.

I'd phrase it a little different. Small email providers were stuck
between a hard spam rock and a DMARC stone. And guaranteed to lose.

> Sadly, I suspect there'll be a poignantly regretful decision to actively restrict federation over time, for reasons of performance, security, and so on. Spam is an
> excellent excuse, too - it's worked before, after all.

Yes, we see this at every level. IM, DNS, email and don't forget cloudflare.
I love cloudflare, but the fact that websites are forced to buy kneecap
insurance is bad. It further centralises everything.

> Well, they did indeed try that strategy first. I'm glad it failed this time, don't get me wrong, but I don't think it was performed with market capture as entirely a
> happy coincidence.

And sadly, some decentralization efforts are now captured in a
dead-end street of blockchains.

Other worrying developments are "resolverless", mass use of DNS over
TLS/HTTPS to a few (walled garderner) providers, and the Origin
experiments of serving webpage parts from other domains.

Some of this could be used for good, but my experience so far suggests
it just leads to more centralization.

Paul

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Nov 2018 00:45:55 -0600

> it just leads to more centralization.

Centralization is mostly a result of need for efficiency, convenience
and scalability.  Mom-n-pops can't really run a good datacenter, and so
on.  So one way or another we end up centralizing.  Of course, we could
still maintain cloud / CDN vendor mobility, and be distributed at a
layer where that mobility can be taken advantage of to get us
resilience.  But it's too late for many services.

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Sat, 10 Nov 2018 09:10:47 +0000

On Sat, 10 Nov 2018 at 06:46, Nico Williams <[email-masked]> wrote:

> and scalability.

I think you're vastly underestimating the effects of strong branding, and
the consequences of information asymmetry in purchasing services, actually,
alongside a dozen other factors. People do not, after all, buy Coca Cola
(or even wine) for the taste compared to its rivals, nor the cost. However,
your implicit assertion that there are benefits to centralization is of
course quite correct.

Centralization is not, in and of itself, a bad thing. Having large
providers who can take advantage of economies of scale means that end-users
can enjoy the services at a lower price, and this expands access, and from
there it follows that - assuming we believe that the technology we design
generally improves people's lives - the world is a better place.

But I do believe that, in order to maximize their shareholder value, the
larger service providers act in monopolistic ways, or form cartels, in
order to control the technology and its standards. In the case of WHAT-WG,
I think that's obvious, but there are a number of less overt cases. This in
turn cements their position, and places them in a position of power over
people and their data which at best is questionable, at worst outright
dangerous. I believe this runs the risk of outweighing any positive
benefits.

There are strong protections in place in most jurisdictions against
collusion on price in a cartel or monopoly, but we do not have the same
protections in place to prevent direct collusion in technology standards
which can similarly lead to greater control of the market to the detriment
of the consumers.

>   Mom-n-pops can't really run a good datacenter, and so

There is, of course, always the great question of why a mom-n-pop needs to
run a content delivery network and a multi-availability-zone datacentre in
order to run basic services - indeed, in those services where federation
has been a success, it's not really the case. We've addressed scalability
and availability in the web by introducing "heavy" technical fixes like
load balancers and so on (which, incidentally, are invisible to the
standards model), whereas we've addressed the same in email and XMPP
through largely different means like SRV and MX.

Loosely, we've made the endpoints in these protocols - particularly the
clients - play a greater part in handling scaling and availability, and -
perhaps - the result is stronger provider independence, less
centralisation, and (I suspect) more complex configuration for trivial
cases.

If anyone has concrete suggestions for how to improve XMPP, and in
particular, making the deployment of a new XMPP domain simpler, I'd welcome
suggestions. At the moment, however, my feeling is our biggest barrier is
that we've trained the market so thoroughly that all application services
run over HTTP that any deviation from this model is met with bewilderment
and confusion. Perhaps we need a specification for XMPP S2S over Websockets
and BOSH. :-)

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Nov 2018 12:23:19 -0500

I think the issue with XMPP is that it's not actually a good solution for
the problem we're trying to solve with it.   There are way too many moving
parts, and the moving parts don't actually add value.   Whenever I've tried
to climb the XMPP learning curve, I've fairly quickly realized that I don't
have time to do it as a yak shave, which is what it always is, and so I
give up and use something else.   Obstacles abound: the base protocol
doesn't actually do what we need, so we need extra add-ons, and then there
needs to be a server, because federation is mandatory, and so on.   Better
tools wouldn't hurt, but they'd be a bit of a band-aid over the basic
problem that it's not scoped to address the right use case.

On Sat, Nov 10, 2018 at 4:11 AM Dave Cridland <[email-masked]> wrote:

> order to control the technology and its standards.. In the case of WHAT-WG,

---

From: Jared Mauch <[email-masked]>
Date: Sun, 11 Nov 2018 18:54:42 -0500

The things that should have been easy in XMPP started to be hard. Multiple presence. Directed presences, etc suffer from engineers delight and result in end user pain. 

Less is more, etc...

Why do people use the centralized services like slack, AWS, etc? Because they don’t want to manage all the details, they just want a service that works. When we select these technology and techniques are we doing them for our own joy or the end users?

I don’t run an XMPP server anymore due to the spam and reliability issues. 

Sent from my iCar

> On Nov 10, 2018, at 12:23 PM, Ted Lemon <[email-masked]> wrote:
> 
> I think the issue with XMPP is that it's not actually a good solution for the problem we're trying to solve with it.   There are way too many moving parts, and the moving parts don't actually add value.   Whenever I've tried to climb the XMPP learning curve, I've fairly quickly realized that I don't have time to do it as a yak shave, which is what it always is, and so I give up and use something else.   Obstacles abound: the base protocol doesn't actually do what we need, so we need extra add-ons, and then there needs to be a server, because federation is mandatory, and so on.   Better tools wouldn't hurt, but they'd be a bit of a band-aid over the basic problem that it's not scoped to address the right use case.
> 
>> On Sat, Nov 10, 2018 at 4:11 AM Dave Cridland <dave@cridland..net> wrote:
>> 
>> 
>> I think you're vastly underestimating the effects of strong branding, and the consequences of information asymmetry in purchasing services, actually, alongside a dozen other factors. People do not, after all, buy Coca Cola (or even wine) for the taste compared to its rivals, nor the cost. However, your implicit assertion that there are benefits to centralization is of course quite correct.
>> 
>> Centralization is not, in and of itself, a bad thing. Having large providers who can take advantage of economies of scale means that end-users can enjoy the services at a lower price, and this expands access, and from there it follows that - assuming we believe that the technology we design generally improves people's lives - the world is a better place.
>> 
>> But I do believe that, in order to maximize their shareholder value, the larger service providers act in monopolistic ways, or form cartels, in order to control the technology and its standards... In the case of WHAT-WG, I think that's obvious, but there are a number of less overt cases. This in turn cements their position, and places them in a position of power over people and their data which at best is questionable, at worst outright dangerous. I believe this runs the risk of outweighing any positive benefits.
>> 
>> There are strong protections in place in most jurisdictions against collusion on price in a cartel or monopoly, but we do not have the same protections in place to prevent direct collusion in technology standards which can similarly lead to greater control of the market to the detriment of the consumers.
>>  
>> There is, of course, always the great question of why a mom-n-pop needs to run a content delivery network and a multi-availability-zone datacentre in order to run basic services - indeed, in those services where federation has been a success, it's not really the case. We've addressed scalability and availability in the web by introducing "heavy" technical fixes like load balancers and so on (which, incidentally, are invisible to the standards model), whereas we've addressed the same in email and XMPP through largely different means like SRV and MX.
>> 
>> Loosely, we've made the endpoints in these protocols - particularly the clients - play a greater part in handling scaling and availability, and - perhaps - the result is stronger provider independence, less centralisation, and (I suspect) more complex configuration for trivial cases.
>> 
>> If anyone has concrete suggestions for how to improve XMPP, and in particular, making the deployment of a new XMPP domain simpler, I'd welcome suggestions. At the moment, however, my feeling is our biggest barrier is that we've trained the market so thoroughly that all application services run over HTTP that any deviation from this model is met with bewilderment and confusion. Perhaps we need a specification for XMPP S2S over Websockets and BOSH. :-)
>> 
>> Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2018 10:42:59 -0700

On 11/10/18 10:23 AM, Ted Lemon wrote:
> I think the issue with XMPP is that it's not actually a good solution
> for the problem we're trying to solve with it.   There are way too many
> moving parts, and the moving parts don't actually add value.   Whenever
> I've tried to climb the XMPP learning curve, I've fairly quickly
> realized that I don't have time to do it as a yak shave, which is what
> it always is, and so I give up and use something else.   Obstacles
> abound: the base protocol doesn't actually do what we need, 

By "we" do you mean the IETF? If so, an I-D defining requirements for an
IETF chat service would be welcome.

One of the reasons we use Jabber today is that we need to archive the
discussions ("Note Well") and we can do that server-side with standard
XMPP servers. It's not at clear to me how we'd do that with, say, Slack.
It could be that Meetecho can serve all our needs, but we need to define
them first.

> so we need
> extra add-ons, and then there needs to be a server, 

Well, XMPP is a client-server technology, so yes.

> because federation
> is mandatory, 

False.

> and so on.   Better tools wouldn't hurt, but they'd be a
> bit of a band-aid over the basic problem that it's not scoped to address
> the right use case.

See above. The I-D submission window is open. :-)

Peter

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Nov 2018 13:12:19 -0500

Slack lets you archive discussions.   Not that I'm suggesting using Slack;
I'm just pointing out reasons why Jabber hasn't taken off, and why it's not
working for us.   Federation _is_ mandatory, in the sense that I can't join
an IETF jabber room without it.

I think there's a larger problem to be looked at here, of which this
particular point is one aspect.   It would be good to write something up.
 At the same time, it's a time sink, and I don't have any slack time right
now in which to do it.   :(

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2018 12:14:03 -0700

On 11/12/18 11:12 AM, Ted Lemon wrote:
> Slack lets you archive discussions. 

As long as the provider meets IETF policies on control over the
archives, that's great.

>  Not that I'm suggesting using
> Slack; 

We can use whatever meets the requirements we have, I suppose.

> I'm just pointing out reasons why Jabber hasn't taken off, and
> why it's not working for us. 

Those are two different questions.

>  Federation _is_ mandatory, in the sense
> that I can't join an IETF jabber room without it.   

The IETF could run its own Jabber server, or registered attendees could
use Meetecho as described earlier in this thread.

> particular point is one aspect.   It would be good to write something
> up.   At the same time, it's a time sink, and I don't have any slack
> time right now in which to do it.   :(

If you spent less time on Slack, you might have more slack time. ;-)

Peter

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Nov 2018 14:16:56 -0500

I spend as close to zero time on slack as possible, because it is such a
time sink.   But to your point, yes, IETF could run its own jabber server,
and I've suggested that before (previous IETFs, as well as earlier in this
conversation), but gotten no response.   I think part of the problem is
that setting up a jabber server isn't trivial, and isn't something most
people have done.   It's possible that if someone (you?) who has already
climbed that learning curve were willing to do it, this could be solved
quickly.

The Meetecho server is a lousy choice.   I tried using it this IETF, and it
demanded all kinds of authentication information I didn't have handy.
 Plus it consumes bandwidth even if you don't need the AV feed.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 12 Nov 2018 14:19:46 -0500

Perhaps it makes sense for the Plenary to just use WebEx?  It has good Q&A tools when used properly.

- Jared

> On Nov 12, 2018, at 2:16 PM, Ted Lemon <[email-masked]> wrote:
> 
> I spend as close to zero time on slack as possible, because it is such a time sink.   But to your point, yes, IETF could run its own jabber server, and I've suggested that before (previous IETFs, as well as earlier in this conversation), but gotten no response.   I think part of the problem is that setting up a jabber server isn't trivial, and isn't something most people have done.   It's possible that if someone (you?) who has already climbed that learning curve were willing to do it, this could be solved quickly.
> 
> The Meetecho server is a lousy choice.   I tried using it this IETF, and it demanded all kinds of authentication information I didn't have handy.   Plus it consumes bandwidth even if you don't need the AV feed.
> 
> 
> On Mon, Nov 12, 2018 at 2:14 PM Peter Saint-Andre <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Nov 2018 14:23:51 -0500

WebEx is disastrously bad.   Really poor video compression with,
ironically, fairly bad quality, doesn't work through a lot of firewalls,
etc.  People are switching away from WebEx to Zoom nowadays, because the UX
is so much better.  Maybe the Q&A tools are worth it, but I kind of doubt
it.   We should just figure out how to do fair queuing for the IETF
generally, and that should work fine for the plenary as well.   The trick
is that right now queuing at the mic lines is not part of the queuing
system—it's just done ad hoc, and generally not well.   So then when you
have fair queuing competing with ad hoc queuing, the result is mayhem.

On Mon, Nov 12, 2018 at 2:19 PM Jared Mauch <[email-masked]> wrote:

> > The Meetecho server is a lousy choice.   I tried using it this IETF, and
> it demanded all kinds of authentication information I didn't have handy.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 12 Nov 2018 14:32:38 -0500

> On Nov 12, 2018, at 2:23 PM, Ted Lemon <[email-masked]> wrote:
> 
> the result is mayhem.

You mean it’s the IETF :-)

- Jared

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2018 12:58:17 -0700

On 11/12/18 12:16 PM, Ted Lemon wrote:
> time sink.   But to your point, yes, IETF could run its own jabber
> server, and I've suggested that before (previous IETFs, as well as
> earlier in this conversation), but gotten no response.   I think part of
> the problem is that setting up a jabber server isn't trivial, and isn't
> something most people have done.

Aw, it's actually very easy. Much easier than managing an email server!

> It's possible that if someone (you?)
> who has already climbed that learning curve were willing to do it, this
> could be solved quickly.
> 
> it demanded all kinds of authentication information I didn't have
> handy.   Plus it consumes bandwidth even if you don't need the AV feed.

It's possible that all the choices are lousy. :-)

Peter

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Nov 2018 15:01:20 -0500

I think if there were a jabber server, ideally using the same
authentication as the datatracker so we don't have another ID to track,
that satisfied our logging needs, that would be Good Enough, and not at all
lousy.   Yes, clients are a problem, but there are clients, so they aren't
a _big_ problem.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 12 Nov 2018 20:14:26 +0000

Sounds good. Who do I need to talk to to get the ball rolling on this? I
can do the work, that's no problem, but I'll need hosting etc. Happy to
provide docker images etc to deploy.

On 12 Nov 2018 8:01 pm, "Ted Lemon" <[email-masked]> wrote:

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 12 Nov 2018 21:31:37 +0100

> ironically, fairly bad quality, doesn't work through a lot of firewalls,

RTCWEB has been going on since... 2011? You might want to try the Web 
version and if that still has crappy quality complain to the WG.

> is so much better.

Having tried the UX, I disagree. The web version is a truly nice hack 
though.

If you want to have fun, start a wireshark capture, then start the zoom 
client. Look for the DNS lookups. You will most likely see queries for 
hostnames that contain "xmpp". They don't federate but are probably 
among the ten largest c2s-only XMPP deployments in the world.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Nov 2018 13:48:05 -0700

Dave, I'll poke you offlist - I've talked with a few folks from the
Secretariat about this before.

Peter

On 11/12/18 1:14 PM, Dave Cridland wrote:
> On 12 Nov 2018 8:01 pm, "Ted Lemon" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     authentication as the datatracker so we don't have another ID to
>     track, that satisfied our logging needs, that would be Good Enough,
>     and not at all lousy.   Yes, clients are a problem, but there are
>     clients, so they aren't a _big_ problem.
> 
>     On Mon, Nov 12, 2018 at 2:58 PM Peter Saint-Andre
>     <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Nov 2018 18:06:29 -0500

> Having tried the UX, I disagree. The web version is a truly nice hack

Be that as it may, I don't see people switching _to_ WebEx, but I do see
people switching _from_ WebEx, and essentially all of my online meetings
except for IETF meetings are in Zoom these days.

> among the ten largest c2s-only XMPP deployments in the world.

Hey, I'm not saying that XMPP is bad.   I'm saying that it's a bit
inaccessible.   It sounds like maybe Peter and Dave are going to do
something to make it more accessible, so that's a great outcome as far as
I'm concerned!

---

From: Alessandro Amirante <[email-masked]>
Date: Tue, 13 Nov 2018 09:50:28 +0100

Il 12/11/18 20:16, Ted Lemon ha scritto:
> handy.   

Meetecho is a tool for *participating* remotely at IETF meetings. It 
allows you to actively contribute to the standardization process. As 
such, it requires you to be registered to the IETF meeting (either as 
on-site or remote participant) because you need to be identifiable and 
accept the "Note Well" (which you do during the registration process).

All authentication information you need is your name and your 
Registration ID, which is also printed on your badge if you're a local 
participant. There's also a clear way to retrieve it through the 
registration system.

> Plus it consumes bandwidth even if you don't need the AV feed.

Video feeds can be disabled from within the Meetecho UI. Audio can't. 
Anyway I do agree that using Meetecho only as a Jabber client is far 
from ideal and overkill. There are XMPP clients for that.

Alessandro

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 13 Nov 2018 14:28:50 +0000

Hi,

> -----Original Message-----
> From: ietf <[email-masked]> On Behalf Of Alessandro Amirante
> Sent: martedì 13 novembre 2018 09:50
> To: Ted Lemon <[email-masked]>; [email-masked]
> Cc: Paul Wouters <[email-masked]>; ietf <[email-masked]>
> Subject: Re: Jabber [Was: Plenary questions]
> 
> > The Meetecho server is a lousy choice.   I tried using it this IETF,
> > and it demanded all kinds of authentication information I didn't have
> > handy.
> 
> Meetecho is a tool for *participating* remotely at IETF meetings. It allows
> you to actively contribute to the standardization process. As such, it requires
> you to be registered to the IETF meeting (either as on-site or remote
> participant) because you need to be identifiable and accept the "Note Well"
> (which you do during the registration process).
> 
> All authentication information you need is your name and your Registration
> ID, which is also printed on your badge if you're a local participant. There's
> also a clear way to retrieve it through the registration system.

[>DC] I joined the Meetecho session during the session I was chairing. Obviously I didn't have my registration number at hand (I didn't notice it was on the badge) when asked for it but it took me 5 seconds to ask to have it re-sent by email. I couldn't ask for anything faster and easier than that.

BR
Daniele  

> Anyway I do agree that using Meetecho only as a Jabber client is far from
> ideal and overkill. There are XMPP clients for that.
> 
> Alessandro

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Nov 2018 09:35:19 -0500

FWIW, the problem with meetecho as a local jabber tool is not that it's
impossible to access it.   It's that it's not the right tool.   You have to
jump through hoops to use it, and then you wind up getting stuff you don't
need that needlessly consumes bandwidth and possibly causes feedback if you
don't mute your speaker.   The experience I reported of being "unable to
access jabber through meetecho" was really that combination of factors
arising in consciousness as a great big "nope" when I looked at the sign-in
screen.   I'm sorry if the way I reported it earlier made it out to be the
case that meetecho wasn't working—that really wasn't the point I was trying
to communicate.

On Tue, Nov 13, 2018 at 9:28 AM Daniele Ceccarelli <
[email-masked]> wrote:

> allows
> Registration
> [>DC] I joined the Meetecho session during the session I was chairing.
> Obviously I didn't have my registration number at hand (I didn't notice it
> was on the badge) when asked for it but it took me 5 seconds to ask to have
> it re-sent by email. I couldn't ask for anything faster and easier than
> that.
>
> BR
> Daniele
>
> >

---

From: [email-masked]
Date: Tue, 13 Nov 2018 06:37:40 -0800 (PST)

> from ideal and overkill. There are XMPP clients for that.

Actually, no, there really aren't, at least not on the Mac with any sort of
long term stability.

Having to shift clients from time to time has always been a pain, but it was an
unavoidable plain when Jabber was something I used at work and I had to expend
the time anyway. But now that Slack has completely replaced Jabber in the
workplace this is no longer the case.

I doubt I'm the only one for which this is true.

And so having to hunt for the working client du jour is no longer a task
I'm willing to perform.

The good news is the chat feature in Meetecho gets the job done for me.

				Ned