Re: [ESDS] Proposed Charter - comments

[Mark Harrison <[e-mail]>]

It might be helpful to include a section that lists the current  
internet drafts for ESDS:

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


It seems that work item 11) (bootstrapping policy) is concerned with  
the problem of how to find one or more Discovery Services for the  
object, given limited prior information.  This may be particularly  
important for objects that are mis-delivered or found unexpectedly.

Regarding work item 16) a particular challenge to consider is how a  
query client negotiates for access to information from an organization  
in the situation 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.   
There may be a role for Discovery Services to help in 'bootstrapping'  
that negotiation process, to allow a query client to negotiate for  
access with an initially unidentified organization, while preserving  
the confidentiality and identity of the information-providing  
organization.

Best regards,

- Mark Harrison


On 28 Jan 2008, at 18:52, Ali Rezafard wrote:

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds


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