Minutes of the joint EMANICS / IRTF-NMRG Workshop on Future Direction of Network and Service Management Research 19-20 October 2006, Utrecht, The Netherlands Organized by Aiko Pras [UT] and Juergen Schoenwaelder [IUB] and hosted by SURFnet, the operator of the Dutch research network. Notes and minutes by Juergen Schoenwaelder with the help of Olivier Festor, David Harrington, and Simon Leinen. 0. Participants 1. Claudio Bartolini (HP) 2. Mark Burgess (University College Oslo) 3. Prosper Chemouil (Orange France Telecom) 4. Petre Dini (Cisco Systems) 5. Liam Fallon (Ericsson) 6. Olivier Festor (LORIA - INRIA Lorraine) 7. David Harrington (Huawei) 8. James Won-Ki Hong (Pohang University of Science and Technology) 9. Simon Leinen (Switch - Swiss Education and Research Network) 10. Giorgio Nunzi (NEC Network Labs) 11. Gregorio Martinez Perez (University of Murcia) 12. Aiko Pras (University of Twente) 13. Danny Raz (Technion) 14. Dan Romascanu (Avaya) 15. Juergen Schoenwaelder (International University Bremen) 16. Rolf Stadler (KTH) 17. Burkhard Stiller (University Zurich) 18. Jean Theunissen (Tiscali) 19. Bert Wijnen (Lucent) 20. Jae-Hyoung Yoo (Korea Telecom) 1. Presentation / Discussion of Position Statements (first day) 1.1. Claudio Bartolini (HP) * Understanding of the business relationship of management; how do IT management processes best support business objectives? * IT systems running properly does not imply that business is running well. More detailed list on the position statement * Formalized SLAs are essential 1.2. Mark Burgess (University College Oslo) * Centralization is a myths * Economics of networks must be understood (not only money, but also social currencies) * Convergent change management for arbitrary languages (how to edit config files in different languages in a converging way) 1.3. Prosper Chemouil (Orange France Telecom) * Reduction of OPEX through agile management (focus on human costs associated with trouble shooting and deployment and maintenance) * Interoperability required internally and between operators * Tradeoff between flexibility and usage/costs * Scalability is a key issue (also in the light of a growing number of technologies/services) * Automation essential, hope that autonomic systems will help * Trust / security is a crucial competitive factor * Started with different NOCs for different services distributed (!) in France, now in the process of centralizing the NOCs; mostly separate network management systems for different services, a single integrated system is not expected any time soon * Most people are technicians but not all are experts in all areas BW: Consolidation leads to single points of failure; subject experts need different human interfaces to work with 1.4. Petre Dini (Cisco Systems) * What is research? * Is research a solution you know and you look for a problem? * Is research a problem where we do not really know what is the right solution? * Need to focus to reach critical masses in order to achieve something that is lasting (teams of three people are just to small) * Questions whether EU funded research has been successful in terms of deployment. Many isolated results only. * Service competition leads to feature interactions and policy conflicts (though similar, each topic treated by separate research communities which like to ignore each other) * We do not capitalize the work that has been done * Real research topics: anticipative research, 8 different formats for syslog timestamps in some product lines of some vendors, event correlation still an issue * Lack of methodology. * What is missing in a device to help resolve service composition conflicts? * What is the trade-off between research that is nice to do and the research that has at the end some practical value - it is 20% vs 80%? * Cisco sees research proposals where people have a solution but do not understand the problem * Disconnect between research communities and engineering communities (research sometimes proposes to manage something they do not understand) 1.5. Liam Fallon (Ericsson) * Ericsson is the 6th largest network operator in the world as well as a leading manufacturer of management systems * History: separate specialized networks did have well defined management layers and management was actually simple * Today: many services on a single network which significantly increased the management complexity * Where does management start and end? Should we even consider to manage customer devices? * Still using the 15 year old frameworks to manage networks but networks are not anymore proper layered systems and hence the old frameworks need to change * Management technologies too low-level, protocols come and go, suitable data models are important (too simplistic models do not help, to complex models are too complex) * Future: network management systems are going to be reduced to adapters and intermediation devices * Network management operations across networks are still difficult (think of 10^5 affected devices) * Network management has left childhood, we are in teenager age now * Rethink fundamental concepts, not enough cooperation in the network management communities * Management systems need more horizontal communication, avoid going up/down the management layers whenever possible * Ideally, operators should buy management products because of the offered features that help to operate a network * Pressure: make the network simpler and thereby easier to manage 1.6. Olivier Festor (LORIA - INRIA Lorraine) * Autonomic management is not something new per se, only the fact that things are approached in a more holistic way * Automation is introduced over time, often via specialized protocols; this process has to continue in a fully decentralized way * Need to prove properties like safety, scalability, convergence etc., by means of statistical guarantees * Must be able to track decisions that have been taken in a way operators and customers are able to understand (this brings trust into the management plane) * Research communities do not understand very well the scalability problems associated with network management * Analysis of some 100 papers revealed that only about three papers provide the information necessary to redo experiments * Need to develop standard metrics / benchmarks / testbeds in order to produce comparable results * Increasing lack of access to management data on devices, increasing number of non-standard interfaces * Investigate new forms of management (e.g., distributed data collection and processing) * Worms and bots are perhaps the base technology for future fully distributed management systems (think in totally alternative ways) * Focus on algorithms, not on data structures and protocols * We make the hypothesis that by managing data we will be able to manage behavior. It is not proven that this is a valid hypothesis 1.7. David Harrington (Huawei) * Application of security to network management protocols is not well aligned in various IETF WGs * Not many new contributors in the operations and management area of the IETF * Look at what we did right, take that forward * Suggestion to further develop the RFC 3411 architecture, to broaden it scope and to cover multiple management protocols * Abandon some of the old myths like "SNMP has to work if the network does not work" * How can we deal with the 90% cases effectively and put the burden on the 10% cases? Suggests a pragmatic approach to take decisions to cover the 90% cases * An integrating architecture is outside of what the IETF can do; perhaps the NMRG can do that? 1.8. James Won-Ki Hong (Pohang University of Science and Technology) * Trying to understand what 4G operations and management is all about * Trying to apply autonomic ideas to 4G management * Converged all IP networks project related to planning * Work on terminal management aspect and self-configuration * Handover management between many different technologies (WLAN, WiBro, WCDMA, ...) * Network must provide information to help the device make the right handover decisions in terms or QoS, pricing, ... 1.9. Simon Leinen (Switch - Swiss Education and Research Network) * Simon lives in a simple world (basic IP service only) * Insourcing lower layer technology introduces new challenges but also simplifies trouble shooting * Switch is doing quite a bit of accounting while Surfnet basically runs on a flat fee model * Handling the input from several independent management systems is a more concrete problem * Cross-domain management data exchange is important for IP services * Involvement in a European project where they do inter-domain information exchange * Why are people not using the technologies we already have? 1.10. Giorgio Nunzi (NEC Network Labs) * Working on self configuration technologies * Need to create a bridge between classic centralized and modern fully distributed approaches * The google-like approach: make it simple from the usage interface 1.11. Gregorio Martinez Perez (University of Murcia) * Need to work on the semantics (ontologies, first order logics) in order to be able to reason about data * Working on conflict analysis, security, pro-active monitoring, critical information systems (dependability and resilience), self-management (bio-inspired systems) * Who is going to use ontologies? Trying to make it easy by hiding the details in the background. * Distinguish between those who have to be clueful to put things into the system and those who can be less clueful and operate the network 1.12. Aiko Pras (University of Twente) * Research should focus on dependability (instead of FCAPS) * Users want predictability of provided services * Researchers must talk more to operators (PhD students often have no clue how real networks operate) * Avoid deep research on very detailed topics that are largely irrelevant * Need to manage our management process; remove unused stuff and better document what is actually useful * There are well established definitions of "dependability" - not sure this is really what we are talking about here 1.13. Danny Raz (Technion) * What is management? We do not agree on a single definition * Management deals with the grey area at the boundary of the system * Find the optimal point between management collection and the impact on the actual service * The term "disappearing management" is owned by Olivier Festor * Traditionally networks were engineered to a certain load * Marks says that most monitoring graphs are useless; it is a human factor that people like these graphs; it does not help to detect problems * Petre thinks that these graphs may be mainly for VPs (to justify management costs) 1.14. Dan Romascanu (Avaya) * Dan sees a lack of IDs produced by the NMRG and outcomes of discussions are lost; make things more visible in the IETF style * Need for guidance in many areas in the IETF; lots of operations and management activities now going on in other areas in the IETF * Classic but still important area in the IETF concerns management data transport and data modeling * Believes that the document which defines data and information models (RFC3444) was an important contribution of the NMRG * Many specific data modeling activities in many WGs in the IETF; leads of duplication of work, redundancy and inconsistencies; the NMRG might help in this area in terms of language or basic modeling approaches and constructs * NMRG may help to at least formulate a position * Why did SMIng fail in the IETF? Dan thinks SMIng did not really fail on technical grounds and also not on process grounds but because the industry did not expect such a language to come from the NMRG * Perhaps start with a position on the format of next generation data modeling languages * JS comments that in retrospect bringing SMIGng into the IETF was a mistake; we should have published experimental out of the NMRG and put our focus on tools and running code * Like to see more dialog between the research community and the IETF 1.15. Juergen Schoenwaelder (International University Bremen) * Research Questions: - Configuration is too ad-hoc; lack of engineered approaches to run networks; lack of best practices rules - Event correlation is an old topic in the research community but with the increase of data still not a solved problem - Import good ideas from the distributed _algorithms_ communities (but do not reinvent from scratch) - Security and trust management - Understand how real networks behave, develop models, use the models to make comparable research * Enabling Research - expects money for networking research to decrease (while money for life sciences will increase) - expect more competition for funds and less students - only research areas which are well defined and which have a "face" will survive (we do not have a face, lack of books, lack of agreed achievements, lack of accepted research methodologies, ...) 1.16. Rolf Stadler (KTH) * Goal: scalable, robust management systems with low complexity for large scale, dynamic network environments * change research methodology: more formal methods, more probabilistic functions * overlap with other communities: sensor networks/embedded systems, streaming databases, data mining * consider a network as a distributed processing machine (network as a management computer) * comparison with sensor networking community: (see Rolf's slide) * network management community solves problems similar to the sensor network community however under different constraints * trade-offs between completion time, accuracy, overhead, robustness 1.17. Burkhard Stiller (University Zurich) * Is there a chance to asses distributed systems with a "currency"? * Pre-paid schemes are interesting; developed a time based charging algorithm * Economic transaction support is related to business models; still mechanisms can be provided to service providers with open interfaces * Service bundles, automated provisioning following charging models, operational across domains * To what extend are services bundled with content and should things be treated as a bundle or as separate things? 1.18. Jean Theunissen (Tiscali) * Tried zero-touch ordering systems (completely automated) - reached in one year. * Zero-touch provisioning with command line interface automatization build from scratch (commercial tools did not help) * Transition from ATM DSLAM to Ethernet DSLAM, required to build own tools to switch / provision (based on CLI) (again no commercial tools) * What the operator needed could not be bought (or commercial solutions are way overpriced for what they are capable to do) * What is needed: DSLAM interfaces where behaviors are published through web services * Real problem is the changes in interfaces (especially CLIs) * Operators are able to build their own management systems; they just need good interfaces * Q: Why is versioning easier with WSDL? To what extend is this a property of the interface? A: If you use WSDL within the management system, the problem is at least well understood * Failed management transactions that leave devices in some arbitrary non-operational state is a common source of customer bug reports * No interest in running code on the device itself; interfaces only needed for basic actions ("atoms"); vendors understand their devices better than operators - so leave the devices to the vendors * Generic management platforms are becoming irrelevant since networks are very different in terms of services and procedures these days * Perhaps .NET is as much of a management framework as Tivoli * Invitation: send students to operators (but not PhD students!?) 1.19. Bert Wijnen (Lucent) * There is a lack of women in network management research * Stop adding new paradigms since none of the old ones goes away * Research on existing technology is not sexy; researcher seem to prefer hype things and then run away quickly * Even worse, research and the need to demonstrate impact can block good progress in non-research organizations; focusing and reaching critical mass seems to not align with how funding systems work * Duplication in terms of multiple solutions to the same problem is an issue since researchers (in particular from commercial research organizations) push things into standards bodies * Doubts about confederation / harmonization of information models (bowls of spaghetti bowls) * Dave Harrington says that vendors use standard bodies these days to push IPR into standards and subsequently make money out of licenses; even in the IETF this has become more acceptable lately 1.20. Jae-Hyoung Yoo (Korea Telecom) * Too many systems, automation of work flows is needed * Problem: running out of IP addresses due to mis-behaving customer networks; field engineers have to deal with many different CLIs (they actually take many heavy manuals to their field trips); analysis of the CLI command output often manual (and time consuming) * Service interactions difficult to handle, tools missing * Trying work-flow engines; must make sure to keep flexibility * Don't confuse dream with the real world 2. Operator Break-out Session - Prosper Chemouil (Orange France Telecom) - Simon Leinen (Switch - Swiss Education and Research Network) - Jae-Hyoung Yoo (Korea Telecom) - Aiko Pras (University of Twente) - James Won-Ki Hong (Pohang University of Science and Technology) O1: Is there a future for general purpose management platforms, like OpenView, or will operators primarily rely on home-baked scripts? If the later, are there any reusable building blocks missing that can reduce the costs of the in-house development of management systems? Management platforms exist even at large operators (OpenView) - platforms useful for smaller networks - used as EMS, not general NMS - some operators build tools on top of them But "custom" tools are vital, - both internally written and contracted - both small (scripts) and large systems Open-source tools used: - Cricket / MRTG - CMU/UCD/Net-SNMP - RANCID - NMIS Wishlist: - for tool/script development: ORM for SNMP (like Ruby on Rails' ActiveRecord for SQL) - real-time network simulator - platforms that are designed for extensibility/evolution more than adaptation to network and customization O2: What are the major differences between network management and service management? Are there other different types of management? [TMN]: Service management includes functions such as service order handling, service trouble ticketing, Service management -> interface to customer Network management -> interface to devices (Larger) operators have these as separate groups and feel they have the right level of interaction between them. Business management - customer contact point systems - customer relationship management (Organizational) knowledge management O3: It is more than 20 years ago that FCAPS have been defined as the five main management areas. Does this still hold, are some areas outdated or do we need to add others? The five areas Fault, Configuration, Accounting, Performance, and Security are still considered important. management plane -> control plane diagnosis function between these two -> management plane has to be extended towards control plane performance management is still important - during unexpected events - for SLA validation - less for daily optimization accounting is still important, although less than it used to be - mobile services - telephony - less for normal Internet service security has become even more important. Jae-Hyoung agrees with Rolf Stadler's suggestion that the management plane should be split in two. [Ed. not sure which ones] O4: How much research is needed on (a) the integration of network and service management with business processes and goals and (b) the costs / benefit analysis of network and service management? And who is qualified to do this kind of research? (a) Definitely interesting. Probably more a MIS/business problem. (b) Not (core) computer science work. O5: How much is network/service management a factor of competition between operators? Is knowledge about how you run a network or provide a service a business secret? Do you expect to change this over the next five years? very important for differentiation - quick, reliable service - Korea: one-day provisioning of broadband connections (one week in the remote mountain areas) important to be able to show that they control things - transparency secrecy - very important for commercial operators with respect to competitors ("showroom" for visitors, real operations hidden) - for researchers: KT more open, FT only for contractors - difficult to get information such as traces (even internally!) - privacy legislation usually given as reason not to distribute data (often more a corporate policy issue) - research networks are more open O6: Is research needed to improve the human interface of management systems (e.g., visualization techniques)? definately yes! O7: How can the research community evaluate whether novel ideas and approaches work in practice? Difficult for high-level ideas that researchers cannot implement; implementations aren't highly recognized [[[ At this point we ran out of time. Sorry! ]]] O8: How do you monitor research and capitalize research results? O9: Where does management start and end? Should we even consider to manage customer devices (terminals)? O10: From an OPEX perspective, what are the three most important research questions to be addressed in the next five years? O11: Is "self-x" desirable in practice from the network manager's point of view? - self-configuration of control by customers service profiles (e.g. bandwidth, voice mail forwarding) - self-discovery or resources by OSS - self-diagnosis - self-healing "Self-x" just a buzzword for management automation? Restricting general appeal of self-management features: - lack of trust in implementation of features in network devices - need for manual intervention if something goes wrong. 3. Vendor Breakout Session - Claudio Bartolini - Petre Dini - Liam Fallon - Dan Romascanu - David Harrington - Giorgio Nunzi - Bert Wijnen - Juergen Schoenwaelder V1: Is research still needed on new technologies to transport management information, or can we rely on generic protocols and middleware technologies (such as Corba, Java, Web Services etc) to transfer such information. If research is still needed, what are the specific problems these new technologies have to solve? It is important to distinguish between "vertical" management protocols and "horizontal" management protocols. Dan did the following drawing: NMS -------- NMS | | EM +--+-EM--+ | | | | | E--E---E--E--E--E It was mentioned that there is a need for a taxonomy and a definition of general concepts. People re-invent management protocols and by documenting the experience in this area ("network management protocol design pattern"), it might be possible to reduce repeated failures. It was also mentioned that it is difficult to have an overview what is actually already available. V2: Is research still needed on languages for data models and/or information models, or research on core data / information models? If yes, what are the specific problems that need to be solved? While machine readability of data models is considered important, this seems to be much less important for information models. It was questioned whether universal information models are achievable or needed. It was stated that formalization must enable to drive tools, otherwise formalization does not help much. It was noted that academics like to do new languages but languages alone are not useful. Finally, it was noted that top-down modeling approaches don't work well across vendors and are also difficult across product groups. V3: Is the current approach where devices have hundreds of MIB modules and many thousands of MIB objects, the right one, or do we need something else? If yes, which approaches are considered promising (programmable devices, high-level network element management functions integrated on devices, document-oriented approaches, ...)? Standard MIBs are agreed upon, but they are not implemented throughout the product, or across product lines, and are not implemented accurately. Achieving uniform implementations of managed objects across a large product base is difficult to achieve. There is little published info about what functionality is actually enabled when a specific MIB is implemented. It is very unclear what functionality applications will provide if a given MIB is available. For vendors, it is kind of difficult to find out which objects are highly relevant and should be implemented. (It was later noted that vendors maintain list of "important" objects and they usually consider these lists a business secret.) It was noted that some vendors seem to strongly dislike operators putting their own software on network elements (since this makes support much more complex). V4: What is needed to make a system manageable? What is in particular difficult or expensive from a device / system vendor point of view? Making a _device_ manageable is very different from making a _system_ manageable. The later requires at least a book to be written while the former is more feasible to address. It was noted that services drive the requirements for EMs and are difficult to anticipate. Discussion about manageability requirements for protocols just started in the IETF. Some practical issues were discussed such as requirements for synchronized clocks, test functions, auditing functions, state reporting functions, ... V5: How do you monitor research and capitalize research results? A popular method is to acquire startups, that is wait until research ideas have been developed close to product quality and then buy the company. Other companies look out for famous people which bring prestige once hired. Research done within companies is measured in terms of patents and to a lesser extend in terms of published papers. It was noted that research has become too commercial. Research is driven by need for funds and focused on short term achievements. V6: Is probabilistic management feasible? Not discussed. V7: What SLA related research is needed? Do we need them and for what? Not discussed. V8: What are the three most important research questions to be addressed in the next five years from a vendor perspective? Access control in the OAM space is "unorganized" and not well understood (in the broad sense, includes auditing features). In general, there is interest which helps to reduce costs and identifies or even leads to new markets. It was noted that from a vendor perspective, research is an appendix for exploring things outside the core competitive core. 4. Researcher Break-out Session - Mark Burgess (University College Oslo - Olivier Festor (LORIA - INRIA Lorraine) - Gregorio Martinez Perez (University of Murcia) - Danny Raz (Technion) - Rolf Stadler (KTH) - Burkhard Stiller (University Zurich) R1: What have been the most important past achievements in network and service management ? In the late 80s, early 90s: - definition of a set of models everybody did follow. - separation of data modeling from the protocol that transports it - manager/agent models - TMN layering Policy-based management paradigm Programmable control & management planes (TINA-C in the 90s, P1520 in the 2000s, active nets ...) What have been some failures - we still have no clear understanding of the scope of management - to focus too much on the way data is transported and entities are organized than on the algorithms that have to process this data - attract a critical mass R2: What are the (network and service management) research topics that most Ph.D. students focus on today? - XY-management and X-based management; the next generation management middleware X applied to network technology Y - aspects of distributed management We observe an increase in the modeling (formal abstractions) activity in the community which is very encouraging R3: Is management of networks similar to the management of services / systems / applications? If not, what makes these things fundamentally different? Network and service management are similar, but not identical. The same principles are applicable. The constraints are, however, different (e.g., load balancing in the network vs. load balancing in systems) which leads to different solutions. R4: Is research needed to introduce metrics that can quantify the effectiveness of network and service management processes? YES, measure cost vs. gain. R5: How can we improve the way we do research in the network and service management area? Do we need more collaboration and interaction of people? Do we need to improve the education to better prepare students for research in this area? The community should be better structured around the poles to ease or improve cooperation. Preparing students on fundamentals is important; A summer school would be something very good. Collaboration is nice but is harder to achieve. Collaboration would be much easier if we would address fewer more precise and well identified problems. A clear pole are policies, are there others? - distributed vs. centralized monitoring - obligation vs. voluntary cooperation - deterministic vs. probabilistic mgmt R6: Should we research problems instead of engineering solutions? Yes but we need both. [It was later correctly noted that the question was not well phrased and ambiguous.] R7: Is research of the type "how to apply technology X to management" still relevant? Do we need to agree on evaluation criteria to deal with this type of "soft" research? Yes as long as X changes fast enough to write a paper every 2 years :-) Seriously, such technology-oriented incremental research remains relevant if the application scenario is valid and results are comparable. R8: Is monitoring still a research area? What are the unsolved questions? Yes, monitoring is still an active research area : - very high speed monitoring (adaptive, real-time) - aggregation of distributed data - accuracy, synchronization, uncertainty R9: What are the three fundamental research questions to be addressed during the next five years? See above the monitoring problems Modeling of behaviors / events of abnormal conditions (e.g. virus infection events, coupled with propagation models, ....), reactions. (anomaly detection), definition of a healthy, unhealthy state. Investigate probabilistic approaches for management: - output of management functions (probabilistic SLA, management decisions provide solutions with statistical guarantees) - uncertainty in input (do not rely on the assumption that everything is deterministic and that the manager has a permanent view of all data he wants (management data can be wrong, devices can cheat, connectivity may be intermittent) - evaluation probabilistic vs deterministic. Abstraction/aggregation algorithms that can deal with large volumes of management data and that hide complexity without loosing semantics of captured data Investigate fully distributed approaches to network management (auto-configuration, self....) And what are the three "soft" research questions (easy to get funding, low-risk of failure type of research, easy to recruit the right people) that we will see addressed during the next five years? - X-based management (the next generation management middleware, whatever X comes out in the next) - The "S" in FCAPS; Self-adaptive secure management. Many programs currently provide funding for security related research, but this does not mean security is a simple problem. 5. Summary After the discussion of the results produced during the break-out sessions, an attempt was made to identify research areas and to agree about their relevance. It turned out that finding agreement on the importance of topics was still difficult and hence topics appear below in the order they were discussed (no implied rating) (1) More research needed on monitoring (scalability, accuracy, correlation, interpretation, statistical approaches, inconsistent data) (2) Research is needed on anomaly detection (modeling of behaviors / events of abnormal conditions (e.g. virus infection events, coupled with propagation models, ....), reactions, definition of a healthy, unhealthy state) (3) Research is needed on understanding what modeling of behavior means. Reproducable and/or stabelizing behavior was considered important (even though a precise definition of the terms could not be found). Some questions raised during the discussion were: - How to design systems that exhibit reproducable behavior? - How to specify behaviors - How to encourage implementation of similar behaviors (4) Research is needed to investigate probabilistic approaches for management: - uncertainty in management goals (probabilistic SLA, management decisions provide solutions with statistical guarantees) - uncertainty in input (do not rely on the assumption that everything is deterministic and that the manager has a permanent view of all data he wants - how to decide between probabilistic and deterministic approaches (5) Research is needed on abstraction/aggregation algorithms that can deal with large volumes of management data (Ed. note: this seems to overlap with (1) above) (6) Research is needed on data presentation mechanisms that hide complexity without losing semantics of data (7) Research is needed to investigate fully distributed approaches (since we are in the P2P age ;-). Investigate the relationships between centralized and fully distributed approaches. (8) Research is needed on self-* technologies for network management (auto-configuration, ...). (Note that self* does not necessarily imply distribution nor does distribution imply self* properties.) Investigate how self-* mechanisms differ from traditional approaches for automation, control loops, ... (9) Research is needed on access control in the OAM space since it is "unorganized" and not well understood (access control used in the broad sense, includes auditing features) The meeting was closed without being able to go through all the items mentioned during the meeting and as such the above list is a first draft of ideas and as such is likely to be incomplete, missing orthogonality, and to some extend fuzzy. 6. Action Items - JS will compile the meeting minutes - JS will collect the slides to link them to the meeting web page - We agreed to document insights gained during this workshop in an ID (need to think about the structure and scope) [JS,AP,SL,DR] - We agreed to work on a Communications Magazine article [JS,AP,BS,JH,GN,GM,JY] - Mark Burgess will integrate some ideas in the editorial of his handbook