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

From: Ali Rezafard <[email-masked]>
Date: Sat, 09 Feb 2008 11:39:16 -0500

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
[email-masked]
http://www.ietf.org/mailman/listinfo/esds

---

From: Ted Hardie <[email-masked]>
Date: Sat, 9 Feb 2008 21:40:54 -0800

Ali,
	Thanks for posting this.  Just to remind folks who may
not have attended many IETFs, the IETF schedule remains subject
to change very late.  The IESG and Secretariat strive to keep
changes to a minimum at this stage and to minimize issues where
changes have to be made.  But please continue to check the
schedule as the time gets closer, to ensure that there are no
changes which would affect your ability to participate.
			regards,
				Ted Hardie

At 8:39 AM -0800 2/9/08, Ali Rezafard wrote:
>Content-Type: text/plain; name="bof-description.txt"
>Content-Description: bof-description.txt
>Content-Disposition: attachment; filename="bof-description.txt"; size=9676;
>	creation-date="Sat, 09 Feb 2008 08:40:04 GMT";
>	modification-date="Sat, 09 Feb 2008 08:40:04 GMT"
>
>Attachment converted: Macintosh HD:bof-description.txt (TEXT/ttxt) (006CA62C)
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=190;
>	creation-date="Sat, 09 Feb 2008 08:40:04 GMT";
>	modification-date="Sat, 09 Feb 2008 08:40:04 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 7.txt (TEXT/ttxt) (006CA62D)

---

From: Gregor Baues <[email-masked]>
Date: Mon, 11 Feb 2008 10:27:43 +0100

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                                                  
             <[email-masked]                                             
             ias.info>                                                   A 
             Envoyé par :              [email-masked]                       
             esds-bounces@ietf                                          cc 
             .org                                                          
                                                                     Objet 
                                       Re: [ESDS] Call for participation   
             02/09/2008 05:39          in the IETF ESDS BOF                
             PM                                                            

Hello,

Best Regards,
Ali Rezafard

Chair(s):

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.

Current Internet Drafts:

Suggested reading list:

---

From: Ali Rezafard <[email-masked]>
Date: Mon, 11 Feb 2008 09:34:21 -0500

Date correction: Monday, March 10, 2008

Thanks Gregor.

Ali

Ali Rezafard wrote:
> ------------------------------------------------------------------------
>