[ESDS] Work Items - update
Mark Harrison <mark.harrison@cantab.net> Mon, 08 September 2008 15:19 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 1DE813A6817; Mon, 8 Sep 2008 08:19:18 -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 F1AB23A6A41 for <esds@core3.amsl.com>; Mon, 8 Sep 2008 07:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.549
X-Spam-Level:
X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, 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 X4somoikkcdp for <esds@core3.amsl.com>; Mon, 8 Sep 2008 07:55:35 -0700 (PDT)
Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id C33B93A68A2 for <esds@ietf.org>; Mon, 8 Sep 2008 07:55:34 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from mlpc-mgh-p.eng.cam.ac.uk ([129.169.78.104]:51149) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:mgh12) (TLSv1:AES128-SHA:128) id 1Kci9R-0001wa-NY (Exim 4.70) (return-path <mgh12@hermes.cam.ac.uk>); Mon, 08 Sep 2008 15:55:37 +0100
Message-Id: <19D8822E-51B7-49FF-91B7-E705F9BAC8C8@cantab.net>
From: Mark Harrison <mark.harrison@cantab.net>
To: esds@ietf.org, Ali Rezafard <arezafar@ca.afilias.info>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Mon, 08 Sep 2008 15:55:35 +0100
X-Mailer: Apple Mail (2.926)
Subject: [ESDS] Work Items - update
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: esds-bounces@ietf.org
Errors-To: esds-bounces@ietf.org
Dear ESDS folks, Please find below an edited version of the ESDS work items. Reading through the work items that Ali posted on 31st July, there is still quite some emphasis on industrial supply chains - particularly in the data fields. The IETF may be more interested in developing a protocol for a rather more generic referral system, which can be used for other applications as well as for supply chains. Certainly, one of the applications motivating the development and standardization of Discovery Services is the increasing use of automatic identification technologies (in particular Radio Frequency Identification (RFID) ) to capture observations of tagged physical objects within the premises of a company and also as they pass from one company to another, in a supply chain or supply network. However, Discovery Services have a potentially wider generic applicability, as a bottom-up mechanism for constructing indices and referral systems for information about particular topics or keywords, particularly when the contributed information is distributed across multiple nodes on the internet and in particular, where the contributed information (and the metadata that enables its discovery) is not intended to be available to everyone or is not ordinarily discoverable by public web search engines that perform automated crawling and indexing of publicly accessible content. Some of the optional data fields and example extensible data fields are perhaps too specific to supply chains and might need to be made one level more abstract. I've therefore made some minor edits to the work item 1b. I have also split work item 3b (publishing interface) into three separate items and also made some edits and comments on work items 4c (multilayer information visibility), 5a (queries within a federation of Discovery Services) and 5c (joining a federation of Discovery Services). Best regards, - Mark Harrison Suggested modifications too the work items (and additional comment from Mark Harrison) below: Work item current status and summary: 1.Initial Conventions a) Define common vocabulary and terminology. http://www.ietf.org/mail-archive/web/esds/current/msg00085.html http://www.ietf.org/mail-archive/web/esds/current/msg00087.html b) Define core data sets for sharing on Discovery Service, There are two sets of core data fields, one for data being published, and another for the data returned in response to a query. Publishing data fields: required data fields: URI object identifier (what) Publish timestamp (server timestamp) Service list of URLs (links) Event class (event type attributes, such as time-to-live (TTL)) URI of event publisher (who) optional data fields: Contextual metadata (why) Application context: e.g. supply chain sub-context: e.g. pharmaceuticals Process: e.g. shipping Location: e.g. geospatial location (latitude, longitude, altitude) postcode businessLocation URI (as in EPCIS standard) (includes extension mechanism for other kinds of location) Event timestamp (client timestamp) Related identifiers: Application context: e.g. supply chain, Process: e.g. aggregation, disaggregation, relabeling, synonyms Related ID List: e.g. ID of parent container or relabelled product Relation: e.g. parent, children, relabelled-as example extensible data fields: Cross-referenced documents and transactions (type and ID): e.g. Purchase Order #, Advanced Shipment Notice #, Invoice # Query response data fields: required data fields: URI object identifier (what) optional data fields: Publish timestamp (server timestamp) List of URL referrals to information resources Event class (event type attributes, such as time-to-live (TTL)) URI of event publisher (who) Contextual metadata (why) Application context: e.g. supply chain sub-context: e.g. pharmaceuticals Process: e.g. shipping Location: e.g. geospatial location (latitude, longitude, altitude) postcode businessLocation URI (as in EPCIS standard) (includes extension mechanism for other kinds of location) Event timestamp (client timestamp) Related identifiers: Application context: e.g. supply chain, Process: e.g. aggregation, disaggregation, relabeling, synonyms Related ID List: e.g. ID of parent container or relabelled product Relation: e.g. parent, children, relabelled-as example extensible data fields: Cross-referenced documents and transactions (type and ID): e.g. Purchase Order #, Advanced Shipment Notice #, Invoice # c) Define handling for time zones. ESDS will only support UTC timestamps d) Define handling for Aggregation, Disaggregation, and Relabeling events. These events are useful for expressing when it may be necessary to track a different identifier in order to follow the same object. http://www.ietf.org/mail-archive/web/esds/current/msg00101.html e) Define handling for Transaction events. These events would associate (or disassociate) one or more object identifiers from the identifier of a business transaction or document. 2.Security a) Considerations for access control policies and their impact on Work Items 3 and 4. b) 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). http://www.ietf.org/mail-archive/web/esds/current/msg00104.html c) Define a common interface and roles for access control configuration (e.g. supply chain, partner, user). d) Define a mechanism for verifying digitally signed DS events published. The challenge is that the DS may need to validate the signatures for signed events it receives and log whether the data underlying a link was from a verifiable signed source. i.e. the DS should log and indicate the presence of a verified signature in the query response (especially when it does not pass the whole signed event record to the query client). 3.Publishing Interface a) Define mechanism for uniquely identifying objects in a scope without requiring a global unique identifier for each and all objects that enter a scope (e.g. supply chain). Closed deployments of DS can utilize internal numbering authority/ rule and to make the identifier globally unique, prefix it with a registered domain name (e.g. to construct a well-formed HTTP URI ) http://www.ietf.org/mail-archive/web/esds/current/msg00114.html 3b-part 1) Define an initial registration protocol through which a data resource may join a Discovery Service, including mutual authentication between a Discovery Service and the new resource. (Resource Registration) 3b-part 2) Define a protocol for advertising/publishing data records for a particular ID (or list of IDs), to link to particular resources (Record Publication) 3b-part 3) To cater for the situation where a resource publishes a record to establish a link to another resource other than itself (see 3e below), define a protocol to allow the Discovery Service to authenticate the identity and type of that other resource, which may include periodic monitoring to detect change of address or non-availability (Resource Authentication & Monitoring) c) Define a protocol and policy for retracting or voiding published data. d) Define policies for updating stale and broken links (e.g. for events with a long retention period, it is vital that links can be updated, when required). Publisher profile described in BRIDGE's "High level design for Discovery Services" will address this requirement: http://www.ietf.org/mail-archive/web/esds/current/pdfuMVBqNwBjM.pdf e) Define a mechanism to enable linking Discovery Service servers together (e.g. retrieving information about the entire lifecycle of a product as it moves through various supply chains). In the case of a record that points to another DS (instead of an information source), the query client application may choose to make a separate query to the other DS, not necessarily requring any involvement of the original DS (other than if DS1 is required to provide a federated trust token to the client that it can present to DS2). 4.Query Interface a) Define a protocol for querying published data, supporting both one-time queries and standing queries (e.g. pull vs. push queries). b) 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 and access policy). Refer to 1.d above. c) 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. The client may be provided with one of the following three kinds of visibility: i) no visibility - no awareness that the resource exists ii) awareness of existence of a resource, albeit via an opaque non-revealing reference. ( Like the NodeRef idea in the BRIDGE design) iii) URL referral data (and optionally also contextual metadata) that enables it to connect to the resource if it chooses to do so. This has particular implications for peer-to-peer searching across multiple Discovery Services). In the case of peer-to-peer searching, the remote peer DS may provide one of the above responses (where the URL in iii) is the URL of the peer DS, rather than returning the URLs of the resources that the peer DS knows about. d) Determine if Discovery Services should facilitate an access negotiation process (e.g. a query client negotiates for access to information from an organization in the situation where the information-providing organization does not have an established business (trust) relationship with the client and therefore chooses initially not to reveal its identity to the client). 5.DS-DS Peer Communications Interface a) Define a protocol for inter-DS querying. Initial draft of approach to DS federation 1) Each DS holds an index of neighboring DSs (URLs) in its DS federation. 2) A propagating-query is sent to a DS whose address is known by the client. This is hereafter referred to as the 'initiating DS'. 3) The DS forwards the propagating-query to DSs listed in its index and waits for the replies. The DS also appends its DS index to the propagating-query, so that the same DS is not queried multiple times. 4) Each DS that receives the propagating-query will perform step 3 on DSs which are not queried already. 5) Each DS will review the propagating-query and decides whether it is interested in volunteering to receive the actual query. 6) Each DS will wait until a specified deadline is passed for its federation neighbors to reply back. 7) Once that period has passed, it will merge the received replies along with its own reply and send it back to the initiating DS. Comment: We need to be clear about whether a DS receiving the propagating query should reply to the DS that sent the propagating query to it (the previous DS) or whether it should reply directly to the initiating DS. In step 7, we seem to be saying that some intermediate DS within the DS network will wait for replies from the DS nodes it contacted and then merge their responses together with its own response and reply directly back to the initiating DS. However, if the DS nodes that it contacts adopt the same approach, then they respond directly to the initiating DS with their response, rather than to the previous DS that sent them the propagating query. In that case, the previous DS might be waiting a very long time to receive a response from the DS nodes that it contacts - since they have replied direct to the initiating DS node instead of responding to the previous DS that propagated the query to it. I think we need to be consistent here. I'd suggest that each DS node adds its own ID to the list of DS that have already been contacted, replies direct to the initiating DS and forwards the propagating query to any of its contacts that do not already appear in the list of 'already contacted DS nodes'. In this way, none of the intermediate nodes (other than the initiating DS node) need to wait for responses from the DS nodes that they contact - the burden of waiting for responses from other DS peers falls only on the initiating DS. 8) The first DS will send back to the client a list of DSs (URLs) which have replied. Note: All above actions are voluntarily for any DS server. A server could provide discovery Services without opting into forwarding or replying to any propagating-queries. b) Architect a bootstrapping policy for objects while ensuring security and confidentiality (e.g. locating one or more Discovery Services for a product which is mis-delivered). c) Define a procedure for a Discovery Service server to join or leave a federation of Discovery Services. This could potentially involve some manual operations (e.g. physically validating identity of a DS operator). Comment: this may also involve checks that the joining DS is using identifiers that are globally unambiguous within the federation into which it is joining or has a mechanism for translating its identifiers into a form that is globally unambiguous within the federation it is joining. Note that I did not say globally unique because we may have a situation where two rival Discovery Services choose to co-operate within the same federation and a client has published records for the same identifier to both of them and both records refer to the same object. i.e. maybe we need to explicitly say that this does not mean that the identifier ranges handled by the members of the DS federation must have no intersection or overlap - since that is allowed if referring to the same object. What we are trying to ensure is that we avoid collisions of unqualified (locally-scoped) identifiers that are numerically or lexically identical but in fact refer to different objects. _______________________________________________ ESDS mailing list ESDS@ietf.org https://www.ietf.org/mailman/listinfo/esds
- [ESDS] Work Items - update Mark Harrison