idnits 2.17.1 draft-rezafard-esds-problem-statement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1279. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2008) is 5611 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 4930 (Obsoleted by RFC 5730) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Rezafard 3 Internet-Draft Afilias Canada 4 Intended status: Informational November 17, 2008 5 Expires: May 21, 2009 7 Extensible Supply-chain Discovery Service Problem Statement 8 draft-rezafard-esds-problem-statement-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 21, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document discusses the requirements of an application layer 42 protocol for Discovery Services. Discovery Services at its core 43 offers to authenticated and authorized users the means to discover 44 resources of information for a particular identifier. The 45 information resource can be any data source which provides an 46 interface on a network that allows for retrieval of the data. An 47 information resource could publish its network address (reference to 48 the resource) to a Discovery Service coupled with an identifier. 49 Then an authenticated and authorized user could query the Discovery 50 Service with the same identifier to receive reference information to 51 the resources. Interfacing with the resources for actually 52 retrieving the data is out of scope of Discovery Services; the role 53 of Discovery Services is to enable a client to find the network 54 addresses and types (e.g. URLs) of information resources for a 55 particular identifier of interest. 57 This protocol is applicable to numerous scenarios such as track and 58 trace in trade supply chains, where a number of independent resources 59 may hold information about a particular object and may have an 60 interest in selective sharing of that information, in order to 61 improve the efficiency of the supply chain network. 63 However, other applications can be envisaged, as a 'bottom-up' or 64 'grassroots' way for generators of information content to: 1) declare 65 that they have information or commentary on a particular topic or 66 subject (which might be a physical object, geographic location or 67 even an abstract concept) 2) specify a network address through which 68 that content can be retrieved, 3) specify restrictions about the 69 community of clients that are entitled to receive knowledge about the 70 existence of their content or see the link. This approach can be 71 contrasted with the top-down approach of existing web search engines 72 that rely on crawling/spidering of content that must be already 73 posted in the public domain before it can be indexed - and where the 74 link information is generally made publicly available in a manner 75 that does not discriminate between clients on an individual basis. 77 This document outlines a set of design concerns that an application 78 layer protocol needs to address in order to be widely adopted and 79 deployable on public networks 81 This document obsoletes "Extensible Supply-chain Discovery Service 82 Problem Statement draft-rezafard-esds-problem-statement-02". 84 Comments are solicited and should be addressed to the mailing list at 85 esds@ietf.org and/or the author(s). 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.1. Introduction: Supply chain applications as one driver . . 5 91 1.2. What is ESDS? . . . . . . . . . . . . . . . . . . . . . . 6 92 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 93 1.4. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 94 1.5. Description . . . . . . . . . . . . . . . . . . . . . . . 9 95 2. Internet Concerns . . . . . . . . . . . . . . . . . . . . . . 10 96 2.1. Public Networks and Tree-Walking Concerns . . . . . . . . 10 97 2.2. Bootstrapping Concerns . . . . . . . . . . . . . . . . . . 11 98 3. Other Standards . . . . . . . . . . . . . . . . . . . . . . . 13 99 3.1. Object Naming Service (ONS) . . . . . . . . . . . . . . . 13 100 3.2. EPC Information Services (EPCIS) . . . . . . . . . . . . . 13 101 3.3. Universal Description Discovery and Integration (UDDI) . . 13 102 3.4. Interface for Metadata Access Point (IF-MAP) . . . . . . . 14 103 4. Related Standards Development Organizations . . . . . . . . . 16 104 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.1. Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . 17 106 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 5.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 18 108 5.3. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 19 109 5.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 5.5. Relabel/Aggregation/Disaggregation . . . . . . . . . . . . 20 111 5.6. Multiple Organizations . . . . . . . . . . . . . . . . . . 21 112 5.7. Identifier Agnostic . . . . . . . . . . . . . . . . . . . 21 113 5.7.1. Reusing Identifiers . . . . . . . . . . . . . . . . . 22 114 5.8. Extensible . . . . . . . . . . . . . . . . . . . . . . . . 23 115 5.9. Policies . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 5.10. Stale Links . . . . . . . . . . . . . . . . . . . . . . . 23 117 5.11. Peer-to-Peer Communications . . . . . . . . . . . . . . . 24 118 6. Technical Challenges . . . . . . . . . . . . . . . . . . . . . 26 119 6.1. Auditability . . . . . . . . . . . . . . . . . . . . . . . 26 120 6.2. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 26 121 6.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 26 122 7. Related Activities . . . . . . . . . . . . . . . . . . . . . . 27 123 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 124 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 128 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 129 12.2. Informative References . . . . . . . . . . . . . . . . . . 32 130 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 Intellectual Property and Copyright Statements . . . . . . . . . . 35 133 1. Introduction 135 As the Internet applications become more and more service oriented 136 and specialized, the demand for collaboration among these 137 applications increases. These applications can collaborate on 138 services or on topics. Open collaboration on services is already 139 taking place via Universal Description Discovery and Integration 140 (UDDI). Selective collaboration on specific topics is the problem 141 domain that Discovery Services aims to address. 143 A first step towards collaboration among applications on topics would 144 be to use a common identifier for each topic. For example a topic 145 can be something conceptual like the name of a book, or a topic can 146 be a particular physical object with a serialized identifier. The 147 use of common identifiers will enable dispersed applications to 148 inter-communicate with each other. Note that it is not the role of 149 Discovery Services to develop such common identifiers - this is left 150 to existing standards such as URIs and semantic web initiatives such 151 as the Dublin Core vocabulary. 153 The second step for the applications would be to find other resources 154 of information on a common topic. This is made possible when an 155 application advertizes that it holds information on a topic. This is 156 made possible by Discovery Services since an application can 157 advertize to a Discovery Service that it holds information on a 158 specific topic, by publishing a reference to resources that hold 159 relative information on the topic of interest. 161 At a conceptual level, Discovery Services can be superficially 162 regarded as being somewhat analogous to a bottom-up 'search engine' 163 for an 'Internet of things'. However, there are some fundamental 164 differences from the paradigm of public web search engines. The 165 serial-level information will usually be protected and will only be 166 made available to authorized organizations, with whom the information 167 provider has an established trust relationship. For this reason, we 168 cannot assume that Discovery Services will be able to automatically 169 'spider' or 'crawl' the network to compile an index of links, since 170 the underlying information may not be generally available. 172 Instead, we assume that each information provider will be able to 173 voluntarily publish a record or registration for a particular common 174 identifier, in order that a link can be established back to them as a 175 potential provider of information. At the same time, also the 'link' 176 information will be protected by access control policies defined by 177 each information provider, as well as any policies that are imposed 178 by the operator of a Discovery Service. Unlike most public search 179 engines, there may be little or no 'link' information provided to 180 non-authenticated users or directly to the general public without 181 authentication, although in some specific applications, citizens may 182 be provided with indirect access to traceability information that was 183 gathered via an authorized authenticated actor, such as the retailer 184 or manufacturer. 186 This approach enables distributed management of collected information 187 and allows each organization to restrict who can access the data; 188 they can specify an access control policy (which is enforced by a 189 Discovery Service) to limit visibility of the 'link' information - 190 and additionally, they can specify and enforce an access control 191 policy within their own information resource that holds the more 192 detailed information. 194 1.1. Introduction: Supply chain applications as one driver 196 Currently, a number of industry sectors are moving towards improved 197 track and trace systems by the use of Auto-ID technologies (such as 198 Radio-Frequency Identification (RFID)) that improve the ability to 199 automate collection of observations, as well as the use of unique 200 identifiers for each individual object, to improve the granularity of 201 information, so that it is possible to track not only at the 202 granularity of batches or lots - but actually trace the entire life 203 history of an individual object. This is particularly important in 204 the fight against counterfeiting and for assuring the traceability 205 and authenticity of foods, pharmaceuticals and other safety-critical 206 objects, such as aircraft and automotive parts. 208 As well as automating the collection of such data, companies are also 209 moving towards sharing and exchange of serial-level data (i.e. data 210 about individually identifiable objects), in order to improve the 211 efficiency of supply chains. This involves greater use of machine- 212 to-machine information exchange, using standard interfaces for 213 queries and output formats and requiring less intervention by human 214 operators (e.g. less exchanging of spreadsheets via e-mail or FTP). 215 However, serial-level data is commercially sensitive, since it can 216 reveal information about stock levels and volumes and flows of goods. 217 For this reason, most companies insist on maintaining strict control 218 over who is granted access to their data, including the links to 219 their data repositories or information services. The entire 220 lifecycle information for an individual object therefore remains 221 decentralized and fragmented across multiple actors in the supply 222 chain or extended product lifecycle. Discovery Services will provide 223 secure referral services that can be queried with a unique ID and 224 return to authenticated authorized clients a list of links to 225 multiple information providers, who can then be queried for more 226 detailed information about the individual object. 228 1.2. What is ESDS? 230 ESDS is a protocol for infrastructure that enables track and trace 231 applications as well as product lifecycle information systems to find 232 multiple sources of information. Using the links provided by 233 Discovery Services, they can then attempt to gather complete 234 information about an individual physical object. 236 Several organizations may handle an individual object at different 237 stages of its life - and each of these organizations may collect and 238 store some information about each object. This may include 239 observations of where the object was seen, details of operations 240 performed on the object, as well as measurements (e.g. temperature) 241 of the object or its environment. 243 Even two objects that are of the same product type and which were 244 created in the same batch or lot may ultimately follow different 245 paths throughout their lives and each might be handled by a 246 completely different set of organizations. 248 We DO believe that each organization should be able to keep control 249 of the data that they collect and store - and should have the ability 250 to determine how much of this information is made available to others 251 - and with whom. This can be achieved by requiring authentication of 252 clients specifying fine-grained access control policies associated 253 with the roles assigned to those authenticated clients. 255 We DO NOT propose that ESDS should act as an aggregator of detailed 256 information. 258 Instead, ESDS is intended as a lightweight referral service, whose 259 sole purpose is to help a client to find one or more sources of 260 detailed information. In practice, a query to an ESDS about an 261 object ID should return to an authenticated client a list of URLs of 262 information resources that hold the detailed information about that 263 particular object. The client will only receive the URLs to 264 information resources that have authorized (e.g. via access control 265 policies) the client to see their URL address for that specific 266 object ID. The client can then contact each of those information 267 resources in order to request more detailed information. This 268 process is OUTSIDE the scope of ESDS and may be subject to further 269 authentication and authorization checks bilaterally between the 270 client and each individual information resource. 272 1.3. Terminology 274 There are three actors in this problem: 276 Client: refers to an actor that seeks (sources of) information about 277 an individual object (or topic). 278 Resource: refers to an actor that holds information about an 279 individual object (or topic) and may choose to share (some of) 280 that information with a client (under certain conditions). 281 ESDS: refers to an intermediary lookup service protocol that enables 282 a client to obtain referral information to one or more resources. 283 Publish: refers to the act of writing to a intermediary lookup 284 service, Resource reference (address) information coupled with an 285 object (or topic) identifier. The publishing actor, as the 286 information owner, could define access control rules to restrict 287 which clients (or client roles) are allowed to view the Resource 288 reference (address) for a particular object (or topic). 290 What emerges from combinations of these actors and their 291 relationships are: 292 Organization (Partner): refers to a business entity, which can be 293 comprised of client actors or Resource actors. 294 Community (Supply chain): refers to a group of member organizations 295 (partners) that may be willing to share some information among 296 themselves. 298 Note that not all members of the community will share exactly the 299 same access privileges; there can be different bilateral access 300 privileges within a community. 302 Each organization can define rules that restrict which clients shall 303 be allowed to see the address of its resource as a potentially 304 relevant resource for a particular object identifier (or topic). 305 Note that in some situations, the overall access control policy may 306 be the result of a combination of rules defined by one or more 307 organizations, as well as rules defined at a community level. 309 Access privileges as defined by a community and its member 310 organizations are only applicable to the information published by 311 ESDS. Each Resource must take its own security measures to protect 312 its data (hosted at the published network address) from unprivileged 313 clients. 315 1.4. Problem Statement 317 Information sharing between organizations is essential for all modern 318 networked communities. There is a strict set of business and 319 technical requirements that must be observed in order to enable open 320 sharing of information between organizations. 322 There are resources and clients in each community. Each resource 323 wants to advertise its knowledge (data) to interested and authorized 324 clients. Only deploying private networks to connect whole 325 communities is no longer feasible, as the more efficient and 326 economical means of connecting resources and clients is to use public 327 network infrastructure. Currently, many industrial inter- 328 organizational track-and-trace initiatives are deployed on public 329 networks and the information is routed through the Internet. Because 330 of this trend, it is highly desirable that a draft protocol should be 331 developed. An IETF process consensus would ensure that the adopted 332 protocol conforms to the Internet's operational needs. 334 A key principle of information sharing within a community is that 335 data ownership must be respected. This means that each organization 336 can collect information within their own systems and is not required 337 to route that information to any other organizations. However, they 338 can choose to share selected information with other trusted 339 organizations. This in turn means that the information about any 340 individual object may be held by multiple resources in a community. 341 Therefore a mechanism is needed in order to facilitate the gathering 342 of this information. 344 A key requirement is that information accessibility is fully 345 controllable. The confidential information must be secure and hidden 346 from unauthorized clients and only visible to the intended clients in 347 a community. In order to establish trust and reputation with the 348 participating resources, unauthorized clients need to be barred from 349 viewing, eavesdropping, or deducing information or even being aware 350 of the existence of another organization's involvement with a 351 specific identifier, if the client is not authorized to be aware of 352 this involvement. 354 There must be a common set of data that all resources will offer 355 (only to authorized clients). This set must be defined and agreed 356 upon in the final protocol. This set may include answers to who, 357 what, when, where, and why as well as links to back-end systems. An 358 essential feature is for the protocol to be general-purpose and 359 extensible to support multiple applications and uses beyond the needs 360 of trade supply chains that motivated its initial development. 362 Defining a bootstrapping procedure is a necessity when designing a 363 global and autonomous network of systems. Bootstrapping procedure 364 would be the process of locating on the network, the appropriate 365 Discovery Service(s) for a specific identifier. Currently there are 366 deployed supply chain systems that bootstrap via Internet's DNS 367 roots. One example of this is the EPCglobal Object Name Service 368 [epc-object-naming-services] (ONS). While ONS enables an economical 369 means of bootstrapping, improper implementations may increase the 370 traffic on DNS roots exponentially. Since data will be routed 371 through the Internet, the bootstrapping procedure needs to be 372 formulated under the IETF approval process. 374 1.5. Description 376 An Extensible Supply-chain Discovery Service (ESDS) provides a 377 mechanism to locate one or more resources of information about a 378 specific topic such as an individual physical object. In a trade 379 supply chain resources of information may include the original 380 manufacturer or supplier of the object, as well as other 381 organizations who have handled the object at some point during its 382 lifecycle (including repair and maintenance organizations) and even 383 organizations (such as customs or insurance agencies) who might hold 384 information records related to the object, even though they may have 385 never had physical custody of the object. 387 This document defines the Problem Statement, Objectives and Technical 388 Challenges related to the application layer protocol currently 389 proposed as Extensible Supply-chain Discovery Services (ESDS). ESDS 390 enables the publishing and querying of referral links to information 391 services that historical events related to specific objects with 392 attached object identifiers. The interface enables disparate 393 applications to discovery resources of information and compile a 394 consolidated view for an identifier. Primarily, ESDS provides 395 referral services in a loosely coupled mechanism with granular 396 security that enables selective visibility. 398 2. Internet Concerns 400 2.1. Public Networks and Tree-Walking Concerns 402 Currently, another standards body, EPCglobal, has issued a related 403 standard referred to as ONS [epc-object-naming-services]. ONS is 404 effectively an extended version of DNS that does not benefit from the 405 IETF review process and, in its design, necessitates increased tree- 406 walking. ONS specifies a reverse mapping of the EPCglobal "SGTIN" 407 (one type of supply chain object identifier) as a hostname and allows 408 for a reference (i.e. URL) to a manufacturer's relevant back-end 409 system (using a NAPTR record). The SGTIN identifier is comprised of 410 an EPC Manager Number, an Object Class, and a Serial Number. The ONS 411 lookup excludes the Serial Number portion of the SGTIN. However, the 412 ONS specification has already been extended in industry pilot 413 projects to include the Serial Number, as this enables item level 414 lookups for tagged objects in the supply chain. Using serial level 415 lookups, ONS could be used to indicate point to point referrals 416 through the passage of a relevant identifier throughout the supply 417 chain. This would require successive updates to the hierarchal ONS 418 to indicate incremental supply chain member referrals, reducing the 419 effectiveness of caching. Alternatively the ONS could provide a 420 single, static point of referral to the first or initiating supply 421 chain member. However, even a relatively static entry, which only 422 refers to the point of origin within the supply chain, would drive 423 the number of public zone entries to extremely large numbers if an 424 individual records were created for each serial number. The number 425 of records could exceed the current IPv4 address space by several 426 orders of magnitude. Also since many of the tagged physical objects 427 would neither require nor provide network connectivity, utilizing 428 IPv6 for such objects would waste this finite address space resource 429 unnecessarily. 431 One common suggestion to manage this problem is to have multiple 432 alternate ONS roots which can be managed for separate and unrelated 433 supply chains and/or regions. However, since there is nothing to 434 prevent ONS from operating in the existing Internet root hierarchy, 435 even alternate ONS providers can opt to drive traffic to the existing 436 Internet root servers, rather than operate their own ONS roots. 437 There has already been a pilot ONS implementation under the .aero 438 zone (sgtin.id.ons.autoid.aero) where this phenomenon may already be 439 observed. 441 It should be noted that ONS 1.0 [epc-object-naming-services] 442 currently only specifies how to perform a lookup for a GTIN class 443 identifier, which represents a product type. It does not currently 444 specify that ONS should be used for lookup of fully serialized 445 identifiers. While the number of GTIN codes may be a manageable 446 number, the potential number of serialized SGTIN identifiers is much 447 larger. Already in EPCglobal Tag Data Standards, the structure of 448 SGTIN identifiers are defined such that it is theoretically possible 449 to create in excess of 10^38 unique SGTIN identifiers for each GTIN 450 code that is currently resolvable using ONS 1.0. Already there are 451 some companies who create over a billion objects per year for a 452 single GTIN class. 454 It was therefore a very wise decision of EPCglobal not to propose 455 that ONS 1.0 should store a DNS record for each unique EPC, since the 456 number of resulting DNS records could clearly overwhelm the DNS 457 infrastructure. 459 However, there is currently a missing element in the EPCglobal 460 Network architecture, namely a search service that provides 461 authorized authenticated clients with links to the multiple 462 organizations who hold information about the unique life history of 463 an individual object. This missing element is essential for enabling 464 robust track and trace applications. Because this element 465 ('Discovery Services') has not yet been defined, there is a danger 466 that some organizations may misuse the ONS design and begin creating 467 DNS records for each fully serialized object. There is already one 468 industry pilot where this is happening. It is therefore essential 469 that rapid progress should be made towards a protocol for Discovery 470 Services that avoids placing such a burden on the DNS infrastructure. 472 To summarize, there are two variations to the ONS specifications that 473 can be observed in current deployments. The first variation is an 474 extension to the ONS structured hostname to include serialized level 475 data (serialized SGTIN) instead of just the specified class data 476 (GTIN class). The second variance involves the tendency of the 477 implementers to utilize the existing Internet root DNS servers 478 instead of operating alternate ONS roots. These variances could 479 adversely affect the stability of the public network infrastructure. 480 The IESG and IAB overview procedures at the IETF will ensure that the 481 protocol and architecture proposed by the ESDS Work Group will be 482 mindful of such deviations and take counter steps to prevent it. 484 2.2. Bootstrapping Concerns 486 The bootstrapping process enables an interested and authorized client 487 to locate an object's Discovery Service server using only the 488 information provided by the object identifier. Unlike DNS, where 489 there is a known set of root servers, ESDS will have numerous roots 490 for various communities (supply chains) operating globally. This, in 491 turn, complicates the bootstrapping process. 493 A common bootstrapping scenario would be exception handling in a 494 trade supply chain. For example, if an object is mis-delivered, a 495 recipient who has no pre-existing relationship to the trade supply 496 chain, needs to obtain object ownership information and its 497 corresponding Discovery Service server. ESDS design must aim to 498 accommodate this scenario while respecting privacy and security 499 considerations. 501 It has been suggested that ONS could be used for the bootstrapping 502 process. However, ONS-URN encoding and decoding scheme is only 503 defined for EPC identifiers and ESDS is being architected to support 504 non-EPC identifiers as well. Also, ONS's hierarchical identifiers 505 have raised privacy and security concerns by multiple participants in 506 some Discovery Service scenarios. While ONS can technically support 507 multiple identifier schemes, with multiple issuing authorities, its 508 hierarchical operation does depend on structured identifiers (for 509 example, ManagerNumber.ObjectType.SerialNumber). These identifiers 510 display information about the object they are representing, such as 511 type and manufacturer and as a result could compromise the privacy of 512 an individual using the identifier. Additionally, ONS has no 513 authentication nor access control restricting who can query it. ESDS 514 must be designed for serial-level lookups and must support 515 unstructured opaque identifiers to use as lookup keys within an ESDS 516 service. Because serial-level lookup information could potentially 517 be subject to data mining by competitors, to reveal information about 518 volumes and flows of goods, ESDS should fully support authentication 519 and serial-level access controls to address concerns about privacy 520 and confidentiality of data. 522 To facilitate bootstrapping and exception handling scenarios ESDS 523 design could investigate the use of peer-to-peer lookup protocols 524 (such as JXTA [jxta-protocols]) as an alternative to hierarchical 525 lookup protocols such as DNS and ONS. This would keep the ESDS 526 traffic flat and avoid walking up the Internet root hierarchy. A 527 major concern is that the bootstrapping design must not implicitly 528 establish monopolies in the long run. The IETF process will ensure 529 that the resulting protocol design addresses the concerns of both the 530 end-users and the network operators. 532 3. Other Standards 534 Discovery Services address a problem domain that is not fully covered 535 by any existing protocols. Discovery Services enables authorized and 536 authenticated users, to gather and retrieve links to resources of 537 information about a topic or an object, this information is typically 538 fragmented across multiple organizations and domains. While there 539 are related standards such as ONS, EPCIS, and UDDI, each of these 540 address different problem statements and domains as follows: 542 3.1. Object Naming Service (ONS) 544 ONS is a mechanism that leverages the Domain Name System (DNS) to 545 locate sources of authoritative information and related services 546 about a product when queried using a hostname derived from the 547 Electronic Product Code (EPC). Its query interface as currently 548 defined lacks access controls, authorization and authentication and 549 this security deficiency makes it unsuitable for a Discovery Service 550 handling commercially sensitive serial-level information. The 551 volumes of serial-level records generated by the supply chains would 552 place an unreasonable burden on the DNS roots if ONS were mis-used 553 for holding ONS records for each serial number. However, Discovery 554 Service can be used in collaboration with ONS to meet specific 555 business requirements. [epc-object-naming-services] 557 3.2. EPC Information Services (EPCIS) 559 EPCIS targets the sharing of data within an established network of 560 trust and relationships. Typically, a company can provide an EPCIS 561 query interface to allow trusted organizations to retrieve some of 562 its data. It is not the role of EPCIS to enable robust linking to 563 information across the entire supply chain or product lifecycle, nor 564 to perform recursive 'proxy queries' to retrieve data from other 565 parties, nor to facilitate exception handling and object 566 bootstrapping across the whole supply chain. 567 [epc-information-services] 569 3.3. Universal Description Discovery and Integration (UDDI) 571 UDDI is a standard for description and discovery of services and the 572 functionality that they offer. In contrast with UDDI, ESDS is 573 concerned with locating services that provide information about a 574 specific physical object; the ID of a physical object is the primary 575 lookup key for ESDS, whereas UDDI is primarily queried for a 576 particular type of service functionality desired. Unlike UDDI 577 registries, the data held within some Discovery Services may be much 578 more commercially sensitive. For example a supply chain Discovery 579 Service, could reveal volumes and flows of goods in supply chains; 580 from a security and scalability perspective, ESDS therefore attempts 581 to solve a more challenging problem than the problem that UDDI 582 already solves. 584 3.4. Interface for Metadata Access Point (IF-MAP) 586 The protocol, IF-MAP, defines a simple publish/search/subscribe 587 interface to the MAP. The MAP is a common metadata database. Within 588 the MAP, metadata automatically aggregates with respect to common 589 unique keys (i.e. identifiers). 591 While IF-MAP's initial use-cases are in coordinated security, it was 592 designed to meet other coordinated computing use-cases and may be 593 appropriate for ESDS. However, IF-MAP does not provide historical 594 information (according to section 2.2 of the IF-MAP protocol). A 595 major use for ESDS is to maintain historical link information between 596 the ID of a physical object (or a discussion topic or keyword) and 597 multiple entities who have collected/ generated some information 598 about that individual object (or discussion topic or keyword) at 599 previous times. 601 IF-MAP is concerned with building a graph to build associations 602 between different identifiers and pieces of meta-data. With ESDS, 603 the internal data model is concerned primarily with time stamped 604 events containing associations between: 606 - ID of object (or keyword/topic) 607 - URL of resource that holds more detailed information 608 - [ timestamps to help with sorting into chronological order and 609 completeness of result sets ] 610 - [ serviceType indicating what kind of resource to expect at the 611 URL ] 612 - [ other metadata that provides additional context or is helpful 613 for defining access control policies ] 615 Furthermore, ESDS may also need to handle an additional data model of 616 the access control policies it is expected to enforce by the 617 publishers of information. 619 Authorization model is outside the scope of IF-MAP (according to the 620 footnote 3 on p49 of the IF-MAP protocol), "3 An IF-MAP server 621 implementation may provide an authorization model, which protects 622 data published by one IF-MAP client from being visible to another IF- 623 MAP client. The specifics of such an authorization model are outside 624 the scope of this specification." 626 The ability to enforce an authorization model based on policies 627 defined by individual publishers is a key functional requirement for 628 ESDS. Without this, many end-users will not publish data to it if it 629 cannot be protected (hidden) from other end-users with whom they do 630 not wish to share this information. 632 In IF-MAP, the link is an un-named bi-directional binding 633 relationship between two identifiers. (S.2.6.2 of IF-MAP protocol). 634 In ESDS, there will be 1-many links: One entity (or information 635 provider) may hold information about many different individual 636 physical objects (or many different topics / keywords). One 637 individual physical object (or topic/keyword) may be linked [via 638 ESDS] to multiple entities that hold more detailed information 639 fragments about it. 641 However, in supply chain applications, resource owners may prefer 642 that the link cannot be discovered the other way, e.g. by querying a 643 Discovery Service with the address of a resource in order to retrieve 644 a list of IDs of all the objects it claims to hold information about. 645 ESDS will need to provide for such directionality restrictions on how 646 links can be discovered. 648 4. Related Standards Development Organizations 650 Discovery Services is an interesting problem with significant 651 challenges for both end-users and service providers. To tackle these 652 challenges, the problem must be approached from both viewpoints, to 653 ensure that the final adopted solution meets the needs of all 654 organizations involved. 656 The EPCglobal Data Discovery Joint Requirements Group (JRG) is in the 657 process of gathering use cases and user requirements in order to 658 define a Discovery Services standard which can meet the needs of 659 supply chain participants and end-users. In a parallel and 660 complementary effort, ESDS is addressing the technical challenges of 661 Discovery Services, such as its deployment on public network 662 infrastructures. The final goal is to share the lessons learned in a 663 co-operative effort to forge a single standard protocol. 665 ESDS is chartered to produce draft proposals for the Discovery 666 Service protocol. Similar to the manner in which the ONS standard 667 adopted the approach and architecture developed by the IETF DNS Work 668 Group, it is the intention of the ESDS activity that any draft 669 protocols developed will be useful to EPCglobal and will help to 670 accelerate the development of an EPCglobal standard for Discovery 671 Services. 673 5. Objectives 675 This section outlines the objectives of the ESDS protocol. In an 676 effort to convey the goal of each objective, possible solutions are 677 provided in order to trigger discussion on the subject matter. 679 5.1. Flow Diagrams 681 Draft flow diagrams for a directory based model of sharing reference 682 information. 684 Diagram showing the publish of reference information by multiple 685 organizations: 687 +-------------------------------------------------------------------- + 688 | ESDS Server | 689 | | 690 | Community_1 | 691 +---------------------------------------------------------------------+ 692 ^ ^ ^ 693 |ESDS Record Published |ESDS Record Published |ESDS Record Published 694 |for an individual |for an individual |for an individual 695 |object X |object X |object X 696 |(containing reference |(containing reference |(containing reference 697 | to sources | to sources | to sources 698 | of information) | of information) | of information) 699 |Subject to access |Subject to access |Subject to access 700 |control privileges |control privileges |control privileges 701 | | | 702 +------------------+ +------------------+ +------------------+ 703 | ESDS | | ESDS | | ESDS | 704 | Publish | | Publish | | Publish | 705 | Client | | Client | | Client | 706 | | | | | | 707 | Organization_1 | | Organization_2 | | Organization_3 | 708 +------------------+ +------------------+ +------------------+ 710 Figure 1 712 Diagram showing the query client sending a request to a virtual 713 community to retrieve list of resources for an object or topic. 715 +------------------------------------------------+ 716 | ESDS | 717 | Client | 718 | Query | 719 | +------------------> 720 | Organization_4 | 3. Reference 721 +------------------------------------------------+ information is 722 | ^ passed to other 723 |1. ESDS Query |2. ESDS Query response applications 724 | for an individual | for the individual to access the 725 | object X | object X detailed 726 | | (contains references information 727 | | to sources 728 | | of information) 729 | | Subject to access 730 v | control privileges 731 +--------------------------------------------------------+ 732 | ESDS Server | 733 | | 734 | Community_1 | 735 +--------------------------------------------------------+ 737 Figure 2 739 5.2. Security 741 Since ESDS needs to be deployable over a public network 742 infrastructure, issues of security and privacy are of heightened 743 importance. Clients must be authenticated to prevent theft of 744 information and resources must be authenticated to ensure integrity 745 of information. The information routed over the Internet must be 746 encrypted. It is suggested that the security model should be based 747 on open standards, trusted by the industry. 749 The ESDS protocol should be decoupled from the security layer and not 750 have embedded components specific to certain security protocol 751 implementations. This will enable ESDS implementations to respond 752 quickly to changes in the ever advancing security layer protocols. 754 5.2.1. Access Control 756 An ESDS should provide a resource with the ability to protect its 757 link information in order to retain control over which clients are 758 allowed to read this information. Such rules may be expressed in the 759 form of access control policies which are evaluated against the 760 client's authentication and authorization credentials and its role in 761 relation to the provider of the resource, as well as other criteria 762 such as the time elapsed since the link was published. 764 ESDS needs to define the granularity of information at which access 765 control policies are specified and enforced. Whether they apply to 766 individual events as atomic indivisible entities, or they can specify 767 which data fields to include or omit. 769 A situation may arise where a client and the provider of a resource 770 have no existing trust relationship with each other. An ESDS should 771 allow a resource to specify multiple levels of 'visibility' to such a 772 client, so that the resource either remains completely 'silent' or 773 'invisible', or so that an opaque handle is visible. The opaque 774 handle should not reveal the identity of the resource in any way, but 775 can be used to facilitate the initial negotiation between a client 776 and a resource, such as forwarding a number of messages from the 777 client to the provider of the resource, provided that the client 778 specifies the handle in their message, and provided that an ESDS or 779 associated service incorporates such a mechanism. To protect the 780 resource provider and ESDS from additional burden, such a facility 781 may be limited in the number of messages which are forwarded and the 782 time window following the client's query during which forwarding of 783 messages is offered. 785 It is recommended that ESDS follows existing standards for defining 786 access control policies, such as XACML. ESDS should study for the 787 BRIDGE project work package 4 (Security) on recommendations for 788 access control interface and protocols 789 [bridge-network-confidentiality]. 791 5.3. Publish 793 An ESDS must provide a mechanism whereby a resource can dynamically 794 establish a link for an individual object (or list or range or class 795 of objects) that points from the ESDS to the resource. The link can 796 be expressed as a string or URI and it is helpful if this is 797 accompanied by an indication of the type of service which can be 798 accessed via the link (in order to distinguish between web pages, web 799 services, EPC Information Services (EPCIS) and other communication 800 mechanisms which might even include phone or fax numbers). 802 5.4. Query 804 An ESDS should provide a mechanism whereby a client can query the 805 ESDS in order to retrieve a list of links to one or more resources. 807 Queries may be one-time queries or standing queries, and an ESDS may 808 support either type of query, or both. 810 The query interface needs to define the criteria fields as well as 811 acceptable criteria values, such as regular expressions or wildcards. 813 The ESDS Work Group should decide on whether to support multilayer 814 information visibility. A query with limited access can be informed 815 of the existence of information for a particular object, but to view 816 the actual information, full access privileges would be required. 817 This has particular implications for peer-to-peer searching across 818 multiple Discovery Services. Another scenario to consider is whether 819 visibility into the information in the extended fields of a published 820 event, should be controlled independently of event information? (i.e. 821 should access control policies be sufficiently expressive that they 822 can grant or deny access to individual data fields within events, 823 rather than simply granting or denying access to events) This has 824 particular implications for tracking aggregation and disaggregation 825 events and visibility into the entire lifecycle of an object. 827 5.5. Relabel/Aggregation/Disaggregation 829 To provide complete and resilient visibility across the entire life 830 of an object or a product, it is required that changes in identifiers 831 are maintained in the Discovery Service layer. 833 One scenario for relabeling can be a Discovery Service for 834 maintenance of installed software packages. An organization with a 835 multitude of machines, deployed anywhere on the Internet could use DS 836 to notify machines about the availability and location of (secure and 837 tested) updates to packages. Each machine can submit standing- 838 queries to the DS, for all the packages that are installed on it 839 locally. The organization operators would test and verify every new 840 release of a package. Once a package is approved, it is placed on 841 trusted file servers and the link to those files (and any mirror 842 links) is published to DS along with the package name. This would 843 result in all the machines with standing-queries to be notified of 844 the new downloadable and verified package. Package name change is a 845 common phenomena, specially when the version number is appended to 846 the package name (e.g. wxWidgets libraries). So ESDS needs to 847 provide relabeling facilities in order to be comprehensive enough to 848 address a wide range of problem domains. 850 Another scenario requiring the capture of aggregation and 851 decomposition events is the regulation of the European parliament 852 with respect to the cold supply chain regarding the tracking of fresh 853 meat. For example, as a cow moves from a farm into the supply chain 854 where it is finally sold as beef to a consumer at a retail store, it 855 is vital that relabelling and disaggregation events can be stored 856 within a Discovery Service in order to enable querying information 857 about the entire lifecycle of the cow "from farm to fork" While 858 having access control over visibility of these kind of events is 859 desired, it is recommended that Discovery Services should not attempt 860 to interpret or validate these events. It has been suggested that 861 these complexities be excluded from the core of ESDS, instead 862 facilitating them via the extensions mechanism and/or leaving such 863 interpretation, validation and analysis to client applications that 864 query ESDS. This approach must also give consideration to providing 865 access control to the extension information. 867 5.6. Multiple Organizations 869 It is the intention of ESDS to provide authorized clients with the 870 link referral information necessary to enable client applications to 871 gather information from multiple organizations covering an object's 872 or a topic's lifespan. For a product this could include link data 873 from the design phase, through manufacture, distribution and retail, 874 usage period (including service, repair, maintenance, overhaul) and 875 even end-of-life phase (including collection, sorting, 876 remanufacturing and recycling). So it could be desirable to record 877 the current phase. Also there may exist lifecycle steps within a 878 particular phase, a higher perspective or meta view could show that 879 entire phase as a single step in the life of the product. For 880 example, a product can be in a Manufacturing supply chain, then move 881 into a Logistics supply chain, followed by a Service supply chain. 882 Each of these particular supply chains may have their own set of 883 lifecycle steps, but the entire lifecycle is spread across all three 884 supply chains. ESDS should facilitate the linking of these supply 885 chains and phases together to enable the capture of the entire 886 lifecycle of the object. 888 5.7. Identifier Agnostic 890 To enable the grouping of information belonging to the same object, 891 each object needs to be uniquely identifiable. Information about the 892 object is held by a number of independent organizations that agree to 893 use a shared identifier schema. These identifier schemas are defined 894 and distributed by numbering authorities in each industry sector. 895 Some numbering authorizes guarantee global uniqueness of the issued 896 identifiers, but this is not the case all the time. Especially when 897 there exists issued legacy numbers currently in use within the domain 898 of a numbering authority. Also there are cases were numbering 899 authorities for different domains have collisions in their space of 900 issued identifiers (e.g. Animal Identification Number (AIN), 901 National Stock Numbers (NSN), and the International Mobile Equipment 902 Identity (IMEI) are all 15 digit identities and there are collisions 903 in the space of issued identities.). 905 There are procedures for converting identifiers to URIs which can 906 also assure that the URI is globally unique. However although global 907 uniqueness of identifiers is highly desirable for use within a co- 908 operating federation of Discovery Services, it is not a requirement 909 for each individual instance of a Discovery Service, and it would be 910 out of scope for a Discovery Service to verify global uniqueness for 911 identifiers used. 913 To define a protocol which is applicable to all scenarios, it is 914 essential that the protocol supports various numbering authorities. 915 The ESDS protocol should have a broad scope and support multiple 916 identifier schemes including schemas with non-unique identifiers. 917 The intelligent handling of identifier associated with an object is 918 out of scope of Discovery Services and can be handled accordingly by 919 ESDS query applications. It must also be identifier agnostic in 920 order for Discovery Services to be embraced by all potential 921 adopters. 923 5.7.1. Reusing Identifiers 925 There are scenarios where the same object (and its identifier) is 926 used within a Discovery Service but in different sessions or phases. 927 It could be the case that the authorization and access control 928 policies differ based on attributes such as timestamps, or metadata. 929 An identifier reuse scenario can be for reusable assets and other 930 returnable transport items that may circulate among multiple 931 organizations - and in many situations, it may be more economical and 932 more feasible to tag the reusable asset than to tag its contents. 933 This is particularly true when attaching not only a unique ID tag but 934 also environmental sensors to the reusable asset. 936 Company A that provides and manages reusable assets can provide an 937 additional service to its customers, such as company B (which borrows 938 or leases an asset from company A), by allowing company B to access 939 data about the asset while it carries the products from company B. At 940 the same time, there are benefits to company A in being able to track 941 its own assets, to balance supply and demand of assets and detect 942 when assets are not being returned correctly, e.g. for cleaning and 943 repair. 945 However, it is also very important to protect the confidentiality of 946 the data for company B from its competitor, company C, who may happen 947 to use the same asset at a later time. 949 One possible solution to this is for company A to dynamically manage 950 access permissions to data about the asset and its contents using 951 time-based windows that provide its customers with visibility only to 952 data about the asset during the time periods when it is associated 953 with their products or their lease/use of the asset. 955 This could be achieved by appending additional time-based constraint 956 qualifications to access control policies. 958 For example, company B could be granted visibility to track and trace 959 data about the asset for events that occur after they take custody of 960 the asset and before they relinquish custody of the asset. Company C 961 might be granted access for a different time window. There should be 962 no overlap between the time windows granted to competing companies, 963 in order to protect the confidentiality of their data. 965 5.8. Extensible 967 The event data needs to accommodate various scenarios and their 968 business requirements. Therefore it must be an extensible protocol 969 which enables the collaborating organizations to communicate messages 970 specific to their industry and terminology. 972 An ESDS protocol should enable the sharing of information without 973 involving the business rules of various scenarios. This will keep 974 the interface clean and uniform across all scenarios and ESDS 975 services. 977 ESDS should give consideration to approaches for dealing with access 978 control and visibility of extended information and protocols. One 979 approach could be to provide one level of access to all the event 980 information, whereby if a client can access an event information, it 981 can retrieve the extended information. Another approach could be to 982 provide multilayer visibility, where only clients with proper 983 privileges can retrieve the extended information. 985 5.9. Policies 987 The Retention policy for data records in ESDS would vary based on the 988 business and regulatory requirements. Some scenarios would need 989 retention of only few days and some would require retention for 30 990 years. Some other policies with similar parameters but different 991 interpretation are the archiving policies, purging policies, and 992 audit policies. 994 5.10. Stale Links 996 There are situations where the link information (such as a URL) that 997 was originally specified is no longer effective (e.g. because the 998 provider of the resource has not taken care to maintain redirection 999 from the original link address to the new location of the resource 1000 when restructuring a website or moving to a different domain name). 1001 In such situations, it is desirable that a Discovery Service could 1002 provide a client with link information that is current and effective. 1003 For audit purposes, it may also be necessary for an ESDS to be able 1004 to retain and reconstruct the original (or previous) link 1005 information, even if it is no longer effective. 1007 This may also imply that an ESDS should allow a resource provider to 1008 loosely couple the link record with the current link address, to ease 1009 migration of multiple records to a new resource address, while still 1010 providing a mechanism to recover a full audit trail of such changes 1011 of link addresses. This is particularly important when the link 1012 records are digitally signed and we wish to avoid having to "void" 1013 such records merely because they embedded a URL which is no longer in 1014 service. 1016 5.11. Peer-to-Peer Communications 1018 Architecting a bootstrapping policy will involve defining a protocol 1019 for peer-to-peer communication between Discovery Services (DS). The 1020 ultimate goal is to locate the target DS without dependence on 1021 hierarchical information and services such as ONS or the underlying 1022 DNS. To facilitate the peer-to-peer communication it is recommended 1023 that existing protocols and proven architectures such as JXTA 1024 [jxta-protocols] be utilized. Another candidate architecture is 1025 ECRIT's approach to locating authoritative sources of information in 1026 a peer-topeer network [ecrit-mapping-arc]. 1028 One point to keep in mind with DSs is that finding one target DS does 1029 not mean that the search is over. One object identifier could be 1030 acceptable to many DSs; therefore a search cannot stop once a DS is 1031 located but needs to propagate to all peers. 1033 Care and consideration must be given to privacy and the sensitivity 1034 of information at the DS nodes. It is also critical that steps are 1035 taken to protect against increased vulnerabilities that the extra 1036 exposure that P2P brings, such as denial-of-service attacks, or data 1037 mining tricks. 1039 Another challenge is when the target DS is successfully located. How 1040 much information on an object inquiry can that DS share with the peer 1041 DS, without jeopardizing security and privacy? Should the DSs 1042 facilitate the peer-to-peer access negotiation process or should it 1043 be done by the Certificate Authority? 1045 A sample scenario would be a query client negotiating for access to 1046 information from an organization where the information-providing 1047 organization does not have an established business (trust) 1048 relationship with the client and therefore chooses initially not to 1049 reveal its identity to the client. In this case, it is possbile to 1050 use the opaque 'node ref' concept and perhaps each object can have 1051 such a 'node ref' handle to deal with such scenarios 1052 [bridge-discovery-services-design]. Considerations must be given to 1053 protection against data mining to discovery whether a serial number 1054 exists or has been issued. 1056 6. Technical Challenges 1058 ESDS should be purely an application layer protocol disassociated 1059 from implementation specifics and challenges. Below are some of the 1060 technical challenges that certain business requirements demand. 1061 However ESDS is not chartered to address these implementation 1062 challenges. 1064 6.1. Auditability 1066 Based on some business and regulatory requirements, auditing 1067 capabilities should be facilitated by ESDS to provide accountability 1068 if and when something goes wrong. With an auditing mechanism, record 1069 data can be tracked and the person responsible identified, thus a 1070 series of data records can be reconstructed at a later date, allowing 1071 the Discovery Service operators to prove who was responsible for 1072 which data records [bridge-security-analysis]. 1074 6.2. Responsiveness 1076 ESDS implementations will need to be designed to accept updates in a 1077 close to real time basis from multiple providers of information 1078 across the globe. Because they store serial-level records, they will 1079 need to be sufficiently scalable to store large volumes of data, 1080 possibly up to trillions of records per year. 1082 6.3. Availability 1084 ESDS availability requirements would vary from business case to 1085 business case. Research by BRIDGE shows that the uptime requirements 1086 for some supply chain business cases are 99.99% year round. 1088 It is expected that the ESDS instances will be available over a 1089 shared network that exposes them to the effects of network attacks. 1090 Furthermore, in many cases it is expected that these components 1091 should be globally reachable from the Internet and not hosted on a 1092 secure private network. Such components are also built using 1093 commonly available Operating Systems and middleware (e.g. 1094 Application Servers). Thus they are also subject to any 1095 vulnerabilities of these supporting systems. 1097 A major security issue for shared services such as the ESDS is 1098 service availability. In particular if services are considered to be 1099 vital for businesses and organizations (e.g. "pharma e-Pedigree" or 1100 "product-authentication") ESDS needs to be able to guarantee minimal 1101 amount of service downtime due to security vulnerabilities and 1102 attacks [bridge-security-analysis]. 1104 7. Related Activities 1106 Currently, the standards organization EPCglobal, and EU research 1107 projects BRIDGE, SMART, and PROMISE are looking into the global 1108 supply chain track-and-trace challenge. As part of their research, 1109 each of them has identified the need for Discovery Services to link 1110 resources and clients in the supply chains. 1112 EPCglobal is beginning to gather user requirements for Discovery 1113 Services. However, EPCglobal is a paid membership organization 1114 focused on serving their own subscriber community. Although the 1115 final ratified EPCglobal standards are open and freely available to 1116 download, the subscription fees for joining the EPCglobal community 1117 may deter a significant proportion of the end-user community from 1118 directly participating in the development of their global standards. 1120 IETF would be the ideal body to oversee the development of this 1121 protocol because of its deep knowledge of Internet infrastructure and 1122 experience with development of application layer protocols. 1124 An IETF working group would be an inviting and open community which 1125 facilitates contribution and participation of all interested parties 1126 involved in the global supply chain as well as other potential 1127 industries with organizations enthusiastic about the benefits of 1128 collaboration with each other. The output would be released as a 1129 freely available RFC in the public domain. ESDS will make best 1130 efforts to ensure good communication with complementary activities at 1131 EPCglobal, in order to ensure that the output of ESDS is as relevant 1132 and useful as possible to a future EPCglobal standard for Discovery 1133 Services. 1135 8. Acknowledgements 1137 This document and the process of authoring was made possible by the 1138 excellent xml2rfc tool [RFC2629]. Credit must also be given to Scott 1139 Hollenbeck author of [RFC4930] for the organization and grouping of 1140 RFC sections. 1142 9. Contributors 1144 Dr. Mark Harrison 1145 Senior Research Associate, Distributed Information and Automation 1146 Laboratory 1147 Director, Auto-ID Labs at Cambridge 1148 Institute for Manufacturing 1149 University of Cambridge 1150 Mill Lane 1151 Cambridge, UK 1152 CB2 1RX 1154 Phone: +44-(0)1223-338178 1155 Email: mark.harrison@cantab.net 1157 Michael Young 1158 Senior Director, Technology 1159 Afilias Canada 1160 204-4141 Yonge Street 1161 Toronto, ON M2P 2A8 1162 CA 1164 Phone: +1-416-646-3304 1165 Email: myoung@ca.afilias.info 1167 10. IANA Considerations 1169 This document has no actions for IANA. 1171 11. Security Considerations 1173 This document is a problem statement that does not by itself 1174 introduce any security issues. 1176 12. References 1178 12.1. Normative References 1180 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1181 June 1999. 1183 [RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1184 RFC 4930, May 2007. 1186 12.2. Informative References 1188 [bridge-discovery-services-design] 1189 BRIDGE, "BRIDGE WP02 High-level design for Discovery 1190 Services", August 2007. 1192 [bridge-network-confidentiality] 1193 BRIDGE, "BRIDGE WP04 Security Analysis Report: RFID 1194 Network Confidentiality (D 4.5.1)", December 2007. 1196 [bridge-security-analysis] 1197 BRIDGE, "BRIDGE WP04 Security Analysis Report", July 2007. 1199 [bridge-serial-level-lookup-requirements] 1200 BRIDGE, "BRIDGE WP02 Serial Level Lookup Requirements", 1201 August 2007. 1203 [draft-thompson-esds-commands] 1204 Thompson, F., "Extensible Supply-chain Discovery Service 1205 Commands (work in progress)", February 2008. 1207 [draft-thompson-esds-schema] 1208 Thompson, F., "Extensible Supply-chain Discovery Service 1209 Schema (work in progress)", February 2008. 1211 [ecrit-mapping-arc] 1212 Schulzrinne, H., "Location-to-URL Mapping Architecture and 1213 Framework", September 2007. 1215 [epc-information-services] 1216 EPCglobal Information Services Work Group, "EPCglobal 1217 Information Services", September 2007. 1219 [epc-object-naming-services] 1220 EPCglobal, "Object Naming Service 1.0", October 2005. 1222 [epcglobal-tds] 1223 EPCglobal Tag Data Standard Work Group, "EPC Tag Data 1224 Standard Standard", March 2006. 1226 [jxta-protocols] 1227 Duigou, M., "JXTA v2.0 Protocols Specification", 1228 June 2004. 1230 Author's Address 1232 Ali Rezafard 1233 Afilias Canada 1234 204-4141 Yonge Street 1235 Toronto, ON M2P 2A8 1236 CA 1238 Phone: +1-416-646-3304 1239 Email: arezafar@ca.afilias.info 1241 Full Copyright Statement 1243 Copyright (C) The IETF Trust (2008). 1245 This document is subject to the rights, licenses and restrictions 1246 contained in BCP 78, and except as set forth therein, the authors 1247 retain all their rights. 1249 This document and the information contained herein are provided on an 1250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1252 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1253 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1254 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1257 Intellectual Property 1259 The IETF takes no position regarding the validity or scope of any 1260 Intellectual Property Rights or other rights that might be claimed to 1261 pertain to the implementation or use of the technology described in 1262 this document or the extent to which any license under such rights 1263 might or might not be available; nor does it represent that it has 1264 made any independent effort to identify any such rights. Information 1265 on the procedures with respect to rights in RFC documents can be 1266 found in BCP 78 and BCP 79. 1268 Copies of IPR disclosures made to the IETF Secretariat and any 1269 assurances of licenses to be made available, or the result of an 1270 attempt made to obtain a general license or permission for the use of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository at 1273 http://www.ietf.org/ipr. 1275 The IETF invites any interested party to bring to its attention any 1276 copyrights, patents or patent applications, or other proprietary 1277 rights that may cover technology that may be required to implement 1278 this standard. Please address the information to the IETF at 1279 ietf-ipr@ietf.org. 1281 Acknowledgment 1283 Funding for the RFC Editor function is provided by the IETF 1284 Administrative Support Activity (IASA).