1 / 4

802.11be Selection procedure clarifications

This document discusses ambiguities in the draft selection procedure for 802.11be, proposing edits to ensure timely and complete drafts. It clarifies the role of the SFD (Specification Framework Document) and suggests modifications for clearer guidelines.

cfaulk
Download Presentation

802.11be Selection procedure clarifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.11be Selection procedure clarifications • Date: 2019-05-13 Sean Coffey, Realtek

  2. Abstract • A recently posted draft selection procedure for 802.11be (doc. IEEE 802.11-19/0559r0) proposes text modelled on 802.11ax, and largely follows the “Spec Framework Document” methodology. • There are (at least arguably) some ambiguities in the draft selection procedure as currently stated, and different sets of expectations that result, and that may contribute to significantly different project timelines. • It would be useful to clarify the draft selection procedure in ways that will help ensure timely, complete drafts. Sean Coffey, Realtek

  3. The role of the SFD • The Functional Requirements (in 19/0559r0) are explicitly binding • “The TG shall adopt, through a 75% approval vote, a Functional Requirements document that shall be met by the proposed draft amendment” (item 2) • The Spec Framework Document documents high-level agreements • The SFD “outlines” the “mainfunctional blocks” of the amendment (item 3) • What happens if (when) some blocks are later ready and others are not? • “Ready” = implemented in full by text adopted in the 802.11be Draft Amendment; “not ready” = anything down to single sentences stating a concept • Is the 11be Draft then “complete and coherent enough for WG letter ballot” (item 5)? • In practice the SFD does not seem to function as an FRD-style requirement • We just go to letter ballot—it’s complete and coherent enough when we say it is • But the role of the SFD is not fully clear—it’s “sort of” half-required, and we end up with drafts that mix mature text with half-finished (or less) work, and/or delay going to LB to get lagging features into semi-adequate shape Sean Coffey, Realtek

  4. Proposed edits • The underlying motivation is to clarify that the SFD documents TG agreement in principle on high-level, outline blocks (to be filled in by a collaborative process), but this agreement is contingent on adoption of complete implementing text in the draft • Proposed clarifications: • In 4a, delete “all”: “TG members are responsible to make amendment text contributions that implement allthe functional blocks in the Specification Framework document or subsets thereof” • In 4b (after “Collaboration on these blocks is encouraged”), add “The TG Chair may establish ad hoc groups to facilitate such collaboration” • In 4c, add new sentence at end: “Adopted draft amendment text contributions should be complete enough that the 802.11be Draft Amendment is always in a coherent state.” • In 5, change “is complete and coherent” to “meets the Functional Requirements and is coherent” Sean Coffey, Realtek

More Related