Subject: Re: draft-housley-two-maturity-levels

From: [email-masked] (Scott O. Bradner)
Date: Tue, 26 Oct 2010 07:59:54 -0400 (EDT)

> The known problem is it takes well over four years to get anything
> published.

...

> What I *am* hoping is that with two, clearly defined maturity levels, we
> can go back to publishing Proposed Standards in about a year

the only way that could happen is if the IESG were to change their ways a lot
and permit less complete documents to be published as PS

Scott

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 09:12:44 -0400

>>>>> "Scott" == Scott O Bradner <[email-masked]> writes:

    Scott> ...

    >> can go back to publishing Proposed Standards in about a year

    Scott> the only way that could happen is if the IESG were to change their ways a lot
    Scott> and permit less complete documents to be published as PS

so, from this point of view, two-maturity is a step backwards, because
it makes the new PS seem even more 'mature', and therefore higher
barrier to entry.   I don't have an answer for this.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Oct 2010 13:54:10 -0700

> and permit less complete documents to be published as PS

Did you miss James Polk's comment yesterday? The IESG is already changing
their ways!! They now require 2 independent implementations for a personal
I-D to become a WG draft. 

I don't think that is the direction of change you were looking for though.
;)

FWIW: I support the goal of removing the useless state of DS, but I see
Russ's draft as more of a starting point for discussion than a reasonable
destination. As many others have said, the most pressing problem is getting
past the IESG in the first place, and given there is evidence they are going
to be attacking I-Ds, it is clear that this document does nothing to help
with the core problem. The best it does is to reduce some of the external
confusion, but it doesn't even really do that well since most outside
parties equate "RFC" with "Full Standard". 

What we really need to do is make the process simple:

Personal I-D gathers interest
WG chair gauges interest - establishes WG doc (AD is explicitly overruled if
necessary)
WG I-D presented to Area - Area AD enables publication as PS RFC
Full IESG reviews requests to move from PS to IS, and doesn't get in the way
before that.

This does not preclude cross-area review and comments at any point along the
way, and in fact an AD would be wise to seek out comment from other areas.
What it does is restore the state when the IETF was productive and relevant.
It is effectively a 4 stage doc process rather than the 5 stage one today.
Getting the major hurdle of IESG review out of the way of the step to
generate initial archival documents is the big win here, both in terms of
workload on the IESG and the ability of the IETF to be public about its
evolutionary steps. 

Tony

---

From: John Leslie <[email-masked]>
Date: Tue, 26 Oct 2010 19:10:42 -0400

> I-D to become a WG draft. 

   Though I'd rather steer clear of this fray, I must question this.

   I'm quite certain the IESG doesn't have such a blanket policy.

   The reported incident _may_ be accurate, but such a requirement
would have come from the WG Chair, not the responsible AD, least of
all some other AD. I'd be very surprised if this incident turns out
to be anything more than a WGC (who may _also_ be an AD) requiring
implementation reports for a single I-D proposed for adoption.

   I'd also be surprised if there doesn't turn out to be some
mis-communication of what was requested and why.

   We do, alas, sometimes misunderstand a policy statement and start
voluntarily following it in cases where the actual policy wouldn't
apply. That is IMHO a measurable part of why the path to PS takes so
long. :^(

--
John Leslie <[email-masked]>

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Oct 2010 17:14:17 -0700

I will let James speak to most of your points, but I did talk to him as he
exited that session, and he was very clear at that point this was the AD for
that WG not the chair, and there was no misunderstanding. 

While I trust this is not an official policy, I look at that event as a
leading indicator for the general IESG 'we are here to protect the Internet'
attitude. We all know that most people stop at PS, because it is not worth
the effort to do anything more, particularly after the effort to get the
first step. That feeds the perception (if not the reality) of the need for
the first PS doc to be perfect. The IESG doesn't do itself any favors by
perpetuating the perception that the first step has to be perfect, and while
I know there have been personal efforts to minimize the blockage the IESG
presents, outside indicators show those have been insufficient. The core
issue is that IESG appears to believe its role is to protect the world,
rather than manage the process of document creation and drive toward some
degree of architectural consistency. Note: driving toward a goal does not
mean preventing progress until the goal has been achieved. 

As I suggested in the earlier note, the IESG as a group should really step
back and only get involved in the step for full Internet Standard, where it
actually means that the IETF as a whole has considered this document as
representing a consensus standard, rather than agreeing at PS 'this is a
document we all intend to work on'. Doing that means the sponsoring AD has
to take on more of the role of verifying the WG is progressing toward the
architectural goal, and seeking out cross-Area review, but that approach
will allow incremental progress where the current approach does not. 

Yes, the cost for the RFC Editor goes up when we relax the bottleneck the
IESG currently represents, but that is the price of progress. Also, the
external confusion about RFC vs. STD goes up as there are more PS docs, but
the counter to that is that if we can focus the IESG on getting documents
from PS to IS there will be a broader array of more relevant documents at IS
to reference. 

Tony

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 4:11 PM
> To: Tony Hain
> Cc: [email-masked]
> Subject: Re: draft-housley-two-maturity-levels
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Oct 2010 20:39:29 -0400

If it is still possible to get code points issued on an Informational or
Experimental RFC and the bar for those documents is not raised, I don't see
the problem.

Original  ->  Current ->  2 step

Proposed -> Informational / Experimental ->Informational / Experimental
Draft -> Proposed -> Proposed
Standard -> Draft -> Standard

Almost none of the STD documents would qualify for DRAFT status these days
and some would not make Proposed without radical changes.

All we are talking about here really is acknowledging that what the IETF
labels 'DRAFT' standard are in practice full standards.

As for what the IESG should do. Looking at the comments made on KEYPROV,
there were some editing changes that really didn't take a great deal of time
to process and there were some substantive issues that could not have been
changed after the PROPOSED RFC issued.

If someone is suggesting use of a particular identifier space or consistency
with another specification, those are changes I want to see made as soon as
possible. I do not want to have a process where we can get to PROPOSED
really quickly but then have to make major changes to advance to DRAFT
because the IESG is giving the type of feedback that would have been useful
in the previous iteration.

What I would suggest as a means of speeding up the process is for the IAB to
get back into the business of doing architecture and write up a style book
for some of the engineering choices. A lot of the discussions we had in
KEYPROV recapitulated earlier discussions I have had in every XML based
protocol I have worked on. In several cases there are four approaches, all
of which have some drawback that I may or may not remember. Most really
don't have a good answer and it would be as well just to pick one and move
on rather than have the same conversation yet again.

On Tue, Oct 26, 2010 at 8:14 PM, Tony Hain <[email-masked]> wrote:

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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 20:41:56 -0400

Tony, if I understood what you wrote, you are saying that the change we
need is really for the IESG to step back from reviewing documents before
they go to PS.  

This task would be delegated to the ADs (and directorates).  
This could even mean eliminating IETF LCs on documents going to PS?

The IESG as a committee would focus on movement from PS to DS/IS.

As PHB has pointed out, we *do* have a three-stage process today, but
the names aren't what 2026 says:
    stage 1) ID-WG-xx, where XX > 10 or so.
    stage 2) PS
    stage 3) DS

Since stage 1 IDs get implemented, and often deployed, one finds that
one often can't even amend them easily if they have been 'stable' for
more than 6-8 months. 

I think we have been trying for sometime to change things so that 
my stage 1/2/3 corresponds to PS/DS/IS, but we haven't found a way to
have the IESG let go.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Oct 2010 10:20:36 +0300

> I-D to become a WG draft. 

James characterization is inaccurate. See my other email.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Oct 2010 10:22:07 +0300

>   I'm quite certain the IESG doesn't have such a blanket policy.

Correct (of course).

> implementation reports for a single I-D proposed for adoption.

In this case, James was the author *and* is the WG chair. This is why I got involved as AD.

Lars

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Oct 2010 09:24:31 -0700

Lars,

As I understand it, the characterization was correct. The level of the bar
you appear to be setting is appropriate for progressing an ID out of the WG,
but completely insane for evaluating a personal submission for becoming a WG
item. In the abstract, requiring multiple interoperable implementations of
personal drafts essentially codifies that the IETF process is irrelevant...

At the end of the day the market only cares about interoperable
implementations. The only thing they look to the IETF for is a reference for
getting the vendors to play together in the sandbox. If the IETF process
starts requiring the vendors to play nice in the sandbox BEFORE being
blessed by the wisdom of those who are here to protect us, what is the
point? Once the vendors play together the market could care less if the
protectors of the world have rubber stamped their creation.

Tony

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2010 12:21 AM
> To: Tony Hain
> Cc: 'Scott O. Bradner'; [email-masked]

---

From: John Leslie <[email-masked]>
Date: Wed, 27 Oct 2010 14:19:34 -0400

Tony Hain <[email-masked]> wrote:
> 
> Lars,
> 
> As I understand it, the characterization was correct.

   Try though I may, I can't stretch it to "correct".

   In fairness to James, though, it was _not_ false, just misleading.
(After all, it led me to a thoroughly inaccurate assumption: that the
ruling and the suggestion were about the same issue.)

   Assuming the minutes are correct (by definition, an appropriate
assumption), the _ruling_ was that the I-D _could_not_ be adopted
because it was out of scope in the Charter.

   The suggestion had to do with what would make Lars comfortable in
proposing a change in the Charter (which could not be accomplished that
day in any case). _One_thing_ he suggested was documenting multiple
implementation if they existed.

   James, of course, is perfectly entitled to raise the question of
whether an AD should even _consider_ whether a spec is sufficiently
detailed to enable two interoperable implementations without being
supplemented by out-of-band communications with the author(s).

> The level of the bar you appear to be setting is appropriate for
> progressing an ID out of the WG,

   Actually, I don't agree the "multiple implementations" bar for
Proposed Standard is _ever_ appropriate...

> but completely insane for evaluating a personal submission for
> becoming a WG item.

   (Thus, I'd consider it also inappropriate for that evaluation.)

   But recall, the _ruling_ was that it was out of scope -- not whether
the I-D was adequate for adoption by _a_ Transport WG as a WG draft.

   (I find it a bit distressing that some WGs don't think their Charter
places any limits on what they may adopt as a work item. I'm pretty
sure this is explained in WGC training sessions. Does it need to be
repeated at a WGC meeting every IETF?)

> In the abstract, requiring multiple interoperable implementations
> of personal drafts essentially codifies that the IETF process is
> irrelevant...

   It would be _entirely_ appropriate if the Individual Submission
was seeking Draft Standard status.

   May I suggest that our problem may be the RFC2026 "time-in-grade"
requirements? Perhaps the IESG should be trusted to publish an RFC
as Draft Standard _without_ going through the whole process twice?

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Oct 2010 13:27:09 -0700

> supplemented by out-of-band communications with the author(s).

Interoperable implementations have absolutely nothing to do with charter
scope. 

> Proposed Standard is _ever_ appropriate...

I was reacting to the excerpted minutes in the response Lars sent to James. 
	Right now, it is hard for
          me to judge if an RSVP implementer can interoperate using this
          specification. If there were two independent implementations,
          this would clearly demonstrate the implementability of a Spec.

If the AD questions the clarity of WG output, multiple interoperable
implementations from the spec would be a reasonable measure of clarity. I
don't want multiple implementations to become a bar for every PS to
overcome, but the bigger point is that it can't even be a hint at a bar for
getting INTO a WG. If the doc is so complete that multiple interoperable
implementations are done, what work is there for the WG to do? Given that an
array of products will have shipped and been end-of-life'd before a WG & the
IESG could even think about allowing a PS to be published, what relevance
does the IETF have if the implementations are done before allowing a WG to
start?

> the I-D was adequate for adoption by _a_ Transport WG as a WG draft.

I was not in the room, but this is inconsistent with the minutes excerpt
that is focused on document clarity. 

> repeated at a WGC meeting every IETF?)

In vs. out of charter is something the Chair should be able to resolve, and
-might- call for AD consultation if there is ambiguity. In any case,
implementation clarity of the document is not grounds for consideration, yet
the minutes show clearly that was the discussion at hand. 

> was seeking Draft Standard status.

At that point one presumes it would be a PS RFC, not an individual I-D, or
did I miss a process step that allows skipping PS?

> as Draft Standard _without_ going through the whole process twice?

Again, I have no problem dropping DS from the sequence. Time-in-grade has a
grand intent, but is totally OBE given the length of time it takes for the
IESG to get PS out the door. The products are on their deathbed by the time
documents are blessed, so we might as well move straight from personal I-D
to Historic.

Tony

---

From: Ralph Droms <[email-masked]>
Date: Wed, 27 Oct 2010 21:42:56 -0400

Time for another contrarion position...

Tony, why do you say the most pressing problem is getting past the IESG, and what evidence do you have that we are "going to be attacking I-Ds".

- Ralph

On Oct 26, 2010, at 4:54 PM 10/26/10, Tony Hain wrote:

> [...]As many others have said, the most pressing problem is getting
> with the core problem.