[ESDS] Proposed Charter
Ali Rezafard <arezafar@ca.afilias.info> Mon, 28 January 2008 18:54 UTC
Return-path: <esds-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1JJZ7Q-00035w-C6; Mon, 28 Jan 2008 13:54:08 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1JJZ7P-00035q-JW
for esds@ietf.org; Mon, 28 Jan 2008 13:54:07 -0500
Received: from vgateway.libertyrms.info ([207.219.45.62]
helo=mx4.ca.afilias.info)
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJZ7P-0005YT-02
for esds@ietf.org; Mon, 28 Jan 2008 13:54:07 -0500
Received: from dev20.int.libertyrms.com ([10.1.3.167])
by mx4.ca.afilias.info with esmtp (Exim 4.22)
id 1JJZ7O-0003f5-3e; Mon, 28 Jan 2008 13:54:06 -0500
Message-ID: <479E2480.7080702@ca.afilias.info>
Date: Mon, 28 Jan 2008 13:52:48 -0500
From: Ali Rezafard <arezafar@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: esds@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SA-Exim-Mail-From: arezafar@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Subject: [ESDS] Proposed Charter
X-BeenThere: esds@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of the ESDS \(Extensible Supplychain Discovery Service\)"
<esds.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/esds>,
<mailto:esds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/esds>
List-Post: <mailto:esds@ietf.org>
List-Help: <mailto:esds-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/esds>,
<mailto:esds-request@ietf.org?subject=subscribe>
Errors-To: esds-bounces@ietf.org
Dear ESDS group,
Below is the proposed charter and work items for our work group. Please
review and comment.
Extensible Supply-chain Discovery Service (ESDS)
=====================================
Chair(s):
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
Purpose of Working Group:
-----------------------------------
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.
Goals and Milestones:
----------------------------
The work group will address to the following work items:
1) Define common vocabulary and terminology
2) Define core data sets for sharing on Discovery Service, including
required data fields, optional data fields, and extensible data fields
(e.g. who, what, when, where, why, links, identifier, lifecycle, class,
etc.)
3) Define fault tolerance for missing required data fields
4) Define mechanism for uniquely identifying objects in a supply chain
without requiring a global unique identifier for each and all objects
that enter a supply chain
5) Define handling for time zones (e.g. accepting only UTC timestamps
vs. accepting timestamps with any timezone)
6) Define a protocol for advertising/publishing data resources (Resource
Discovery)
7) Define a protocol and policy for retracting or voiding published data
8) Define a protocol for querying published data, facilitating both
one-time queries and standing queries (e.g. pull vs. push queries)
9) Define a common interface for access control configuration (e.g.
supply chain, partner, user, roles)
10) Define security architecture and mechanisms for authorization,
authentication , encryption (e.g.
integrating security certificates into the protocol vs. relying on a
security layer such as SSL)
11) Architect a bootstrapping policy for objects while ensuring security
and confidentiality
12) Define a common configuration interface for each category of
policies (e.g. access policies, retention policies, archiving policies,
purging policies, audit policies, QoS policies, propagation policies)
13) Define policies for updating stale and broken links (e.g. for
records with a long retention period, it is vital that links can be
updated, when required)
14) Validate that the deployment architecture is independent, scalable
and robust
15) Determine how aggregation and disaggregation events should be
handled including policies for access control and visibility of these
events (e.g. a pallet is broken down into boxes and each box has its own
destination supply chain)
16) Determine if multilayer information visibility is required (e.g. 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)
17) Define a peer-to-peer protocol to enable linking Discovery Service
servers together
_______________________________________________
ESDS mailing list
ESDS@ietf.org
https://www1.ietf.org/mailman/listinfo/esds
- [ESDS] Proposed Charter Ali Rezafard
- Re: [ESDS] Proposed Charter - comments Mark Harrison
- Re: [ESDS] Proposed Charter Kary Främling
- Re: [ESDS] Proposed Charter Mark Harrison
- Re: [ESDS] Proposed Charter Kary Främling