Subject: Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 26 Jun 2006 14:46:59 +0200

On 17:55 24/06/2006, Keith Moore said:
>That's not quite sufficient, because most WGs aren't proceeding 
>according to good engineering discipline (e.g. they're doing things 
>in the wrong order, like trying to define the protocol before the 
>problem space is understood), there's little external visibility of 
>what the WG is doing (so it's difficult to make timely input without 
>actually following the entirety of the mailing list discussion), and 
>often, nobody with any authority over the WG is checking to see 
>whether the WG is actually responding appropriately to such 
>comments.  A more formal process is necessary.

+1

> > Having some new sclerotic "pipeline" involved with the life
> > blood of a
> > working group sounds like a recipe for working group infarction to me.
>
>In other words, we don't want to distract WGs with useful input ... 
>better that they should keep their heads in the sand for the entire 
>2-3 years of their existence and then produce irrelevant or even 
>harmful output.  And that way, maybe a few influential people within 
>the WG can coerce the WG into producing something that favors their 
>employers' short-term interest even if it harms other interests or 
>glosses over important limitations.

+1

At 17:46 24/06/2006, Keith Moore wrote:
>One reason that it's difficult to charter and complete WGs might be 
>that WGs have demonstrated a huge potential to do more harm than good.

+1

May be my French "cartesian" spirit, but I feel all that denotes a 
lack of method. A methodology includes milestones and check points.

- someone/group proposes an area where to produce an IETF deliverable.
- a charter is drafted, discussed and approved for that deliverable (set).

I think it should be then appropriate that the WG

- starts understanding the charter
- possibly calls on its revision from this inner study
- describes what it wants to achieve and proposes a TOC of the 
intended document, explainging how it will fit the charter. That part 
should further on be used to document the deliverable and clarify 
possible confusions.
- gets the whole thing reviewed by the community.
- works on the content of the described deliverable.
- loops back into that process when the WG discovers a flaws at a 
previous level.

At each step any third party (other wg, IESG, IAB, users ..) could 
check the consistency between the intent and the deliverable.

This methodology is the one we all use when developping a software 
program. Or may be we are not? Or may be we have not much people 
developping running code anymore.

For example, I am amazed by the total lack of WG requests for IAB 
guidance. IAB should steer the IETF deliverable consistency.

jfc

I am amazed that m.

What the IETF does is to specify a program named "Internet".  

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Jun 2006 07:51:19 -0700

> From: Keith Moore [mailto:[email-masked]] 

> there is one important class of bad ideas that doesn't go 
> away in IETF -- the class of bad ideas that is obviously bad 
> from a wider perspective but which looks good to a set of 
> people who are focused on a narrow problem.  and in IETF what 
> we often do with those ideas is to protect them and encourage 
> development of them in isolation by giving them a working 
> group.  we sometimes even write those groups' charters in 
> such a way as to discourage clue donation or discussion of 
> other ways of solving the problem.

That is a somewhat cynical way to describe IPSEC isn't it? Care to mention any other groups that fit that description?

The IESG and the IETF in general has hardly demonstrated an infalible understanding of what is and is not a bad idea, nor for that matter has anyone else. This is a research area and there are plenty of areas where the great and the good get it wrong.

Take Gopher for example, I remember the days when the assumption was that the Web would merge into gopher rather than the other way round. After all the Gopher people knew so much more about networking. Only they did not understand the UI issue and it turned out thsat Tim had a much more powerful idea despite not being an IETF longtimer.

My theory is that Vint and Jon set up the whole IETF infrastructure as a Gordian knot test. Keep the systems safe from over tampering until someone comes along who is decisive enough and addressing a need that is so urgent that either the layers of obfustication will yield or they will snap.

No Keith, you are not Vint Cerf, or Tim Berners-Lee and neither is anyone else here including me.

I know that folk focused on narrow problems have tended to come up with narrow solutions. That is hardly suprising, the rules of engagement here prohibit the discussion of the general.

Take DKIM for example we are about to discuss a one off policy language to serve a single protocol, not because there is only a single protocol that requires policy but because there are people in the establishment who tried policy fifteen years ago, failled to solve the problem and have declared it 'insoluble'. There is also the problem of the other group who need s to be part of the policy discussion which has repeatedly demonstrated itself to be unwilling to listen to any outside view. Try to explain a problem to them and its 'la la la I'm not listening'.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Jun 2006 11:13:44 -0700

> From: Jeffrey Hutzelman [mailto:[email-masked]] 

> No, we don't.  We just need to discourage the practice of 
> waiting to write such a document until after protocol design 
> is complete, rather than doing it first.

That depends.

Take the recently renamed WAE. The original idea of this group was to go after phishing. I work on phishing every day, I think they would do far better and produce something with much more immediate impact by instead applying their technology to the problem of Internet pedophiles.

Changing bank authentication infrastructure is hard and the liability issues are savage.

Bottom up work is what this particular community does best.