1. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid Discussions – November 2010 Date: 2010-November-08 Abstract: NIST PAP#2 Report r6 recommended changes Other Smart Grid activities NameCompanyAddressPhoneemail Bruce KraemerMarvell5488 Marvell Lane, Santa Clara, CA, 95054 +1-321-751-3988bkraemer@marvell.com Jorjeta JetchevaItron

2. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 2 Smart Grid Meetings Monday Agenda Item 4.1.12

3. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 3 Agenda Topics for the Week Action Item Finalize change suggestions for the NIST PAP#2 Report Information Items SGIP update OpenSG update P2030 update ITU Focus Group March Tutorial topics/speakers

4. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 4 NIST Timeline Release of draft 0.6 Release of Version 1 Draft 0.5 July 28, 2010 Call for Input to Section 6 August 4, 2010 End of draft 0.5 review period September 15, 2010 December 3, 2010 November 4, 2010 SGIP face-to-face, Chicago PAP 2 meeting OpenSG meeting, Miami Tentative PAP 2 meeting SGIP face-to-face, St Louis Tentative PAP 2 meeting September 16, 2010 End of draft 0.6 review period September 30, 2010 October 29, 2010

5. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 5 PAP#2 Report was updated Oct 1 http://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Actio n_Plan_2_r06.pdfhttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Actio n_Plan_2_r06.pdf

6. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 6 NIST PAP#2 Report v6 – Section 4 4.1 Technology Descriptor Headings To be able to describe wireless technology a set of characteristics were identified and organized into logical groups. The group titles are listed below. 1. Link Availability 2. Data/Media Type Supported 3. Coverage Area 4. Mobility 5. Data Rates 6. RF Utilization 7. Data Frames & Packets 8. Link Quality Optimization 9. Radio Performance Measurement & Management 10. Power Management 11. Connection Topologies 12. Connection Management 13. QoS & Traffic Prioritization 14. Location Characterization 15. Security & Security Management 16. Radio Environment 17. Intra-technology Coexistence 18. Inter-technology Coexistence 19. Unique Device Identification 20. Technology Specification Source 21. Deployment Domain Characterization 22. Exclusions

7. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 7 IEEE 802 contributed a number of suggestions on how to change the NIST PAP#2 Report r6. These were contained in documents 1210 and 1209. https://mentor.ieee.org/802.11/dcn/10/11-10-1209-00-0000-comment-set-1-on-pap-2-report-r6.doc https://mentor.ieee.org/802.11/dcn/10/11-10-1210-01-0000-comment-set-2-on-pap-2-report-r6.ppt https://mentor.ieee.org/802.11/dcn/10/11-10-1209-00-0000-comment-set-1-on-pap-2-report-r6.doc https://mentor.ieee.org/802.11/dcn/10/11-10-1210-01-0000-comment-set-2-on-pap-2-report-r6.ppt

8. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 8 Material for this meeting Section 4 edited

9. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 9 Comment #01 Section 4.2.1.3 talks about Coverage Area. It is important to discuss coverage in conjunction with data rates and link margin for example, in order to avoid associations between inconsistent pieces of information, e.g., citing the largest coverage area achievable by a given technology along with the highest data rate achievable by the technology is incorrect – generally the two have a reverse relationship and the highest coverage is achievable at the lowest data rate. Agreed to text change: Add the following text at the end of Section 4.2.1.3: When comparing coverage areas between different technologies, it is important to take into account the link budgets used in the coverage computation. Note that the largest coverage area achievable by a specific technology typically requires transmission at the lowest data rate used by that technology.

10. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 10 Comment #02a Section 4.2.1.4 talks about Mobility. It would be useful to mention the data rates achievable at various mobility levels to avoid assumptions that mobile devices can communicate at the highest data rates used by a specific technology. Agreed to text change: Add the following text at the end of Section 4.2.1.4: Comparisons between the capabilities of different mobile technologies have to take into account the maximum data rate achievable at each mobility level -- mobile devices may not be able to communicate at the highest available data rates when moving at high speeds.

11. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 11 Comment #03 Section 4.2.1.5 talks about Data Rates. Agreed text change: Add the following text at the end of Section 4.2.1.5: Additional factors to consider when discussing data rates: Throughput must be considered in conjunction with packet size, coverage range and rate of mobility (if any). It is important to distinguish between unicast, multicast and broadcast rates, as they may not be the same for a given wireless technology. Throughput depends on medium access scheduling, including the capability to provide block transmissions (whereby multiple data packets can be sent in succession with minimum or no individual medium access operations per packet except before the first packet is sent), and/or block acknowledgements (whereby a single acknowledgement packet can acknowledge multiple preceding data packets). The capability and flexibility to optimize block transmissions and acknowledgements can have a significant effect on GoodPut. The use of rate adaptation mechanisms, where the data rate on a link is modified when the quality of the link changes.

12. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 12 Add these definitions to Section 2.2 Broadcast Broadcast is a form of message transmission where a message is sent from a single source to all potential receiving nodes. Multicast Multicast is a form of message transmission where a message is sent from a single source to a subset of all potential receiving nodes. (The mechanism for selecting the members of the subset is not part of this definition.) Unicast Unicast is a form of message transmission where a message is sent from a single source is sent to a single receiving node.

13. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 13 Comment #04 Section 4.2.1.6 talks about RF utilization. Agreed text change: Add the following text at the end of Section 4.2.1.6: –Consider the power level regulations for the different channels used by a particular technology. –Consider the impact of Dynamic Frequency Selection (DFS) regulations on the channels used by a particular technology, e.g., certain UNII channels are subject to DFS regulation which requires wireless devices to change channel when they detect the use of radar on their current channel.

14. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 14 Comment #05 Section 4.2.1.7 talks about Data Frames and Packets. It is important to consider frame duration in conjunction with data rate and size of the frame. Also, we need to consider multicast and broadcast frames in addition to unicast frames. Agreed text change: Modify item “a)” in Section 4.2.1.7 as follows: What is the maximum frame duration for a unicast, multicast and broadcast frame respectively, and what are the corresponding frame size and data rate at which each type of frame was sent? Modify item “b)” in Section 4.2.1.7 as follows: What is the maximum packet size that can be sent in one unicast, multicast and broadcast radio frame respectively? Modify item “c)” in Section 4.2.1.7 as follows: Does the radio system support segmentation of unicast, multicast and broadcast packets respectively, when the payload size exceeds the capacity of one radio frame?

15. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 15 Comment #06 Section 4.2.2.4 talks about Connection Topologies. The Bus and Ring topology need to be removed, they are not wireless topologies. One way to characterize wireless topologies is as single hop and multi-hop (statically configured or mesh), and wireless links as point-to-point, point-to-multipoint, and omnidirectional. We need to add figures that correspond to the text we end up with. Agreed text change: Remove the Bus and Ring figures Replace the current text in Section 4.2.2.4 with the following: Wireless network topologies can be divided into single hop and multi-hop, where a multi-hop topology can be statically configured, or can be dynamic and self-forming, e.g., a mesh. A wireless link can be point-to-point, point-to- multipoint, or broadcast. Add the definitions on the following 4 slides to Section 2.2

16. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 16 Hop Definitions Proposed PAP2 Guidelines Document Definitions Hop: The term hop is used to signify a link between a pair of devices that a frame or packet needs to traverse to reach one device from the other. Single-Hop Network: A single-hop network is one in which devices can only communicate with each other directly, e.g., over a single link (hop), and do not have the capability to forward traffic on each other’s behalf. Multi-Hop Network: A multi-hop network is one in which devices have the capability to forward traffic on each other’s behalf and can thus communicate along paths composed of multiple links (hops).

17. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 17 Configuring Definition Statically Configured Multi-Hop Network: A multi-hop network can be statically configured, such that each node’s forwarding decisions are dictated by configuration. Dynamic and Self-Configuring Multi-Hop Network: A multi-hop network can be dynamic and self-configuring, such that network devices have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre- configured constraints and requirements, e.g., lowest delay or highest throughput.

18. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 18 MESH Definition Mesh Network: A mesh network is a dynamic self- configuring network composed of devices that can forward traffic on each other’s behalf, have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre- configured constraints and requirements, e.g., lowest delay or highest throughput.

19. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 19 Comment #07 Section 4.2.2.5 talks about Connection Management. The section needs to mention what aspects of “connection management” can be used to compare different wireless technologies. For example, we can evaluate the latency to join a network, available security mechanisms employed when joining a network, and overhead to join the network (number of control packets exchanged). Perhaps section titles such as “Network Participation Mechanisms” or “Joining the Network” are more descriptive of the content of this section.

20. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 20 Comment 07b Add the following text at the end of Section 4.2.2.5: It is important to evaluate: – the time it takes for a device to join a particular network, and the overhead required to do so – the time and overhead required to rejoin the network when a device becomes disconnected from the network –the overhead required to maintain membership in the network after the initial admission into the network –the overhead associated with optimizing connectivity, e.g., in mesh-based topologies.

21. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 21 Comment #08 Section 4.2.3.2 talks about Location Characterization. It seems like many of the techniques applicable to this section are not technology- specific but implementation-specific and as such can be incorporated across different wireless technologies even if they are not currently incorporated into the products of a specific wireless technology. It would be helpful to make the distinction between technology-specific properties and product-specific properties in the text. Agreed text change: Add the following text at the end of Section 4.2.3.2: It is important to distinguish between technology-specific mechanisms for location characterization and mechanisms that are applicable across technologies or communication topologies, which can easily be added to products that may not currently support them.

22. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 22 Comment #09 A category that is missing from Section 4 is one that characterizes the deployment complexity of each technology. Agreed text change: Add the following text after Section 4.2.4.1: 4.2.5 Group 22: Deployment Complexity It is important to evaluate the complexity of: –installation and maintenance of a given wireless system –integration with other, possibly existing, networks –expansion of the wireless network coverage over time.

23. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 23 General Comment #10 It would be helpful to have some tables and text summarizing the information in Section 5, and to move a lot of the discussions/derivations to an appendix. Otherwise, the message/conclusions/recommendations get lost in the text.

24. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 24 General Comment #11 Section 4.2.1.2 (p. 24) talks about voice and video traffic over the smart grid. We need more use cases motivating why we would want to have voice and video traffic over the smart grid network. The current set of use cases supplied by OpenSG does not currently contain this service. The only video example given in the text is one of surveillance of affected outage areas. It would seem that voice and video might be of lower priority during outages, e.g., caused by disasters or weather-related events, since the network would require a high degree of availability for its regular functions. In addition, surveillance is generally part of the public safety infrastructure and there is spectrum allocated for such use so I am not convinced that we should be discussing this kind of application in the context of the smart grid. Applications such as voice and video have requirements that even broadband network providers are struggling with (wireless and landline) and making them part of the smart grid infrastructure requires significant justification.

25. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 25 General Comment #12 Link Availability in Section 4.2.1.1 does not appear to be consistently calculated for the various candidate various radio technologies, nor did majority of the technology candidates describe the method used to calculate availability. The current description of the characteristic does not match the calculation. Both of these issues need to be resolved before progressing to completion of Sections 6 & 7. “The technology “Operating Point” chosen is presumably chosen recognizing that achieving a low failure rate is desirable.” Agreed text change: Change this sentence to “The technology “Operating Point” is chosen to achieve a low failure rate and is an outcome of deployment flexibility & strategy.”

26. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 26 Comment #13 Para 2 Recommended change Reword the preface to incorporate the idea that SG application requirements evolve over time, yielding to experience rather than remain locked in 1989 or 1999 or 2009 economics. Smart Grid application requirements must be defined with enough specificity to quantitatively define communications traffic and levels of performance over the lifetime of the applications. Applications requirements must be combined with as complete a set of management and security requirements for the life-cycle of the equipment. The decisions to apply wireless for any given set of applications can then be based on expected performance and costs over the projected useful lifetimes of the spectrum and equipment.

27. doc.: IEEE 802.11-10/1316r0 Submission November 2010 Bruce Kraemer, MarvellSlide 27 Agenda Topics for the Week Action Item Finalize change suggestions for the NIST PAP#2 Report Information Items SGIP update OpenSG update P2030 update ITU Focus Group March Tutorial topics/speakers

28. 286/8/2010 Footer for this presentation CATALOG OF STANDARDS 9/8/2015 Mark Klerer SGIP Plenary Vice Chair

29. 29 Plenary leadership team working in conjunction with SGAC and other SGIP working groups Proposed Scope of the Standards Catalog – Standards and guides recognized as relevant for enabling SG capabilities Proposed Objectives of the Standards Catalog – Explain value & purpose of the catalog for SG community – Influential, but independent of NIST/FERC decision-making – Characterize the various specification organizations with respect to their processes in developing their specifications – Provide an annotated resource that identifies standards created by recognized SSOs and/or industry consortia that are relevant to Smart Grid applications – Identify functional areas of smart grid where each standard is appropriate (draw on SGAC work) C ATALOG OF S TANDARDS (S TATUS OF W ORK IN P ROGRESS )

30. 30 Process – NIST Framework and Roadmap for SG Interoperability v1.0 identifies many standards to consider – Additional standards can be identified to the SGIP Administrator by any SGIP member for potential inclusion in catalog – Relevance and importance evaluated by appropriate SGIP working group (e.g. DEWG, PAP, etc) and consensus developed – 75% approval by SGIP membership required prior to SGIPGB approval for inclusion in the catalog – Standards included in the catalog may be deprecated from further use to changes in technology or needs by following the same process. Catalog Structure – Entries in catalog to be structured based on application domain defined in the Framework and further classified by GWAC stack Relationship to NIST and FERC lists – Standards Catalog strives for accurate characterization and relevance to the smart grid community, and avoids recommendation – Standards Catalog expected to be a larger compilation which can inform NIST and FERC in their decision processes C ATALOG OF S TANDARDS : P ROCESS & S TRUCTURE CATALOG OF STANDARDS: PROCESS & STRUCTURE

31. 316/8/2010 Footer for this presentation TESTING & CERTIFICATION COMMITTEE 9/8/2015 Rik Drummond SGTCC Chair

32. 32 November 201032 P URPOSE Establish a Testing and Certification Framework for the Smart Grid Establish a brand called ‘Interoperability’ that has a consistent meaning across the Smart Grid for the buyers of interoperable products. – At this time a set of products deemed interoperable may be interoperable with a 80%, 95%, 99%, or 100% confidence level. Thus to say a product is interoperable has little current meaning in the market place as many purchasing organizations have found.

33. 33 6/8/2010 Footer for this presentation 33 Deliverables  D3 – Interoperability Process Reference Manual (IPRM) is being finalized for SGIP review.  Interoperability Maturity Assessment Tool completed Activities and Accomplishments  D3 – Interoperability Process Reference Manual (IPRM) completed 1 st review and comment period during St. Louis meetings; comment resolution and final editing remains in progress  Began piloting IPRM with several Interoperability Testing and Certification Authorities (ITCA) who have expressed willingness to cooperate and participate in assessing their organizations against the IPRM recommendations.  Prepared draft ITCA audit process document and checklist in preparation for ITCA reviews  Launched discussion with accreditation bodies for future independent ITCA reviews Upcoming Key Milestones and Activities  Presentation on SGTCC framework and plan to the SGIP on October 29 to build awareness and support for the process  Completing 2-3 ITCA reviews by late November  Updates to the IPRM based on experience gathered during the ITCA review process, and revision/release in early January  Engaging with the CSWG testing sub-team to coordinate security related testing issues Issues, Concerns, and Help Needed  Obtaining timely cooperation from the ITCAs to participate in the review process with the TCC, and accelerating their commitment to adopt and enact the SGTCC recommendations in their operations  Engaging end users to gain their commitment towards requiring IPRM conformance for ITCAs certifying the products that they purchase October 2010 Activities - PMO Monthly Report SGTCC M ONTHLY Q UAD C HART SGTCC MONTHLY QUAD CHART

34. 34 November 201034 D EFINITIONS ITCA – Interoperability Testing and Certification Authority Framework Manual - IPRM – Interoperability Program Reference Manual ISO 65 - General Requirements for Bodies Operating Product Certification Systems ISO 17025 – General Requirements for the Competence of Testing and Calibration Laboratories SGTCC Interoperability Test Construction Best Practices – Lists of best practices not covered in ISO 65 and ISO 17025 SGTCC/CSWG Cyber Security Testing Best/Standard Practices –List of best practices not covered in ISO 65 and ISO 17025 Interoperability Maturity Assessment Model – looking for IOP products based on standards NOW.

35. 35 6/8/2010 Footer for this presentation 35 G ENERAL S TRUCTURE OF THE F RAMEWORK M ANUAL GENERAL STRUCTURE OF THE FRAMEWORK MANUAL ISO Guide 17025 ISO Guide 65 Best Practices for IOP Test Construction Best/Standard Practices for Cyber Security Test Construction Introduction, Responsibilities, Rationale, Usage and Checklists 2011 Transition Bootstrap Support Plan for ITCAs Evaluation Checklist for ITCA Delta to Manual Framework Manual

36. 36 November 201036 ISO Guide 65 contains the requirements necessary for an organization to demonstrate competence to perform certification activities related to the standards or specifications stated in the certification ISO Guide 65 criteria include: – Technical competence Certifying personnel criteria; accessibility of certification test processes; assessment fairness and integrity and others – Management systems Quality management processes, technical dispute resolution processes Lab qualification criteria, lists of certified products, record control, ongoing certification maintenance and withdrawal process ISO Guide 65 conformance demonstrates a robust, thorough and meaningful certification program Implements a monitoring program for IOP products in the field to ensure IOP remains ISO G UIDE 65 O VERVIEW

37. 37 ISO 17025 contains all requirements that laboratories need to demonstrate that they – operate a management system, – are technically competent, – are able to generate technically valid results. ISO 17025 is the most widely accepted and used standard for the operation of test laboratories ISO 17025 applies to any testing laboratory operation (1 st, 2 nd or 3 rd party), with many 3 rd party labs formally accredited It facilitates acceptance of test results from accredited laboratories and serves as the requirements that formal accreditation bodies apply in assessing laboratories. ISO 17025 O VERVIEW ISO 17025 OVERVIEW

38. 38 November 201038 – Test Suite Specification of a standard used for interoperability or conformance testing shall be managed in the same way as the standard they are derived from. – IOP Certification test reports shall fully describe the test methodology used including the justification for statistical or deterministic testing. – A certified interoperable product set shall also be conformant to the standard or profile of the standard. – The only means to ensure interoperability among products is to perform a full matrix test. B EST P RACTICES FOR IOP TEST CONSTRUCTION EXAMPLES

39. 39 November 201039 2011 T RANSITION B OOTSTRAP YEAR SGTCC, with NIST will help bootstrap the process by offering tutorial help in 2011 to the first few committed ITCAs. – Preliminary review of implementation of ISO 65 and ISO 17025 implemented processes. – Review and analysis of interoperability test construction best practices. – Other general guidance. Maintain a list for the industry showing ITCAs in the process of implementing the Manual.

40. 40 November 201040 2011 T RANSITION B OOTSTRAP YEAR SGTCC, with NIST will help bootstrap the process by offering tutorial help in 2011 to the first few committed ITCAs. – Preliminary review of implementation of ISO 65 and ISO 17025 implemented processes. – Review and analysis of interoperability test construction best practices. – Other general guidance. Maintain a list for the industry showing ITCAs in the process of implementing the Manual.

41. 41 November 201041 2012 AND B EYOND ITCAs will be using Test Labs using ISO 17025, and ISO 65 standards and be accredited by the existing formal accreditation organizations. SGTCC will maintain lists of SGIP Approved ITCAs (those implementing the Manual) for a standard and demonstrating the production of interoperable products. The products of the standard will be monitored for interoperability in the field by ITCA and secondarily by SGTCC Accreditation Bodies (e.g., NVLAP and ANSI) will periodically audit test labs and certification bodies using the Manual as guidance and re-accredit them. SGTCC will subsequently update the ‘SGIP ITCA Approved List ’. Note many Test lab now use ISO 17025, but not the IOP best practices. Also many ITCAs do not use ISO 65.

42. 42 November 201042 N EXT S TEPS AND Y OUR R ESPONSE Receive SGIP consensus for Manual / Framework Each SGIP member MUST REQUIRE the purchase of interoperable products to initiate the monetary incentive for many of the ITCAs to upgrade to the Manual / Framework. – Note: this is an issue about wide scale interoperability across the smart grid. Having only a percentage requiring interop products will in many ways leave us in our current state. SGTCC will offer two Webinars in late November and early December to address questions and concerns. To be announced.

43. 43 November 201043 GB Election Timeline – Even Stakeholders, 2010

44. 44 November 201044 UPCOMING 2010 PLENARY EVENTS 30 Nov – 3 Dec: Grid-Interop, Chicago – See http://www.grid-interop.com/2010/#agenda for detailed agendahttp://www.grid-interop.com/2010/#agenda Mon. 11/29 Tue. 11/30 Wed. 12/1 Thu. 12/2 Fri. 12/3 8.00 am GB Meeting 10.30 am PAPs & WGs 12.00 pmLUNCH 1.00 pm Optional Meetings Opening Plenary Closing Plenary 3.30 pm DEWGs & Committees PAPs & WGs Optional Meetings 5.00 pm Candidate Interviews and Optional Meetings 7.00 pm PAPs & WGs 9.00 pm

45. 45 November 201045 2011 Plenary Meeting Schedule MonthDateTimeDetail Jan211 – 3 p.m.Virtual Meeting/Conf. Call Feb Mar29-31All DayF2F: Nashville likely Apr May261 – 3 p.m.Virtual Meeting/Conf. Call hosted @ ConnectivityWeek Jun Jul12-14All DayF2F: Montreal, Canada – International theme Aug Sep151 – 3 p.m.Virtual Meeting/Conf. Call hosted @ GridWeek Oct Nov Dec5-8All DayF2F: Grid-Interop, Phoenix