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

["Philippe Gautier" <[e-mail]>]

Mark,
Yes, I'm sorry : I did read it and posted as well an additional comment.
I did read all the following comments as well so you shouldn't receive any
"out of time" reply from me now....
;-)
I have also personal views on "how to create ad-hoc/fortuitous contact with
entities having no prior relationships" but it would be too complicated and
long to comment here (I'm trying to take time to feed BRIDGE WP4 with it as
well).
Philippe

-----Message d'origine-----
De : Mark Harrison [mailto:[e-mail]] De la part de Mark
Harrison
Envoyé : jeudi 31 janvier 2008 11:24
À : [e-mail]
Cc : [e-mail]
Objet : Re: [ESDS] RE: ESDS Digest, Vol 5, Issue 2
Importance : Haute

Dear Philippe,

Kary Främling has made a similar remark earlier this week.

I agree that an ESDS protocol should support linking to potentially  
all organizations within an object's lifecycle, from the design phase,  
through manufacture, distribution and retail, usage data (including  
service, repair, maintenance, overhaul) and even including end-of- 
life, including collection, sorting, remanufacturing and recycling.

Best regards,

- Mark



On 31 Jan 2008, at 10:08, Philippe Gautier wrote:

> Dear all,
> Sorry for this late reply.
> My first comment could be "why only focusing on Supply Chain issues  
> and not
> on Object's Lifecycle's ones ?".
> Actually, a DS standard will potentially cover a wider scope than  
> the Supply
> Chain itself.
> Regards,
> Philippe
>
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : lundi 28 janvier 2008 19:54
> À : [e-mail]
> Objet : ESDS Digest, Vol 5, Issue 2
>
> 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.  Proposed Charter (Ali Rezafard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 28 Jan 2008 13:52:48 -0500
> From: Ali Rezafard <[e-mail]>
> Subject: [ESDS] Proposed Charter
> To: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
> End of ESDS Digest, Vol 5, Issue 2
> **********************************
>
>
>
> _______________________________________________
> ESDS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds




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