Subject: No single problem... (was Re: what is the problem bis)

From: Ted Hardie <[email-masked]>
Date: Fri, 29 Oct 2010 16:15:55 -0700

As is moderately obvious from the stream of commentary on this
thread and there companions, there is no *one* problem at
the root of all this.  One way to draw this is:

Issue:  Documents are too slow in achieving the first rung of the
standards process

Contributing issues:

--------->WG formation is slow, as there are now often 2 BoFs before work begins
--------->Working group activity is slow, as it pulses to physical meetings
--------->Late surprises arrive from late cross-area review (often
from teams) or the IESG
--------------->Because there is little early cross-area review after a BoF

Resulting issues:

------->Little energy remains in working groups to advance documents
once they do complete
-------->The IESG sees that few documents get early re-review as part
of advancement, and
             raises the document quality requirement for the first
rung to prevent impact on the
             rest of the ecosystem

Results of the results:

------->Things get slower
------->More work is done outside the IETF and brought in only to be blessed
------->More of the internet-runs on Internet Drafts.

Results of the results of the results:

--------->It's harder to tell which documents are actually the ones
you need, both because
             some actual Standards documents are obsoleted by drafts
and because some sets
             of drafts have functional consensus and some don't.

Results of the results of the results:

---------->ADs and others want more tutorial data added to the RFCs,
which makes
           producing them slower.

Try to find one place to tug on this and the actual results of your
tugging won't
really be seen until a full document cycle, and there will be odd
states in between.
That causes debate and discussion, and worry with all the nice people
we've tasked
to worry about these things (and many others besides).  That burns energy that
could be going into working groups and, well, you get the picture
(things get slower).

Should we do nothing?  No.  But we need to accept that no single thing we do
is going to solve all of the problems.  Changing the document labeling
will not increase
early cross-area review.  But if the top-line issue is "Documents achieving the
first rung of the standards track do so too slowly" we may have to tackle
it, the WG creation problem, and the WG "pulsed activity" problem at once
to make real progress.

If the problem we want to tackle is "The first rung is set too high", then there
are other possibilities (including simply recognizing that the first rung is
really WG draft, marked or unmarked as it may be).   I personally don't
think that's quite enough, as the value of the IETF (as opposed to its
working groups) is that it can and does cross-WG and area review.  But I
see the attraction--if the first rung goes lower, the documents may be produced
faster, which can mean that there is enough energy to go up the track plus
the cross-area review is functionally earlier. My worry (yes, I worry)
is that if we
re-use a label for the first rung after lowering its bar, we create a
confusion that we
can't easily solve *especially if the energy does not magically appear*.

As we stare down this rathole one more time, let's at least be certain
that there is more than one rat down there, and be realistic about the
energy we have on how many we can tackle.  Russ's draft tries to
do two things:

Restore the 2026 rules for Proposed as the functionally in-use bar for the
first rung.

Reduce the bar for Standard to the old bar for Draft.

Listening to the discussion, I think we have focused a great
deal on point two, but have either not really noticed point
one or didn't believe it.    I think this addresses a marketing problem
(long an issue, though now commonly explained away) and it
focuses on the first two "resulting issues" in the quasi-chart above, and
thus may have some cascade effects on the other two.  It doesn't
tackle any of the contributing issues, but this is not really a defect
in my eyes, as those can't really be addressed by document issues.

Are there other ways to tackle this?  Sure.  But if the community
accepts that this restores the 2026 bar for the first rung *and holds the IESG
to it*, then I think this is one useful place to tug on the tangle of issues.

Just my two cents,

regards,

Ted

---

From: John Leslie <[email-masked]>
Date: Fri, 29 Oct 2010 19:46:11 -0400

The first part of Ted's post is excellent:

Ted Hardie <[email-masked]> wrote:
> ------- Contributing issues:
> 
> --------> WG formation is slow, as there are now often 2 BoFs before
>           work begins
> --------> Working group activity is slow, as it pulses to physical
>           meetings
> --------> Late surprises arrive from late cross-area review (often
>           from teams) or the IESG
> ---------------> Because there is little early cross-area review after
>                  a BoF
> 
> ------- Resulting issues:
> 
> --------> Little energy remains in working groups to advance documents
>           once they do complete
> --------> The IESG sees that few documents get early re-review as part
>           of advancement, and raises the document quality requirement
>           for the first rung to prevent impact on the rest of the
>           ecosystem
> 
> ------- Results of the results:
> 
> --------> Things get slower
> --------> More work is done outside the IETF and brought in only to
>           be blessed
> --------> More of the internet-runs on Internet Drafts.
> 
> ------- Results of the results of the results:
> 
> --------> It's harder to tell which documents are actually the ones
>           you need, both because some actual Standards documents are
>           obsoleted by drafts and because some sets of drafts have
>           functional consensus and some don't.
> 
> ------- Results of the results of the results:
> 
> --------> ADs and others want more tutorial data added to the RFCs,
>           which makes producing them slower.

   (The rest of his post is less important; I won't repeat it.)

   Relatively little of this, IMHO, results from RFC 2026, so I must
admit to being a little surprised how many folks continue to argue
that we'll fix this by changing one particular part of RFC 2026 --
the number of "maturity levels".

   But, as we should have learned by now, it's human nature to grasp
onto the first "solution" you find, and grasp all the harder when
your choice is questioned.

   So be it -- I won't object to that...

   But I _do_ commend Ted's outline of the base issue; and I sincerely
hope that whatever becomes of Russ's proposal, we save some attention
for the things Ted has outlined -- because those things are the ones
we need to actually fix.

--
John Leslie <[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Oct 2010 18:05:07 -0700

Hi -

> From: "Ted Hardie" <[email-masked]>
> To: "IETF" <[email-masked]>
> Sent: Friday, October 29, 2010 4:15 PM
> Subject: No single problem... (was Re: what is the problem bis)
...
> the root of all this.  One way to draw this is:
...

I wonder whether our collective non-enforcement of the last
paragraph of RFC 2026 section 6.2 has also contributed to this mess.

   When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status.  This
   decision shall be communicated to the IETF by electronic mail to the
   IETF Announce mailing list to allow the Internet community an
   opportunity to comment. This provision is not intended to threaten a
   legitimate and active Working Group effort, but rather to provide an
   administrative mechanism for terminating a moribund effort.

Our current way of doing business has only a few wilted carrots
and no sticks to goad advancement efforts.

Randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Oct 2010 21:24:25 -0400

Well I for one would prefer to call the IESG's bluff than spend five minutes
proposing taking HTTP to STANDARD.

We are clearly not following the process and have not been doing for ten
years. I don't think there is anyone who is even claiming the the process is
viable.

So why is there so much resistance to changing a process that we are not
following?

Fear of unspecified bad happenings is not a justification. There are plenty
of standards organizations that can manage to do this. If the doomsday
people are so worried about the possibility of something bad then we should
adopt a process from W3C or ITU or OASIS that is proven to work.

So in my view there are two options

1) Adopt Russ's proposal to change the process documentation to reflect
reality

2) Admit that we don't understand process and choose a process from some
other group.

My preference would be for the first option. But if people are really
serious in their belief that there could be something really bad from
tinkering with this that would argue for #2.

On Fri, Oct 29, 2010 at 9:05 PM, Randy Presuhn <[email-masked]
> wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Oct 2010 20:07:28 -0800

> So why is there so much resistance to changing a process that we are not

I think there's a sentimental attachment to it.  That said,
I suppose if I were in your position I'd be asking myself
why I'm still whacking away at the same stuff, still being
combative, still failing to build anything remotely
resembling consensus, and yet I'm not changing my own behavior that
not only doesn't seem to be working at all but has been suggested
to constitute a DOS attack on at least one working group.

If you can figure that one out maybe you'll have a better
handle on why other people aren't modifying their approaches
to problems, either.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 01:00:58 -0400

Consensus can be achieved in two ways

The first is that everyone understands the issues in the same way and are
agreed on a common approach.

The second is that people would prefer not to face unfortunate facts and so
they agree to ignore them and get the squeaky wheels to shut up.

Now we could continue to discuss how the sky might fall in if we admit that
the IETF process emperor has no clothes, but that seems a somewhat
unproductive use of everyone's time.

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Oct 2010 04:17:55 -0400

Ted, 

I agree with almost everything you say, but want to focus on one
issue (inline below).

--On Friday, October 29, 2010 16:15 -0700 Ted Hardie
<[email-masked]> wrote:

>...
> As we stare down this rathole one more time, let's at least be
> certain that there is more than one rat down there, and be
> realistic about the energy we have on how many we can tackle.
> Russ's draft tries to do two things:
> 
> Restore the 2026 rules for Proposed as the functionally in-use
> bar for the first rung.
>...

> one or didn't believe it.    I think this addresses a
> marketing problem (long an issue, though now commonly
> explained away) and it focuses on the first two "resulting
> issues" in the quasi-chart above, and thus may have some
> cascade effects on the other two.  It doesn't tackle any of
> the contributing issues, but this is not really a defect in my
> eyes, as those can't really be addressed by document issues.
> 
> Are there other ways to tackle this?  Sure.  But if the
> community accepts that this restores the 2026 bar for the
> first rung *and holds the IESG to it*, then I think this is
> one useful place to tug on the tangle of issues.

Noticed.  I probably fall into the "don't believe" category, but
for a reason I've tried to identify before.

I recognize (and have commented on) the issue of how the IESG
gets sufficient community support for changing Proposed Standard
criteria back to what 2026 says and how a transition would
occur.  Some relabeling might be useful in that regard but
perhaps not useful enough to be worth the trouble.  The current
document does not propose to change the name of "Proposed
Standard", so that is a non-issue at present.

However, a change to the handling of documents that are
candidates for Proposed Standard is ultimately in the hands of
the IESG.  In principle, they could announce tomorrow that any
document submitted for processing after IETF 79 would be
evaluated against the criteria in 2026 and no others other than
reasonable document clarity.  If the IESG has the will --and
whatever community backing is needed-- to do that, then the
"two-step" document is not needed.  If the IESG does not have
that will and backing, then community of the "two-step" document
would merely leave us --as far as this issue/problem is
concerned-- with one more set of rules we aren't following.

So, if we are serious about changing (or reverting) those
criteria, then let the IESG issue a statement about the new
rules, schedule, and any transition plan.  Let's see if such a
statement is successfully appealed by someone (I'd hope, given
the concerns on this list about the problem, that wouldn't
happen).  And then let's see if we can actually do it.

There is lots of time to change the written procedures if such
an effort works, even experimentally.  After all, we've been out
of synch with 2026 for 14 years now and it hasn't shut us down.

best,
   john

p.s. I also believe that, if part of the intent of the
"two-step" document is to restore that bar, it is _very_ hard to
deduce that from the document itself.  I'd feel better about the
document if that were more clear.  But the document is really
not the issue, the strategy is.  At least IMO.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 30 Oct 2010 10:45:05 -0400

I don't think it's "resistance to changing a process that we are not following" - I think it's which part of the process we think isn't working, or which part is IMPORTANT that isn't working.

Going from three steps of which only one step is used, to two steps of which only one step will be used, isn't helpful.

It's like the old metaphor of rearranging the deck chairs on the Titanic.  It's not the critical problem.  And it wastes time/energy from either fixing the leak or getting in lifeboats.

-hadriel

On Oct 29, 2010, at 9:24 PM, Phillip Hallam-Baker wrote:

> Well I for one would prefer to call the IESG's bluff than spend five minutes proposing taking HTTP to STANDARD.
> 
> We are clearly not following the process and have not been doing for ten years. I don't think there is anyone who is even claiming the the process is viable.
> 
> So why is there so much resistance to changing a process that we are not following?
> 
> 
> Fear of unspecified bad happenings is not a justification. There are plenty of standards organizations that can manage to do this. If the doomsday people are so worried about the possibility of something bad then we should adopt a process from W3C or ITU or OASIS that is proven to work.
> 
> 1) Adopt Russ's proposal to change the process documentation to reflect reality
> 
> 2) Admit that we don't understand process and choose a process from some other group.
> 
> 
> My preference would be for the first option. But if people are really serious in their belief that there could be something really bad from tinkering with this that would argue for #2.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 30 Oct 2010 11:16:28 -0400

Hi Ted,
...

What makes you say that?
I read the draft and I don't see it doing that, really.  I know it says:
"The requirements for Proposed Standard are unchanged; they remain exactly as specified in 
RFC 2026 [1]." 
and that in theory 2026's bar for PS was not as high as it appears to be today.

So is your expectation that if Russ's draft gets published, the bar for PS will suddenly drop?

If so, why do we need Russ's draft to begin with?  We already have rfc2026.  Why would a new RFC which says "follow this other RFC" be needed??

Later you say:
> if the community
> to it*

How do we do that?  Why aren't we doing it now, since rfc2026 already exists?  In what way does Russ's draft make it any easier (or possible) to hold them to it?

-hadriel