Internet Personal Appliance Control BoF (IPAC), Duluth Rm, March 20, 2001 15:45-16:45 Chaired by Simon Tsang (Telcordia) and Mauricio Arango (Sun). Notes taken by: Peter Blatherwick (Mitel Networks). 1. Simon Tsang goes through Intro. See slides (file: IETF50-IPAC-BOF.ppt) Participation stats, why we’re here, reasoning for IETF participation. 2 key questions to answer during the BoF are highlighted. 2. Stan Moyer goes through draft-tsang-appliances-discuss-00. See slides (file: stan-ipac-bof.ppt) Key question: where’s the intelligence? ‘Fat’ (application capable) vs ‘Thin’ (application dumb) model. Application intelligence NOT the same as processing power, separate issue. Where used: home (via NATs, FWs, RGWs,..), work/SOHO, vehicle (mobility) Key issue: security, and related ownership/permissions. How are trust zones defined (trust zones may be flexible/morphable). Privacy & eavesdropping. Related groups and work: ZeroConf, OSGi, UpNP, Note: post URL and list details for all to see. 3. Dave Marples goes through OSGi Overview. See slides (file: Dave-IETF20-Mar-01.ppt) Basic model in OSGi operates as an RSG/app platform Question from audience: Why is OSGi NOT a router? Basic answer is, it could be in some cases, but it’s also more. Deferred for later discussion. 4. Prakash Iyer goes through UPnP Overview. See slides (file: prakash-IETF50UPnPupdate.ppt) Main intent is to define device interfaces and enable capability discovery. Consists of Control Point, Controlled Devices, Bridge (supports legacy devices). XML-based descriptions for Device Control Points (DCPs). Get and Set actions defined through templates. Events based on GENA. Clarification Question (AD): Does UPnP plan to solve location of devices from anywhere on the planet? Answer *thinking about* answering this issue. 5. Mahfuz Rahman, industry perspective (Panasonic). See slides (file: panasonic-ietf1.ppt) Provides very basic architecture diagram (cloud level). Provides application scenarios. Some basic technical requirements: notification, device mobility, user mobility, device status query, security and privacy. 6. Elliot Schwartz, industrial perspective (Embrace Networks). No slides. Key perspective, 1) embedded devices are NOT PCs, no big rich user interface, no complex auto-configuration, 2) devices are extremely cost constrained, so must be absolutely minimal complexity, not full of complex protocols, options, settings etc. IETF key value is open minded, clear thinking perspective, working through what are minimalist requirements focused on the head of a pin. 7. Larry Masinter, IETF historical perspective. See slides (file: larry-ipac-history.ppt) Series of April Fools RFCs etc. Real point is some (if not most) of the issues have been analyzed and have solutions that can be made to work, make sure you do it better. 8. Open Discussion led by Mauricio. See slides (file: IETF50-IPAC-BOF.ppt) Randall Atkinson: really confused. What is difference from what is already done. No summary of what is different is presented. - Response by Elliot Schwartz: yes many do exist, but what is needed to do it is very large in implementation, requirements to find minimalist solution are the real key. Erik Guttman: What are the requirements, really, what are we trying to do? - Response by Dave Marples: command and control across NAT/FWs etc in authenticated way, industry consensus on requirements and common framework, need real analysis and specific recommendations on what to use and how (not ‘we think its all going to be OK’) Simon Tsang: Noted just under half of audience has actually read the discussion draft. [Name missing]: Scope: enterprise vs home network are very different scopes, and why is GW approach not OK. - Response by Mauricio: GW approach is not the only way, and not desirable to require it in all cases. Robert Hinden: confused (still) on what is different from existing solutions. - Response [name missing]: want to find specific set of protocols to use and ways to constrain them to keep it small yet consistent. Henning Schulzrinne: 1) IETF does not ‘do’ architectures, architecture work is very often doomed to failure 2) Several solutions already exist for several aspects (‘we don’t do profiles’). - Response by Simon Tsang: Intent of BoF is NOT to provide protocols, profiles or anything else – intent WAS to provide forum for working through issues and recommendations on how to use what exists. Henning Schulrinne: legitimate question exists if anything is truly missing. Stan Moyer: sees need for app level communication protocol. Erik Guttman, agrees that profiles and specific products are not on for IETF. [Name missing]: Possible scope = application-layer authentication. AD Recommendation [Erik Nordmark]: Continuing discussion on the list. Clarify reason for existence and scope. 9. Conclusions 1 strike, try again next time with clearer reasoning for WG to form, what are specific problems to solve, and why IETF should be involved relative to other related efforts. Also needs some expectations and clarity management for the next BoF – meeting management issue.