Re: [ESDS] Call for participation in the IETF ESDS BOF

[Gregor Baues <[e-mail]>]

Hello

Thanks for the update on the session date and time. I have no idea if it is
possible to reschedule this date as i would like to come to Philadelphia
but can't make it for the 9th and actually this is sunday probably you
meant the 10th anyway.. Possible date for me would be the last two days of
the meeting i.e. the 13th or 14th.

I would be grateful if there is a possibility for rescheduling the date.

Best Regards

Gregor Baues
Chief Architect Application Infrastructure
Air France Information Systems


                                                                           
             Ali Rezafard                                                  
             <[e-mail]                                             
             ias.info>                                                   A 
             Envoyé par :              [e-mail]                       
             esds-bounces@ietf                                          cc 
             .org                                                          
                                                                     Objet 
                                       Re: [ESDS] Call for participation   
             02/09/2008 05:39          in the IETF ESDS BOF                
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hello,

Details of the ESDS BOF session at the 71st IETF gathering in
Philadelphia, PA, USA are as follows:
Date: Monday, March 9, 2008
Time: 1:00 PM
Duration: 2 hours
Place: Marriott Philadelphia Downtown, 1201 Market Street
Room Name: Breakout Room
Information on registration, and accommodation:
http://www3.ietf.org/meetings/71-IETF.html

We look forward to meeting you at the BOF session.

Best Regards,
Ali Rezafard
Extensible Supply-chain Discovery Service (ESDS)

Chair(s):
    Ted Hardie <hardie at qualcomm.com>
    Mark Harrison <mark.harrison at cantab.net>
Applications Area Director(s):
    Lisa Dusseault <lisa at osafoundation.org>
    Chris Newman <chris.newman at sun.com>
Applications Area Advisor:
    Lisa Dusseault <lisa at osafoundation.org>
Mailing List(s):
    esds at ietf.org
General information about the mailing list is at:
    https://www1.ietf.org/mailman/listinfo/esds

BoF Description:
The use of Supply chain Tracking Systems is rising at an unprecedented
rate,
particularly as various industry sectors are increasingly adopting
automatic
identification technologies such as Radio-Frequency Identification (RFID)
to
automatically track individual physical objects as they move through a
supply
chain.  Rather than tracking at batch or lot level, the ultimate goal of
this
technology is that each individual physical object will have its own unique
ID, which can be used to gather and retrieve complete lifecycle information
about the object, which is fragmented across the supply chain.

Deployment of these systems has grown to a point where they can no longer
operate effectively in isolation from other systems.  There is a need to
share
data among these disparate systems, which are owned and operated by
separate
organizations.

ESDS has been chartered to architect and define the protocol of a Discovery
Service for global supply chains. ESDS's goal is to enable searching for
information on physical objects flowing in a supply chain, by authorized
and
authenticated users.  Economic and technical factors dictate that Discovery
Services and their protocol ESDS must be designed for deployment on the
Internet. Access control, data protection and security are of utmost
importance, due to sensitivity and value of the information generated by
the
supply chain.

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. 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. The output
would be released as a freely available RFC in the public domain.

Some areas of concern are:
1) Public Networks and Tree-Walking Concerns Currently, another standards
body, 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 must aim to prevent this problem by keeping most of the network
traffic
off the Internet root hierarchy.

2) 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 must aim 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 must be designed for serial level lookups and must
also 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 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.

3) Concerns over dependence on identifier schemas
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. The ESDS
protocol must 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.

The objectives of the BoF meeting are to:
1.Assess interest in forming a Working Group on Discovery Services
2.Solidify the Problem Statement
3.Have consensus on WG goals and define the milestones

The proposed agenda can be found here:
http://www.ietf.org/mail-archive/web/esds/current/msg00056.html

The proposed Work Group charter can be foudn here:
http://www.ietf.org/mail-archive/web/esds/current/msg00054.html

Current Internet Drafts:
http://www.ietf.org/internet-drafts/draft-rezafard-esds-problem-statement-00.txt

http://www.ietf.org/internet-drafts/draft-young-esds-concepts-03.txt
http://www.ietf.org/internet-drafts/draft-thompson-esds-commands-02.txt
http://www.ietf.org/internet-drafts/draft-thompson-esds-schema-02.txt

Suggested reading list:
BRIDGE project - Requirements for Discovery Services
http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf


BRIDGE project - high-level design for Discovery Services
http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf

_______________________________________________
ESDS mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/esds

_______________________________________________
ESDS mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/esds