At 13:39 29-10-10, Andrew Sullivan wrote:
Supppse we actually have the following problems:
1. People think that it's too hard to get to PS. (Never mind the
competing anecdotes. Let's just suppose this is true.)
2. People think that PS actually ought to mean "Proposed" and not
"Permanent". (i.e. people want a sort of immature-ish level for
standards so that it's possible to build and deploy something
interoperable without first proving that it will never need to
change.)
Some people view that level as an immature-ish level; some people may
view it as a mature as they have overcome the barriers to publication.
4. Most of the world thinks "RFC" == "Internet Standard".
Yes.
If all of those things are right and we're actually trying to solve
them all, then it seems to me that the answer is indeed to move to _n_
maturity levels of RFC, where _n_ < 3 (I propose 1), but that we
introduce some new document series (call them TRFC, for "Tentative
Request For Comment", or whatever) that is the first step. Then we
get past the thing that people are optimizing for ("everything stays
as Proposed Standard once it gets published") by simply eliminating
that issue permanently.
That's somewhat similar to the Working Group Snapshot proposal. Such
proposals are mainly about addressing point 4.
I don't think that this community would support having "Proposed
Standard" renamed to "Alleged Standard" or that such a change is in
accordance with the IETF's sense of humor.
Ah, you say, but now things will stick at TRFC. Maybe. But we could
on purpose make it easier to get TRFC than it is now to get PS (say,
by adopting John's limited DISCUSS community for TRFC, or one of the
other things discussed in this thread). Also, the argument about
everyone thinking that RFCs are "standard", and the resulting pressure
to make them perfect and permanent, would be explicitly relieved (at
least for a while), because nobody thinks that TRFCs are standards.
The RFC brand worked too well. The people who have to decide on the
issue are the same people who have authored documents which are
currently at Proposed Standard level. At a different level, this is
like asking the IETF to give up the RFC brand.
Note that this is not to denigrate SM's suggestion, which also doesn't
I view your comments as constructive criticism.
seem wrong to me. But since one of the issues appears to be that
anything called "RFC" is set in stone, then if we just stop calling
the early-publication documents "RFC" that and introduce something
after I-D (which is formally only on the _way_ to some consensus, and
not actually the product of it), the blockage might be removed.
People commented that there were not one issue but multiple
issues. RFCs published in the IETF Stream differ from RFCs from
other streams in one aspect; they go through the IETF Standards
Process. I am over-simplying here. The label is also about archival
of the consensus decision [1].
At 14:03 29-10-10, Martin Rex wrote:
Essentially, you seem to be asserting that IETF community feedback
should be considered harmful and delayed to much later in the process
where it can have even less impact.
I did not describe community feedback as "harmful". I prefer not to
provide an example here to avoid conflating this with matters that
are subject to appeal.
To me, that sound a little like giving up.
Maybe. I doubt that the ideal solution would gain
consensus. Anyway, what's ideal is subjective.
Changing solutions, fixing protocols and fixing documents is exhausting
and painful, so let's just skip all of that. Let vendors and implementors
I agree that it can be exhausting and painful. But then there is a
price to pay for getting free reviews. Authors who would like to
have their protocols and documents fixed should realize that it
cannot happen without effort on both sides.
wiggle out how to create interoperable products from shoddy specs
all by themselves -- which is what some of them have been doing for
some time -- implementing defective specs and shipping interoperability-
impaired products long before the standardization work has converged
on a moderately stable Proposed Standard.
We might call it shoddy specs; other view it as a matter of doing
business. "It works for me" is a bad idea if we are concerned about
interoperability and clarity.
At 01:39 30-10-10, John C Klensin wrote:
If that is true --and it may be-- it would indicate that not
even we can keep track of the difference between "RFC" and
"Standard". If that were to be the case, discussion of maturity
levels is basically a waste of time.
Yes, and the end result could be giving up.
I think there are other issues with your outline, but the key
one is that it would really, really, depend on "do or die"
working. If it didn't, the IETF would rapidly acquire a
reputation for producing garbage as Standards, and that would
be, IMO, really bad.
Yes.
But the odds are against "do or die". We've had that provision
(automatic moves to Historic for Proposed (or Draft) Standards
that are not advanced within a set period) for a very long time.
Agreed.
I also suggest that the odds are against us, if only because the
IESG will always have higher priorities than reviewing the
status of documents no one cares about any more (either because
they didn't get traction or because they got so much traction
that they represent established practice that no one has
motivation to update them). In addition, I'm cynical enough to
believe that IESG members would hesitate to kill off documents
that have a few supporters who might put a lot of effort into
complaining to the Nomcom... at least without strong documented
evidence of community support.
Yes.
Note that we have also made killing things hard: the idea that
it takes putting together and publishing an RFC with details,
justification, and all of the usual sections and boilerplate to
move another RFC to Historic is a post-2026 innovation. I think
It is called bureaucracy.
languish. IMO, if we wanted "do or die", we'd have to change
that culture too.
Yes.
Picking up a comment from a different thread:
At 01:17 30-10-10, John C Klensin wrote:
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.
Please feel free to correct me; the Internet Standards Process has
been out of sync for 18 years. The RFC publication rate jumped from
100 to approximately 300 a year. Most documents are under 75
pages. The process requires more a reading of the documents, e.g.
tracking discussions, cat herding, etc. At another level, there is
the question of what guidance can be given to people that are new to
the IETF. Is this what 2026 is about, i.e. what the process attempts
to achieve?
I am not going to comment on [2]:
"Proposed Standard (PS). The first official stage, but many standards
never progress beyond this level (probably because IETFers don't like
bureaucracy)."
Anyone asserting that IETFers do not understand the process faces the
risk of being flamed by other participants. There is a divergence of
opinions about how the process works at times [3].
There isn't any pressing need for a change to 2026. There is an
opportunity to make a change. There is also the option of doing
nothing and put this to the list of periodic discussions that come up
every now and then.
Regards,
-sm
1. See RFC 5741. Michael StJohns posted some questions (
http://www.ietf.org/mail-archive/web/ietf/current/msg64191.html )
about a document that was approved for publication.
2. http://www.ietf.org/newcomers.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg64445.html
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf