Dave -
----- Original Message -----
From: "Dave Crocker" <dhc2@xxxxxxxxxxxx>
To: "Paul Hoffman" <paul.hoffman@xxxxxxxx>
Cc: "IETF Discussion" <ietf@xxxxxxxx>
Sent: Friday, July 21, 2006 3:06 PM
Subject: Re: netwrk stuff
>
>
> Paul Hoffman wrote:
> > At 12:06 AM -0700 7/21/06, Dave Crocker wrote:
> >> By way of providing some incentive, I suggest that Proposed have a
limit,
> >> such as 3 or 5 years (and, yes, we can quibble about that, too.) If the
> >> work cannot gain sufficient adoption by the end of that time, it has
failed
> >> and warrants moving to Historic.
The question as to why that initiative's process was stalled would have to
be answered to be fair. One would have to take into consideration whether
the underlying technologies were the issue, those undertaking the effort
abandoned it, or whether it was the WG and AD who had failed to properly
marshal their WG Vetters to complete this effort.
Since the IETF has said it needs to be smart about what projects and
initiatives it undertakes, then it should want as much assurance up-front as
possible. That said when a formal project is proposed it should be well
enough defined and documented, and have commitment formally from those who
are the core of the Initiative's Vetting Team.
.
There is also a disconnect I think (IMHO) in thinking that it takes an
entire WG to approve some protocol - "the ONLY people who should have to
approve the protocol are those involved inside of the development of the
protocol project". Allowing others to cast votes which effect whether that
initiative is advanced creates a condition where one group can tortuously
interfere with another's IETF Standard's initiative, and having personally
been a victim of this I assure you it happens.
The issue here is just in making it such that anyone who is willing to step
to the plate and commit hours to the vetting process should be allowed to.
Also the folks to implement the protocol-interoperability ports should be
committed WHEN THE PROJECT IS ORIGINALLY SUBMITTED *(did I say that loud
enough?). A plan for the vetting and fabrication of the reference ports for
interoperability testing should be put in place to assure the IESG that the
proposal is 'properly funded and staffed outside the IETF ' - two key
requirements for successful completion of an IETF initiative these days.
> >
> > Fully disagree. If there is "some implementation but not enough" it
> > should remain "proposed". Otherwise, vendors will hesitate to implement
> > protocols that might eventually make them look silly ("why does the box
> > include the FrobzBaz protocol when everyone knows that it is
Historic?").
>
Paul's probably right - but so is Dave. The real issue I think is how the
IETF wants to be perceived and which classes of End-User customers it wants
to focus on. Which is to say - that it would make more sense to unify the
Standards Vetting Process and to define it such that one could select
different types of vetting models inside the IETF's Processes. Also
cafeteria
style. This would address BCP's and RFC's for Standards alike.
> That sounds like an extremely reasonable concern, except for all the
empirical
> evidence to the contrary.
>
> Vendors do not look silly by being aggressive in providing new features.
True -
>
> And they take risks about the future, formal approval and market-wide
acceptance
> of a technology all the time.
Especially if those differentiate them as being more and better that their
competition.
>
>
> > This leads to two designations: Proposed and Full. An implementer
> > looking at a Proposed standard would assess how long it has been out and
> > which other implementers have put it in competing products to assess
> > whether they want to put it in theirs. Things labeled Full standard
> > would probably be put in by default.
>
> So, we are in agreement about having 2 levels and having the second one be
based
> on market acceptance? Our disagreement is about deprecating Proposed
specs that
> have not reached Full after a period of time.
I think the way to address whether deprecation is some level of use in the
world. Set a use minimum for any protocol - and anyone that falls below that
use level - is deprecated. This way the IETF active standards track the
Internet's tastes and desires since it is the Internet that the IETF is to
track... But rather than true deprecation - lets just change their names to
"Reference and Active" Standards. Reference are any non-active Standards.
Active Standards are those that are voted (did I really say that?) by the
IESG to track the Industry's use.
This review should be done annually at one of the meetings as a process
model and the level of penetration of any protocol needs to be factored into
the equation somehow.
>
> Note that we already have this policy, although it applied erratically by
In closing lets put blame for a failed project where it belongs... in the
WG Chair's
lap. I think there is a fundamental failing in the mindset of the IETF and
that is that "the failings of the WG Vetters to come to consensus documents
the failure of the WG Chairs for not better controlling their resources or
projects".
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf