Subject: [ESDS] Comments on ESDS Documents

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Mar 2008 09:47:31 -0400

I have a few high-level comments on the ESDS documents that I wanted
to share with the list in preparation for the BOF this afternoon.  I
do plan to be at the BOF, so we can also discuss them there.

(1) There are two separate concepts that seem to be mixed together in
     some of the ESDS documents, I think we need to be very clear about
     which one(s) we are hoping to standardize within the IETF:

     - A Discovery Service: A means to determine where event
       information about a particular item (or group of items) is held.
       This might include the fully qualified domain name(s) of one or
       more hosts providing an Information Service, the protocol(s) that
       can be used to access that service (such as EPCIS, proprietary
       protocols, etc.)  and potentially other information about how
       to access the service.

     AND/OR

     - An Information Service: A means to store and receive event
       information about an item.  Events might include the transfer of
       the item to a supply chain partner, relabling/aggregation/
       deaggregation, the sale of the item to an end customer, items
       lost in the supply chain, returns, etc.

     It is my understanding that we are hoping to standardize a
     Discovery Service (as described above) not an Information Service.
     If that is true, it is not clear to me how the "commands" and
     "schema" documents would relate to this work.

     It seems to me like we would benefit greatly from a strawman
     proposal for a Discovery Service, but what we seem to have is a
     strawman proposal for an Information Service.  Am I
     misunderstanding something?

(2) In either the "problem statement" or "concepts" document, it would
     be extremely useful, IMO, to include a diagram of a simple supply
     chain and discuss the possible relationships between the entities
     and how items might flow back and forth in the chain.  It would
     also be good to include descriptions of some application-level
     functions that could be supported by a globally-available
     discovery service, such as product recalls, return tracking and
     field upgrades.

(3) Although the "problem statement" document mentions the scale of
     this function in the discussion of ONS, it does not list
     scalability as a "technical challenge", and I think it should.

(4) I think that the document(s) would benefit from a clearer
     discussion of the security requirements of the discovery service.
     Specifically, it would be good to add a clearer explanation of
     what data might be considered senstive and why.  For example, the
     fact that a retail store contains any events about a given product
     may be sensitive, as their competitors could detect when the store
     have added a new item to their inventory.  The existence of a
     specific serial number may be sensitive, as it could be used to
     determine how many items have been manufactured.

     Also, there should be some discussion of how access
     control may relate to the physical world -- you may want to give
     access to information about a specific item only to the partner(s)
     to whom that item has been shipped.

If it would be helpful, I'd be happy to work with the document authors
to update the document(s) to address these issues.

Margaret

_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Michael Young <[email-masked]>
Date: Mon, 10 Mar 2008 10:46:29 -0400

Some comments below

>      "schema" documents would relate to this work.

Agreed, this is meant and should be about discovery, I don't know if that
means you get completely away from information because even to enable
discovery you do need some "context" in order to decide which referrals you
want to follow.

I'll let the authors speak, but my understanding is that these docs are
simply a contribution of related work. I would expect parts of them to
perhaps be useful, as you stated are currently of limited use.

>      misunderstanding something?

Clearly need more discussion, but I think the intent of a discovery service
is clearly there, its probably more an issue of parsing out language that
implies information service.

>      discovery service, such as product recalls, return tracking and

Agreed will add.

>      determine how many items have been manufactured.

This is one of the work items called for, I agree its needed,

>      to whom that item has been shipped.

Yes and again that one of the proposed work items.

> to update the document(s) to address these issues.

That I am sure is an offer that will be gladly taken up!

---

From: Mark Harrison <[email-masked]>
Date: Mon, 10 Mar 2008 11:00:10 -0400

Hi Margaret,

Many thanks for your very helpful comments.  We look forward to your  
participation in the ESDS BOF this afternoon.

I'll try to respond to your comments inline below:

>     "schema" documents would relate to this work.

We are intending to do work on a protocol for Discovery Services - not  
an Information Service.
We already recognize the highly relevant EPC Information Services  
(EPCIS 1.0 ) standard that
the EPCglobal community has developed - so no need for us to work on  
an information service.

A Discovery Service is not about replicating all the information from  
an EPCIS - but about providing a lightweight
referral service that can provide URL links to one or more information  
services that hold detailed information
about an individual object.

A Discovery Service could point to one or more EPCIS instances, as  
well as to other kinds of services, such as
web services, web pages related to the product etc.

However, a Discovery Service clearly needs a mechanism to allow each  
company to 'publish' a link into a DS
as well as a mechanism for another company to 'query' a DS to obtain  
link referrals.

The internet drafts on commands and schema represent a very initial  
'straw man' proposal for these publish / query mechanisms
for a Discovery Service.  Although there are some syntax parallels  
with similar commands for an EPCIS, the intention is not that a
Discovery Service should provide the detailed events - but return a  
list of links (URLs accompanied by service types).

>     misunderstanding something?

There are some subtle differences - and for example, the EventLookup  
method primarily returns a list of links (although these are termed  
'events' - but they are referral events rather than EPCIS events).

Note that in the ESDS internet drafts, the term 'event' is used - but  
this is just one 'significant' event in the DS
from among the many more detailed events that an EPCIS repository  
might store for that object.

For this reason, the BRIDGE design documents actually use the term  
'record' instead of 'event', in order to
make this distinction clearer.

>     discovery service, such as product recalls, return tracking and

These are very helpful comments.  The BRIDGE design documents (already  
contributed both to
the ESDS mailing list and to EPCglobal's Data Discovery JRG) provide  
such diagrams and rather
more 'narrative' text than is contained in the ESDS internet drafts.   
There should be no problem about
re-using or adapting any figures that I contributed to the BRIDGE  
documents.

It's also helpful for many readers to make the distinction between  
track-and-trace applications
vs Discovery Services (that provide an enabler for such applications).

>     scalability as a "technical challenge", and I think it should.

Scalability is certainly a challenge for Discovery Services - not just  
the volumes of records
- possibly in the trillions
- but also the challenge of ensuring that the access control policies  
that protect these records
can be expressed in a scalable way, in order to avoid the number of  
policies scaling with N^2
(where N is the number of companies in the supply chain or lifecycle).

>     determine how many items have been manufactured.

These are all very helpful comments.  There is also some related work  
from the BRIDGE project
(WP4 - Security work package) which we can draw upon to elaborate on  
this.

>     to whom that item has been shipped.

Agreed.

> to update the document(s) to address these issues.

That would be really helpful.  We look forward to working with you to  
improve the documents.

Best regards,

- Mark Harrison