--On Thursday, October 28, 2010 14:15 -0400 RJ Atkinson
<rja.lists@xxxxxxxxx> wrote:
>
> On 28 Oct 2010, at 13:29 , Dave CROCKER wrote:
>> On 10/28/2010 9:22 AM, RJ Atkinson wrote:
>>> Most times it would be better if IETF WGs initially create
>>> an Experimental status RFC, possibly doing so quite rapidly,
>>> and then later revise that (based on at experience) and
>>> publish the revision on the IETF standards-track.
>>
>>
>> 1. Getting /any/ RFC through the IETF process is very high
>> overhead, including Experimental.
>
> I believe that publishing an Experimental RFC is
> visibly easier than publishing a standards-track RFC.
While, based on the recent EAI experience, I think there is
sometimes (not necessarily often) considerable advantage in
going to Experimental first, I don't believe that there is any
significant difference in the time or pain level associated with
getting WG Experimental documents through the IESG as compared
to Proposed Standard documents. There may be some, e.g., it is
easier with an Experimental document to respond to "DISCUSS: I
don't think this can be implemented, nor that it will work as
intended" with "that is what we are trying to find out and
document", but I've only rarely seen that come up in a DISCUSS
on either type of document.
As Dave has tried to say in a variety of ways, these things just
depend on the views of the responsible AD and the composition of
the IESG -- generalizations are generally not possible other
than that the mechanisms that produce "slow and/or painful" take
a lot less IESG consensus than moving things along quickly.
The situation might be quite different for non-IETF streams and
possibly non-WG document streams.
>...
>> Shouldn't a standards process be able to sit down and do a
>> standard, rather than iterate on experimental designs?
>
>
> The above seems to reflect a mis-reading of what I wrote.
>
> I merely suggested that often an IETF WG would find it
> more productive to go to Experimental RFC first,
> then later to the standards-track. There are a number
> of worked examples of this historically, going back
> some number of years. I provided a handful of recent
> or current examples.
>
> This suggestion is not in any way novel or strange.
> Indeed, I'm merely echoing the suggestions of other
> folks -- this is not an idea that I originated.
I think this takes us immediately back to those fundamental
questions of what problem we are trying to solve and why do we
think it would make a difference. I still remember my very
first task when I became Apps AD: I got to explain to a vendor
that, by implementing and deploying something based on (IIR) a
Proposed Standard, they had only themselves to blame for their
deployed system being incompatible when the WG decided a
particular feature was a bad idea and changed it. I don't
think it would be possible for an AD to do that today: along
with making it harder to get Proposed Standard, we have started
to treat them as if they are cast in concrete (one can argue
cause and effect either way).
Personally, I continue to believe that the Internet would be
better served by having a lot less difference between Proposed
and Experimental, by changing things (back?) so that getting one
or the other approved and published was really quick, and making
our main standardization/ get the document exactly right /
consensus level the second one. In that context, I think it
would make less difference whether we had two levels or three
(but I'm the guy who proposed replacing category-levels that are
never quite right with narrative text what could be used to
explain what we really thought about a spec and its maturity).
But, if we are going to persist in treating Proposed as "already
refined specification to be implemented and deployed" and in
requiring a very high standard of documentation, specification,
and agreement for Experimental, then it seems to me that the
odds are good that trying to insert Experimental "below"
Proposed would, in lots of cases, just push Proposed up (four
levels?) and make things even slower.
And that would, IMO, increase the justification for documents
bearing a WG-only stamp of approval such as the "snapshot" I-D
plan. I'm not a fan of that plan because I think we should fix
Proposed, including reduce the time and trouble it takes to get
a spec published as Proposed, but, if we really can't do that,
then formal pre-approval by a WG seems like the right way to go.
Strawman (consciously derived from the current procedures of
another SDO who, oddly, modeled those procedures on what they
thought we are doing a decade or two ago):
Suppose we eliminate "Proposed Standard", replacing it with
"IETF Area Specification" or "Preliminary Specification" (there
are probably better names) with the following properties:
-- No known technical defects (the present criterion for
Proposed)
-- Review and approval only within the (single) area of
origin, i.e., WG review and AD review and approval (with
whatever addition input the AD wanted to ask for, as
now), but no IESG approval process at all.
-- Published as RFCs, but clearly labeled as
"preliminary", "possibly incomplete" and "not a
standard". I wouldn't expect that to do much good,
especially if someone were inclined to distort the
situation for marketing reasons, but we can and should
try.
-- Instructions to the RFC Editor to favor speed of
publication and basic comprehensibility over getting the
text just right.
Presumably this gets things through the IESG faster, if only
because the number of people who can launch a formal DISCUSS is
reduced to two from 15. It would also reduce IESG workload on
documents that really are preliminary somewhat which, IMO, would
be A Good Thing.
While my instinct is that RFC publication would be desirable, if
that didn't seem workable we could move the idea a bit closer to
the "Snapshot" idea by posting the document in the I-D series
and giving it a gold star.
Then we have a second level that constitutes a real IETF Spec:
satisfaction of various "nits", full community review, including
cross-area review and evidence of community consensus. I don't
know if we would need one of those levels or two, but an
experiment might be useful. The advantage of keeping two (or
more) is that a WG could advance something directly to the first
IETF level if they thought the spec was stable and complete
enough, or proceed on the basis of getting an "Area Preliminary
Specification" out as soon as there was agreement on the
technical spec but then move directly (no waiting period) on to
the level of document refinement now needed for Proposed.
If the WG didn't care about IETF approval, then they don't care.
Nothing stops such a WG from giving up after posting I-Ds today;
with the "Snapshot" idea, they would have equally little (or
much) incentive to move to full IETF review.
If this gets any traction, I'd be happy to write it up or help
someone else do so. Otherwise, just consider it another
demonstration that it is possible to address the problem of "two
high a barrier to Proposed, few things move to Draft" to which
draft-housley-two-maturity-levels appears to be addressed in a
way that is meaningful, i.e., looking at what happens at the
entry level rather than hoping that the problems with levels 1
and 2 will be magically solved by eliminating level 3.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf