Subject: Pervasive abuse

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 2015 07:04:00 -0800

There should be little comfort in seeing that the IETF is not the only
place that being personally abusive is the norm:

     Linux kernel dev Sarah Sharp quits, citing ‘brutal’ communications
style

http://www.networkworld.com/article/2988850/opensource-subnet/linux-kernel-dev-sarah-sharp-quits-citing-brutal-communications-style.html

Direct assaults on specific individuals are the easy examples to see,
even if they do not cross over as an attack on an identified class.

What is more difficult to note and appreciate is a general tone of
disrespect spread more broadly, by studiously misinterpreting what is
said, asserting strawmen, and otherwise serving to distract from the
focus on what was said.

Then of course, there are the nearly-inevitable and unprofessional
snipes about whining and micromanagement.

All of which work quite nicely to undermine broad participation by
presenting a very strong disincentive to most participants, who can see
little benefit and much unpleasant risk in making suggestions or even
participating in public discussions.

Note the latest thread about IESG workload as merely one example of the
severe lack of community engagement.

But really, it's so much more satisfying to be dismissive of proposals
than it is to focus on real and basic problems.  Real and basic problems
are difficult to solve.  Sniping is easy.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Nov 2015 14:12:05 -0500

> even if they do not cross over as an attack on an identified class.

I think the IETF has issues in this area but I haven't seen behavior
remotely like the rant about the IPv6 code someone attempted to commit
to the kernel. There are pathologies in IETF interactions but I don't
think this is a particularly good illustration except to the extent
that it is an example of someone trying to do the right thing, getting
a large amount of aggravation and giving up.

In that particular case the author of the rant was complaining about
this specific line in the IPv6 stack:

if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||
mtu <= 7) goto fail_toobig;

Now without wanting to rehash the dispute here. The code corrects a
real security problem in the original code and an architectural issue
in IPv6 in general that is understood today but was not recognized in
1995.

Specifically, if you have a protocol in which byte length is used to
denote the length of nested structures, an inconsistency can arise
when a sequence such as 8 { 3 { a } 4 { b c } is incorrectly presented
as 8 {100000000 {a } 4 {b c} }. That is the heartbleed bug.

What I see in the code there is someone making a perfectly reasonable
engineering decision and then being bullied into submission by someone
throwing their reputation about. All bugs may be shallow given enough
eyes. But those of us who have studied the history of intelligence
services know that there are countless examples of agencies having an
abundance of eyes studying a subject whose advice and conclusions were
ignored by a tiny number of individuals.

IETF aggravation doesn't come in the form of 'This is S**t'. It comes
in the form of 'you need input from Fred' where Fred will turn out to
have no actionable advice.

In particular, I think that we have on rather too many occasions
failed to remember that the whole point of the Internet architecture
is to see what could happen if we just let chaos run. The approach to
architecture that is appropriate at layer 3 in the stack is not
appropriate at layer 7.

For the Internet to work it is essential that the routers, switches,
etc. that make up the 'Inter-network' have a common understanding of
what they are doing and perform their actions in ways that other parts
of the infrastructure can predict. Caution is required, inappropriate
changes could potentially bring down the whole stack of cards.

At the application layer, the approach has rather too often been to
tell people to 'be careful' and what they are doing it 'difficult' or
'tricky' without any explanation of what to be careful of how to avoid
the difficulties that might be faced or even what they are. Thus
ensuring that people attempting to address a problem in that area have
the maximum discouragement and the minimum amount of useful
assistance.

There is a Reverse Dunning-Kruger effect where a person realizes that
a problem is difficult and assumes that since they can't solve it,
nobody else can either. They must therefore warn anyone who might
attempt that problem of how difficult it is going to be and if
possible discourage them from the attempt.

Which is of course nonsense as if you look at the reason the Web works
and other attempts to build network hypertext infrastructures failed
is that Tim Berners-Lee decided to ignore the hard problems entirely.
Referential transparency is a difficult problem, OK lets not bother
then, show 404 not found. But! But! I have spent 20 years designing
algorithms for efficient referential transparency!

At the moment we have several points in the IETF process where
supplicants are asked to jump through hoops to get a code point
assigned for an application layer protocol. And one of the reasons we
have those check points is that there are lots of people who seem to
thing something really bad can happen if someone accidentally does the
wrong thing.

Hello.

Why are we so bothered about people bringing down the Internet by
accident when the folk who have been trying to do the same thing on
purpose haven't managed it yet? Yes, I know they cause a lot of
aggravation and annoyance but they aren't going to succeed.

The only way someone could bring down the Internet with an application
is if they produced one that was so awesome and useful that the three
billion users all decided they had to get it. And if someone has an
idea that powerful, denying them an SRV registration isn't going to
stop them.

I would like it if we could get back to the idea of the Internet being
an enabling platform for people to try stuff out. I would like it if
we could somehow get all those folk who are getting excited about the
Internet of things had a way to quickly and easily get 1) single code
point that assigned them a DNS SRV prefix, a HTTP .well-known prefix
and a chunk of URN space and 2) a short guide with suggestions for how
they might use it and avoid later regrets.

So instead of having to fire off three separate applications for the
Mesh, I would make a request for the codepoint 'MatheMaticalMesh' to
be reserved to me. That would automatically give me authority to
define documents specifying the interpretation of:

_mathematicalmesh._wk.example.com SRV ...

http://example.com/.well-known/MatheMaticalMesh/

urn:mathematicalmesh:

My problem with IETF isn't that people will say 'this is sh*t' to my
face. My problem is that when I make a request I can never really know
if the reason it takes six months or two years to get a response is
because everyone is really busy or because that is what people are
saying behind my back.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 10:27:31 +1100

In message <CAMm+LwiF5=GO_xxdBohh2U85dppu1VffKMrM3zYvH_JmE=[email-masked]>
, Phillip Hallam-Baker writes:
> >      Linux kernel dev Sarah Sharp quits, citing =E2=80=98brutal=E2=80=99 =
> communications
> > style
> >
> >
> > http://www.networkworld.com/article/2988850/opensource-subnet/linux-kerne=
> l-dev-sarah-sharp-quits-citing-brutal-communications-style.html
> >
> mtu <=3D 7) goto fail_toobig;
> 
> 

How does anyone know you need code points in the three spaces?  Do
you need a code point in a forth space?

> because everyone is really busy or because that is what people are

I needed 2 code points for EDNS COOKIES.  I had both of them within
a days of the initial request.  One is permanent (edns option=EDNS
COOKIES) and one is provisional (rcode=BADCOOKIE).  Both were sent
to IANA using the general code point assignment request form.  Both
are in use in production code which was released weeks after the
requests (BIND 9.10.3).

The paperwork (I-D) which covers these is at AD Evaluation.  It's
needed for BADCOOKIE.  Its useful for EDNS COOKIES.

Prior to requesting EDNS COOKIES I played around using a private
code point to ensure that I was happy with the design of the option
in BIND 9.10.0, BIND 9.10.1 and BIND 9.10.2 knowing that I could
request a final code point once everything was stable.

Those experiments and the observed misbehaviour of some DNS servers
lead me to measuring EDNS comliance in authoritative servers
https://ednscomp.isc.org/compliance/summary.html and to write
draft-andrews-dns-no-response-issue.  I don't like having to write
code to work around other vendors misimplementations of what is a
straight forward specification.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Nov 2015 21:11:35 -0500

> you need a code point in a forth space?

I have just asked to register mmm for the SRV space.

I will be *REALLY PEEVED* if I get that and then someone else gets mmm
for the .well-known. And so would anyone else if that happened to them
I expect. Or lets take another example:

http://example.com/.well-known/pop3/

Makes no sense, right? Well what if we end up using Web Sockets for
everything. Maybe not over http but it could make a lot of sense to do
it that way over SSH or some other VPN like protocol.

My point there is that once you have an assignment in one space, the
others had better be consistent or else we are creating trouble for
ourselves. Even if I don't need that code point, nobody else can have
it. There are plenty of 15 character alphanumeric strings.

Even odder, the process for reserving at IANA doesn't actually match
the RFC at all. That isn't bad, in fact one of the things they have
done is to remove an issue in the spec that makes no sense, namely
having to give a spec for an open protocol but not a proprietary one.

> are in use in production code which was released weeks after the

Well that would just fuel people's suspicion that you have to know the
right secret handshake to get things done.

Or problem is not the same as the one facing the Linux kernel. But
that is not the same as not having any problems.

I don't see people saying they don't want to be involved in IETF
because of people being openly aggressive and rude. I do see people
getting turned off because they feel their input isn't considered as
worthwhile as those of the inner circle or you have to be in the right
club to get things to happen.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Nov 2015 01:21:23 -0200

For what it is worth, I have said this elsewhere but I
can repeat it here: the recent Linux discussion style
examples are bad. When an aggressive communication
style is taken into use — particularly if used by
prominent members — the communication effort
turns into heat and anger. Real information (if any)
is lost, no learning can happen, people start to be
afraid to take up issues, and for what? To score
points? To follow an established style? I think
communities in open source and standards world
have better things to do. Like continue to build
better operating systems and Internet protocols.

I don’t think we have the kind of style in the IETF
that was used in the example, but we of course
have problems. Let me be the first one to confess
to many sins, starting from expressing far too sharp
criticism, instead of working together to increase my
and other people’s understanding of a topic.

But I’m probably not the only one. Please take
a moment to consider how you communicate.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Nov 2015 01:21:23 -0200

Jari