Extensible Supply-chain Discovery Service (ESDS) BOF Minutes Meeting : IETF 71, Monday, March 10, 2008 Location : Marriott Philadelphia Downtown, Salon I , 13:00-15:00 Chairs : Ted Hardie Mark Harrison Minutes : Elaine Chin version: 1.0 ================================================================== AGENDA 1. Agenda Bashing ( Mark Harrison ) [5 min] 2. Introduction to concept ( Mark Harrison ) [15 min] - Questions regarding clarification [15 min] 3. Review of Problem Statement ( Michael Young ) [10 min] - Questions regarding clarification [10 min] 4. Expectations of deliverables ( Mark Harrison ) [15 min] - Questions regarding clarification [15 min] 5. Scope of work ( Mark Harrison ) [10 min] - Comments [15 min] 6. Next Steps and Action Items [10 min] =================================================================== MEETING Report 1. Agenda Bashing (Mark Harrison) (5 min) * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt Ted Hardie welcomed attendees and did introduction of Chairs, followed by meeting administrivia: Elaine Chin volunteered as scribe. Stephen van Egmond volunteered as jabber scribe. Mark Harrison displayed the agenda (Slide 3) and reviewed the scope of discussion (Slide 4). No items were added to the existing agenda. 2. Introduction to concept ( Mark Harrison ) [15 min] * draft-young-esds-concepts-03.txt * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt Mark provided a conceptual overview of the role of Discovery Services (DS) by walking through a food traceability scenario which followed a cow through the supply chain from farm to retailer (Slides 5,6). He showed how Discovery Services enable end-to-end traceability by providing links or referrals to providers of product information along this chain of custody. He emphasized that Discovery Services do not store detailed information; they point to where you can find it. He also pointed out that Discovery Services differ from public search engines in that Discovery Services will normally enforce access control policies restricting who can access information. Next Mark reviewed current business drivers resulting from the increased adoption of automatic identification technologies (e.g. RFID, 2D Barcodes). These drivers include improved traceability, more efficient data sharing and improved supply chain efficiency through the exchange of serial level information. (Slide 7). He talked about how DS also enables the improved gathering of life cycle information history, which allows companies to make better decisions on how to remanufacture or extract residual value from products. The latter is of interest to organizations like PROMISE. From a technical perspective, he showed the role of Discovery Services in relationship to existing network stacks and architecture frameworks (Slide 8), such as those using EPCglobal standard interfaces (E.g. EPCIS, ALE). The focus of ESDS within IETF would be a technical protocol centered on 3 aspects: a Query protocol, a Publish Protocol and a Bootstrapping protocol. The ESDS group has worked with EPCglobal and is hoping to complement its efforts by feeding the work done by the IETF community into future EPCglobal standards. He then outlined what's different about Discovery Services (Slide 9), highlighting the focus on being lightweight referral services that scale, and are able to store changes of identifier mappings (e.g. upon aggregation, disaggregation or relabelling). He also talked about the challenges needing to be addressed (Slide 10), such as the scalability of access control permissions. A diagram (Slide 11) was then shown outlining the interaction between companies representing a client application (Q), an information provider resource (R), and one or more Discovery Services (D,E,F). To better illustrate that D, E, and F all represent Discovery Services, they were renamed as follows: D=D1,F=D2,E=D3. R has stored event information about an object with ID=X. R can publish records (or events) to one or more Discovery Services so that those Discovery Services can link back to R as an information provider for object with ID X. Note that it does not need to publish all of its detailed events about object X - it is sufficient to just publish a single record to say that at some time it collected information about object X. At the same time, companies such as R will probably also specify access control policies to protect the DS records they post from viewing by unauthorized users. Q can query a Discovery Service to ask who has information about object R. If the Discovery Service directly queried by Q has this information and if Q is authorized to see it, the Discovery Service can respond to Q with information that contains a URL link to R. Q can then contact R directly to request detailed event information. This direct interaction between Q and R would be out of scope for Discovery Services - and something that could be handled by a standard interface dealing with querying of serial-level event data, such as the EPCglobal EPC Information Services (EPCIS) query interface that is already defined and ratified. If Q contacts a Discovery Service that has no knowledge about object X, Q could try making a different kind of query via the Discovery Service it usually contacts. This different kind of query is a query across a federation of Discovery Services that know of each other's existence but do not exchange or mirror records. This would allow another Discovery Service within the federation to identify itself if it held information about object X. Q could then contact that alternative Discovery Service to request referral information. These companies could also define access control policies to control the extent of information sharing. This diagram was referred to often in the course of discussion.. It was made clear that the direct interaction between Q and R would be out of scope for Discovery Services, and something that would be handled by a standard interface dealing with query content (e.g. EPCIS). - Questions regarding clarification [15 min] * Appendix A: Detailed Discussion Notes Eric Rescorla wanted to better understand a) the business relationships among partners in the diagram (Slide 11). Had concerns about b) whether DS would enforce a business relationship c) in scope and out of scope boundaries e.g. with respect to information content. Mark: a) Answer is it depends. The DS shown may be independent of each other but have some sort of federation. b) No c) We are not dealing with a data model or the interfaces to the database, which is already addressed by interface standards such as EPCIS. Margaret Wasserman: Need to understand who the players are, what data they have. Defining that defines the problem. The problem statement is too weak on what is the real interesting problem trying to solve. Need to make it more clear in the documents what you are trying to solve. A few speakers commented on leveraging existing protocols and open source implementations, as well as work done previously such as the TISDAG project(distributed whois directory), which are described in the RFC archives. Kurt wanted to understand the scope of communications being handled. Mark outlined the 3 protocols ESDS hopes to develop: publish, query and bootstrapping. Phillip Hallam-Baker raised point about too often trying to solve for a specific application and not abstracting to a generic. Thinks a focus on architecture still has value, but is opposed to architectural thinking divorced from a use case. Dave Crocker: Don't have a track record in IETF of solving this category problem in terms of large scale global activity with the exception of DNS. Not in a position yet to say there's a solution that exists because can't understand the problem statement yet. Thinks we need an IETF process, possibly a requirements group, to get to the point of specifying protocol or protocol choices. One speaker wanted to know the current status of solution with respect to IP protocols. Mark replied that the object itself may not have a network interface as such. Communication often involves talking to an agent or information service representing that object. (e.g. Database records). 3. Review of Problem Statement ( Michael Young ) [10 min] * draft-rezafard-esds-problem-statement-01.txt * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt Mike asked for a show of hands how many had read the Problem Statement. Approximately 45%, or 30 people raised their hands. By way of addressing some of the "sore points" that might arise from the Problem Statement re: who will contribute to this effort, etc., he showed a list of organizations including EPCglobal (Slide 14) who represent both contributors and users defining requirements. To explain "Why the IETF" (Slide 15), Mike talked about challenges that IETF, based on its expertise and lessons learned, could help solve, such as the complexity of the bootstrapping process and scaling to global operations. To answer the question "What does this work enable?" (Slide 16), Mike talked about the importance of point-to-point communications and real world needs, such as an audit trail for safety-critical products, counterfeit product detection and support for product recalls. Cited a Pfizer recall example where Pfizer received back 2.5 times as much product as was shipped due to lack of accurate track and trace capabilities in the distribution network, and lack of visibility by the manufacturer and retailer into that network. Mike spoke to the driving forces behind Discovery Services (Slide 17), including fraud protection for consumables like drugs or food products. He also talked about how multiple circles of relationships and increased demand for security necessitates having multiple Discovery Services vs having one global Discovery Service. - Questions regarding clarification [10 min] * Appendix A: Detailed Discussion Notes A number of questions arose after Slide 16: Speaker at mic: How many different organizations are contacted to get this information? Is there an automated way of doing this? Where does this scale today? i.e. How many actors do you imagine being involved in a product's life cycle? Mike: On a given object may have 20 or more organizations. Mark: the Bridge project has seen up to 50. Margaret Wasserman: That's for a serialized item. If you want to find all of the Tylenol manufactured in the last 2 months it could be a very large number. 4. Expectations of deliverables ( Mark Harrison ) [15 min] * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt Mark reviewed expectations of what Discovery Services will provide, derived from user requirements for the BRIDGE project. He provided a brief history of BRIDGE. In terms of functionality required, he mentioned how DS enables object tracking, forecasting, and alerting on misplaced ids by providing links to sources of information that need to be checked. Other requirements around support for standing queries and provisioning were also discussed (Slide 20). Technical expectations were covered next (Slides 21,22). Primarily referral URLs and possibly some meta data for defining access control policies. Other expectations included the need to support scalability that might involve billions of events/year, support for synchronous and asynchronous responses, full trace query, journal logging and creation of a voiding policy. The slide provides a link to a Bridge website for more details. - Questions regarding clarification [15 min] * Appendix A: Detailed Discussion Notes A number of questions were posed after Slide 21: One speaker made the point that if the assumption is that DS is a simpler model than distributed directory services because it is only dealing with referrals, this is a mistake. Feels DS will have problem of modelling and matching rules. Mark agreed that a simple data model doesn't make it less complex to solve. Phillip Hallam-Baker: The reason most directory projects fail is because the content isn't there to look up in the directory. Should recognize that this is an IETF proposal to take on part of the technical work going on in EPCglobal. If we do the work for EPCglobal they will either use it or if not completed in time, do the work on their own. Questions after slide 22: Andrew Sullivan: Because you are dealing with distributed meta data - makes it more complicated because you have a vocabulary of meta data spread out .i.e. Have a directory of directories problem plus problems of directory issue itself. Wondered if we should go back and use the DNS model in ONS even if you are going back to one source. Margaret Wasserman: To Phillip's point re: EPCglobal - Work at present in EPCglobal is requirements gathering only. The hope is that their work would feed into this group with a technical protocol done in this body. There is no technical work being done at EPCglobal in this area. Ted: From a process perspective it's not a global distributed directory problem. Real question is "What does it take to make this a manageable chunk of work? 5. Scope of work ( Mark Harrison ) [10 min] * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt Mark read the ESDS Charter and the Scope of Discovery Services (Slides 24,25)and indicated he would like consensus on the BOF questions (Slide 26): 1) Is this an interesting problem to tackle? 2) Is the scope of work appropriate to the problem? 3) Is there support to form a work group with the following charter? (i.e. that the charter itself is ready and supported by the community) 4) Can I ask for a show of hands for who is willing to review documents? 5) Do we have any additional volunteers as an editor for some of the document(s) to be produced by the work group? - Comments [15 min] Leslie Daigle: I do think its an interesting problem to tackle. Some similarities to the whois service problem where have some entities notionally working together and problems in establishing a shared context. Not a global directory services problem. Eric Rescorla is unclear what it is we are trying to achieve. Had a lengthy exchange around the nature of the business relationships (e.g. D1 and D2) represented in diagram on Slide 11 leading to the topic of how does one become a DS and how do you stop malfeasance in a single large circle of trust if you assume that an access control problem will be handled by non-technical measures? Problem with the security model is that everyone is in trust boundary. There's limited access control. Margaret Wasserman: Comment on Eric's question. Not sure this is a solvable problem. One of the answers is that R tells us the level of security of information allowed (which Qs are allowed to see it, which D2s are allowed to expose itself to). Eric Rescorla: I don't understand how only certain Ds can see it, because all Ds are identical. Margaret Wasserman: We don't have a strawman proposal for this. A particular group will contract to provide their Discovery services. Margaret used an example where D1, D2 and D3 could cover different industry sectors that do not intersect. R. has to say whether it's sensitive information or not. Answers to BOF questions: 1. Yes interesting problem to solve. Need to define problem better within IETF context before can charter work group on a solution. 2. Don't get the sense of the scope of work. Charter needs some work to be done about what work items are to come out. 3. Charter needs to be more complete. 4. She's willing to review documents, she would help with document producing. 5. She supports the effort but feels it needs more work to be a well defined IETF Working Group. Michael Richardson: Answers to BOF questions 1. Yes, interesting problem to tackle. Lessons from DNS sec space who has been through this valuable to review. 3. Charter has to say specifically what kinds of ACLs are necessary and what kinds of privacy and security are relevant because it changes scope of solution. For this to be useful the problem and scope will have to defeat the assumption that all D1s are at the same security level. Speaker at mic: Agrees it's an interesting problem and support the effort, but wanted to know what is the consideration for Discovery Services under multiple standards, such as those to be built by China, Korea, that are independent of existing standards (e.g. EPCglobal)? Mark replied DS is completely agnostic. Points a URL to something which hopefully has a standard protocol. Andrew Sullivan: 1. thinks it's interesting to tackle 3. Concerned over scope of charter - Is this a global directory problem? Whether it's a global supply chain or not, make it clear in the charter. 5. He is willing to contribute. Phillip Hallam-Baker: Answers to BOF questions 1. Yes interesting problem to tackle. Many interesting problems to tackle. The real questions are 6. Will we be able to solve it? 7. Is the world going to care if we do? Re: access control, thinks it's an accountability based control not an access control. Dave Crocker: Instead of a requirements group, let's call this a service specification. Benefit is that there are real world needs. If you have someone with the need, it constrains and motivates the service specification. Leslie Daigle agreed largely with Dave. Emphasized need to express it in IETF space. Important to look at it architecturally but has to be driven by actual requirements that exist. Eric Rescorla agreed needs to be driven by actual requirements but is fuzzy about what they are. Not crisp enough For IETF to charter. Brian had some questions back to diagram on Slide 11 about who needs to know what and how they find that. Some key or index serving as starting point for query? Mark: EPC identifiers are structured identifiers - so it is possible to use patterns and ranges for indexing. However, there may be a case for supporting unstructured/opaque identifiers. Speaker at mic: Back to Slide 11 - What kinds of information should information provider R provide to D? Does D have some information first from R? Mark: If Q is in a relationship with D1 it might not need to go through the federated D1 to find link information for R. Re: protecting the information, have to have some way about restricting who will have access to that. R may not publish to a Discovery Services unless legislation might require it to do so. Same speaker at mic: What is published to D? Mark: mainly the URL for R. Speaker supports the ESDS effort. 6. Next Steps and Action Items [10 min] Ted observed that at this point, he has seen some interest. Asked for a show of hands of those who agreed with BOF Question 1. but were not ready for agreement on a BOF charter today. No one disagreed that this is an interesting problem to tackle or that there needs to be work done (e.g. On the charter) before a working group is ready to be formed. He asked who were willing to work on the charter between now and the Dublin IETF. About 20 raised their hands. Ted indicated there are two ways to move forward: Have a second BOF in Dublin or request an IETF study group. There are a maximum of two BOFs allowed. You don't have to wait for a second BOF, if you form a Working Group in the meantime. The move to a study group is an important step. The benefit of this move is some scoping according to a charter. Ted: Does anyone here believe there's a difference between staying as a BOF or becoming an IESG study group? Margaret Wasserman: Haven't done enough yet to form a study group charter. Maybe having a study group will come out of the next IETF. Could aim for a working group but have a study group come out of it. Ted asked if anyone thought this work didn't need to be done? No hands went up. He then asked for a show of hands if you think this work belongs in the IETF. Approximately 30 hands in the room were raised. Phillip Hallam-Baker: All we can ask at this point is if anyone thinks this doesn't belong in the IETF. Ted summarized the next steps in terms of Action Items as follows: Action Items: Those interested should join the mailing list. Work to be done on technical documents to be more IETF-like Refine the charter Aim to form a working group before Dublin. If not possible, consult with Lisa Dusseault and IESG on whether to form a study group or have a second BOF in Dublin. Strong sense of the room in continuing the effort within IETF and a strong sense that there is a need for work on next set of steps before proceeding. Participants were invited to a Beer BOF that evening at McGillans. The session was attended by approximately 65 people, and there was a high level of engagement and participation. Appendix A Detailed Discussion Notes of Agenda Items: See slides for each section: * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt 1. Agenda Bashing (Mark Harrison) Ted Hardie welcomed attendees to the ESDS BOF and reminded them of the statements in the Note Well, particularly that any statement made within the context of an IETF activity is considered an "IETF contribution". He then did an introduction of the Chairs. Mentioned the ESDS introductory session that morning in the APPs open meeting and asked if there was any Agenda bashing. No items were added. Noted for those listening to audio stream, that the BOF rooms were not set up early enough. Instead they will find a Jabber scribe in APP area room. In terms of meeting administrivia: Elaine Chin volunteered as scribe. Stephen van Egmond volunteered as jabber scribe. Slide 3 - Mark Harrison displayed the agenda briefly before moving to next slide. Slide 4 - Mark reviewed the scope of discussion (see points on the slide). 2. Introduction to concept ( Mark Harrison ) Slide 5 - Mark talked through the example titled "How to chase a bull" which walked through the food traceability scenario following a cow through the supply chain from farm to retailer. In this scenario Discovery Services could perform a one to many mapping of a cow to its various parts after processing. Showed when events might be published at various points in the life cycle e.g. upon being transported to processing plant, or upon shipping to a retailer who can publish an event to say they received the product. The goal is end-to-end traceability. Also used examples of surviving object composition (e.g. assembling a plane or laptop from individual components) or decomposition (breaking a container into pallets, pallkets into cases). Mark made the point that Discovery Services are about enabling traceability and that this slide represented a conceptual overview of how you publish records. Slide 6 - In the reverse scenario, a consumer may want to know where a product has come from. For the traceability scenario discussed on Slide 5, a Discovery Service can answer questions such as "Is my food safe for consumption? Where has it been? How fresh is it?" . Discovery Services could provide links or referrals to this chain of custody. Discovery Services are a referral service. They do not store detailed information; they point to where you can find it and only the information you're allowed to access. It is not a public search engine in that sense. Slide 7 - Mark reviewed current business drivers, such as improved traceability (i.e. things are safe and we know where they come from). Another driver mentioned is improving supply chain efficiency which can be done by enabling the exchange of serial level information. It's about balancing supply and demand using fine-grained data for each individual item. Talked about the trending toward more efficient data sharing e.g machine to machine interfaces via EDI progressing towards web services. Talked about how DS enables improved gathering of life cycle information history. Important for reuse of products at end of life, like refurbished products, allowing for better decisions on how to remanufacture or extract residual value. This is of interest to D. Potter of PROMISE as this is an issue which is of concern to them. Slide 8 - Discovery Services from a technical perspective. Mark explained the EPCglobal network stack and noted that the EPCglobal community has made progress on defining open standard interfaces between these components. e.g. ALE specification is a way to request filtered data, while EPCIS specifies ways to query an individual company for its detailed information including business context. (i.e. answers not only where, what, and when but why). EPCglobal have developed standards based on end user requirements and these are freely downloadable. They have worked with ISO on e.g. GEN 2 air interface standard, embraced by both standards bodies. Discovery Services provides pointers to information services (e.g web services, EPCIS) to find out which organizations have information about an object. Some companies may not use the EPCglobal network framework but have similar architecture stacks, as shown on this slide. The focus of this work is on a technical protocol for Discovery Services. The role of Discovery Services to provide referrals or pointers to the organizations who have information about an individual object. There are 3 aspects focused on by ESDS work: a) Publish protocol (how to get information into DS) b) Query protocol (how to retrieve it) and c) bootstrap protocol which is concerned with how to find relevant DS in the first place. The ESDS group has worked with EPCglobal and is hoping for good collaboration. The IETF community can help solve some of the technical problems and feed into future EPCglobal standards work. Slide 9 - What's different? Not so much concerned about describing a service itself but finding which organizations have information about a unique id. The focus is on a lightweight referral service that provide links to resources.(see points on slide). Can be multiple providers to an organization. One object may be handled by multiple organizations. Many changes can occur in mapping along the supply chain - e.g. cow to various meat products with various ids. Should be able to map changes of links over time. Path an object takes can't be predicted in advance, so need a directory-type referral service to find out where things go over time. Some of the challenges: scalability. There are potentially trillions of records for the objects in circulation. e.g. A pharma company had said they were shipping a billion units of a product every year for one product line. IETF expertise on scalability issues could be valuable here. Also information may not be publicly accessible. Commercially sensitive information needs to be protected by access control policies, proper authentication etc. Need to have security at Discovery Services layer as well as the information service layer to protect those links and prevent competitors from mining the links. Slide 10 - Some Specific Challenges: Scalability issues with access control. There could be potentially trillions of records of objects in circulation. Could end up with a cat's cradle or hyperlinear scaling of access control permissions, if we don't develop a framework to handle security policy scaling. Another challenge is co-existence and co-operation between multiple Discovery Services and how to find the appropriate Discovery Service to locate information for an object. Slide 11 - This diagram shows the interaction between a client application, an information provider resource, and one or more Discovery Services (D1-D3). Start with Organization R, a company that has information and a database; it handles an object with a particular id and stores event information in its own database or information service. In order for other people such as trading partners to find out this information, R needs a way to declare that it has information about an object. It can publish a link into one or more Discovery Services (e.g. D1, D2) to say it has information and possibly define an access control policy to say with whom the information can be shared. Sometime down the supply chain Organization Q encounters the object. It has an application and wants to make a query on this object. Say the object information resides on D1. Q makes a query to a Discovery Service it knows about (D3). That Discovery Service can communicate with other Discovery Services it it is aware of (D1 and D2)and reply with a delegation to D1. Could keep an index or it could do multi-path broadcast. One or several Discovery Services could respond (query routing). D3 can say D1 knows about it. Q can then query D1 directly to request information, and subject to access permissions, D1 can send a referral response to say organization R has some information. Q can then make a direct query to information provider R for more information. R may decide to release some information to Q in response. Q's direct interaction with R is not something Discovery Services would handle, but something which could be handled using the open standard EPC Information Services (EPCIS) interface, which is downloadable from the EPCglobal website. Discovery Services would focus only on the referral, not the content of the query. - Questions regarding clarification [15 min] Q. Eric Rescorla?: (audio not clear). Wanted to understand the business relationships among partners in the diagram on Slide 11. A. Mark: There may be several information providers in the supply chain. The Discovery Services shown may be independent of each other, and focused on different geographic regions, industry sectors etc. but may have some sort of federation so they are aware of each other's existence. May also have different business models or different Discovery Services. Q. Eric Rescorla?:(audio not clear) Rephrase of question: How do D1 and D2 relate from a business perspective? A. Mark: A Discovery Service will by definition represent a type of community. Within Discovery Services you need to have clusters or Supply Chain networks who may have a policy on allowing another company to join their network. There may be policies governing who is allowed to query or publish. Mike Young gave a real world example of European pharmaceutical association EFPIA who is considering use of a Discovery Service for their members. EFPIA is an example where people with no mutual trust have obligations (imposed externally) to cooperate. Q. Eric Rescorla: (audio not clear) What stops a D4 from claiming he has a part when he doesn't? A. Mike Young: One of the working items being proposed for the group is a need for a security model around Discovery Services. Q. Eric Rescorla:(audio not clear) Do you expect Discovery Services to enforce a business relationship? Answer from Mark to this was "No". You seem to be avoiding the information content question. Mixing up boundaries re: what parts of series of protocols are in scope vs out of scope. A. Mark: We are not dealing with a data model or the interfaces to the database, which is addressed by EPCIS already. Interested in Discovery Services in finding links to one or more information services. While there are some similarities in the commands and framework of EPCIS, it's not about replicating all the detailed information in a Discovery Service. It's a lightweight referral service. We are trying to align terminology with EPCglobal where appropriate. Q. Margaret Wasserman: (audio not clear) Need to understand who the players are, what data they have. Defining that defines the problem. The problem statement is too weak on what is the real interesting problem trying to solve. It's an interesting problem when Q doesn't know which Rs are needed.(i.e. when Discovery Services might be a different provider). R may have opinions about an object but may not want to have another R to know. Complicated and interesting problem to solve. Need to make it more clear in the documents what you are trying to solve. A. Mark: Certainly an interesting problem to solve. Q. Speaker at the mic:(audio not clear): There are existing protocols that do this, though not in this body. Wouldn't have to reinvent the wheel. At least two open source implementations are available. He will post a link to the ESDS list space. A. Mark: If we can leverage existing work, that will help all of us. XML and Web Services are not a problem. Q. Ted Hardie: When D1 sends a pointer to Q that tells it to talk to R, it might use an independent query mechanism that's not an EPCglobal standard. Maybe it can tell you what the query mechanism is. There's a requirement for generality. Other piece is tied to the business model. There are definitely going to be information providers who are tightly bound to specific identifiers. This would be useful in cases where it's very loose. e.g. creating commentary meta data rather than ownership meta data, where there may be multiple places to query because with commentary meta data it's not about control vs a baggage handling use case, where the bag cannot be in more than one place at one time. There are many things that are not as unitary as a bag. Commentary-related things can benefit from generality. A. Mark: Discovery Services can point to other information services or commentaries and so on. A serviceType field could be used to distinguish between different kinds of service accessible through the various referral URLs. Q. Speaker at mic: If you go back in the RFC archives for the TISDAG project (distributed whois directory), the search and referrals model is very similar to this and there may be good experiences to draw from. Some of the same problems were identified. Written in technical terms that were hot at that time. Like LDAP. Q. Kurt: Clarification question on diagram (Slide 11)- which of those communications are you looking at standardization in this forum?...D1 and D3? R and D1? A. Mark: We're looking at developing protocols for publishing (R to D1), query (Q to D3) and also interested in the bootstrapping problem between DS. whose problem lies in the pink triangle on the diagram (D1 - D2 - D3), not in the Q to R query response, which is already handled, for example by EPCIS. Q. Phillip Hallam-Baker: Noticed in security world a higher incidence of people asking for security and Access Control Lists (ACLs) than using them when deployed. Thinks this is due to lack of visibility in existing systems of knowing whether security is there. Would be a shame to go through designing a system that could be secure but in fact is as insecure as the rest of the infrastructure, because it is not configured right. Keep coming back to this trying to solve for a specific application and not abstracting to a generic and then reinstantiating a problem as an example. Has seen too many one offs that we should now be thinking about an architectural approach. Opposed to architectural thinking divorced from a use case. Focus on architecture - it still has value. Q. Dave Crocker - Phillip's suggestion is good. For this group bringing this to the IETF is a bad idea. I think there's multiple agendas here that could and should be served. Here you have a use case that could be solved. You want us to help you with it. "We" in the IETF world have some knowledge that can come to bear, but we'll be thinking about this in a larger way than you might need us to. Not there yet. What's really great is to have some outside group come with a narrow concrete easy to understand problem where we could provide an narrow concrete easy solution. Not the case here. Don't have a track record in IETF of solving this category problem in the general or in terms of large scale global activity with the exception of DNS. Given the usage scenarios, you wouldn't do it in 15 min. Not in a position yet to say there's a solution that exists because can't understand the problem statement yet. Think you are in need of an IETF process to get to the point of specifying protocol or protocol choices. Loathe to call it a requirements working group, vs choosing a protocol space. Problem space is way more complicated than that. Will take time and work to make sure IETF understands the problem before getting your world and our world to the point where we know the solution. Q. Speaker at mic: wanted to understand relationship between ESDS...and IP in the triangle figure (Slide 11). Current ISO, or EPC solutions don't consider IP protocol. New devices like RFID, need end to end connectivity using IP. Wants to know the current status of solution. A. Mark: Some of the objects you are trying to track might not have network interfaces as such. Can respond saying this is my ID. Won't be able to communicate via TCP/IP to talk to that object. What you're doing often is talking to an agent that represents that object. e.g. Records in a database. The object itself has no network interface as such. Communication often involves talking to an agent (e.g. an information service) that represents that object. 3. Review of Problem Statement ( Michael Young ) Slide 13 - Mike asked for show of hands how many had read the Problem Statement. Approximately 45%, or 30 people raised their hands. Mike pointed out that he had been at IETF meetings where people haven't. Wanted to pick out some "sore points" that IETFers will ask in their heads re: the Problem Statement. e.g. who's interested, going to contribute, consume, do the work, etc? Slide 14 - The list of names on this slide represents both consumers as well as contributors to DS work. ESDS mailing list has over 70 members. He mentioned the EPCglobal working group whose information can be consumed to satisfy need for defining requirements and get to the work of the technical protocol. Some of its members here today are people who have worked for research groups such as BRIDGE and PROMISE. Slide 15 - Why the IETF?. There are some problems that IETF could help solve. e.g. complexity of the bootstrapping process and scaling to global operations. The IETF have long, deep expertise and knowledge of mistakes we can learn from e.g. where not to go. Security consideration is a big work item. Security will be borne out of requirements. It has to adhere to or enable a security model, so if validation is done externally, could work with that. Protocol has to be able to work if security is to be done externally. Can leverage other learning too. The Forest Guides have outlined a similar problem P2PSIP has distinct similarities to DS and differences (proxy validation). Looking for feedback on the right way to deal with these issues. Slide 16 - Answers the question: What does this work enable? Today the world is about point-to-point (PTP) communication when it comes to physical objects moving around. If you don't have PTP won't have access to a lot of information. So if you are tracking maintenance on airplane parts there is no reason not to enable that solution to find all the MROs for airplane parts. This work enables the addressing of real world needs, such as audit trail for safety-critical products, counterfeit product detection and support for product recalls. How to establish and enforce trust is important. Shortly legislation will require pharma track and trace. No easy way to do this today. Items like Discovery Services make this more valuable. Cited Pfizer heart drug recall example where Pfizer received back 2.5 as much product as was shipped due to lack of accurate track and trace capabilities in the distribution network not known to the pharma manufacturer or retailer in depth. DS could help heuristically discover things like that. Slide 17 - See slide points. Driving forces include fraud protection for consumables like drugs or food products. Need for multiple Discovery Services - In an open market, even if it is technically possible to have one Discovery Service to share, with access controls no one would accept that. Reality is that a supply Chain dealing in car parts in Europe doesn't care about a milk delivery supply chain in Delaware. The World is a series of circles of relationships so multiple Discovery Services have to be assumed. Also mentioned the demand for increased security. It is not assumed that anyone can connect to Discovery Services. - Questions regarding clarification [15 min] (came after slide 16) Q. Speaker at mic : When a query is done today (e.g. What part is in the airplane, Where are these drugs now?). How many different organizations are contacted to get this information? Is there an automated way of doing this? Where does this scale today? i.e. How many actors do you imagine being involved in a product's life cycle? A. Mike: Reality is scary. Current plane part records are maintained on paper. Q. Same speaker at mic: It's a multiple choice question... What is the number? A. Mike: On a given object may have 20 or more organizations Mark: the Bridge project has seen up to 50. Q. Margaret Wasserman: That's for a serialized item. If you want to find all of the Tylenol manufactured in the last 2 months it could be a very large number. There's a large number with these tabs of 50 going through it. Questions were cut off at this point in order to move on with the agenda. 4. Expectations of deliverables (Mark Harrison) Slide 20 - Reviewed expectation of what Discovery Services will provide, based on user requirements for the BRIDGE project.(3 year project with 30 organizations). Started by asking what functionality needs to be provided: tracking, forecasting (where's an object expects to be), alerting, misplaced and duplicate ids. Discovery Services enable those applications by providing links to sources of information that need to be checked. When would you update a DS? On shipping and receiving events. Latency should be ideally 1 sec. Should have support for standing queries. Manufacturer might want to know who's handling the product next. Provisioning with multiple information providers. Emphasized the need for all supply chain parties to contribute to the service preferably on subscription basis. Slide 21, 22 - Technical expectations: Primarily referral URLS, timestamp and possibly some meta data to have hooks for defining access control policies. In terms of size need to support scalability e.g. up to 1 billion events per year for a particular line with 50 or more companies handling an object and 100K queries a day. Discovery Service records might refer to other systems where information is stored: EPCISs, ERP systems, or other Discovery Services. Not a hard-coded link. Should allow full trace query of all organizations who have event information, preferably time ordered. Support for synchronous and asynchronous responses. Felt shouldn't be allowed to update records. Maintain a journal log. Have a voiding policy. Further details can be found at the Bridge project website listed on the slide. There are also some design documents related to ESDS activity. - Questions regarding clarification [15 min] (Questions after slide 21) Q. Speaker at mic: Substantial list of requirements. The assumption you're making is that you're only dealing with referrals; you hope that would simplify things enough for you to get this Working Group. This ends up looking like a distributed directory. You think that just dealing with referrals will make it more successful than previous distributed directory attempts. Is it your assumption that you're only going to deal with referrals vs other distributed directory attempts? A. Mark: A lot of detailed information might be stored with a company (e.g. 100 events), but you only need to post one link. Referrals is a way of reducing the scale of the problem. Q. Same Speaker at mic: Would have to maintain some sort of index. Brings up problem of modelling and matching rules (essentially LDAP). If assumption is that it's a simpler model, it's a mistake. Just as complex as any distributed directory. Won't get away with dealing with matching. A. Mark: Trying to reduce the amount of space records take up. Simple data model doesn't make it less complex to solve. There are some patterns in existing EPC identifiers that can be used for matching. Q. Phillip Hallam-Baker: The failure of directory systems has been raised. Reason x.500 is extinct has nothing to do with technical merits. The reason most directory projects fail is because the content isn't there to look up in the directory. Should recognize that this is an IETF proposal to take on part of the technical work going on in EPCglobal. Clearly EPCglobal won't wait for technical challenges to be addressed in this body. Good to have a use case that focuses on the technical considerations. Similar to Keyprov and other working groups. If deliver on time, it will be used. Likely one of these deals - if we do the work for EPCglobal they will either use it or if not completed in time, do the work on their own. A. Mark: I have a slide that discusses that on a time scale, will show it shortly. (Questions after slide 22) Q. Andrew Sullivan: General purpose directory-ness of this. Because you are dealing with distributed meta data - makes it more complicated because you have a vocabulary of meta data spread out. Have a directory of directories problem plus problems of directory issue itself. Does it make it worse? Should we go back and use the DNS model in ONS even if you are going back to one source? At least you'd have one well known problem. Q. Margaret Wasserman: Co-chairs SAG at EPCglobal. Work at present in EPCglobal is requirements gathering only. The hope is that their work would feed into this group with a technical protocol done in this body. Hope is that ongoing process will feed in here. There is no technical work being done at EPCglobal in this area. Q. Ted: Follow up from a process perspective. It's not a global distributed directory problem. Important to think about differences between distributed directory vs global distributed directory. Security and scope considerations have to be taken into account. Real question is "What does it take to make this a manageable chunk of work? Is that enough?". 5. Scope of work ( Mark Harrison ) Read ESDS charter out loud. And scope of work. Any comments? Have some questions he would like some rough consensus on: BOF Questions 1) Is this an interesting problem to tackle? 2) Is the scope of work appropriate to the problem? 3) Is there support to form a work group with the following charter? (i.e. that the charter itself is ready and supported by the community) 4) Can I ask for a show of hands for who is willing to review documents? 5) Do we have any additional volunteers as an editors for some of the document(s) to be produced by the work group? - Questions regarding clarification [15 min] Q. Leslie Daigle: I do think its an interesting problem to tackle. Some similarities to the whois service problem where do have some entities notionally working together and problems in establishing a shared context. Not a global directory services problem. Hasn't seen anything too scary here. Q. Eric Rescorla: Has read the documents. Unclear still about what trying to achieve. I let the thing go Re: the business relationship but wants to go back to it. Re: diagram on slide 11 - start with R (company who handles the object) and D1 (who has Discovery Services). Does R have a contract with D1? A. Mark: R is a company who handles an object. May have a relationship with D1 as a Discovery Service for their region. May be posting to more than one DS (e.g. If product is shipped from Europe to North America). Q. Eric Rescorla: Is there a contract? SLA? Bilateral agreement? A. Yes should be. Q. What is the relationship between D1 and D2? A. Mark: D1 and D2 could be aware of each other's existence. May be aware of the scope that the DS services (e.g. Region). Q. Eric Rescorla: Say I want to become a Discovery Service, how do I do that? Post something on the Internet? A. Mark: Ideally there should be conformance tests to a standard protocol; may be independent auditing, enforcing access control policies ,further checks of audit trails imposed by legislators. Checks and balances to be set up as a Discovery Service. Q. Eric Rescorla: The system you're describing assumes a single large trust boundary. Ted: He's saying that everyone who has a D prefix in this federation of DS is in a single trust boundary. Important to remember that this trust boundary is different from the boundary between Q and R. It is not the full trust boundary implied between Q + R. Answer is yes perhaps but its a different trust boundary that would have dealt with previously. Q. Eric Rescorla: Would be fine if concerned with information leakage. Pushing on this because he has heard two things. First: Important to conceal which info providers are providing info about an entity. Seems Every DS knows. It matters where things actually are. Don't understand what stops any information provider from claiming to own any entity at any time. A. Michael Young: Reality is there's not one owner of this object. Consequences of misbehavior: e.g. If D1 is a large contractor company with an accreditation process, the D1 operator will have some type of an out-of-bound physical verification where if you misbehave we point the authorities to you. But this is out-of-bounds to a technical protocol. A. Ted: Recast the problem by going back to baggage claim scenario. Is your issue: If a bad D4 is willing to lie, they can point you to an R2 who doesn't have your bag but is willing to claim the bag is there? So if there's an R2 with a relationship with D1 or D2 it can claim to have the bag even if it doesn't? Q Eric Rescorla: Problem with the security model is everyone is in trust boundary. There's limited access control. Way you stop malfeasance is by having people shot. Goes to fact that you've already assumed the fact that access control problem will be handled by non-technical measures. A. Ted: There are aspects of this that require non-technical measures. Part of it is in way identities are minted. Assuming if IATA assigns minting, if try to handing over to D2 they are risking their bilateral agreements to D1 and accreditation with signing authority and even if they are willing to risk those,it doesn't give me the bag. Q. Eric Rescorla: Whole premise of systems being described is that there is a disjunction between people doing the minting and people who have the stuff. If they're the same it'd be different A. Ted: That's true. In beginning they may be the same. Q. Eric Rescorla: Trying to figure out what the implied relationships are in terms of what's being enforced. Seems 90% of enforcement is non-technical. You say important to have technical access controls. So one way to handle it, have no access controls. If people are looking at wrong information, have them shot. Before get into tech access controls, wants to know why can't do that? A. Ali Rezafard: Everyone who injects goes over SSL layer. Q. Eric Rescorla: How can that be relevant? Ali: They are given a certificate by certified authority so know who published it. If bad information is published. Can have consequences. Q. Ted: Agreed you can shoot a person as long as it's not a member of the author team or the BOF chairs. Q. Margaret Wasserman: Comment on Eric's question. Not sure this is a solvable problem. One of the answers is that R tells us the level of security of information allowed (which Qs are allowed to see it, which D2s are allowed to expose itself to). Forget the ID minter. Q. Eric Rescorla: I don't understand how only certain Ds can see it, because all Ds are identical. Q. Margaret Wasserman: We don't have a strawman proposal for this. A particular group will contract to provide their Discovery services. If D1, D2 and D3 are different information Services (shoe containers example). R. has to say whether it's sensitive information or not. Answers to BOF questions: 1. Yes very interesting problem to solve. Have read more about this problem because of involvement with EPCglobal, etc. Doesn't think the problem has been effectively defined within an IETF context. Need to define problem better before can charter work group on a solution. 2. Don't get the sense of the scope of work. Charter needs some work to be done about what work items are to come out. 3. Charter needs to be more complete. 4. She's willing to review documents, she would help with document producing. 5. She supports the effort but feels it needs more work to be a well defined IETF Working Group. Q. Michael Richardson: Answers to BOF questions 1. Yes, interesting problem to tackle. Lessons from DNS sec space who has been through this. When DNS was invented,it had no  Access Control Lists (ACLs). Over the 20 yrs. since deployed and DNS sec have added ad hoc mechanisms... DNS sec's previous processes are valuable to review. Didn't invent ACLs. Contained information for people wanting to know it. 3. Charter has to say specifically what kinds of ACLs are necessary because it changes scope of solution and has to say what kinds of privacy and security are relevant. It's not enough to say there's SSL on the communications path. Important for the reason Margaret mentioned with respect to shoes in box in container shipping to Walmart in St. Louis that also contains diamond rings. Similar to Internet: we do standards for things like BGP or diffserv Because traffic flows through different providers to get from Point A to Point B. Its the Same problem... even if people are members of various associations. If I'm a Manager of Wal-mart I have to talk to a dozen organizations that I have no relationship with. For this to be useful the problem and scope will have to defeat the assumption that all D1s are at the same security level. Bigger problem there to make it useful but maybe good it's shown up at the IETF which is good at solving interdomain problems. Maybe we don't care about Q to R, as Q to D1-D3 relationships. Q. Speaker at mic: Agrees it's an interesting problem, but before he answers the five questions wants to ask - EPCglobal is used as an example for the problem statement. But so many standards countries like China, Korea are going to build standards for supply chain. What is your consideration for Discovery Services under multiple standards? Independent of existing standards? A. Mark: DS is completely agnostic. Points a URL to something which hopefully has a standard protocol to it, accompanied by a service type. Q. Same speaker: He supports (BOF question 3.) Q. Andrew Sullivan: Worry he has is in the scope of proposed charter. Is it a global directory problem? On one hand talking about some relationships on other hand talking about the global supply chain (i.e. everyone in the world). Clarification in charter needs to be made or could end up with a very big problem. Would be willing to review docs and work on them. Re: Answers to BOF questions - 1. thinks it's interesting to tackle 3. Is this a global directory problem? Whether it's a global supply chain or not, make it clear in the charter. Becomes automatically a distributed directory problem. 5. He is willing to contribute. Q. Phillip Hallam-Baker: Missing some questions. Answers to BOF questions 1. Yes interesting problem to tackle. Many interesting problems to tackle. The real questions are 6. Will we be able to solve it? 7.Is the world going to care if we do? To Margaret's point, he is aware of EPCglobal politics more than you think and has been pouring oil on troubled waters these past weeks. There are a lot of problems here. Control of world supply chain could be another can of worms. To answer a previous speaker's point re: access control - doesn't think this will work as an access control problem. Can't write all the rules in advance. All you can do is keep audit trails and have accountability, so if someone does default, can shoot them or fine them. Use case of bag is not a problem. It's an accountability based control not an access control. Q. Dave Crocker: beginning to believe he knows what ought to do now. A requirements group would be the worst thing in world. We have the best track record for doing syntax and exchange rules. Let's call this a service specification. There was no protocol reference in the discussion last night which led to diagram on Slide 11. What you need to do is work through or negotiate functionality without worrying about the acronyms that go with them. Trust domains are not easy. That's serious technical work. Benefit is that there are real world needs. If you have someone with the need, it constrains and motivates the service specification. It's fine if it does more, not if it does less. Makes it a realm that's larger than before but at least its constrained and concrete. Q. Leslie Daigle: Largely agrees with Dave Crocker's last comment. Wanted to emphasize need to express it in IETF space to make it something can get our heads around. Look at in terms of an architecture related to but separate from efforts done before in directory services, so it's reusable. Make it be an engineering problem and separate out the business requirements. Interesting problem to tackle. Make it part of an architectural suite of Internet services. Important to look at it architecturally but has to be driven by actual requirements that exist, else theoretical. Q. Eric Rescorla: Agrees needs to be driven by actual requirements but is fuzzy about what they are. Not crisp enough For IETF to charter. Not convinced about this control thing. Gave example of a friend's move with items in a shared container. Suddenly he's part of a larger sphere of influence now. Doesn't see how the system doesn't devolve into a single global database almost immediately. Fascinating research problem to build a system like that with reasonable security but doesn't know how to solve it. Q. Brian Dickson: Back to the diagram on Slide 11 - Another couple of questions based on Ds, Q and who needs to know what and how they find that. Presumably will have a lot of Ds - Hundreds? Thousands? A. Potentially lots of Qs and Rs that will outnumber Ds. Q. Brian Dickson: Ds will likely be less but still numerous. D's may or may not have a bilateral relationship but not a multilateral relationship other than at the protocol level. A problem: Anything other than the ID itself acting as a key into the system that allows Q to decide who to ask? A. By inspection? Brian Dickson: By some index that this ID is this kind of thing (e.g UPC + something else). How does it start querying anywhere in the system? A. Mark: EPC has those structured identifiers. Some use cases where identifier may be opaque (structured or not).e.g. Pharma unclear whether to use structured identifier because someone might read it. May involve technical solutions like pseudonym schemes. Q. Brian Dickson: As long as there's some structure to start with could provide insight as to what is or is not needed. A key part of understanding those relationships and what's needed to make it work. Q. Speaker at mic: Simple question. In future will be many information providers e.g. China, Korea. Referred to Slide 11 Diagram. Why would Information Provider R provide information to D to discover the service? Some information may be secret. What kinds of information should information provider R provide to D? Does D have some information first from R? A. Mark: If Q is in a relationship with D1 it might not need to go through the federated D1 to find link information for R. What you're saying about protecting the information, have to have some way about restricting who will have access to that. In some cases may not publish to a Discovery Service. Whole mixture of possibilities. R may not publish to a Discovery Services unless legislation might require it to do so. Q. Same speaker at mic: What is published to D? Mark: mainly the URL for R. Speaker thinks R should provide general information to D. He supports the BOF. 6. Next Steps and Action Items Ted wanted to know how many interested in going forward. Clearly at this point has seen some interest. And has some strong sense of the room that this group is not yet ready to be chartered as a Working Group. Anyone disagree? No hands ready. Ted: How many of you are willing to work on charter to prepare it for a Working Group? Fair number of hands raised. Ted: There are two ways of doing this: 1) aim for another BOF in Dublin. 2) ask IESG for a study group (similar to a requirements group but gives you formal standing). Anyone believe it makes a difference to be a study group or BOF? Ted: Raise hands if think should be a study group, which has a charter. Only get two BOFs. Could ask for a Working Group if activity on the mailing list justifies an update between now and Dublin (without having a second BOF). Margaret Wasserman: Study group might be good for this effort, but not scoped enough to make a study group charter. Maybe form a study group out of the next IETF. Ted: Aim for a Working Group but come out with a study group. Ted: Anyone believe this work does not need to be done? One participant can't tell. Ted: Does anyone believe it shouldn't be done here? One participant can't tell. No one else is raising an objection. Ted: Raise your hand if you believe this work belongs in the IETF. Sense of room is pretty strongly in favour. Given that, he proposed as Action Items: 1. Those who continue to be interested in the problem go on the mailing list. 2. Refine charter. 3. Continue to work on the technical documents. 4. Caucus with Lisa and IESG to see they believe if next steps are Working Group, BOF or study group. With the presumption that work needs to be done to bring technical docs into IETF terminology. Strong sense of the room in continuing the effort within IETF and a strong sense that there is a need for work on next set of steps before proceeding. Anyone object to next set of steps? No. Ted thanked attendees for their time. Ted: See you on the mailing list where we will be working on technical docs to make them more IETF like. And where we will refine the charter and continue the conversation on whether we are going for a study group or Working Group before or at Dublin. Mark also thanked everyone. Beer BOF invitation extended to participants at McGillans on Drury Street.