Controlling the IETF -- Engineers vs. Marketeers and Politeers

Vach Kompella vkompella at timetra.com
Mon May 26 11:55:45 CEST 2003


Dave,

If we could exclude the marketeers and the politeers from the IETF and from
society...

More comments below.

-Vach

>
> The discussion about standards track status highlights a basic source of
> disparity in quite a few of our discussions about changing the IETF.

When does the world outside the IETF decide that documents are making adequate
progress that they may talk about them?  Typically, when they hit certain
milestones - WG accepts the draft, draft goes to IESG, various RFC labels
attached to document...  These _are_ important for an organization to judge
whether something is worth implementing/deploying/marketing.

>
> I'm finding myself labeling this disparity "Who is in charge of the
> IETF?"

If we let them, then the marketing arms of organizations are.  They are a far
more powerful lobby than engineers have been.

>
> Historically, the IETF has done exceptionally well when it focuses on
> the "E".  When we act like engineers who are concerned with engineering
> quality and core utility, we do great.

The best we can do is to ignore the stuff outside the IETF, and prevent
marketing/politics from influencing the IETF.

>
> When we wander into the territories of sociology, marketing or politics,
> we do very badly.
>
> Input from those three areas can be useful.  But there is a difference
> between treating those considerations as "input" and treating them as
> "critical concerns that must determine strategic decisions".

Harald posted an email about "fixing" WG chairs and the counterpoint of
"accusations of fixing".  How we deal with those situations is critical to the
independence of IETF decisions from the World Outside the IETF.

Likewise, ballot stuffing, denial of service.

>
> There is always someone, somewhere who will abuse our work in some
> fashion.  They will tout an I-D as being under IETF consideration; they
> will tout an Informational RFC as an IETF standard, they will pressure
> the IETF to use small key sizes; etc., etc.

Abuse is one thing.  Affecting the integrity of the IETF is another.

>
> We must not let these people control the IETF.
>
> We need to make sure that the meaning of I-D status is clear and is
> applied correctly.  The same for Informational.  We need to make sure
> that we choose key sizes that ensure the ability to provide the level of
> protection that is needed.  Etc. Etc.

I agree.  Clear definitions allow us to correct impressions created by
"marketeers" and "politeers".

>
> These are engineering factors and they are what we have historically
> done well.
>
> When we make strategic decisions because someone, somewhere has
> distorted things, we cease to be engineers.  We pretend to be
> politicians, marketeers and sociologists.

I disagree.  We don't pretend.  We are surely influenced by the organizations we
work for.  I think that our only hope is to define clear processes so we can
create enough organizational influence to prevent ourselves from shooting
ourselves in the foot.  Basically create a set of checks and balances that
ensures that one group doesn't push the IETF the wrong direction.

>
> Let's keep control of our work WITHIN the group doing the work, namely
> the iEtf.

It's the Ietf to most people, i.e., there's a lot more riding on the Internet
today than engineering.

>
> Let's discuss changes to the IETF that pertain to doing better
> engineering. That means focusing on engineering design quality and the
> utility of our specifications. It means focusing on deployment and use.
>
> It does not mean trying to react to "social" abuses and it does not mean
> trying to anticipate them.
>
> We have management and quality problems.  Let's fix them.
>
> But let's not be distracted by the folks outside the world of IETF
> development and implementation.
>

It does mean reacting to abuses.  It means limiting the impact of those abuses
to outlying instances rather than letting them be the norm.  It means not
putting our heads in the sand about them actually occurring.  It means defending
the IETF against them.

>
> d/
> --
>  Dave Crocker <mailto:dcrocker at brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>
>




More information about the Problem-statement mailing list