[security-jc] RE: Specification Errata Process Issue

["Karl F. Best" <karl.best@oasis-open.org>]

Hal:

There may be another solution. The TC Process is currently being
revised, and due to be completed this month or next. A major revision
is the shortening of the specification review/approval cycle from five
months to two, with submissions made on a monthly rather than a
quarterly schedule. The intent of this change is to reduce the "cost"
of withdrawing/fixing/resubmitting a spec once errata have been found.

Would this meet your needs, or would this reduced schedule still need
to include some provision for errata?

</karl>
=================================================================
Karl F. Best
OASIS - Director, Technical Operations
+1 978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, July 11, 2002 5:00 PM
To: 'Karl F. Best'
Cc: 'security-jc@lists.oasis-open.org'
Subject: Specification Errata Process Issue


The understanding of the SSTC (and others) is that the specification
voted for by the membership must be EXACTLY the same document
presented at the begining of the review cycle. The problem is that we
have found errata and expect there will be more. These do not differ
from the intent of the specification, but they are important for
implementers to be aware of. As we understand it, the only way to get
these in the spec is an additional 4-5 month review + approval cycle.
The kind of process we would recommend (this is my summary of the
consensus at the last concall) is as follows:
1. publish spec with a statement that errata can be found at such and
such location and will be incorporated into the document at the end of
the review cycle.
2. Post an errata document with two sections: identified errors and
approved changes to the spec
3. At the end of the review period, close all errors by either
approved changes or deferral. Apply all changes to document.
4. Membership votes on updated document which becomes normative spec.
Obviously variants of this are possible.
Other TCs, e.g. XACML believe this may be an issue for them as well.
IMO people have rightly been impressed with the speed with which SAML
was developed. It is certainly a good idea to allow plenty of time (3
mo review + 1 month voting) to approve a major specification. However,
there ought to be a more streamlined way to correct minor errors and
ommisions without going through the entire cycle.
Hal