TGac Ad-hoc lifecycle model

1. TGac Ad-hoc lifecycle model Date: 2009-11-19 Authors:

2. Revision history • R1: Added straw polls and results during 2009-11-17 am1 TGac meeting. • R2: Added discussion and straw poll related to generation of draft text.

3. Introduction • TGac Ad-hocs are starting up activity this week • There needs to be a clear expectation of the phases of activity (the “lifecycle”) performed by an ad-hoc • Earlier work (11-09/0237) addressed the contents of the framework document. It did not address how high-level design decisions should be recorded. This submission highlights the need to record these design decisions before drafting text. • Also there are two questions that need to be discussed and addressed now: • Are transitions between phases of activity formalized (e.g. formal sign-off that requirements are complete)? • Do we record high-level design decisions in the Framework document, or some other document?

4. Lifecycle • Establishing requirements • Making top-level design decisions • Writing draft text • Resolving comments

5. Establishing requirements • Purpose of this phase is to determine the features that the ad-hoc is supporting • During this phase we expect to see justification of features • i.e. performance simulations/results, complexity estimates • Output is the Framework document, e.g. • “Preamble shall support colored training symbols” ** ** The example is fictitious :0)

6. Making top-level design decisions • During this lifecycle phase, the ad-hoc considers alternative proposals that show how to meet its requirements (which have been documented in the framework doc). • Eventually the group decides on mechanisms/methods/structures that meet its requirements. • The output is in a TBD document (could be Framework document, or new system design document), containing high-level design • e.g. “The preamble supports colored training symbols through the following structure: following the single spatial stream VHT SIG field there will be n VHT-LTFs, where n is the total number of spatial streams. the colors of the LTFs will be selected in order from: red, green, blue, red, green, blue … ” ** * This is still a fictitious example

7. Writing draft text • During this phase, the ad-hoc writes text for incorporation into the draft amendment. • Only “low level design” decisions are made at this stage • All feature decisions and top-level design decisions have been made in previous phases of the lifecycle • Phase is complete when the draft is approved for ballot

8. Resolving comments • Comments will be received during letter ballot • The ad-hoc will be asked to provide resolutions for comments “in scope” of its charter, to be approved by TGac • This phase completes when the IEEE Standards Board have approved the amendment

9. Moving between phases of the lifecycle • Do we have a hard switch? • i.e. Once an ad-hoc has started making top-level design decisions, is it allowed to go back and change its requirements? • Switch into comment resolution is necessarily “hard” because it is dependent on entry to letter ballot • If we have a hard switch, we need to formalize two transitions: • From requirements to top-level design • From top-level design to drafting text • If have a “soft” switch, an ad-hoc can move between phases as it needs • e.g., to reflect learnings from design back into requirements • Which is going to be the most effective way to operate?

10. Recording the top-level design • We need a place to record top-level design decisions • We have only two documents so far: • Framework • Draft Amendment • Do we need a third document “System design spec”, or can we use the framework document to capture this output?

11. Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches Source: Rolf de Vegt (this and next slide) System Design Document Spec Framework Document System Design Document Draft Text Draft Text Slide 11

12. Alternatives for Major Taskgroup Decision Points Framework Update System Design Draft Text Coex PHY MAC MU Framework Update System Design Draft Text Hard Switch Letter Ballot Framework Update System Design Draft Text Framework Update System Design Draft Text System Design Draft Text Coex PHY MAC MU System Design Draft Text Soft Switch Letter Ballot System Design Draft Text System Design Draft Text = Taskgroup Approval Decision Point Slide 12

13. Straw poll 1 • Should we have a separate system design document, or should we use the framework document to hold the system design? • Separate 6 • Framework 24 • Don’t know yet 34

14. Straw poll 2 • Should we use a formal switch (i.e. by motion in task group to switch between requirements and system design) between requirements and design phases, or should we allow iteration between them? • Formal switch 0 • Allow iteration 36 • Don’t know 16

15. When can we generate draft text? • It is clear that changes to the framework document, or changes to the draft text require 75% TGac approval. • It is not clear (i.e., we haven’t discussed this in TGac yet) whether TGac approval is needed to switch between “requirements/system-design” and “drafting” phases in the ad-hoc.

16. Straw Poll • Does an ad-hoc need TGac permission before starting to consider/generate draft text? • Yes – needs TGac permission - 2 • No – can generate draft text whenever it likes - 32 • Don’t know- 27

17. Straw Poll 2 • If permission is required for an ad-hoc to start generating draft text, is this permission granted independently, or coordinated across all ad-hocs? • Independent decision points for each ad-hoc • A single decision point across all ad-hocs. • Don’t know