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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 17:00:14 -0800

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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Mar 2006 19:29:20 -0600

On Wed, Mar 22, 2006 05:00:14PM -0800, Hallam-Baker, Phillip allegedly
wrote:
> 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.
> 
> 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.

It seems to me that if we can't motivate people to review/evaluate/fix
a proposed|draft standard once, how can we motivate them to commit to
doing so periodically?  Are you saying that if we allow them to slap a
standard together and declare it done more easily, that they will be
more willing to come back and fix it later?