1. TGac Ad-hoc lifecycle model
Month Year
doc.: IEEE yy/xxxxr0
TGac Ad-hoc lifecycle model
Date:
Authors:
John Doe, Some Company

2. Revision history
R1: Added straw polls and results during 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
Month Year
doc.: IEEE yy/xxxxr0
Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches
‘Hard Switch’
‘Soft Switch’
‘Requirements Definition’
‘Systems Design’
‘Spec Text Development’
System Design Document
Spec Framework Document
System Design Document
Draft Text
Draft Text
Source: Rolf de Vegt (this and next slide)
Slide 11
Page 11
John Doe, Some Company

12. Alternatives for Major Taskgroup Decision Points
Month Year
doc.: IEEE yy/xxxxr0
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
Page 12
John Doe, Some Company

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