Re: [ESDS] Interaction models for Discovery Services

<trevor.burbridge@bt.com> Thu, 10 July 2008 13:16 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 D7A513A680A; Thu, 10 Jul 2008 06:16:25 -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 D2C0D3A680A for <esds@core3.amsl.com>; Thu, 10 Jul 2008 06:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
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 lnBcwCR7NT6G for <esds@core3.amsl.com>; Thu, 10 Jul 2008 06:16:23 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E94C93A6809 for <esds@ietf.org>; Thu, 10 Jul 2008 06:16:22 -0700 (PDT)
Received: from E03MVA3-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 14:16:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 10 Jul 2008 14:16:35 +0100
Message-ID: <A006D7FE5B11C445A4353373CDFA017502796E2E@E03MVA3-UKBR.domain1.systemhost.net>
In-Reply-To: <F1E8CE72-929D-408D-BB79-080B636CDCEF@cantab.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ESDS] Interaction models for Discovery Services
Thread-Index: AcjiiFQRPkr0gVRAQROxshyo+biRsgAAcyzQ
From: trevor.burbridge@bt.com
To: esds@ietf.org
X-OriginalArrivalTime: 10 Jul 2008 13:16:36.0292 (UTC) FILETIME=[2E2C6040:01C8E28F]
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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: esds-bounces@ietf.org
Errors-To: esds-bounces@ietf.org

> From: esds-bounces@ietf.org [mailto:esds-bounces@ietf.org] On 
> Behalf Of Mark Harrison
> Sent: 10 July 2008 13:27
> To: Kary Främling
> Cc: esds@ietf.org
> Subject: Re: [ESDS] Interaction models for Discovery Services
>.... 
> DS granularity and co-operation:
> ==========================
> In one of the presentations, I did mention that the ESDS 
> group had been thinking about having a federation of 
> Discovery Services - and even the EPCglobal DD JRG seems to 
> be coming around to the idea of a co-operative Network of 
> Discovery Services - rather than attempting to fit everything 
> into a single DS or small number of Discovery Services.  I 
> think they could understand the potential benefit of 
> partitioning implementations of DS according to industry 
> sector or geographic region (while at the same time striving 
> towards a technical protocol for the interfaces and data 
> model that is truly global and
> sector-agnostic.)


I think as Kary mentioned, the choice to run a localised DS could have a very significant impact on the early deployment of the technology. If a community can choose who can have access, and who hosts the service, then many of the problems of large-scale fine-grained access control policies can be mitigated.

The other point to consider is that we can imagine that DSs may serve very different concepts of community. As Mark mentions: industry segment, partnerships, geographical area etc. Thus it would be wrong to try to enforce a single meaningful structure on the system. Certainly structuring a single global DS system by identifier (like DNS) doesn't seem sensible as I loose any choice (and also any business or geographic relationship) with the parties hosting of my data and routing my queries.

If we allow DSs to represent different overlapping community concepts we can also see that an information owner (e.g. EPCIS owner) may want to register their information with many DSs. This can be a perfectly legitimate way of making the information available in all of the scopes it needs to be instead of assuming that we only register the data once to single fully-connected global network. Furthermore, the publisher can control exactly what it registers which each DS and understand the audience using that DS along with the motivation of the DS.

If we define a standard for the DS interfaces (register,query,potentially peering), then if someone (or collection of people) wants to set up a single global system they can. If this market never emerges and the standard is only used for a collection of smaller systems with ad-hoc peering, then that doesn't have to change the standard.

As you can probably gather aiming for a single global network worries me for two reasons:

- I'm not clear we need it (given that we can register data multiple places under clear control of the publisher)

- Security. On 'local' systems we can just about imagine how to write fine-grained access control policies (we're not going to want the same set of people to see all of our registrations). On a global system we'd have to propagate these policies in addition to the information registrations. All the systems would need to be using the same (federated) security attributes. We'd also need policies to express which DS providers the information could be propagated to as well as the permitted clients. Keep in mind that both the registrations and the security policies are confidential information. The query propagation model suffers similarly as we try to control who can subscribe to different publication scopes/identifiers.

Trevor.

Trevor Burbridge
Principal Researcher
Networks Research Centre | BT Research
Telephone: 01473 645115
Fax: 01473 640929 
Web: http://labs.bt.com/networks/
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications plc which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.
 

> 
_______________________________________________
ESDS mailing list
ESDS@ietf.org
https://www.ietf.org/mailman/listinfo/esds