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