ietf
[Top] [All Lists]

RE: Clarification of my comment on giving up on process issues

2006-03-22 18:01:00
I have a growing feeling that part of the problem here is that many Working
Groups are in effect maintenance activities.

The three tier PROPOSED-DRAFT-STANDARD scheme has many accepted flaws, not
least the fact that grandfathered specs aside practically nothing ever makes
the final step from DRAFT to STANDARD. I think that a bigger problem may
well be the fact that RFC 822 is officially THE standard while for all
meaningful purposes the real standard is RFC 2822.


I think that one of the flaws in the scheme is that the original proposal
was designed for specs like IPv4/TCP etc which are effectively fixed for all
time on deployment. Most specs are not like that, continuous maintenance is
required. If the spec does not require any maintenance it probably indicates
that it should probably be shuffled off to HISTORIC.

I would like to see a two tier scheme for standards (i.e. eliminate the
illogical and misleading status 'DRAFT') but on the understanding that
standards require periodic review. By periodic I mean that there should be
fixed windows that are scheduled in advance when the standard will be
reviewed. There would be a fixed interval in which defect reports could be
submitted. One of the topics of the general session for each area would be a
report on the defect reports and discussion of whether a new revision WG was
required.

It might be easier to close WGs down if this was not quite so final.
Allowing a 'fast track' for defect reports would encourage proposers to come
to the IETF with complete proposals with a substantial degree of consensus
in the user and developer communities. If the defect report is justified the
need should be widely felt, if as is likely the report is describing
existing field practice addressing that need there should not be a need for
substantial discussion.


In some cases it would be appropriate to reactivate the working group
concerned, in others a mini-WG might address multiple protocols. The need is
most common in the security area where crypto practices need to be revised
every 5 years or so. An area wide activity describing use of SHA-256 would
be an example.



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf