Project IEEE 802 15 Working Group for Wireless

Project: IEEE 802. 15 Working Group for Wireless Personal Area Networks (WPANs) March 2003 doc. : IEEE 802. 15 -03/078 r 2 Submission Title: [WG-TG 3 Closing Report March 03] Date Submitted: [14 March 03] Source: [John Barr] Company [Motorola] Address [1303 E. Golf Road, Schuamburg, IL 60196] Voice: [+1 847 576 -8706], FAX: [+1 847 576 -6758], E-Mail: [John. Barr@Motorola. com] Re: [02424 r 0 P 802 -15_TG 3 -November 02 -Meeting-Objective-and-Agenda. xls] Abstract: [TG 3 Chair Report to 802. 15 WG] Purpose: [TG 3 chair report to WG to update them on work completed at DFW. ] Notice: This document has been prepared to assist the IEEE 802. 15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by 802. 15. Submission 1 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 802. 15 IEEE 802. 15 Working Group for Wireless Personal Area Networks TG 3 Closing Report March 2003, DFW Texas Submission 2 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Agenda • Goals of March Meeting • Sponsor Ballot Status • Motion to add 802. 15. 3 to REVCOM agenda • Motion to empower BRC • Goals for May Meeting Submission 3 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Goals for March ü Conference call status, including approval of any ad hoc business. ü Sponsor ballot comment resolution. • Update draft as required. • Approve sponsor ballot recirculation. Submission 4 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 SB 1 Comment Status (Draft 15) Submission 5 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 SB 2 Comment Status (Draft 16) Submission 6 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Motion to the TG 3 Move to empower the 802. 15. 3 SBRC to update D 16 to D 17 and release for sponsor ballot recirculation under LMSC Procedure 10. Mover: Al Heberling Second: Jim Allen For – 5 Against – 0 Abstain – 0 Submission 7 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Motion to the WG Move to empower the 802. 15. 3 SBRC to update D 16 to D 17 and release for sponsor ballot recirculation under LMSC Procedure 10. (TG 5/0/0) Mover: John Barr Second: Jim Allen For – Against – Abstain – Submission 8 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Conditional Approval Support • D 16 Recirculation Ballot – – Closed – 8 March 2003 (15 -day) 74 Approve/2 Disapprove/6 Abstain (97%) Disapprove Comments (package) Completed Confirmation Schedule • Pre-D 17 on 24 March 2003 – Inform IEEE-SA of ballot in two weeks • • • SBRC comments on 31 March 2003 D 17 Released for SB on 5 April 2003 D 17 SB Starts on 7 April 2003(15 -day) D 17 SB Closes on 22 April 2003 SBRC Meeting in Chicago on 24 April 2003 – Submit to REVCOM 5 May 2003 for June Meeting Submission 9 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 802. 15. 3 SB No Vote Resolution • D 15 Remaining Disapprove Votes: – Rajugopal Gubbi – 5 Comments (1 Rebuttal) • • Total 5 Accepted 0 Withdrawn 0 Remaining 5 – Rene Struik – 3 Comments (No Rebuttal) • • Total 39 Accepted 33 Withdrawn 3 Remaining 3 – All disapprove comments were provided to the sponsor ballot pool along with D 16. No additional NO votes were received supporting these comments. D 16 had 97% approval. Submission 10 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 802. 15. 3 SB No Vote Resolution • D 16 Remaining Disapprove Votes: – Rene Struik – 2 Comments (03/174 r 2) • • Submission Total Accepted Withdrawn Remaining 3 1 0 2 11 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 CID 153 Comment History Rajugopal Gubbi submitted the following comment during the 802. 15. 3/D 15 sponsor ballot: CID 153: Clause: 00 Subclause: 00 Page: 00 Line: 00 Comment Type: TR COMMENT START: Summarise all PHY timing parameters in one table in 11. 2. 7 ref: CID 69 - LB 22 A summary all PHY dependent parameters (a. CCADetect. Time, a. PHYSIFS-Time etc. ) in a table with actual values at one place instead of spreading them all around the PHY clause is very desirable from implementors'view. An example would be Table-64 for MAC parameters. Although Table-120 provides a list of just the IFS parameters in a table, even there the for actual values the readers have to scrouge through the individual subclauses, which can easily be avoided. SUGGESTED REMEDY: Make the change as requested. RESPONSE: ACCEPT IN PRINCIPLE. Make a table of all of the p. ZZZYyy parameters and their values, this will follow the format of table 65 in clause 8. Submission 12 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Rajugopal Gubbi’s Email Response (18 Feb 2003): TR-153 - Why is this ACCEPT in PRINCIPAL? Why not simplify the process by saying ACCEPT? If there is any deviation to listing parameters in one, single comprehensive table, the resolution will be unacceptable to me. 802. 15. 3 Technical Editor’s Reply (19 Feb 2003): In the suggested resolution, you did not exactly specify what was to be done, so it was an accept in principle. To do an Accept, we need exact text or changes to be made. I put the following parameters in one table: p. PHYMIFSTime, p. PHYSIFSTime, p. CCADetect. Time, p. PHYChannel. Switch. Time with the associated timing information. It makes it more difficult to read the PHY clause in the draft to have them in a single table rather than the location where the measurement is defined, but it wasn't a big deal to move them either. In any event, the comment is really editorial, we have not changed any of the technical requirements in the standard, just the location of the information. All of the timing information is defined in exactly the same way as it was before. Submission 13 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 D 16 added Table 80: PHY layer timing parameters, to satisfy this Accept. 802. 15. 3 Chair’s Request to D 16 sponsor ballot negative voters (8 March 2003): Please submit a recirculation ballot with your vote on D 16. This will help us get a clean record for all of the previous NO voters. Rajugopal Gubbi’s Response (9 March 2003): Please refer to the following section of the SB announcement. "NOTE: You must respond to a Recirculation Ballot if you wish to change your initial vote. If you do not respond to a Recirculation Ballot, your last vote will be carried forward. " Hence what you are asking is completely unnecessary, since the NO votes will be carried through. 802. 13. 3 Chair’s Request for Reconsideration (12 March 2003): Please review D 16 and your comments one more time and let me know whether the new draft satisfies any of your outstanding unsatisfied comment resolutions from the first sponsor ballot. End of Resolution Record for CID 153. Submission 14 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 CID 167, 168 Comment History (1) Rene Struik submitted the following comment during the 802. 15. 3/D 16 sponsor ballot: CID 167: Clause: 00 Subclause: 00 Page: 00 Line: 00 Comment Type: TR COMMENT START: The 802. 15. 3 Chair directed the removal of all public-key establishment mechanisms from the D 15 Draft (see 03/054 r 1). It is however not clear at all on which rationale this decision was made. In fact, one can easily provide technical arguments that the decision lacks any justification and is not based on sound professional or engineering arguments The 802. 15. 3 standard without proper entity authentication and key establishment mechanisms is a standard that cannot be implemented by industry, since it is incomplete. Moreover, no concrete suggestions are done how to provide adequate specifications for this functionality. Without this, this standard cannot be implemented by industry and will not be used or used with considerable delay. Last, but not least, the decision on what is supposed to be inside scope and what isn’t seems to be based on arbitrary arguments. For a detailed rationale considering this comment, see the document I will post during the March 2003 Dallas meeting and the presentation I intend to give there. SUGGESTED REMEDY: Revert the decision to drastically modify the security properties of the standard. Re-incorporate all authentication and key establishmentrelated security mechanisms that were removed from the draft in the transition process from Draft D 15 towards Draft D 16. Re-consider all sponsor ballot comments related to Draft D 15. RESPONSE: REJECT. The PAR of 802. 15. 3 limits the scope of our standard. There are many issues of an implementation that are outside of the scope of a MAC and PHY. For example, service discovery, network address resolution, routing and bridging are all outside of the scope of a MAC/PHY standard. The committee has used the experience with the public-key cryptography suites to ensure that the 802. 15. 3 MAC supports the use of these higher layer protocols to perform entity authentication and key establishment. There are higher layer protocols, e. g. 802. 1 x, that allow MAC/PHY standards to implement entity authentication and key establishment. The 802 leadership and the 802. 15 working group chair both indicated that the inclusion of these security suites was outside of the scope of a MAC/PHY standard. Submission 15 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 CID 167, 168 Comment History (2) Rene Struik submitted the following comment during the 802. 15. 3/D 16 sponsor ballot: CID 168: Clause: 00 Subclause: 00 Page: 00 Line: 00 Comment Type: TR COMMENT: The 802. 15. 3 Chair directed the removal of all public-key establishment mechanisms from the D 15 Draft (see 03/054 r 1). It is however not clear at all on which rationale this decision was made. In fact, one could address Paul Nikolich’s comments (as worded in 03/54 r 1) by implementing just 1 public-key security suite (this removing choice). This would allow a standard that is functional and complete and was also the initial intention before politics entered the 802. 15. 3 stage. SUGGESTED REMEDY: Revert the decision to drastically modify the security properties of the standard. Re-incorporate 1 authentication and key establishmentrelated security mechanisms, viz. the ECMQV security suite that was removed from the draft in the transition process from Draft D 15 towards Draft D 16. Re-consider all sponsor ballot comments related to Draft D 15. RESPONSE: REJECT. The SBRC voted 11 to remove the public-key cryptography suites, per the recommendation from the 802 SEC chair and the 802. 15 working group chair. The SBRC agreed that the inclusion of these suites could be seen as being outside of the scope of the PAR which limits the standard to the MAC and PHY only. The decsion to remove the security suites was affirmed by the working group in the closing plenary of the Ft. Lauderdale meeting as well. The issue of the inclusion of the public-key cryptography suites was not that there were more than one option, but rather that the authentication process took place in layers above the MAC and PHY. Removing all but one public-key suite would not resolve the issue of the public-key security suites being out of scope of the 802. 15. 3 PAR. Submission 16 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 CID 167, 168 Comment History (3) Rebuttal: Rene Struik presented document 03/174 r 0 “Rationale for Security in 802. 15. 3” during a joint session of TG 3 and TG 3 a during the DFW IEEE 802 Plenary, Thursday March 13, 2003. In a later session of TG 3, slides 9 and 10 of the presentation were offered as justification for not accepting the resolution of the SBRC. Response: TG 3 did not conclude that the SBRC findings were incorrect as a result of the presentation. These unresolved comments will be carried forward with the D 17 sponsor ballot recirculation. End of Resolution Record for CID 167 & 168. Submission 17 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Motion to the Task Group Move to seek approval of the WG to place IEEE 802. 15. 3 D 17 on the May REVCOM agenda subject to successful completion of recirculation ballot following LMSC Procedure 10. Mover: Jim Allen For – 5 Against – 0 Abstain – 0 Submission Second: Al Heberling 18 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Motion to the Working Group Move to place IEEE 802. 15. 3 D 17 on the May REVCOM agenda subject to successful completion of recirculation ballot following LMSC Procedure 10. TG 3 Approval: 5/0/0 Mover: Jim Allen For – Against – Abstain – Submission Second: John Barr 19 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Goals for May • Conference call status, including approval of any ad hoc business. • Review and address any REVCOM issues. • Editing recommendations for IEEE-SA. • Prepare for final approval Submission 20 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 SBRC Ad Hoc Meeting • April 24, 2003 – Schaumburg, IL – Hosted by Motorola – Noon to 5 PM – Address D 17 Sponsor Ballot Comments Submission 21 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Publicity Committee Input • IEEE 802. 15. 3 sponsor ballot has >97% approval. Task group has reviewed all of the technical comments and is preparing an updated draft (D 17) for recirculation in April. • IEEE-SA will have pre-standard copies of IEEE 802. 15. 3 available for distribution in April. • IEEE 802. 15. 3 draft standard is expected to be submitted for final approval following successful recirculation in May. Submission 22 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 802. 15. 3 Application Space Submission 23 Dr. John R. Barr, Motorola

March 2003 doc. : IEEE 802. 15 -03/078 r 2 Ultra Wide Bench (UWB) Submission 24 Dr. John R. Barr, Motorola