|
Re: netwrk stuff
2006-07-12 19:00:57
On 12-jul-2006, at 19:36, Fred Baker wrote:
RFCs are published as Informational, Proposed Standard or
Experimental. This represents the confidence level the IETF/IESG
has at the moment of publication. Irrespective of I/PS/E, a
document may move to Standard (which replaces Draft Standard and
Internet Standard) or Historic if its implementation and
deployment warrant this. The IESG publishes a short note
explaining the rationale when changing designations.
Seems mostly reasonable.
I do believe that there is value in the BCP status, and would add
it to the above.
Yes, that makes sense.
I would also argue in favor of the "Historic" status. Documents are
rarely published as historic, although it has happened (RFC 1716).
But they should be allowed to become historic at some future date.
Sure, I wasn't saying anything to the contrary, except that I didn't
include publishing as historic, which I hope should be rare.
On 12-jul-2006, at 19:40, Pekka Savola wrote:
I'm not sure if Brian was serious about writing, as there are
numerous proposals already [1], every one of them simplifying the
current situation.
Yes, but spending tons of time in netwrk is exactly part of the
problem. I took his talking about it in the plenary to indicate that
a different way forward is desireable. That's why I posted just a few
lines rather than read drafts and then write one of my own.
[1] hit 'newtrk' in I-D tracker [2]. My personal favourite is draft-
atkinson-newtrk-twostep-00.txt, which seems to strike a good
balance between stripping out useless process but keeping at least
some features (revision based on implementation experience, etc.)
which at least I have found useful.
Yes, there is a lot of good stuff in there, including the two-step
standards track. Can someone explain the complexity in the tradeoffs
between having one, two or three steps that was alluded to in the
meeting?
However, the problem I have with that draft is that it still tries to
formalize the progression of documents. We heard "declare success" a
lot and "declare failure" once or twice tonight, and I'd like to take
this opportunity to do both:
1. The internet works: success
2. Few specifications mature to Internet Standard: failure
Since the current rules prevented a lot of progressing of
specifications but at the same time there doesn't seem to be a
negative effect on the operation of the internet, it looks like these
rules don't accomplish anything. So get rid of them. All of them. The
IESG is full of smart people who are more than competent enough to
decide on the fate of a document without a long list of rules to
follow in doing this. When they get it wrong once in a blue moon, the
last call and appeal processes should take care of that.
And while we're at it, let's cut down on all the documents that
accompany the actual specifications. I'm not saying they're all
worthless, but many applicability documents seem to exist because of
formalities rather than because they contain crucial information that
couldn't be put anywhere else. As a "user" of RFCs in the years
before I got involved in the IETF I generally ignored these
documents. The protocol specifications is where it's at. So extra
documents when they add something, but don't require them.
Also, it's not by accident that people remember RFC numbers and not
STD numbers. There is a big difference between implementing RFC 822
and implementing RFC 2822. Saying you have implemented STD 11 is
useless because a year from now STD 11 may be something different
than it is today, while RFCs 822 and 2822 will still be the same.
That's why I think it's useful to have some IESG notes accompany each
RFC. This can be a simple "updates XXX, obsoletes YYY, obsoleted by
ZZZ" or more text that describes certain issues where required. This
removes one or two layers of indirection in determining a document's
status.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|