Minutes: IETF-51 Internet Personal Appliances Bar BoF

08.08.01, 11:30-13:00, Fiamma Restaurant at Hilton convention center

Attendees: Joerg Ott, Henning Schulzrinne, Mario Kolberg, Dirk Kutscher, Mohammed Rahim, Miknon Go, Mahfuz Rahman, Ashutosh Dutta (note taker), Peter Blatherwick (meeting chair)

The following summarizes main points of discussion.

Topic 1: Getting to Successful BoF at IETF-52

A key to success is ensuring we can actually get the work done between now and IETF-52 BoF, and sustain the effort to successful WG completion thereafter. Noted that e-mail list and document efforts were very vigorous leading to previous (unsuccessful) BoF, yet has been very quiet and unproductive in last several months, most effort falling to a very small number of people. Show of hands, most attendees are willing to help, author documents.

In general, there are 2 types of WG possible, with corresponding approach to BoF: 1) specific protocol output WG, creating new product or extensions to existing; 2) requirements / survey WG leading to proof of need for more specific output (or not).

Key to BoF success is to show there is a real need to either 1) set specific requirements for IPA use of existing approaches, or 2) show clear need to extend existing approaches or provide a new solution to suite needs.

Discussed urgent need, and why IETF has a critical role to play. General strong agreement there are proprietary products being built now, which will at best create islands of vendor-specific interoperability -- at worst it’s a mess. Need for a common, presumably IP-based, interoperability layer to allow broad interoperability and create positive-feedback economics to grow industry. IETF role is creation of the IP-based interoperability layer and ruthless defense against single vendor interests, appropriate skill set / knowledge base to get it right.

One issue, given large number of University affiliates attending, is this must not appear to be a "research project". Must show end user and commercial value, willingness to build product in the real world. Noted that there were several attendees intending to build product, and in fact non-standardized product is being built now.

On the issue of profiles, while there may be needs to specify minimum support requirements for interoperability purposes (specific functions that all IPAs MUST support), we must be extremely careful not to propose "profiling" of existing approaches. There is a very real tension here: there must be some base level of required support, yet must enable a "menu approach" to vendor and user selection of what specific features are present on any specific IPA device. Agreed we must only use the "P" word if there is a very real and readily provable need that profiling is strictly required to achieve interoperability.

Topic 2: Work Items for IETF-52 BoF

Need to decide on type of WG that we aim to create (see previous point). Briefly discussed whether BCP would be an appropriate output, confirmed it was not since there is no real current practice to draw on for experience.

Need to create tentative charter, including some (if not most) of the following items.

As part of this, IETF will almost certainly require MIB output (assuming protocol output mandate for the WG), however this can possibly be deferred to later WG phase and/or simply reuse existing. Either way, this specific item should be included in charter text as "flak deflection".

Need a specific BoF presentation prepared and agreed in advance. This is likely best derived from a set of pre-developed papers (see next).

Specific documents to be worked in advance may include:

1) Requirements (needs to be created, some can be pulled from item 2),

2) Protocol Analysis (started, some effort to go),

3) Architecture Framework (started, likely needs re-alignment and collation into single document).

Noted that it is perfectly acceptable, even desirable, to capture open issues as part of these documents -- points to work items for the WG and shows this is not a "solution looking for rubber stamp approval".

Need specific scope statement! (See next topic.)

Topic 3: Scope of IPA Work

There is a very clear need for a concise scope statement delimiting the work effort. This is likely the most important next step, since this shapes other work items. [PB: Volunteers?]

There is a desire to not limit scope to specific application types (home networking, office appliances, …), keeping it as general as possible, yet there is a strong need also to be able to focus on specific scenarios to provide a clear path to success.

After some discussion, it was generally agreed a suitable approach might be to state scope in general terms but provide example application areas. Some specific application areas discussed included home device networking (nearly all are interested in this one), industrial control (process control, traffic lights, …), office workspace networking. [PB: Note we have also discussed several others on the list and at previous meetings, such as wearable computing, automobile.]

There was rough consensus (to be confirmed or denied) that IP connectivity would be out of scope (e.g. we can simply assume IP layer auto-configuration comes from elsewhere, such as ZeroConf).

Unclear what other common attributes may be acceptable, for example not all IPAs may be "small", or "personal".

Wrap-Up / Remaining Burning Issues

Joerg stated concern of proper understanding of issues around closeness / proximity of device to user and/or control. To put together a contribution to list.

Peter noted we are weak in knowledge on some potentially related work areas (e.g. ZeroConf Networking, IP over BlueTooth, non-IETF consortia efforts). Concern is we will very likely be asked how some of these efforts relate to ours, and why we are both different and necessary, need answers well understood in advance.

--------

Note that we did not have sufficient time for any substantial discussion of technical topics (e.g. Framework and Protocol Analysis works in progress posted prior to meeting). Also, Joerg has noted that MBus should be included in Protocol Analysis document in preparation (e-mail prior to meeting), see draft-kutscher-mbus-ipac-00.txt.

Thanks to all for attendance and participation.

Comments? Corrections? Flames?

-- Peter Blatherwick