[security-services] updated -- proposed schedule. plus"committee last call" process

[Jeff Hodges <jhodges@oblix.com>]

Here's an updated proposed schedule per the SSTC Telecon, Tuesday Dec 11, and
the updated list of docs comprising our "doc set", based on my understanding
from said telecon. Note that the schedule beyond 9-Jan is tentative. 

Below the schedule is the proposed "committee last call" process. Note that it
defines how we make decisions as to whether a doc passes Last Call or not.
Please review this and provide feedback. 

thanks,
JeffH

                 -------------------------------

SSTC document set:

  draft-sstc-core
  draft-sstc-bindings-model
  draft-sstc-sec-consider
  draft-sstc-conform-spec
  draft-sstc-glossary

present maturity level of these docs: "committee working draft"


                 -------------------------------

Proposed schedule, per SSTC Telecon, Tuesday Dec 11:

[note, schedule for SSTC official concalls will perhaps need to be tweaked to
help facilitate the process]


5-Dec (Wed): Prateek to issue bindings-07   [DONE]

12-Dec (Wed): comments on bindings-07 due.  [DONE]

~17-Dec (Mon): Prateek to issue bindings-08 based upon feedback on -07.

ISSUE: any interim dates similar to above for issuance/iteration on core-2x?


9-Jan (Wed): release of fresh drafts of all 5 docs in the doc set, plus the
FAQ. Goal is for this doc set being one we can share with the world for
outreach and feedback purposes, and also for refining all to "candidate
committee specification" maturity level. 


10-Jan -- 1-Feb (Fri) : refine doc set into "candidate committee specification"
maturity level. 


1-Feb (Fri): Issue Committee Last Call.


15-Feb (Fri): Last call cutoff date.

15-Feb -- 28-Feb (Thu): refine any editorial issues. decide (via process
outlined below) whether an "showstopper normative technical issues" exist. Such
issues, if upheld, will require another last call. 

1-Mar (Fri): Submit doc set to OASIS. 



                 -------------------------------
Proposed "Committee Last Call" process:

0. This is where we are now. At this stage, the doc(s)'s maturity level is
"committee working draft".


1. In order to issue a "committee last call" on a doc or docs, there should be
no open action items or issues associated with the doc(s). 


2. A "committee last call" is issued by the committee co-chairs via an email
message to the security-services list. We will leverage content from IETF and
W3C examples. The "committee last call" message identifies the docs, lays out
the timeframe and vehicles for submitting comments, and provides some context
wrt the last call process. 

At this stage, the maturity level of the doc(s) is "candidate committee
specification".


3. People review the docs and submit comments (via the list -- comments must be
in writing and available for all to see).


4. upon the "last call cutoff date" or shortly thereafter, the chairs and doc
editors summarize the comments received to the committee. If there are issues
with the doc(s) that the committee regards as "showstopper normative technical
issues", then the doc(s) don't pass "committee last call", and the process
iterates back to (1) (since there are again open issues with the docs). Else,
go to (5). 

detailed process for step (4):  

In order to decide whether there are any "showstopper normative technical
issues", the doc editors will summarize to the committee the issues raised
during last call (e.g. via a msg to the list). The co-chairs will facilitate a
walk-through of the issues list for each doc (if any) during a formal committee
meeting. 

If a issue has a champion, and no one challenges the issue, then the doc
doesn't pass committee last call (i.e. goto (1)). 

If an issue has a champion, and the issue is challenged, a formal committee
vote is held. The question being voted on will be constructed so the result of
the vote will be to either "the issue is a showstopper normative techical one:
re-do Committee Last Call", or the issue is closed (e.g. it wasn't felt to be a
normative technical one), or it is deferred (e.g. the issue may be a normative
technical one, but it isn't a showstopper at this point). If the issue is
closed or deffered, it doesn't hinder the doc(s) passing committee last call. 

If an issue no longer has anyone willing to champion it, it is closed or
deferred, and doesn't hinder the doc(s) passing committee last call. 



5. The doc(s) have passed "committee last call" and are subject to
non-normative editing. They remain at this step (5) and at "condidate committee
specification" maturity level until all all non-normative editorial issues are
closed. Once these non-nomative editorial issues are closed, goto (6).


6. The doc(s) are annointed the maturity level of "committee specification" and
are ready for submission to OASIS per OASIS "standards process" (see ref
below).

                 -------------------------------

Refs: 

OASIS TECHNICAL COMMITTEE POLICY
Section 2. Standards Process
http://www.oasis-open.org/committees/process.shtml

IETF Working Group Guidelines and Procedures
http://www.ietf.org/rfc/rfc2418.txt

The Internet Standards Process -- Revision 3
http://www.ietf.org/rfc/rfc2026.txt

W3C Process Document
 5.2 The W3C Recommendation Track
http://www.w3.org/Consortium/Process-20010719/tr.html#Recs

                 -------------------------------