Subject: [newtrk] A slightly different form of radical suggestion

From: avri doria <[email-masked]>
Date: Wed, 3 Aug 2005 19:18:20 +0200

Hi,

In reading through all the ideas for change in the number of steps that 
RFCs take to go through the standardization process i have come to the 
personal conclusion that we should leave the overall process as it is.  
Now, this is rather radical for me, since i seem to be recommending the 
status quo - a position that is not so very normal for me.

But instead of a radical change in the process, I would like to suggest 
that what we need is a radical change in our behavior.  We should 
follow the process we have and should perhaps make some policy 
adjustments to enable the us to follow the process we have.

There have been lots of arguments about why it makes sense to have a 
step that is easy to reach, a step that indicates experience and 
maturity and one that indicates wide deployment and stability.  I find 
that i strongly value the 3 step process, at least in theoretical 
terms.

The current process sort of calls for reviews.  I am not one generally 
in favor of demoting documents, but i do think there is value in 
reviews, and some documents may deserve demotion to historical. Reviews 
might also be good for identifying problems impeding progress or 
identify RFCs that should be  progressed, e.g. some documents may have 
the wrong status because they have reached maturity and should be 
promoted along the track. I don't know if the IESG has the bandwidth 
for this sort of work on an ongoing basis, but I expect that they could 
delegate the responsibility for analysis and for making 
recommendations.

I also think there is a lot of merit in the argument that when WGs are 
closed on having achieved PS, it does not enable progressing the rest 
of the way through the track.

So, if after another round of discussion about 1 step 2 step we cannot 
settle on a consensus change, perhaps then we can look at ways at 
enabling the community to actually make the current process work.

a.

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Aug 2005 05:30:59 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Lars-Erik Jonsson (LU/EAB)

> What you suggest is very much in line with my personal 
> feeling after all these months of discussion. To me, it looks 
> like most people believe the 3 steps process (at least in 
> theory) is what we would like to have. The problem is that we 
> have not managed to use our official 3 step process. However, 
> the desired solution might not be to change the process, but 
> instead change the way we implement it.
> 
> To me, the time to go to PS is the key problem, and also that 
> we treat PS as "completed" specifications. This opinion was 
> also expressed by John K. in his note from  Saturday, titled 
> "Making the standards process more efficient".

The only way to ensure that proposed means 'proposed' is to reduce the
criteria for a proposed standard very significantly. The trend over the
past ten years has been the opposite. I do not think it very likely that
this will reverse even if it were desirable to do so.

The external world treats proposed as a standard and is not likely to
change that opinion. At the very least the IETF would have to set up a
communications branch to compete with the commercial interests that are
going to re-affirm the existing view.

The only practical way to ensure that proposed means proposed is to make
the transition a WG decision rather than an IESG decision, as happens in
OASIS and W3C. The IETF is somewhat unique in having a highly
centralized approval process and requiring every standards proposal to
be reviewed three times by the same board. The only other review
processes I can think of offhand have a different group deciding on each
level.

I think it is pretty obvious that three reviews is too many since the
IESG has effectively stopped making final standards reviews. The
majority of the existing standards got there by being grandfathered. The
small number of specs that have reached standards status through the 3
step process do not appear to have benefited thereby.

At this point there is very little engagement in PKIX from the CA
industry that started the work. I can't think of any principal working
for a major CA who still attends IETF on a regular basis to attend PKIX.
And that group is only working on the transition to draft. I can't
believe that there is going to be any interest from the commercial side
to fund people to attend meetings to work on a transition to 'standard'.
It does not meet any commercial goal. And if it does not meet an
important goal for major businesses that sell PKIX certificates I cannot
imagine what the value in full standards status would be for an academic
or a private consultant. The only body that is likely to care in the
slightest is the US govt.

I don't see the value in a 'return' to a process that was never actually
used at any point in IETF history. The three step process is a major
public relations disaster for the IETF that reinforces the perception
that the IETF is unacceptably slow and never finishes anything.

.

---

From: "Robert Snively" <[email-masked]>
Date: Mon, 8 Aug 2005 07:58:51 -0700

> [mailto:[email-masked]]On Behalf Of Hallam-Baker,
> Phillip
> Sent: Monday, August 08, 2005 5:31 AM
> To: Lars-Erik Jonsson (LU/EAB); avri doria; [email-masked]
> Subject: RE: [newtrk] A slightly different form of radical suggestion
> 
> 

As Phillip points out, Proposed is treated as Standard.  In my 
experience, Standards track RFC is also treated as standard.  And
as Phillip points out below, there is no economic incentive and
little technical incentive to go beyond that. I continue to believe 
that a single-step process, with appropriate approval steps, 
provides the best mechanism to create a standard with both 
implementation authority and the flexibility to evolve through 
new revisions.

.