Subject: Conclusions on draft-housley-two-maturity-levels

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Sep 2011 20:47:24 +0300

Discussion on this topic has continued after my first attempt at judging consensus. Additional people provided opinions (both positive and negative), some new ideas were brought up, and some of the previous discussion continued further. Some of the topics in the discussion included:

- status and interpretation of the consensus
- possibilities for making additional process related changes (I promised to start an effort to go through past proposals)
- concerns on the way that current or past process related process changes have been brought forward by the IESG
- alternative or additional proposals (such as Fred Baker's proposal to focus on documenting interoperability)

I have reviewed the mailing list discussion yesterday and have found that while there are more people on the positive side than on the negative side, the consensus is extremely rough, more rough than it was before. It was also very difficult to make a full determination, because a lot of the discussion has been on tangential topics, because in many cases it has been hard to see if a person is on the "no objection", "absolutely not", or "I have these additional ideas" camp, and because not all points raised in the discussion got responses. I have leaned towards recommending to the IESG that there is consensus to move forward. But it is certainly weaker consensus than what I would normally like to see, and my recommendation was in part based on the desire to move from "it does not hurt but we should rather do something else" to actually looking also at some of those other things. I also think we have gotten as far on this topic as we will get.

The IESG discussed the situation with this draft on its call yesterday and decided to approve the document. A formal approval notice will be forthcoming in the next couple of days.

Russ and I are working to compile a list of IETF process-related proposals to find possible additional proposals to take further. Stay tuned. (And if you have process-related improvement/reality-alignment proposals, drop us a note if you have not yet done so.)

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 9 Sep 2011 14:08:03 -0400

Hi Jari,

> The IESG discussed the situation with this draft on its call yesterday and decided to approve the document. A formal approval notice will be forthcoming in the next couple of days.

What did the IESG decide about when/how this draft will take effect?  Has a group been formed to assess its impact and/or to make sure that any changes related to this draft happen in a coordinated fashion?

Do we need any tracker (or other secretariat tools) upgrades as a result of this change?  If so, is there a plan in place to do those upgrades?

Has there been any discussion with the RFC editor on how/when such changes can be implemented in their process/tools?

I'm interested in knowing what sort of planning is underway for this change and when it is expected to happen, because there will be some (not extensive, but non-trivial) updates required to the EDU Team materials related to this change (mostly in the Newcomer's training that Scott Bradner teaches, and the Document Lifecycle course that Alice Hagens and I teach), and I'd like to know the schedule for when they should be completed.

Also, as you look at other proposed changes, please remember that any change that we make does have some costs associated with it.

Thanks,
Margaret

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Sep 2011 15:13:49 -0400

> What did the IESG decide about when/how this draft will take effect?  Has a group been formed to assess its impact and/or to make sure that any changes related to this draft happen in a coordinated…

Section 2.3 of the document addresses some of this topic.  I do not believe that a coordinated effort is needed.

> Do we need any tracker (or other secretariat tools) upgrades as a result of this change?  If so, is there a plan in place to do those upgrades?

There is a very minor Datatracker change needed.  The 'Draft Standard' option needs to be removed for publication requests.  Until this happens, ADs and Secretariat staff need to avoid choosing it.

> Has there been any discussion with the RFC editor on how/when such changes can be implemented in their process/tools?

Several months ago, there was a brief discussion.  Since all of the current Draft Standards remain so, there is nothing urgent.

> I'm interested in knowing what sort of planning is underway for this change and when it is expected to happen, because there will be some (not extensive, but non-trivial) updates required to the ED…

When the RFC is published, I would expect publication requests for Draft Standard to stop.

> Also, as you look at other proposed changes, please remember that any change that we make does have some costs associated with it.

Thanks,
Russ

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 10 Sep 2011 08:47:10 -0700

On 9/9/2011 10:47 AM, Jari Arkko wrote:
>  It was also very
> difficult to make a full determination, because a lot of the discussion has been
> on tangential topics, because in many cases it has been hard to see if a person
> is on the "no objection", "absolutely not", or "I have these additional ideas"
> camp, and because not all points raised in the discussion got responses.

The pattern of failure to make changes to IETF process and structure has 
involved many people and many years.  This means that there is an underlying 
problem with making change that has nothing to do with particular individuals or 
particular proposals.

Whatever the details in any one case, there's been an overriding consistency to 
my eyes:  Proposals die from the death of a thousand criticisms.  Rather than 
work to a common proposal, there is always a pattern of decrying a proposal's 
lack of perfection and a variety of different proposals are put forward, none 
garnering a base of support.

That is, rather than displaying the usual IETF style of seeking compromise to 
make progress, efforts are killed by individual, rigid idealism.  (In terms of 
project management, I think there also tends to be a failure to develop a core 
of supporters to provide vigorous aid in making progress, but there have been 
exceptions that still failed.)

In the current case, it's been particularly impressive to see criticisms against 
the proposal because it does not solve problems it is not trying to solve and 
because other problems are deemed "higher priority".

Nevermind whether the proposal does something constructive, let's complain that 
it doesn't do enough.

Before the jointly-authored draft was released, I lobbied to have it contain a 
longer list of possible justifications, specifically to reduce the danger of 
relying on everyone's agreeing with any specific justification.  We stalled on 
releasing the document because of this and I finally decided that since the more 
challenging, normative content had agreement among the authors, we should not 
hold the document back on this non-normative point.

No matter the document's own efforts at justification, there is a basic reality 
we have a non-functioning standards sequence that ought to embarrass us, and an 
effort to get it better aligned with reality ought to be intuitively appealing.

There's a good argument for simply going to a one-step process; the argument 
against it is that there might be benefit in the proposed two-step and we will 
never know if we directly jump to one-step.  Personally, I think a low-hurdle 
step that permits recording the actual success of a protocol is worthwhile and 
warrants the second step.

Folk who put forward a proposal tend to be absolutely certain that it will make 
everything -- or at least quite a bit -- better.  I certainly have held that 
view for mine and we've been seeing others demonstrating equal certitude about 
theirs.

The problem is that when it comes to organizational change, it's rare that 
anyone can legitimately be certain of efficacy, nevermind the details of 
unintended -- and usually deleterious -- consequences. (This well-enough 
established to be a cliche when teaching organizational behavior and the like.)

That's the reason initial changes should be small and simple.  It's even more 
important when the community is not well-aligned.

The current draft makes relatively small changes, but includes clarifications 
that ought to be helpful in both lowering some actual barriers and explaining 
purpose.  While I'm not in the camp that expects this to change working group or 
Area Director behavior all that much, regarding new Proposed, it might, and that 
would be nice.

More, it provides substantive clarifications for cycling at Proposed and for the 
criteria to reach Full.  I view both of these as significant.

The most important requirement in making systemic change is creating momentum 
for being productive.  For "interesting" systems needing significant change, 
this is best done by starting with a baby step.  Instead, the IETF seems intent 
on throwing the baby of progress out with the bath water of perfection.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 10 Sep 2011 19:14:18 +0200

On Sat, Sep 10, 2011 at 5:47 PM, Dave CROCKER <[email-masked]> wrote:
> problem with making change that has nothing to do with particular
> individuals or particular proposals.

Another way of looking at it might be that people in general try to
solve everything and make thing perfect... and in that process forget
that it really is all of those small steps that matter. One good
proposal that address and solve one problem in a good way is one of
those small steps.

... and btw, I haven't read this entire proposal all the way through,
but if it do address one problem and solve/fix it, then this proposal
for sure is a good thing. One of those small steps :-)

--- Roger J ---
> Whatever the details in any one case, there's been an overriding consistency
> to my eyes:  Proposals die from the death of a thousand criticisms.  Rather
> than work to a common proposal, there is always a pattern of decrying a
> proposal's lack of perfection and a variety of different proposals are put
> forward, none garnering a base of support.
>
> That is, rather than displaying the usual IETF style of seeking compromise
> to make progress, efforts are killed by individual, rigid idealism.  (In
> terms of project management, I think there also tends to be a failure to
> develop a core of supporters to provide vigorous aid in making progress, but
> there have been exceptions that still failed.)
>
> In the current case, it's been particularly impressive to see criticisms
> against the proposal because it does not solve problems it is not trying to
> solve and because other problems are deemed "higher priority".
>
> Nevermind whether the proposal does something constructive, let's complain
> that it doesn't do enough.
>
> Before the jointly-authored draft was released, I lobbied to have it contain
> a longer list of possible justifications, specifically to reduce the danger
> of relying on everyone's agreeing with any specific justification.  We
> stalled on releasing the document because of this and I finally decided that
> since the more challenging, normative content had agreement among the
> authors, we should not hold the document back on this non-normative point.
>
> No matter the document's own efforts at justification, there is a basic
> reality we have a non-functioning standards sequence that ought to embarrass
> us, and an effort to get it better aligned with reality ought to be
> intuitively appealing.
>
> against it is that there might be benefit in the proposed two-step and we
> will never know if we directly jump to one-step.  Personally, I think a
> low-hurdle step that permits recording the actual success of a protocol is
> worthwhile and warrants the second step.
>
> Folk who put forward a proposal tend to be absolutely certain that it will
> make everything -- or at least quite a bit -- better.  I certainly have held
> that view for mine and we've been seeing others demonstrating equal
> certitude about theirs.
>
> That's the reason initial changes should be small and simple.  It's even
> more important when the community is not well-aligned.
>
> The current draft makes relatively small changes, but includes
> clarifications that ought to be helpful in both lowering some actual
> barriers and explaining purpose.  While I'm not in the camp that expects
> this to change working group or Area Director behavior all that much,
> regarding new Proposed, it might, and that would be nice.
>
> More, it provides substantive clarifications for cycling at Proposed and for
> the criteria to reach Full.  I view both of these as significant.
>
> The most important requirement in making systemic change is creating
> momentum for being productive.  For "interesting" systems needing
> significant change, this is best done by starting with a baby step.
>  Instead, the IETF seems intent on throwing the baby of progress out with
> the bath water of perfection.
>
> d/
> --
>
>  Dave Crocker
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sat, 10 Sep 2011 19:31:18 -0400

On Sep 10, 2011, at 11:47 AM, Dave CROCKER wrote:

> In the current case, it's been particularly impressive to see criticisms against the proposal because it does not solve problems it is not trying to solve and because other problems are deemed "higher priority".
> 
> Nevermind whether the proposal does something constructive, let's complain that it doesn't do enough.

It wasn't at all clear that the "two levels" proposal did anything constructive.

Keith