[ESDS] (no subject)

Dear ESDS members

please find my comments inline within the problem statment document. They 
are
between :
---------
in italic
---------
I recognized that some of my remarks have been taken care of later in the 
document as i was writing them when reading through the document. 

I think it is a very good starting point and can definitely serve as basis 
although i would ev like to have it put a little but higher in abstraction 
and just use "supply chain" as an example instantiation of of the overall 
problem to be solved as supply chain is too heavily related to logistics 
as a business/functional term rather than an abstract term descibing a 
linked chain of information attached to a given object. But all this is 
only my 2 cents and i am happy to further discuss this.

Thanks for the good work and i am more than sorry that i couldn't 
participate in the meeting during the IETF conference.

Cheers

Gregor Baues
Chief Architect Application Infrastructure
Air France Information Systems

====================================================
Network Working Group                                        A. Rezafard
Internet-Draft                                            Afilias Canada
Intended status: Informational                         February 25, 2008
Expires: August 28, 2008

      Extensible Supply-chain Discovery Service Problem Statement
                draft-rezafard-esds-problem-statement-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

Rezafard                 Expires August 28, 2008                [Page 1]

Internet-Draft           ESDS Problem Statement            February 2008

Abstract

   This document discusses the requirements of an application layere
   protocol which can meet the needs of today's complex and dynamic
   supply chains. 

-------------------
I am not sure why we are talking here about an application layer 
protocol. In my opinion the ESDS protocol is application agnostic
and actually the notion of a supply chain can also be removed here
as this already is related to a business problem, albeit present in
many industries. 

The ESDS can be used for problems such as revenue management, concurrent 
engineering could have its application in Software configuration 
management
and i have many more ideas, the list is potentially endless. The point is 
that we want to get event information which at the lowest level has no 
business value at all as it is decorrelated from any business process. So
first we want to know that there has happened something related to an
object ( and here i literally mean object in the sense of software 
development - this object may have a physical instance such as 
a container or a can of soup but this is not strictly required but
I assume that this would be the case in 90% of all cases ) and second 
i want some more information about this object and the ESDS shall 
provide the service allowing me to access this information at the business
where the event has been captured. 

The whole point is about where the raw event capture is transformed
into a usable business event and who specifies the semantics of the event 
information. I argue that in most cases the transformation will be at 
the consumer side of the ESDS ( If i use Producer and Consumer they are 
basically different companies although it can happen that the producer 
and consumer are within the same business - but then the point of where 
business relevant events are produced is solved by default ) and the 
semantics depend on the industry or to be more precise to a given business 

process. In our case i would have different semantics for baggage handling 

than i would have for lets say terminal passenger flow management and i 
would not think that ESDS shall specify this semantic but shall provide 
a meta-model allowing business to specify event semantics and the 
resulting 
services to access ev. more information in the various IT systems of the 
involved companies. The semantics are making the application layer not the
ESDS by itself ESDS is on the infrastructure layer for me and in terms of 
the overall Enterprise Architecture ESDS will not show up at all it will
come into the game when doing the design and the implementation of a 
process.

Obviously ESDS has its own functional specifications as to be developed 
in this standard and can be seen as an application but not to be put up 
to the same level with business applications and enterprise architecture.

ESDS has to allow for a meta-model enabling enterprises to implement 
any granularity of business relevant information attached to the event
( such a life cycle information, location information, a WS URL allowing 
to get more information etc.. whatever is relevant to them and necessary 
by the business process ) 

------------------

   Currently, supply chain communication traffic travels
   over the Internet using existing Internet protocols, such as FTP,
   SMTP, and DNS.  This is a temporary solution for a growing niche.
   This document elaborates on issues that would arise if this trend
   continues.  Also, this document outlines a set of design concerns
   that an application layer protocol needs to address in order to be
   deployable in a real-world supply chain.

   This document obsoletes "Extensible Supply-chain Discovery Service
   Problem Statement draft-rezafard-esds-problem-statement-00".

   Comments are solicited and should be addressed to the mailing list at
   esds@ietf.org and/or the author(s).

Rezafard                 Expires August 28, 2008                [Page 2]

Internet-Draft           ESDS Problem Statement            February 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  6
     1.4.  Description  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Internet Concerns  . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  Public Networks and Tree-Walking Concerns  . . . . . . . .  8
     2.2.  Bootstrapping Concerns . . . . . . . . . . . . . . . . . .  9
   3.  Other Standards  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Object Naming Service (ONS)  . . . . . . . . . . . . . . . 11
     3.2.  EPC Information Services (EPCIS) . . . . . . . . . . . . . 11
     3.3.  Universal Description Discovery and Integration (UDDI) . . 11
   4.  Related Standards Development Organizations  . . . . . . . . . 13
   5.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.1.  Access Control . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Independence . . . . . . . . . . . . . . . . . . . . . . . 15
     5.3.  Publish  . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.4.  Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.5.  Relabel/Aggregation/Disaggregation . . . . . . . . . . . . 16
     5.6.  Lifecycle  . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.7.  Multiple Organizations . . . . . . . . . . . . . . . . . . 17
     5.8.  Identifier Agnostic  . . . . . . . . . . . . . . . . . . . 17
       5.8.1.  Reusing Identifiers  . . . . . . . . . . . . . . . . . 18
     5.9.  Extensible . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.10. Retention Policy . . . . . . . . . . . . . . . . . . . . . 19
     5.11. Stale Links  . . . . . . . . . . . . . . . . . . . . . . . 19
     5.12. Peer-to-Peer Communications  . . . . . . . . . . . . . . . 20
   6.  Technical Challenges . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Auditability . . . . . . . . . . . . . . . . . . . . . . . 21
     6.2.  Responsiveness . . . . . . . . . . . . . . . . . . . . . . 21
     6.3.  Availability . . . . . . . . . . . . . . . . . . . . . . . 21
   7.  Related Activities . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     12.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30

Rezafard                 Expires August 28, 2008                [Page 3]

Internet-Draft           ESDS Problem Statement            February 2008

1.  Introduction

   Currently, a number of industry sectors are moving towards improved
   track and trace systems by the use of Auto-ID technologies (such as
   Radio-Frequency Identification (RFID)) that improve the ability to
   automate collection of observations, as well as the use of unique
   identifiers for each individual object, to improve the granularity of
   information, so that it is possible to track not only at the
   granularity of batches or lots - but actually trace the entire life
   history of an individual object.  This is particularly important in
   the fight against counterfeiting and for assuring the traceability
   and authenticity of foods, pharmaceuticals and other safety-critical
   objects, such as aircraft and automotive parts.

   As well as automating the collection of such data, companies are also
   moving towards sharing and exchange of serial-level data, in order to
   improve the efficiency of supply chains.  This involves greater use
   of machine-to-machine information exchange, using standard interfaces
   for queries and output formats and requiring less intervention by
   human operators (e.g. exchanging spreadsheets via e-mail or FTP).
   However, serial-level data is commercially sensitive, since it can
   reveal information about stock levels and volumes and flows of goods.
   For this reason, most companies insist on maintaining strict control
   over who is granted access to their data.  The entire lifecycle
   information for an individual object therefore remains decentralized
   and fragmented across multiple actors in the supply chain or extended
   product lifecycle.  Discovery Services will provide secure referral
   services that can be queried with a unique ID and return to
   authenticated authorized clients a list of links to multiple
   information providers, who can then be queried for more detailed
   information about the individual object.

   At a conceptual level, Discovery Services can be superficially
   regarded as being somewhat analogous to a 'search engine' for an
   'internet of things'.  However, there are some fundamental
   differences from the paradigm of public web search engines.  The
   serial-level information will usually be protected and will only be
   made available to authorized partners, with whom the information
   provider has an established trust relationship.  For this reason, we
   cannot assume that Discovery Services will be able to automatically
   'spider' or 'crawl' the network to compile an index of links, since
   the underlying information may not be generally available.

-------------------------
I like this comparison as it actually shows my point. When running a
google query i get back a page which doesn't only contain links! It has 
already semantics as the serach results show the "title" information 
as well as some more information from the page not just the URL. The 
amount of information shown is a choice by google but can be defined 
at any granularity they want i am quite sure that they
have meta-model in the background they could instantiate as they want 
and the search engine produces different results all tailored today to 
speed
and quality. Looking into Enterprise search you get the security you need
also for ESDS services

-------------------------

   Instead, we assume that each information provider will be able to
   voluntarily publish an event or record for a particular unique ID, in
   order that a link can be established back to them as a potential
   provider of information.  At the same time, also the 'link'
   information will be protected by access control policies defined by

Rezafard                 Expires August 28, 2008                [Page 4]

Internet-Draft           ESDS Problem Statement            February 2008

   each information provider, as well as any policies which are imposed
   by the operator of a Discovery Service.  Unlike most public search
   engines, there may be little or no 'link' information provided to
   non-authenticated users or directly to the general public without
   authentication, although citizens may be provided access to
   traceability information via an authorized authenticated actor, such
   as the retailer or manufacturer.

   This approach enables distributed management of lifecycle data and
   allows each organization to restrict who can access the data; they
   can specify an access control policy (which is enforced by a
   Discovery Service) to limit visibility of the 'link' information -
   and additionally, they can specify and enforce an access control
   policy within their own information service that holds the more
   detailed event data.

1.1.  Background

   Traditionally supply chain communication has been routed over private
   network infrastructures.  However in recent years this practice is
   abandoned in favour of communication over public networks.  The
   communication and data exchange has taken the form of flat file data
   exchange, XML, and other proprietary forms across existing
   mechanisms, 
-----
I don't think the EDI community would say EDI is proprietary. But again 
here
EDI is a meta-model in which you will have to fit your needs and i agree
the EDI model was to open and could easliy be misused just as at the 
origin 
EAI was more or less misused by missing the point and as such only 
provided
application integration but not business services allowing integration on 
a 
higher level which SOA tries to solve today.
-----

   such as SFTP and SMTP.  This method of exchange requires
   bilateral agreements and networking arrangements amongst all partners
   of a given supply chain.  In this model, information sharing begins
   with the supply chain partner who provides lists of the objects
   (shipping manifest) 

-----
why use already an object specific to logistics ? Our first use-case 
hasn't 
any shipping manifest or ASN etc. ... Actually within baggage handling 
there are
business messages send around and tell the receiving airport ( or more 
precisely
the sorter at that airport what bags to expect but thats called a BPM, 
BSM, .... no shipping
manifest anywhere .... ) I would suggest to remove any reference to a 
given 
industry process and add an annex detailing an example where logistics is 
the 
the example of choice
----
-
   that the other partners can expect to receive and
   exchange within the supply chain. 

   While this one way method is
   effective in very static supply chain relationships, its main
   drawback lies in its inability to support dynamic routing of physical
   objects and, therefore, exception handling.  For example, if an
   object arrived at supply chain partner C without prior notification
   from supply chain partner B or A, the product remains unidentified
   and not routable.

   The advent of Radio Frequency Identification (RFID) tags has been a
   catalyst for the desire to reverse-lookup object information.
   Products are being tagged with RFID tags, traditional barcodes, and
   other types of proprietary object identifiers.  The exchange of
   information now begins with the object and leads back to the supply
   chain partner.  As the object is scanned at various key locations in
   the supply chain, a referral service must be available to match the
   object's identifier either to a relevant supply chain partner or to a
   list of relevant supply chain partners and the data services that
   these partners offer to a requestor.  This enables supply chains to
   route flexibly and handle exceptions.

-----
I don't know sufficiently about logistics processes and how they handle
a situation where an item ends up in a location where it shouldn't go. Who 

is in charge of the item ? In the scenario you depicted its the party who 
receives the item not the party who send it to the wrong place. But what 
if the receiving party simply doesn't care about the object ? Again in
our case a misrouted bag at the current stage will be registered with
the receiving party (because it will run through the sorters ) but that's 
it it will sit then somewhere in storage and nobody cares unless a request 

is logged with WorldTracer when the owner of the bag didn't get it. The 
match is made if the unkown bag is in the system and the query against 
that bag has been made and then we will have to charge our local partner 
to get the bag and put it back into the process. This is not automatic.

Using ESDS i can instruct our local partners automatically as i will get 
the event from the ESDS and our internal application will see its 
misrouted 
and send the fix request, inform the customer, etc ... all in one go
ESDS will enable this as it is a unique interface and i don't have to 
do 300 times B2B integration etc. That's why WorldTracer exists in the 
first place everybody uses it as it provides a unique way of B2B 
integration
( although more or less manual ) without creating burden and costs because 

others didn't do their job well. ESDS will push this to the next level if 
we as
an industry manage to deploy this - which is not going to happen 
over-night 
but thats a different topic.
-----

Rezafard                 Expires August 28, 2008                [Page 5]

Internet-Draft           ESDS Problem Statement            February 2008

1.2.  Terminology

   There are three actors in this problem:
   Client:  refers to an actor that seeks (sources of) information about
       an individual object.
   Resource:  refers to an actor that holds information about an
       individual object and may provide it to authenticated clients who
       satisfy some authorization criteria (access control policies and
       rules).
   ESDS:  refers to an intermediary lookup service that enables a client
       to locate one or more resources.

   What emerges from combinations of these actors and their
   relationships are:
   Partner:  refers to a business entity which is comprised of Client
       and Resource actors belonging to an organization.
   Supply chain:  refers to a group of partners that have the desire to
       share information among themselves. 
-----
Can't we say something like : 'Object information chain' but maybe
maybe in order to make the problem more understandable it is ok to use the 

term but i think it is semantically too narrow. I don't know if for the 
purpose
of this exercise it is to complicated to push the level of abstraction and 
have
a decent meta-model ( or a DSL - Domain Specific Language ) definig the 
problem but i think it could be worth the effort.
-----

1.3.  Problem Statement

   Information sharing between partners is essential for all modern
   supply chain networks.  There is a strict set of business and
   technical requirements that must be observed in order to enable open
   sharing of information in a supply chain.

   There are resources and clients in each supply chain.  Each resource
   wants to advertise its knowledge (data) to interested and authorized
   clients.  Only deploying private networks to connect whole supply
   chains is no longer feasible, as the more efficient and economical
   means of connecting resources and clients is to use public network
   infrastructure.  Currently, many supply chain track-and-trace
   initiatives are deployed on public networks and the information is
   routed through the Internet.  Because of this trend, it is highly
   desirable that a draft protocol should be developed.  An IETF process
   consensus would ensure that the adopted protocol conforms to the
   Internet's operational needs.

   A key principle of information sharing in the supply chain is that
   data ownership must be respected.  This means that each partner can
   collect information within their organization and is not required to
   route that information to any other partner.  However, they can
   choose to share selected information with other trusted partners.
   This in turn means that the complete lifecycle information about any
   individual object may be held by multiple resources throughout the
   supply chain or the product lifecycle.  Therefore a mechanism is
   needed in order to facilitate the gathering of this information.

Rezafard                 Expires August 28, 2008                [Page 6]

Internet-Draft           ESDS Problem Statement            February 2008

   A key requirement is that information accessibility is fully
   controllable.  The confidential information must be secure and hidden
   from unauthorized clients and only visible to the intended clients in
   a supply chain.  In order to establish trust and reputation with the
   participating resources, unauthorized clients need to be barred from
   viewing, eavesdropping, or deducing information.

   There must be a common set of data that all resources will offer
   (only to authorized clients).   This set must be defined and agreed
   upon in the final protocol.  This set may include answers to who,
   what, when, where, and why as well as links to back-end systems.  An
   essential feature is for the protocol to be extensible beyond the
   common data set to facilitate the needs of supply chains that
   discover additional uses.

-----
So we are actually talking about a set of meta-data ( besides time which
is a universally agreed upon invariant ) but e.g. "where" requires 
already some definition from the business using it and can have if it 
refers to a physical location many different coordinate systems. The same
is true for what : object identifier schemas a plentiful etc ... 
-----

   Defining a bootstrapping procedure is a necessity when designing a
   global and autonomous network of systems.  Currently there are
   deployed supply chain systems that bootstrap via Internet's DNS
   roots.  One example of this is the EPCglobal Object Name Service
   [epc-object-naming-services] (ONS).  While ONS enables an economical
   means of bootstrapping, improper implementations may increase the
   traffic on DNS roots exponentially.  Since data will be routed
   through the Internet, the bootstrapping procedure needs to be
   formulated under the IETF approval process.

1.4.  Description

   An Extensible Supply-chain Discovery Service (ESDS) provides a
   mechanism to locate one or more sources of information about an
   individual physical object.  This may include the original
   manufacturer or supplier of the object, as well as other
   organizations who have handled the object at some point during its
   lifecycle (including repair and maintenance organizations) and even
   organizations (such as customs or insurance agencies) who might hold
   information records related to the object, even though they may have
   never had physical custody of the object.

   This document defines the Problem Statement, Objectives and Technical
   Challenges related to the application layer protocol currently
   proposed as Extensible Supply-chain Discovery Services (ESDS).  ESDS
   enables the publishing and querying of referral links to information
   services that historical events related to specific objects with
   attached object identifiers.  The interface enables disparate
   applications to track-and-trace shared lifecycle views of object
   identifiers across a supply chain.  Primarily, ESDS provides referral
   services in a loosely coupled mechanism with granular security that
   enables selective visibility.

Rezafard                 Expires August 28, 2008                [Page 7]

Internet-Draft           ESDS Problem Statement            February 2008

2.  Internet Concerns

2.1.  Public Networks and Tree-Walking Concerns

   Currently, another standards body, EPCglobal, has issued a related
   standard referred to as ONS [epc-object-naming-services].  ONS is
   effectively an extended version of DNS that does not benefit from the
   IETF review process and, in its design, necessitates increased tree-
   walking.  ONS specifies a reverse mapping of the EPCglobal "SGTIN"
   (one type of supply chain object identifier) as a hostname and allows
   for a reference (i.e.  URL) to a manufacturer's relevant back-end
   system (using a NAPTR record).  The SGTIN identifier is comprised of
   an EPC Manager Number, an Object Class, and a Serial Number.  The ONS
   lookup excludes the Serial Number portion of the SGTIN.  However, the
   ONS specification has already been extended in industry pilot
   projects to include the Serial Number, as this enables item level
   lookups for tagged objects in the supply chain.  Using serial level
   lookups, ONS could be used to indicate point to point referrals
   through the passage of a relevant identifier throughout the supply
   chain.  This would require successive updates to the hierarchal ONS
   to indicate incremental supply chain partner referrals, reducing the
   effectiveness of caching.  Alternatively the ONS could provide a
   single, static point of referral to the first or initiating supply
   chain partner.  However, even a relatively static entry, which only
   refers to the point of origin within the supply chain, would drive
   the number of public zone entries to extremely large numbers if an
   individual record were created for each serial number.  The number of
   records could exceed the current IPv4 address space by several orders
   of magnitude.  Also since many of the tagged physical objects would
   neither require nor provide network connectivity, utilizing IPv6 for
   such objects would waste this finite address space resource
   unnecessarily.

   One common suggestion to manage this problem is to have multiple
   alternate ONS roots which can be managed for separate and unrelated
   supply chains and/or regions.  However, since there is nothing to
   prevent ONS from operating in the existing Internet root hierarchy,
   even alternate ONS providers can opt to drive traffic to the existing
   Internet root servers, rather than operate their own ONS roots.
   There has already been a pilot ONS implementation under the .aero
   zone (sgtin.id.ons.autoid.aero) where this phenomenon may already be
   observed.

   It should be noted that ONS 1.0 [epc-object-naming-services]
   currently only specifies how to perform a lookup for a GTIN class
   identifier, which represents a product type.  It does not currently
   specify that ONS should be used for lookup of fully serialized
   identifiers.  While the number of GTIN codes may be a manageable

Rezafard                 Expires August 28, 2008                [Page 8]

Internet-Draft           ESDS Problem Statement            February 2008

   number, the potential number of serialized SGTIN identifiers is much
   larger.  Already in EPCglobal Tag Data Standards, the structure of
   SGTIN identifiers are defined such that it is theoretically possible
   to create in excess of 10^38 unique SGTIN identifiers for each GTIN
   code that is currently resolvable using ONS 1.0.  Already there are
   some companies who create over a billion objects per year for a
   single GTIN class.

   It was therefore a very wise decision of EPCglobal not to propose
   that ONS 1.0 should store a DNS record for each unique EPC, since the
   number of resulting DNS records could clearly overwhelm the DNS
   infrastructure.

   However, there is currently a missing element in the EPCglobal
   Network architecture, namely a search service that provides
   authorized authenticated clients with links to the multiple
   organizations who hold information about the unique life history of
   an individual object.  This missing element is essential for enabling
   robust track and trace applications.  Because this element
   ('Discovery Services') has not yet been defined, there is a danger
   that some organizations may misuse the ONS design and begin creating
   DNS records for each fully serialized object.  There is already one
   industry pilot where this is happening.  It is therefore essential
   that rapid progress should be made towards a protocol for Discovery
   Services that avoids placing such a burden on the DNS infrastructure.

   To summarize, there are two variances to the ONS specifications that
   can be observed in current deployments.  The first variance is an
   extension to the ONS structure to include serialized level data
   (serialized SGTIN) instead of just the specified class data (GTIN
   class).  The second variance involves the tendency of the
   implementers to utilize the existing Internet root DNS servers
   instead of operating alternate ONS roots.  These variances could
   adversely affect the stability of the public network infrastructure.
   The IESG and IAB overview procedures at the IETF will ensure that the
   protocol and architecture proposed by the ESDS Work Group will be
   mindful of such deviations and take counter steps to prevent it.

2.2.  Bootstrapping Concerns

   Currently there are discussions on how to best facilitate a
   bootstrapping processes for objects in the supply chain.  The
   bootstrapping process enables an interested and authorized client to
   locate an object's Discovery Service server using only the
   information provided by the object identifier.  Unlike DNS, where
   there is a known set of root servers, ESDS will have numerous roots
   for various supply chains operating globally.  This, in turn,
   complicates the bootstrapping process.

Rezafard                 Expires August 28, 2008                [Page 9]

Internet-Draft           ESDS Problem Statement            February 2008

   A common bootstrapping scenario is exception handling.  For example,
   if an object is mis-delivered, a recipient who has no pre-existing
   relationship to the supply chain, needs to obtain object ownership
   information and its corresponding Discovery Service server.  ESDS
   design must aim to accommodate this scenario while respecting privacy
   and security considerations.

   It has been suggested that ONS could be used for the bootstrapping
   process.  However, ONS's hierarchical identifiers have raised privacy
   and security concerns by multiple participants in the supply chain.
   While ONS can technically support multiple identifier schemes, with
   multiple issuing authorities, its hierarchical operation does depend
   on structured identifiers (for example,
   ManagerNumber.ObjectType.SerialNumber).  These identifiers display
   information about products such as type and manufacturer and as a
   result could compromise the privacy of an individual carrying them,
   as well as the security of transportation within supply chains.
   Additionally, ONS has no authentication nor access control
   restricting who can query it.  ESDS must be designed for serial level
   lookups and must support unstructured opaque identifiers to use as
   lookup keys within an ESDS service.  Because serial-level lookup
   information could potentially be subject to data mining by
   competitors, to reveal information about volumes and flows of goods,
   ESDS should fully support authentication and serial level access
   controls to address concerns about privacy and confidentiality of
   data.

   To facilitate bootstrapping and exception handling scenarios ESDS
   design could investigate the use of peer-to-peer lookup protocols
   (such as JXTA [jxta-protocols]) as an alternative to hierarchical
   lookup protocols such as DNS and ONS.  This would keep the ESDS
   traffic flat and avoid walking up the Internet root hierarchy.  A
   major concern is that the bootstrapping design must not implicitly
   establish monopolies in the long run.  The IETF process will ensure
   that the resulting protocol design addresses the concerns of all
   participants in the global supply chain.

Rezafard                 Expires August 28, 2008               [Page 10]

Internet-Draft           ESDS Problem Statement            February 2008

3.  Other Standards

   Discovery Services addresses a problem domain that is not covered by
   any existing protocols.  Discovery Services enables authorized and
   authenticated users, to gather and retrieve links to all providers of
   lifecycle information about an object, this information is typically
   fragmented across the whole supply chain.  While there are related
   standards such as ONS, EPCIS, and UDDI, each of these address
   different problem statements and domains as follows:

3.1.  Object Naming Service (ONS)

   ONS is a mechanism that leverages the Domain Name System (DNS) to
   locate sources of authoritative information and related services
   about a product when queried using a hostname derived from the
   Electronic Product Code (EPC).  Its query interface as currently
   defined lacks access controls, authorization and authentication and
   this security deficiency makes it unsuitable for a Discovery Service
   handling commercially-sensitive serial-level information.  The
   volumes of serial-level records generated by the supply chains would
   place an unreasonable burden on the DNS roots if ONS were mis-used
   for holding ONS records for each serial number.  However, Discovery
   Service can be used in collaboration with ONS to meet specific
   business requirements.  [epc-object-naming-services]

3.2.  EPC Information Services (EPCIS)

   EPCIS targets the sharing of data within an established network of
   trust and relationships.  Typically, a company can provide an EPCIS
   query interface to allow trusted partners to retrieve some of its
   data.  It is not the role of EPCIS to enable robust linking to
   information across the entire supply chain or product lifecycle, nor
   to perform recursive 'proxy queries' to retrieve data from other
   parties, nor to facilitate exception handling and object
   bootstrapping across the whole supply chain.
   [epc-information-services]

3.3.  Universal Description Discovery and Integration (UDDI)

   UDDI is a standard for description and discovery of services and the
   functionality that they offer.  In contrast with UDDI, ESDS is
   concerned with locating services that provide information about a
   specific physical object; the ID of a physical object is the primary
   lookup key for ESDS, whereas UDDI is primarily queried for a
   particular type of service functionality desired.  Unlike UDDI
   registries, the data held within ESDS may be much more commercially
   sensitive because it could reveal volumes and flows of goods in
   supply chains; from a security and scalability perspective, ESDS

Rezafard                 Expires August 28, 2008               [Page 11]

Internet-Draft           ESDS Problem Statement            February 2008

   therefore attempts to solve a more challenging problem than the
   problem that UDDI already solves.

-----
I agree with this but would suggest to think of a coupled usage when 
billions 
of messages are involved and the overhead of sending the links just 
doesn't add
value. But maybe i am missunderstanding something here.

Service description and lifecycle management:
How do i get the service description of the partners service ? I will get 
from ESDS 
the URL but i don't know how the services at the other end looks like - or 
in
tech talk where does the WSDL come form if using webservices and if the 
other party 
requires two way PKI to use its system i am back to square 1 as i have to 
negotiate 
with him to get this set up ( hopefully this will not happen but i know a 
couple of 
sec execs who will be very nervous about this and put such an IS system in 
your DMZ 
is not a brilliant idea either ) with potentially 500+ partners this will 
be a 
nightmare. The lifecycle i.e. version management of the services will have 
to be
addressed as well.

As it stands for me services descriptions have been offloaded and will be 
deferred e.g.
to an industry body defining and standardizing the services.

Back on how to get to the URL :A more sophisticated way managing services 
to be called 
may be required such as keeping a routing table inhouse: I know upfront 
the URLs and 
manage them and/or ev learn about them. If i don't have the url for oid X 
from partner 
Z ( i know from whom it came ) so i can look it up inside the ESDS ( the 
same when a 
call fails i can cross check with the ESDS if the URL i have is not stale 
).

This means that partner Z will have to log its service url with ESDS every 
time a change
is happening to the URL to call.

Obviously this is more complicated that sending out the URL every time i 
log an 
event into the ESDS. 

I put this up as in full scale and with a globally deployed system across 
a major 
carrier network i would think that an airline will pull roughly 2 million 
events / day ( only
 for bags ) and receiving many times the same information is of little 
value but resource consuming.
------

Rezafard                 Expires August 28, 2008               [Page 12]

Internet-Draft           ESDS Problem Statement            February 2008

4.  Related Standards Development Organizations

   Discovery Services is an interesting problem with significant
   challenges for both end-users and service providers.  To tackle these
   challenges, the problem must be approached from both viewpoints, to
   ensure that the final adopted solution meets the needs of all
   organizations involved.

   The EPCglobal Data Discovery Joint Requirements Group (JRG) is in the
   process of gathering use cases and user requirements in order to
   define a Discovery Services standard which can meet the needs of
   supply chain participants and end-users.  In a parallel and
   complementary effort, ESDS is addressing the technical challenges of
   Discovery Services, such as its deployment on public network
   infrastructures.  The final goal is to share the lessons learned in a
   co-operative effort to forge a single standard protocol.

   ESDS is chartered to produce draft proposals for the Discovery
   Service protocol.  Similar to the manner in which the ONS standard
   adopted the approach and architecture developed by the IETF DNS Work
   Group, it is the intention of the ESDS activity that any draft
   protocols developed will be useful to EPCglobal and will help to
   accelerate the development of an EPCglobal standard for Discovery
   Services.

Rezafard                 Expires August 28, 2008               [Page 13]

Internet-Draft           ESDS Problem Statement            February 2008

5.  Objectives

   This section outlines the objectives of the ESDS protocol.  In an
   effort to convey the goal of each objective, possible solutions are
   provided in order to trigger discussion on the subject matter.

5.1.  Security

   Since ESDS needs to be deployable over a public network
   infrastructure, issues of security and privacy are of heightened
   importance.  Clients must be authenticated to prevent theft of
   information and resources must be authenticated to ensure integrity
   of information.  The information routed over the Internet must be
   encrypted.  It is suggested that the security model should be based
   on open standards, trusted by the supply chain industry.

   The ESDS protocol should be decoupled from the security layer and not
   have embedded components specific to certain security protocol
   implementations.  This will enable ESDS implementations to respond
   quickly to changes in the ever advancing security layer protocols.

5.1.1.  Access Control

   An ESDS should provide a resource with the ability to protect its
   link information in order to retain control over which clients are
   allowed to read this information.  Such rules may be expressed in the
   form of access control policies which are evaluated against the
   client's authentication credentials and its role in relation to the
   provider of the resource, as well as other criteria such as the time
   elapsed since the link was created.

   ESDS needs to define the granularity of information at which access
   control policies are specified and enforced.  Whether they apply to
   individual events as atomic indivisible entities, or they can specify
   which data fields to include or omit.

   A situation may arise where a client and the provider of a resource
   have no existing trust relationship with each other.  An ESDS should
   allow a resource to specify multiple levels of 'visibility' to such a
   client, so that the resource either remains completely 'silent' or
   'invisible', or so that an opaque handle is visible.  The opaque
   handle should not reveal the identity of the resource in any way, but
   can be used to facilitate the initial negotiation between a client
   and a resource, such as forwarding a number of messages from the
   client to the provider of the resource, provided that the client
   specifies the handle in their message, and provided that an ESDS or
   associated service incorporates such a mechanism.  To protect the
   resource provider and ESDS from additional burden, such a facility

Rezafard                 Expires August 28, 2008               [Page 14]

Internet-Draft           ESDS Problem Statement            February 2008

   may be limited in the number of messages which are forwarded and the
   time window following the client's query during which forwarding of
   messages is offered.

   It is recommended that ESDS follows existing standards for defining
   access control policies, such as XACML.  ESDS should wait for the
   BRIDGE project work package 4 (Security) on recommendations for
   access control interface and protocols.

5.2.  Independence

   In today's morphing supply chains there will always be resources that
   cannot or will not participate in track-and-trace efforts.  If a
   resource in a supply chain chooses not to participate, the protocol
   architecture needs to be tolerant of this missing link in the supply
   chain.  The only acceptable consequence of a non-participating
   resource would be to miss the information that would have been
   supplied had it participated.

   One of the problems with relying on 'following the chain' from the
   manufacturer to the current downstream custodian of the object is
   that there could be a broken link in the chain if one of the
   organizations does not provide an onward link - or if their
   information service is temporarily (or permanently) unavailable.  A
   Discovery Service should provide some resilience to ensure that, it
   is always possible to 'navigate beyond a broken link' to find who
   currently has the object.

5.3.  Publish

   An ESDS must provide a mechanism whereby a resource can dynamically
   establish a link for an individual object (or list or range or class
   of objects) that points from the ESDS to the resource.  The link can
   be expressed as a string or URI and it is helpful if this is
   accompanied by an indication of the type of service which can be
   accessed via the link (in order to distinguish between web pages, web
   services, EPC Information Services (EPCIS) and other communication
   mechanisms which might even include phone or fax numbers).

5.4.  Query

   An ESDS should provide a mechanism whereby a client can query the
   ESDS in order to retrieve a list of links to one or more resources.
   Queries may be one-time queries or standing queries, and an ESDS may
   support either type of query, or both.

   The query interface needs to define the criteria fields as well as
   acceptable criteria values, such as regular expressions or wildcards.

Rezafard                 Expires August 28, 2008               [Page 15]

Internet-Draft           ESDS Problem Statement            February 2008

   The ESDS Work Group should decide on whether to support multilayer
   information visibility.  A query with limited access can be informed
   of the existence of information for a particular object, but to view
   the actual information, full access privileges would be required.
   This has particular implications for peer-to-peer searching across
   multiple Discovery Services.  Another scenario to consider is whether
   visibility into the information in the extended fields of a published
   event, should be controlled independently of event information? (i.e.
   should access control policies be sufficiently expressive that they
   can grant or deny access to individual data fields within events,
   rather than simply granting or denying access to events) This has
   particular implications for tracking aggregation and disaggregation
   events and visibility into the entire lifecycle of an object.

5.5.  Relabel/Aggregation/Disaggregation

   To provide complete and resilient visibility across the entire life
   of a product, it is required that events involving object identifier
   changes can be held in the Discovery Service layer.

   One scenario requiring the capture of aggregation and decomposition
   events is the regulation of the European parliament with respect to
   the cold supply chain regarding the tracking of fresh meat.  For
   example, as a cow moves from a farm into the supply chain where it is
   finally sold as beef to a consumer at a retail store, it is vital
   that relabelling and disaggregation events can be stored within a

-------
Does this mean that events stored already have per se intrisinc semantics 
?
Does that cover/limit usage for other applications? What does relalbelling 
mean
within the functional scope of an ESDS? .Aggregation is a standard 
notation
if we use e;g. the description of UML for that thus allowing for 
meta-modelisation of
aggregates. But in the end aggregates are business objects which will have 
to be
 managed at each individual company as i don't believe that you can even 
within 
the same object information chain achieve a common understanding what an 
aggregate actually is and how it has to be  handled.
--------

   Discovery Service in order to enable querying information about the
   entire lifecycle of the cow "from farm to fork" While having access
   control over visibility of these kind of events is desired, it is
   recommended that Discovery Services should not attempt to interpret
   or validate these events.  It has been suggested that these
   complexities be excluded from the core of ESDS, instead facilitating
   them via the extensions mechanism and/or leaving such interpretation,
   validation and analysis to client applications that query ESDS.

-------
I agree on this as outlined before
-------

  This
   approach must also give consideration to providing access control to
   the extension information.

5.6.  Lifecycle

   As an object moves through the supply chain, it produces events of
   interest.  The same event on the same object may take on a different
   meaning depending on the lifecycle step of the object.  These events
   would be more useful to the interested partners if they conveyed some
   information about the lifecycle step of the object being tracked.
   Lifecycle step definitions and transitions can be different across
   various industry sectors.  The lifecycle step could convey
   information about the state of an object in the supply chain.  The
   lifecycle defined by a supply chain could enable intelligent

Rezafard                 Expires August 28, 2008               [Page 16]

Internet-Draft           ESDS Problem Statement            February 2008

   interpretation and validation of events by a partner's Business
   Application.

   It is strongly suggested that detection of exception scenarios does
   not belong within the scope of ESDS.  This intelligence should reside
   outside of the Discovery Service layer and in the supply chain's
   Business Applications.

------
I totally agree with this and actually this is a key success factor for me
------

5.7.  Multiple Organizations

   It is ESDS's intention to provide authorized clients with the link
   referral information necessary to enable client applications to
   gather information covering the entire life of a product.  This would
   include link data from the design phase, through manufacture,
   distribution and retail, usage period (including service, repair,
   maintenance, overhaul) and even end-of-life phase (including
   collection, sorting, remanufacturing and recycling).  So while there
   may exist lifecycle steps within a particular supply chain, a higher
   perspective or meta view could show that entire supply chain as a
   single step in the life of the product.  For example, an object can
   be in a Manufacturing supply chain, then move into a Logistics supply
   chain, followed by a Service supply chain.  Each of these particular
   supply chains may have their own set of lifecycle steps, but the
   entire lifecycle is spread across all three supply chains.  ESDS
   should facilitate the linking of these supply chains together to
   enable the capture of the entire lifecycle of the object.

5.8.  Identifier Agnostic

   To enable the grouping of information belonging to the same object,
   each object needs to be uniquely identifiable as it moves through the
   supply chain and its lifecycle steps.  The protocol cannot safely
   rely on unique object identifiers alone, because an identifier may
   enter the supply chain multiple times.  A sample use case for this is
   returnable bins, where the same bin will go through the supply chain
   many times.  Another use case is airline baggage, where the same
   baggage identifier could appear the following year, due to the fact
   that the identifier is only required to include a Julian date (the
   day of the year) but is not required to include the year.

   To define a protocol which is adoptable by the various supply chains,
   it is essential that the protocol support various identifier schemes.
   The ESDS protocol should have a broad scope and support multiple
   identifier schemes including schemas with non-unique identifiers.  It
   must also be identifier agnostic in order for Discovery Services to
   be embraced by global supply chains.

Rezafard                 Expires August 28, 2008               [Page 17]

Internet-Draft           ESDS Problem Statement            February 2008

5.8.1.  Reusing Identifiers

   Reusable assets and other returnable transport items may circulate
   among multiple organizations - and in many situations, it may be more
   economical and more feasible to tag the reusable asset than to tag
   its contents.  This is particularly true when attaching not only a
   unique ID tag but also environmental sensors to the reusable asset.

   Company A that provides and manages reusable assets can provide an
   additional service to its customers, such as company B (which borrows
   or leases an asset from company A), by allowing company B to access
   data about the asset while it carries the products from company B. At
   the same time, there are benefits to company A in being able to track
   its own assets, to balance supply and demand of assets and detect
   when assets are not being returned correctly, e.g. for cleaning and
   repair.

   However, it is also very important to protect the confidentiality of
   the data for company B from its competitor, company C, who may happen
   to use the same asset at a later time.

   One possible solution to this is for company A to dynamically manage
   access permissions to data about the asset and its contents using
   time-based windows that provide its customers with visibility only to
   data about the asset during the time periods when it is associated
   with their products or their lease/use of the asset.

   This could be achieved by appending additional time-based constraint
   qualifications to access control policies.

   For example, company B could be granted visibility to track and trace
   data about the asset for events that occur after they take custody of
   the asset and before they relinquish custody of the asset.  Company C
   might be granted access for a different time window.  There should be
   no overlap between the time windows granted to competing companies,
   in order to protect the confidentiality of their data.

5.9.  Extensible

   The event data needs to accommodate various supply chains and their
   business requirements.  Therefore it must be an extensible protocol
   which enables the partners to communicate messages specific to their
   group and supply chain.

   An ESDS protocol should enable the sharing of information without
   involving the business rules of supply chains.  This will keep the
   interface clean and uniform across all supply chains and ESDS
   services.

Rezafard                 Expires August 28, 2008               [Page 18]

Internet-Draft           ESDS Problem Statement            February 2008

   ESDS should give consideration to approaches for dealing with access
   control and visibility of extended information and protocols. .  One
   approach could be to provide one level of access to all the event
   information, whereby if a client can access an event information, it
   can retrieve the extended information.  Another approach could be to
   provide multilayer visibility, where only clients with proper
   privileges can retrieve the extended information.

5.10.  Retention Policy

   The retention time for data records in ESDS would vary based on the
   supply chain's business and regulatory requirements.
   o  For tracking of shipments, the records might only need to be
      stored while the shipment is in transit and has not yet reached
      its final customer (e.g. a few days to a few weeks)
   o  For some objects (e.g. consumer goods/retail sector), the primary
      interest may be tracking from manufacturer to point of sale (e.g.
      a few days to a few months)
   o  In some sectors (e.g. pharmaceuticals), regulatory guidelines may
      require records to be retained for several years beyond the point
      of dispensing.
   o  In other sectors (e.g. aerospace parts), the lifecycle up to the
      point of delivery is only the initial phase of the lifecycle of
      the part - and there may be significant interest in tracking the
      part (and its sequence of custodians and information providers)
      throughout its active service life, which can be up to 30 years
      for some parts.
   [bridge-discovery-services-design]

   Some other policies with similar parameters but different
   interpretation are the archiving policies, purging policies, and
   audit policies.

   The ESDS protocol needs to facilitate the definition and
   customization of such policies within the supply chains.

5.11.  Stale Links

   There are situations where the link information (such as a URL) that
   was originally specified is no longer effective (e.g. because the
   provider of the resource has not taken care to maintain redirection
   from the original link address to the new location of the resource
   when restructuring a website or moving to a different domain name).
   In such situations, it is desirable that an ESDS can provide a client
   with link information that is current and effective.  For audit
   purposes, it may also be necessary for an ESDS to be able to retain
   and reconstruct the original (or previous) link information, even if
   it is no longer effective.

Rezafard                 Expires August 28, 2008               [Page 19]

Internet-Draft           ESDS Problem Statement            February 2008

   This may also imply that an ESDS should allow a resource provider to
   loosely couple the link record or event with the current link
   address, to ease migration of multiple records to a new link address,
   while still providing a mechanism to recover a full audit trail of
   such changes of link addresses.  This is particularly important when
   the link records are digitally signed and we wish to avoid having to
   ?void? such records merely because they embedded a URL which is no
   longer in service.

5.12.  Peer-to-Peer Communications

   Architecting a bootstrapping policy will involve defining a protocol
   for peer-to-peer communication between Discovery Services (DS).  The
   ultimate goal is to locate the target DS without dependence on
   hierarchical information and services such as ONS or the underlying
   DNS.  To facilitate the peer-to-peer communication it is recommended
   that existing protocols and proven architectures such as JXTA
   [jxta-protocols] be utilized.  Another candidate architecture is
   ECRIT's approach to locating authoritative sources of information in
   a peer-topeer network [ecrit-mapping-arc].

   One point to keep in mind with DSs is that finding one target DS does
   not mean that the search is over.  One product identifier could be
   acceptable to many DSs; therefore a search cannot stop once a DS is
   located but needs to propagate to all peers.

   Care and consideration must be given to privacy and the sensitivity
   of information at the DS nodes.  It is also critical that steps are
   taken to protect against increased vulnerabilities that the extra
   exposure that PTP brings, such as denial-of-service attacks, or data
   mining tricks.

   Another challenge is when the target DS is successfully located.  How
   much information on an object inquiry can that DS share with the peer
   DS, without jeopardizing security and privacy?  Should the DSs
   facilitate the peer-to-peer access negotiation process or should it
   be done by the Certificate Authority?

   A sample scenario would be a query client negotiating for access to
   information from an organization where the information-providing
   organization does not have an established business (trust)
   relationship with the client and therefore chooses initially not to
   reveal its identity to the client.  In this case, it is possbile to
   use the opaque 'node ref' concept and perhaps each object can have
   such a 'node ref' handle to deal with such scenarios
   [bridge-discovery-services-design].  Considerations must be given to
   protection against data mining to discovery whether a serial number
   exists.

Rezafard                 Expires August 28, 2008               [Page 20]

Internet-Draft           ESDS Problem Statement            February 2008

6.  Technical Challenges

   ESDS should be purely an application layer protocol disassociated
   from implementation specifics and challenges.  Below are some of the
   technical challenges that certain business requirements demand.
   However ESDS is not chartered to address these implementation
   challenges.

6.1.  Auditability

   Based on some supply chain business and regulatory requirements,
   auditing capabilities should be facilitated by ESDS to provide
   accountability if and when something goes wrong.  With an auditing
   mechanism, record data can be tracked and the person responsible
   identified, thus a series of data records can be reconstructed at a
   later date, allowing the supply chain to prove who was responsible
   for which data records [bridge-security-analysis].

6.2.  Responsiveness

   ESDS implementations will need to be designed to accept updates in a
   close to real time basis from multiple providers of information
   across the supply chain or lifecycle of an object.  Because they
   store serial-level records, they will need to be sufficiently
   scalable to store large volumes of data, possibly up to trillions of
   records per year.

6.3.  Availability

   ESDS availability requirements would vary from supply chain to supply
   chain.  Research by BRIDGE shows that the uptime requirements for
   some supply chains are 99.99% year round.

   It is expected that the ESDS instances will be available over a
   shared network that exposes them to the effects of network attacks.
   Furthermore, in many cases it is expected that these components
   should be globally reachable from the Internet and not hosted on a
   secure private network.  Such components are also built using
   commonly available Operating Systems and middleware (e.g.
   Application Servers).  Thus they are also subject to any
   vulnerabilities of these supporting systems.

   A major security issue for shared services such as the ESDS or ONS is
   service availability.  In particular if you consider services that
   are vital for supply chain processes (e.g. "pharma e-Pedigree" or
   "product-authentication") ESDS needs to be able to guarantee minimal
   amount of service downtime due to security vulnerabilities and
   attacks [bridge-security-analysis].

Rezafard                 Expires August 28, 2008               [Page 21]

Internet-Draft           ESDS Problem Statement            February 2008

7.  Related Activities

   Currently, the standards organization EPCglobal, and EU research
   projects BRIDGE, SMART, and PROMISE are looking into the global
   supply chain track-and-trace challenge.  As part of their research,
   each of them has identified the need for Discovery Services to link
   resources and clients in the supply chains.

   EPCglobal is beginning to gather user requirements for Discovery
   Services.  However, EPCglobal is a paid membership organization
   focused on serving their own subscriber community.  Although the
   final ratified EPCglobal standards are open and freely available to
   download, the subscription fees for joining the EPCglobal community
   may deter a significant proportion of the global supply chain
   community from directly participating in the development of their
   global standards.

   IETF would be the ideal body to oversee the development of this
   protocol because of its deep knowledge of Internet infrastructure and
   experience with development of application layer protocols.

   An IETF working group would be an inviting and open community which
   facilitates contribution and participation of all interested parties
   involved in the global supply chain.  Unlike an EPCglobal work group,
   there would be no economic barriers to participation in the
   development of the technical standard.  The output would be released
   as a freely available RFC in the public domain.  ESDS will make best
   efforts to ensure good communication with complementary activities at
   EPCglobal, in order to ensure that the output of ESDS is as relevant
   and useful as possible to a future EPCglobal standard for Discovery
   Services.

Rezafard                 Expires August 28, 2008               [Page 22]

Internet-Draft           ESDS Problem Statement            February 2008

8.  Acknowledgements

   This document and the process of authoring was made possible by the
   excellent xml2rfc tool [RFC2629].  Credit must also be given to Scott
   Hollenbeck author of [RFC4930] for the organization and grouping of
   RFC sections.

Rezafard                 Expires August 28, 2008               [Page 23]

Internet-Draft           ESDS Problem Statement            February 2008

9.  Contributors

      Dr. Mark Harrison
      Senior Research Associate, Distributed Information and Automation
      Laboratory
      Director, Auto-ID Labs at Cambridge
      Institute for Manufacturing
      University of Cambridge
      Mill Lane
      Cambridge, UK
      CB2 1RX

      Phone: +44-(0)1223-338178
      Email: mark.harrison@cantab.net

      Michael Young
      Senior Director, Technology
      Afilias Canada
      204-4141 Yonge Street
      Toronto, ON M2P 2A8
      CA

      Phone: +1-416-646-3304
      Email: myoung@ca.afilias.info

Rezafard                 Expires August 28, 2008               [Page 24]

Internet-Draft           ESDS Problem Statement            February 2008

10.  IANA Considerations

   This document has no actions for IANA.

Rezafard                 Expires August 28, 2008               [Page 25]

Internet-Draft           ESDS Problem Statement            February 2008

11.  Security Considerations

   This document is a problem statement that does not by itself
   introduce any security issues.

Rezafard                 Expires August 28, 2008               [Page 26]

Internet-Draft           ESDS Problem Statement            February 2008

12.  References

12.1.  Normative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC4930]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              RFC 4930, May 2007.

12.2.  Informative References

   [bridge-discovery-services-design]
              BRIDGE, "BRIDGE WP02 High-level design for Discovery
              Services", August 2007.

   [bridge-security-analysis]
              BRIDGE, "BRIDGE WP04 Security Analysis Report", July 2007.

   [bridge-serial-level-lookup-requirements]
              BRIDGE, "BRIDGE WP02 Serial Level Lookup Requirements",
              August 2007.

   [draft-thompson-esds-commands]
              Thompson, F., "Extensible Supply-chain Discovery Service
              Commands (work in progress)", February 2008.

   [draft-thompson-esds-schema]
              Thompson, F., "Extensible Supply-chain Discovery Service
              Schema (work in progress)", February 2008.

   [ecrit-mapping-arc]
              Schulzrinne, H., "Location-to-URL Mapping Architecture and
              Framework", September 2007.

   [epc-information-services]
              EPCglobal Information Services Work Group, "EPCglobal
              Information Services", September 2007.

   [epc-object-naming-services]
              EPCglobal, "Object Naming Service 1.0", October 2005.

   [epcglobal-tds]
              EPCglobal Tag Data Standard Work Group, "EPC Tag Data
              Standard Standard", March 2006.

   [jxta-protocols]
              Duigou, M., "JXTA v2.0 Protocols Specification",

Rezafard                 Expires August 28, 2008               [Page 27]

Internet-Draft           ESDS Problem Statement            February 2008

              June 2004.

Rezafard                 Expires August 28, 2008               [Page 28]

Internet-Draft           ESDS Problem Statement            February 2008

Author's Address

   Ali Rezafard
   Afilias Canada
   204-4141 Yonge Street
   Toronto, ON  M2P 2A8
   CA

   Phone: +1-416-646-3304
   Email: arezafar@ca.afilias.info

Rezafard                 Expires August 28, 2008               [Page 29]

Internet-Draft           ESDS Problem Statement            February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Rezafard                 Expires August 28, 2008               [Page 30]