Subject: [ESDS] ESDS Concerns

From: Ali Rezafard <[email-masked]>
Date: Fri, 08 Feb 2008 15:11:34 -0500

Dear ESDS group,

In order to facilitate better communication as well as provide an 
understanding of the IETF ESDS effort, it was requested at a recent 
EPCglobal JRG Data Discovery conference call that ESDS submit a list of 
its concerns to the EPCglobal Discovery Services JRG. Attached is the 
document which was sent to EPCglobal.

Additionally Mark Harrison sent an email to the JRG to better introduce 
the IETF ESDS efforts.

Best Regards,
Ali Rezafard
ESDS Concerns:
Currently, the standards organization EPCglobal, and EU research projects
BRIDGE, SMART, and PROMISE are looking into the global supply chain
track-and-traceability 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.

The Internet Engineering Task Force (IETF) is an open international community
of network designers, operators, vendors and researchers concerned with the
evolution of the Internet architecture and the smooth operation of the
Internet.  It is the principal body engaged in the development of new Internet
protocol specifications. The IETF develops and promotes Internet protocols,
cooperating closely with the W3C and ISO/IEC bodies and dealing in particular
with protocols of the TCP/IP and Internet protocol suite including DNS, POP3,
XMPP, IMAP, SMTP, HTTP, HTTPS, and FTP. IETF facilitates thorough counsel from
the Internet Architecture Board (IAB) and the Internet Engineering Steering
Group (IESG).

The IAB provides oversight of the architecture for the protocols and
procedures used by the Internet. The IAB monitors important long-term issues
in the Internet, and to make sure that these issues are brought to the
attention of the group(s) that are in a position to address them.  It plays a
role in assuring that the people responsible for evolving the Internet and its
technology are aware of the essential elements of the Internet architecture.

Given the nature of Discovery Services it is a requirement for it to be
deployed on Internet. The domain experts for protocol development on the
Internet are at the IETF. As responsible citizens of the global network, it is
obligatory to seek and follow the procedures put in place by the organization
governing and operating this network. 

1) Participation concerns
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 the greater 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
protocol.  The output would be released as a freely available RFC in the
public domain.

2) Public networks and tree-walking concerns
Currently, EPCglobal has issued a related standard referred to as ONS (Object
Naming Service, 1.0).  ONS is effectively an extended version of DNS that does
not benefit from the IETF review process and, by design, necessitates
increased tree- walking.  ONS specifies a reverse mapping of the EPCglobal
"SGTIN" (one type of supply chain object identifier) as a domain 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 a 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 that multiple alternate ONS
roots 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.
ESDS aims to prevent this problem by keeping most of the network traffic off
the Internet root hierarchy. The IETF process provides access to Internet
architecture experts that understand and provide insight into the full effects
a protocol can on the public network infrastructure.

3) Object bootstrapping concerns
Currently there are discussions on how to best facilitate a bootstrapping
processes for objects in the supply chain.  The bootstrapping process involves
locating an object's Discovery Service server by an interested and authorized
client.  The bootstrapping process needs to be enabled with 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.

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 aims to accommodate this
scenario while respecting privacy and security considerations.

It has been suggested to use the ONS 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 leak 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
or access control. ESDS will be designed for serial level lookups and support
unstructured opaque identifiers to use as lookup keys within an ESDS service.
It should fully support authentication and serial level access controls to
address privacy concerns.

To facilitate bootstrapping and exception handling scenarios ESDS design could
consider a peer-to-peer lookup protocol such as XMPP. This would keep the ESDS
traffic flat and avoid walking up the Internet root hierarchy.  A major
concern is that the bootstrapping design will 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 including the concerns from the operators of the global network.

4) Concerns over dependence on identifier schemas and universal uniqueness
To enable 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.  One
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, because 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, adoptable by the various supply chains, it is essential
that multiple identifier schemes can be supported by the protocol. EPCglobal's
focus is to support unique identifiers based on GS1 system identifiers.  The
work at the IETF deals with broader considerations such as non-unique
identifiers, and expert oversight as to the impact on public networks
(including DNS). The ESDS protocol will be identifier agnostic in order for
Discovery Services to be embraced by global supply chains.  An IETF Work Group
will be an open forum for defining a protocol that meets both technical and
business requirements.
_______________________________________________
ESDS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/esds