Re: [ESDS] RE: ESDS Digest, Vol 5, Issue 5

[Ali Rezafard <[e-mail]>]

Philippe,

I agree with widening the scope, whoever it can be done WITH the Supply 
chain terminology. We can capture whole lifecycle of an object by 
linking multiple Supply chains together.

An object can be in a Manufacturing supply chain, then move into a 
Logistics supply chain, then move into a Service supply chain. Each of 
these supply chains can have their own set of lifecycle steps, but the 
whole lifecycle is spread across all three supply chains. ESDS can 
facilitate linking these supply chains together to enable capturing 
whole lifecycle of the object.

The flexibility that supply chains introduce is that two objects can be 
together in the Manufacturing supply chain, and then move into two 
separate Logistics supply chains. An object can link the two supply 
chains together when it moves from one to the other, to enable tracing 
the whole lifecycle at a later time.

Ali Rezafard

Philippe Gautier wrote:
> Mark,
> One additional reason to wider the scope up to "Lifecycle" (VS Supply Chain)
> is that DS will, to my opinion, leverage brand new upcoming "pay per use"
> economic models based on the capability to store/track/trace every step of
> the lifecycle of an object.
> Furthermore the question of "property" will also be challenged the same way
> but this is mainly philosophical issues for the time being....
> ;-)
> Philippe
>
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] 
> Envoyé : mardi 29 janvier 2008 15:58
> À : [e-mail]
> Objet : ESDS Digest, Vol 5, Issue 5
>
> Send ESDS mailing list submissions to
> 	[e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/esds
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
>
> You can reach the person managing the list at
> 	[e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ESDS digest..."
>
>
> Today's Topics:
>
>    1. Re:  Proposed Charter (Mark Harrison)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jan 2008 14:58:20 +0000
> From: Mark Harrison <[e-mail]>
> Subject: Re: [ESDS] Proposed Charter
> To: Kary Fr?mling <[e-mail]>
> Cc: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> 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 Frdmling 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 Frdmling
>> ---
>> 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
>
>
> End of ESDS Digest, Vol 5, Issue 5
> **********************************
>
>
> _______________________________________________
> ESDS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds
>   

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