Re: [ESDS] Proposed Charter

[Kary Främling <[e-mail]>]

Dear Mark,

That was a quick reply! What I was thinking about was rather that 
products are sources of information also during their usage by consumers 
- and that usage information is valuable e.g. for manufacturers and 
service providers. Here I am thinking about cars, household appliances 
etc. This implies that "organisation" might need to be extended to 
include individuals, families/homes and maybe something more (could 
machines "own" themselves in the future?). Security is obviously 
important here also - you don't want thiefs to get an online inventory 
of your home or statistics indicating that you haven't opened your 
fridge for a week so they can come and visit your home.

Being anonymous is partially related to this - it's like with ONS 
queries that could allow someone to spy on what objects are located 
where. If your "intelligent machine" needs to do a Discovery Services 
lookup for some reason, it could be good for it to be anonymous.

I know that I am now going far from RFID-only scenarios and from the 
typical EPCGlobal scenarios. But considering such scenarios could 
hopefully help in defining the scope of ESDS.

Best regards,

   Kary

> Dear Kary, ESDS folks,
>
> Many thanks for your comments!
> The E in ESDS is certainly intended to cover both 'extensible' (in 
> the  technical sense) as well as referring to 'extended' supply chains.
>
> When we said 'which can be used to gather and retrieve complete  
> lifecycle information about the object', the intention is of course 
> to  cover the entire product lifecycle, allowing any organization that 
> is  involved at any stage in the life of a product to publish links to 
> a  Discovery Service - or to query it for links to those 
> organizations  who published a link, subject of course to 
> authentication and  authorization (governed by fine-grained access 
> control policies set by  each organization that publishes a link (or 
> event) to a Discovery  Service), as well as any other access control 
> policies that are set by  the operator of the Discovery Service or as 
> a result of other  legislative or regulatory guidelines).
>
> i.e. organizations that interact with Discovery Services potentially  
> include (but are not limited to):
>
> designers of products
> manufacturers
> integrators of composite products
> suppliers of components
> distributors
> wholesalers
> companies providing storage
> companies providing transport and logistics
> retailers
> organizations involved with collection, recycling and remanufacturing  
> of products
> organizations who provide spares, replacement parts and consumables  
> (e.g. cartridges, refills etc.)
> organizations involved in the maintenance, repair, overhaul and  
> servicing of products
> industry bodies and regulators
> insurance companies
> customs officials
>
> In some situations, end-consumers may be provided with some access  
> (subject to access control policies determined by the manufacturers,  
> supply chain members or by legislation) - although it is unlikely 
> that  many organizations would provide Discovery Service records that 
> are  open to anonymous access.  Within a retail store, a retailer 
> might  provide product information kiosks, which provide the public 
> with  information that is gathered using Discovery Services - but in 
> some  cases, this will have been pre-cached by the retailer (using 
> the  retailer's own credentials) in order to make it available to 
> anonymous  customers within their store.
>
> Other public access might be provided to traceability service, via a  
> secure web page, which requires the customer to provide the serial  
> number of the product - or some other details, such as a code that is  
> printed on their receipt of purchase.  Such a web-based traceability  
> service may (behind the scenes) interact with Discovery Services and  
> other information services, such as EPC Information Services - and  
> present a consolidated view of lifecycle traceability information to  
> the customer.  However, like the example of an information kiosk  
> within a retail store, the end-consumer is provided with information,  
> mediated by an authorized supply chain player, such as the product  
> manufacturer or the retailer.
>
> In the two above examples, there is no need for a Discovery Service 
> to  hold a record (or link information) about which consumer brought 
> a  product - or enquired about a product in-store.   Both mechanisms  
> described could allow the customer to remain anonymous.
>
> Many thanks for your input!
>
> Best regards,
>
> - Mark
>
>
> On 29 Jan 2008, at 12:51, Kary Främling wrote:
>
>> Dear group,
>>
>> Just a quick comment about the charter text. It says "which can be  
>> used to gather and retrieve complete lifecycle information about the  
>> object" but apparently the definition of "object lifecycle" only  
>> covers the design and manufacturing phases (i.e. the supply chain)  
>> of the object.
>>
>> As I have been working on the PROMISE project 
>> (http://www.promise-plm.com/ ) for the last years, my understanding 
>> of "object lifecycle" also  includes the usage phase (including 
>> consumers, not only airlines or  similar "commercial" or "industrial" 
>> end-user organisations) and the  "end-of-life", i.e. recycling.
>>
>> This difference is fundamental for the work group charter. The scope  
>> becomes much broader and the technical challenges are greater if the  
>> PROMISE-kind interpretation is used. But the vision also becomes  
>> more interesting, i.e. a "true" Internet of Things.
>>
>> I personally vote for the PROMISE-kind interpretation but no matter  
>> which interpretation is used, it should be clearly expressed in the  
>> charter.
>>
>> Another thing: if consumers are included in the vision, then  
>> "privacy" also becomes a part of security. "Privacy" might sound  
>> unattractive but anonymization and pseudonymization solutions are  
>> used for tackling this in many systems already.
>>
>> Regards,
>>
>>  Kary Främling
>> ---
>> Mail: Helsinki University of Technology, P.O. Box 5500, FI-02015  
>> HUT, Finland
>> Office: TUAS Building, Room 2044, Otaniementie 17, Espoo
>> Phone: [phone], Telefax: [phone]
>> Email: [e-mail], WWW: http://www.cs.hut.fi/~framling
>>
>>> 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
>
>


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