Subject: RE: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 19 Sep 2006 11:26:50 -0700

For what it is worth my takehome from the Montreal meeting was that there was genuine desire for change but no recognition of consensus on a particular way forward.

One of the reasons that there is no recognition of consensus on a way forward is that we did not learn the nature of the objections from the IESG or even who was making it. In other words precisely the type of opaque decision making processes that were being criticized.

It is a FACT that the IETF produces a minute number of actual 100% standards each year. You are the one indulging in handwaving here, not me. 

It is a FACT that when I am asked to propose venues for standards activities the IETF is currently a much harder sell than it should be. 

Stop trying to shoot the messenger here. I want to be in a position where I can suggest bringing work to the IETF in a pre-standards multi-party meeting and not having people laugh or groan.

I certainly do not recommend IETF in all circumstances, nor do I recommend against IETF in every case. My problem is that I cannot recommend IETF in as many situations as I would like.

The two principle issues being the lack of standards recognition (pushback: can't we just do an informational RFC) and the large dose of Not Invented Here.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, September 19, 2006 11:34 AM
> To: Eliot Lear
> Cc: [email-masked]
> Subject: Re: Facts, please, not handwaving [Re: Its about 
> mandate RE: Why cant the IETF embrace an open Election Process]
> 
> Eliot Lear wrote:
> > Brian E Carpenter wrote:
> > 
> >>>We could argue this interminably or you could simply grasp 
> the nettle 
> >>>and align theory with reality.
> >>
> >>It was clear in Montreal that there is no community 
> consensus to spend 
> >>effort on doing this, so we have closed down this avenue for now.
> > 
> > 
> > I'm sorry, Brian, but this answer is truly unacceptable.  
> Reality is 
> > that our 3 step process is not functioning as documented.  
> We thought 
> > we were fixing it in NEWTRK, but you shut down that group.  Please 
> > tell me and the rest of the community what path you expect 
> to correct 
> > the error.  If you don't have a proposal I will have one of my own.
> 
> I'm not sure that I can say it more clearly than I did the first time.
> I do not believe there is enough interest in this problem in 
> the community to invest effort in fixing it. That is quite 
> distinct from whether you, I or a number of other individuals 
> believe it needs fixing.
> 
> I think you weren't in Montreal. You might want to check the 
> plenary minutes at 
> http://www3.ietf.org/proceedings/06jul/plenaryw.html
> or listen to the audio at
> ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ietf66-c
h5-wed-plenary.mp3
> 
> If you can build a strong constituency for a given proposal, 
> that might change things. But over the last few years, I 
> haven't seen more than a few people supporting any given 
> proposal, including ones that I've made, and that doesn't cut 
> it for something that affects every single WG.
> 
>      Brian
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Sep 2006 10:51:44 +0200

> One of the reasons that there is no recognition of consensus on a way forward is that we did not learn the nature of the objections from the IESG or even who was making it. In other words precisely…

There was, to recall history, no consensus in newtrk for any particular
choice among the various options for simplifying the 3 stage process.
So the IESG never saw or responded to any proposal in that area.

There was consensus to put forward the ISD proposal, which the IESG kicked
back, with an explanation of its issues, which you can find in the
newtrk archive. That didn't lead to a revised ISD proposal.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Sep 2006 11:32:05 +0200

Brian,
> newtrk archive. That didn't lead to a revised ISD proposal.

So that it's clear, I am not now nor was I then a proponent of ISDs.  I
think they're too complex.  However, I don't think the IESG provided
appropriate guidance.  Here is the last paragraph from the note you
reference:

> Regardless of what approach is taken, we need to consider the
> procedural implications of these changes.  We believe that significant
> effort needs to be put into thinking about how these changes will be
> automated. The only way to constantly improve the IETF's document
> throughput is to maximize automatic tools. Before any ISD proposal
> can be implemented, we need to understand how it would be implemented,
> how it would modify the existing automation tools, who would implement it
> and what the costs would be.  This effort needs to be closely coordinated
> with the ISD proposal: while these details may not be appropriate to
> include in the ISD document we need to confirm implementation is
> possible while we can still make changes to the proposal. 

The IESG notes that there would be tool issues but doesn't say who
should address those issues.  Was it newtrk?  If so, how should the
issues be addressed?  To the IESG's credit you did provide at least
something of a menu of options, but it was
I would ask that in the future, when the IESG rejects a working group
consensus document, it should be more clear.  It should say one of the
following:

   1. The IESG disagrees with this document in its entirety and refuses
      to advance it, and here's why; or
   2. The IESG disagrees with part of this document and refuses to
      advance it, here's why, and here's what the WG must do to fix it.

I think that fundamentally the IESG and the working group disagreed,
leading to a stalemate.  In a stalemate, the status quo wins.  Not that
I see anything wrong with that, but if you wanted change you could have
been more prescriptive, and you weren't.  The result was (1) in (2)'s
clothing.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Sep 2006 11:47:30 +0200

I garbled:
> To the IESG's credit you did provide at least

... not clear you would advance a draft even if we advanced one of those
options.

Eliot

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 20 Sep 2006 06:54:33 -0500

My apologies in advance for posting in this thread.

> So the IESG never saw or responded to any proposal in that area.

My understanding (as author of three of the proposals) was that for most of 
the time newtrk was in existence, the working group's attention was focused 
on ISDs as a way of avoiding the need to tackle the 3 stage process. So I'm 
not sure there was even a call for consensus on adopting any of the 
proposals as a working group document.

FWIW.

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 20 Sep 2006 06:54:33 -0500

FWIW.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Sep 2006 13:58:35 +0200

> ... not clear you would advance a draft even if we advanced one of those

Well, there wasn't likely to be a blank check promise to advance
a draft, was there?

But I think there is a message here - badly phrased perhaps - that
running code is needed for such proposals to be thoroughly considered.
Suppose there was a proposal that all RFCs should be sourced as XML
files. We have a lot of running code to measure that proposal against.
Douglas Otis started work on running code for his alternative to ISDs.
I'm sure that's the best way to bring ideas in this space forward.

     Brian

58:34 +0200
Date: Wed, 20 Sep 2006 13:58:35 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: Facts, please, not handwaving [Re: Its about mandate RE: Why
 cant the IETF embrace an open Election Process]

> ... not clear you would advance a draft even if we advanced one of those

Well, there wasn't likely to be a blank check promise to advance
a draft, was there?

But I think there is a message here - badly phrased perhaps - that
running code is needed for such proposals to be thoroughly considered.
Suppose there was a proposal that all RFCs should be sourced as XML
files. We have a lot of running code to measure that proposal against.
Douglas Otis started work on running code for his alternative to ISDs.
I'm sure that's the best way to bring ideas in this space forward.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Sep 2006 14:15:30 +0200

Brian,
> I'm sure that's the best way to bring ideas in this space forward.

In general I agree that running code is the strongest indicator - one
way or another.  This having been said, process experiments with the
document series are troublesome, because at the end of the experiment we
are left in a situation where we have to clean it up, usually by further
annotating the documents in some way that hopefully does not go against
the intentions of prior decisions.  Tricky stuff.

I am in favor, instead, of an evolution as opposed to revolution.  Let
me stop there.  I'll have a draft in the coming days over which we can
further debate.

Eliot

---

From: [email-masked] (Scott Bradner)
Date: Wed, 20 Sep 2006 08:23:02 -0400 (EDT)

> proposals as a working group document.

almost

the newtrk chair (at least) felt that ISD would remove the issue of how
many stages by taking a different path

Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Sep 2006 20:56:55 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Brian,
    >> I'm sure that's the best way to bring ideas in this space forward.

    Eliot> In general I agree that running code is the strongest indicator - one
    Eliot> way or another.  This having been said, process experiments with the
    Eliot> document series are troublesome, because at the end of the experiment we
    Eliot> are left in a situation where we have to clean it up, usually by further
    Eliot> annotating the documents in some way that hopefully does not go against
    Eliot> the intentions of prior decisions.  Tricky stuff.

Eliot I look forward to reading your draft with interest.  However, I
expect that I'll read it, agree with parts of it and go recommend you
run an experiment on it.  That, even given your concerns about running
experiments with the document series.