On Wed, 14 Jan 2004, Fred Baker wrote: > I'd be happier bumping the number any time the file is changed, so that the > tombstone supercedes the removed file and a subsequent posting supercedes > the tombstone. Absolutely. Principals of version control are broken otherwise. In the preferences space, I'd rather see the file extension change as well so it would be possible to determine w/o parsing the file content that it is a tombstone. > I am very concerned about the accumulation of tombstones forever, though. > If we don't want to accumulate draft versions forever, what makes > tombstones different? I would far rather age them out after some interval, > such as six months. As was noted, a mechanism must be maintained to track names and such a mechanism SHOULD be visible to the ietf community. Doesn't have to be the drafts directory. If they are aged, it should be based on natural IETF cycles and not the current arbitrary 6 months ... for example, a draft associated with a working group should have the tombstone remain until some time after the WG closes ... 1 year? That should include drafts submitted to but not owned by a WG. Individual drafts should retain the tombstone for substantially longer than 6 months. Perhaps 2 years. Regarding the clarification about expiration occuring the moment the processing reopens after a meeting... a better approach would be 15 days AFTER ALL drafts submitted while processing was suspended and processed. I wonder how many WG drafts are resubmitted these days to reset the clock rather than because there were substantive changes? Needless churn. It seems quite reasonable that a WG would have reference materials written early in the cycle for discussion which don't change but are still important 2 years later as the WG is perhaps finishing the official RFC track documents. Perhaps even later as RFCs progress thru the standards track. WG chairs should have a mechanism which allows them to extend the expiration of WG drafts w/o churn of version, etc. Dave Morris