Re: [ESDS] Interaction models for Discovery Services
Kary Främling <Kary.Framling@hut.fi> Thu, 10 July 2008 12:04 UTC
Return-Path: <esds-bounces@ietf.org>
X-Original-To: esds-archive@optimus.ietf.org
Delivered-To: ietfarch-esds-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3C33A6A1A; Thu, 10 Jul 2008 05:04:33 -0700 (PDT)
X-Original-To: esds@core3.amsl.com
Delivered-To: esds@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6F73A68F0 for <esds@core3.amsl.com>; Thu, 10 Jul 2008 05:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuQW3m5Ofs-f for <esds@core3.amsl.com>; Thu, 10 Jul 2008 05:04:31 -0700 (PDT)
Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 336683A6A17 for <esds@ietf.org>; Thu, 10 Jul 2008 05:04:30 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtp (Exim 4.54) id 1KGut4-0004IK-1f; Thu, 10 Jul 2008 15:04:42 +0300
Message-ID: <4875FAD4.9010808@hut.fi>
Date: Thu, 10 Jul 2008 15:04:36 +0300
From: Kary Främling <Kary.Framling@hut.fi>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Mark Harrison <mark.harrison@cantab.net>
References: <8438190C-CAE5-4D1F-8FD6-758D7C909DAF@cantab.net>
In-Reply-To: <8438190C-CAE5-4D1F-8FD6-758D7C909DAF@cantab.net>
X-Spam-Checker: TKK/TKO/hutcs/SpamAssassin
Cc: esds@ietf.org
Subject: Re: [ESDS] Interaction models for Discovery Services
X-BeenThere: esds@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of the ESDS \(Extensible Supplychain Discovery Service\)" <esds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/esds>
List-Post: <mailto:esds@ietf.org>
List-Help: <mailto:esds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: esds-bounces@ietf.org
Errors-To: esds-bounces@ietf.org
Dear Mark, ESDS people, I had a look through the slides. In general, I think they give a well-organised and complete picture of the different possibilities and challenges - even though I did not think through all of them in detail. I would mainly have the following comments (not intended as criticism!) for the moment: - I do not think it is good to restrict DS keys to EPC. Personally, I do not think EPC will wipe out all other numberings and you never know what will be invented in the future. This could become an obstacle to the adoption of the future DS infrastructure. - DS granularity: the presentation is quite neutral about this; we would need to support a rather flexible way of creating new DS's, e.g. I might (for some reason) even want to install a DS at my home (in addition to the EPCIS or other information source) and be able to declare my existence to some other, existing DSs. Security and trust are of course always an issue with this but the more "geographically local" the setting up of inter-DS links is, the better is the trust usually. PS! "my home" may not be a realistic scenario but it might be the extreme case - or maybe DS on products would be the extreme case? Anyway, if the DS mechanisms can handle this, then they should be able to handle all levels of "granularity". - Focus on SCM: after 3,5 years of work on PLM (or CL2M), I always feel uncomfortable when constrained to speak only in SCM terms. This is because to me, SCM is just a special case of a much broader thing. I do understand that a majority of the ESDS community may think mainly in SCM terms and could get confused by new terminology - but I think the step must be taken at some stage. - The emphasis on EPCIS as the main information source is understandable - but other information sources can be used also. The presentations do show this possibility quite clearly but in the beginning there is an impression that EPC/EPCIS are the only truly supported technologies/interfaces/etc. It seems to me that the answers to most of these comments are already somewhere in the slides, so it may mainly be a question of terminology and presentation. Anyway: I think you are doing a good job, Mark - thanks for your efforts! Best regards, Kary > Dear ESDS colleagues, > > Following on from the previous discussions on this mailing list about > the interaction between Discovery Services and 'Consolidated > Information Brokers', I have attached a couple of Powerpoint > presentations, which I presented 3 weeks ago at a face-to-face meeting > of the EPCglobal Data Discovery Joint Requirements Group. > > The presentation on the interaction models considers the possible > sequences of message flows between a query client, an information > resource and a Discovery Service, considering suitability of each > model for one-off queries as well as standing queries, together with > an analysis of their relative merits in terms of protecting the > confidentiality of information resources, confidentiality of clients' > queries, as well as considering the kinds of data to be stored in a > DS, performance and latency issues and impact on the network traffic > and possible security threats. > > The slides are intended to provide an easy-to-read animated summary of > the analysis contained in section B of the document D2.4 from the > BRIDGE project (High-level design document). > > http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf > > > I would also like to acknowledge that the original BRIDGE document > D2.4 section B was jointly authored by Trevor Burbridge (BT), Oliver > Kasten (SAP), Cosmin Condea (SAP) and Mark Harrison (University of > Cambridge, Auto-ID Lab), with additional inputs from Nicholas Pauvre > (GS1 France) and members of AT4 wireless (who led BRIDGE WP2). > > > I have also attached an Excel spreadsheet which indicates some of the > advantages and disadvantages from the perspectives of the client, > resource, DS and network traffic, together with some possible > countermeasures. Feel free to modify the spreadsheet - though I > suggest that you highlight any changed cells (e.g. set background > colour of cell to yellow) so it is clear to everyone which changes you > have made. > > I really hope that these presentations and the spreadsheet will > stimulate some lively discussion on this mailing list and I look > forward to reading your comments about the different interaction > models for Discovery Services. > > Best regards, > > - Mark Harrison > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ESDS mailing list > ESDS@ietf.org > https://www.ietf.org/mailman/listinfo/esds > _______________________________________________ ESDS mailing list ESDS@ietf.org https://www.ietf.org/mailman/listinfo/esds
- [ESDS] Interaction models for Discovery Services Mark Harrison
- Re: [ESDS] Interaction models for Discovery Servi… Kary Främling
- Re: [ESDS] Interaction models for Discovery Servi… Kenneth R. Traub
- Re: [ESDS] Interaction models for Discovery Servi… Mark Harrison
- Re: [ESDS] Interaction models for Discovery Servi… Kenneth R. Traub
- Re: [ESDS] Interaction models for Discovery Servi… trevor.burbridge
- Re: [ESDS] Interaction models for Discovery Servi… Kary Främling
- Re: [ESDS] Interaction models for Discovery Servi… Mark Harrison
- Re: [ESDS] Interaction models for Discovery Servi… Kenneth R. Traub
- Re: [ESDS] Interaction models for Discovery Servi… David Potter
- Re: [ESDS] Interaction models for Discovery Servi… Mark Harrison