Re: [ESDS] Proposed Charter - update

[Mark Harrison <[e-mail]>]

Dear Kary,

I like your suggestion to modify the wording to say  "develop  
interfaces for publishing available data sources, submitting one-time  
queries for such sources, and registering for standing queries to  
changes in available data sources".

However regarding standing queries, I think that in the context of a  
Discovery Service, the purpose of a standing query with a DS is to  
inform the client of changes in the availability of data sources  
(primarily when additional data sources register that they hold  
information for a particular ID), rather than informing the client  
that an existing data source for an ID has recorded additional data  
internally within its own database.

I also prefer 'information resource' to 'data source', since it is  
more likely that organisations may wish to exchange information rather  
than raw data.

I would therefore suggest fine-tuning the wording further to say,

"develop interfaces for:
i) publishing the address of available information resources [for a  
particular ID of an object of interest],
ii) submitting one-time queries for retrieving the addresses of such  
resources, and
iii) registering for standing queries, whose responses inform the  
client of addresses of any additional information resources that  
publish a record to a DS at a future time for the particular ID of an  
object of interest ",

Perhaps we also need a footnote that when we talk about 'publishing'  
or 'available', this does not imply that the information resources or  
their addresses are available to all or publicly known - the  
availability of a particular information resource might only be made  
available to a restricted set of authorized clients.

Best regards,

- Mark




On 8 Sep 2008, at 14:34, Kary Främling wrote:

> Dear Mark,
>
> I agree with you completely.
>
> The wording in the current charter that I reacted to was "develop  
> interfaces for publishing data, submitting onetime queries, and  
> registering for standing queries". Maybe it should be changed into  
> "develop interfaces for publishing available data sources,  
> submitting onetime queries for such sources, and registering for  
> standing queries to changes in available data sources"? Is this what  
> is actually intended?
>
> And should we change "data sources" into "information sources"  
> according to your message? I would personally vote for "information  
> sources".
>
> Hmmm, discussing small details like this may seem a bit irrelevant -  
> but then again, a charter has to be short, exact and unambiguous.
>
> Best regards,
>
>  Kary
>> Dear Kary,
>>
>> In response to your question about the role of ESDS, my  
>> understanding is that it serves to provide referrals to information  
>> resources (e.g. by providing authorized authenticated clients with  
>> a list of URLs of resources relevant for a particular ID or keyword  
>> (and perhaps some helpful contextual metadata to enable the clients  
>> to intelligently choose which of those resources to contact).
>>
>> I do not consider that it is the responsibility of ESDS to actually  
>> retrieve the information from the underlying resources.  That role  
>> is the responsibility of a separate client application, similar to  
>> what David Potter has called a 'Consolidated Information Broker',  
>> or to the 'Event Gathering Layer' in the track and trace  
>> application that has been developed in work package 3 of the BRIDGE  
>> project.
>>
>> Such client applications may interface with Discovery Services and  
>> with the underlying resources (including EPC Information Services  
>> (EPCIS)) in order to retrieve complete event information from  
>> multiple resources - but I don't feel that it is the role of a  
>> Discovery Service itself to perform this retrieval or to provide a  
>> 'one-stop-shop' for gathering complete detailed lifecycle  
>> information for an object.  In my view, a Discovery Service is only  
>> a referral system that acts as an enabler for such applications.
>>
>> Best regards,
>>
>> - Mark
>>
>>
>> On 3 Sep 2008, at 14:52, Kary Främling wrote:
>>
>>> Dear Ali,
>>>
>>> I personally find your proposal well structured, clear and a good
>>> initiative to work on (as usually with your proposals on ESDS). It  
>>> would
>>> require some more thought to allow me to provide any improvement
>>> proposals - but at least I think your initiative deserves a  
>>> response! I
>>> am surprised that there hasn't been more reactions on the list  
>>> about this?
>>>
>>> The again, some quick comments:
>>> - It would be good to separate the "charter" part more clearly  
>>> from the
>>> "work item current status and summary" part; I didn't notice the
>>> separation straight away.
>>> - From the charter, it is hard to see whether ESDS will provide
>>> discovery only of information sources or also access to the actual
>>> information. The same old question...
>>>
>>> Best regards,
>>>
>>> Kary
>>>> Dear ESDS members,
>>>>
>>>> We have had considerable progress on the Discovery Services  
>>>> protocol
>>>> discussions. I have summarized current status on some of the ESDS  
>>>> work
>>>> items and updated our charter. Our charter is modified to include
>>>> secure and restricted discovery for the broader Internet community.
>>>>
>>>> Please review and comment.
>>>>
>>>> Best Regards,
>>>> Ali Rezafard
>>>>
>>>> ESDS Charter:
>>>> ESDS has been chartered to architect and define a protocol for  
>>>> Discovery
>>>> Services. Discovery Services at its core offers to authenticated  
>>>> and
>>>> authorized
>>>> users the means to discover sources of information for a particular
>>>> object.
>>>> Discovery Services can be implemented as a decentralized  
>>>> directory of
>>>> resources
>>>> indexed by a shared identifier. Discovery Services need to be
>>>> deployable in
>>>> both closed networks as well as open and global networks such as
>>>> Internet.
>>>>
>>>> ESDS will develop interfaces for users of Discovery Services as  
>>>> well
>>>> as an
>>>> interface for peer-to-peer communication among Discovery Services.
>>>> ESDS will
>>>> develop interfaces for publishing data, submitting onetime  
>>>> queries, and
>>>> registering for standing queries.  ESDS should support  
>>>> utilization of
>>>> a trusted
>>>> external identity management service for Authentication. ESDS  
>>>> should
>>>> enable
>>>> configuration of Authorization and Access Control for publishing  
>>>> clients.
>>>>
>>>> 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 TTL)
>>>>           URI of event publisher (who)
>>>>       optional data fields:
>>>>           Lifecycle step (why)
>>>>           Event timestamp (client timestamp)
>>>>           Change in identifier (aggregation, disaggregation,
>>>> relabeling)
>>>>       example extensible data fields:
>>>>           Where (bizLocation)
>>>>           Transaction data (PO, AWB, Invoice)
>>>>
>>>>   Query response data fields:
>>>>       required data fields:
>>>>           URI object identifier (what)
>>>>       optional data fields:
>>>>           Publish timestamp (server timestamp)
>>>>           Service list of URLs (links)
>>>>           Event class (event type attributes, such as TTL)
>>>>           URI of event publisher (who)
>>>>           Lifecycle step (why)
>>>>           Event timestamp (client timestamp)
>>>>           Change in identifier (aggregation, disaggregation,
>>>> relabeling)
>>>>       example extensible data fields:
>>>>           Where (bizLocation)
>>>>           Transaction data (PO,AWB,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.
>>>>   http://www.ietf.org/mail-archive/web/esds/current/msg00114.html
>>>>
>>>>   b) Define a protocol for advertising/publishing data resources
>>>> (Resource
>>>>   Discovery).
>>>>
>>>>   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).
>>>>   a record that points to another DS (instead of an information
>>>> source) In
>>>>   this case, the query client application may choose to make a
>>>> separate query
>>>>   to the other DS, not necessarily involving 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. This has particular implications  
>>>> for
>>>>   peer-to-peer searching across multiple Discovery Services).
>>>>
>>>>   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.
>>>>       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.
>>>>       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).
>>>>
>>>>
>>>>
>>>> On 5-Feb-08, at 6:40PM, Ali Rezafard wrote:
>>>>
>>>>> Dear ESDS group,
>>>>>
>>>>> Thanks for your responses to the initial proposed charter.  
>>>>> Attached
>>>>> is the updated charter based on your feedback and comments by  
>>>>> IAB and
>>>>> IESG. Please review and comment.
>>>>>
>>>>> Best Regards,
>>>>> Ali Rezafard
>>>>>
>>>>> Extensible Supply-chain Discovery Service (ESDS)
>>>>>
>>>>> Chair(s):
>>>>>  Mark Harrison <mark.harrison at cantab.net>
>>>>> Applications Area Director(s):
>>>>>  Lisa Dusseault <lisa at osafoundation.org>
>>>>>  Chris Newman <chris.newman at sun.com>
>>>>> Applications Area Advisor:
>>>>>  Lisa Dusseault <lisa at osafoundation.org>
>>>>> Mailing List(s):
>>>>>  esds at ietf.org
>>>>> General information about the mailing list is at:
>>>>>  https://www1.ietf.org/mailman/listinfo/esds
>>>>>
>>>>> Purpose of Working Group:
>>>>> The use of Supply chain Tracking Systems is rising at an
>>>>> unprecedented rate,
>>>>> particularly as various industry sectors are increasingly adopting
>>>>> automatic
>>>>> identification technologies such as Radio-Frequency Identification
>>>>> (RFID) to
>>>>> automatically track individual physical objects as they move  
>>>>> through
>>>>> a supply
>>>>> chain.  Rather than tracking at batch or lot level, the ultimate  
>>>>> goal
>>>>> of this
>>>>> technology is that each individual physical object will have its  
>>>>> own
>>>>> unique
>>>>> ID, which can be used to gather and retrieve complete lifecycle
>>>>> information
>>>>> about the object, which is fragmented across the supply chain.
>>>>> Deployment of
>>>>> these systems has grown to a point where they can no longer  
>>>>> operate
>>>>> effectively in isolation from other systems.  There is a need to
>>>>> share data
>>>>> among these disparate systems, which are owned and operated by  
>>>>> separate
>>>>> organizations.
>>>>>
>>>>> ESDS has been chartered to architect and define the protocol of a
>>>>> Discovery
>>>>> Service for global supply chains. ESDS's goal is to enable  
>>>>> searching for
>>>>> information on physical objects flowing in a supply chain, by
>>>>> authorized and
>>>>> authenticated users.  Economic and technical factors dictate that
>>>>> Discovery
>>>>> Services and their protocol ESDS must be designed for deployment  
>>>>> on the
>>>>> Internet. Access control, data protection and security are of  
>>>>> utmost
>>>>> importance, due to sensitivity and value of the information  
>>>>> generated
>>>>> by the
>>>>> supply chain.
>>>>>
>>>>> Work Items:
>>>>> The work group will address to the following work items:
>>>>> 1.Initial Conventions
>>>>>  a)Define common vocabulary and terminology
>>>>>  b)Define core data sets for sharing on Discovery Service,  
>>>>> including
>>>>>  required data fields, optional data fields, and extensible data
>>>>> fields
>>>>>  (e.g. who, what, when, where, why, links, identifier, lifecycle,
>>>>> class,
>>>>>  etc.)
>>>>>  c)Define handling for time zones (e.g. accepting only UTC
>>>>> timestamps vs.
>>>>>  accepting timestamps with any timezone)
>>>>> 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)
>>>>>  c)Define a common interface and roles for access control
>>>>> configuration
>>>>>  (e.g. supply chain, partner, user )
>>>>> 3.Publishing Interface
>>>>>  a)Define mechanism for uniquely identifying objects in a supply  
>>>>> chain
>>>>>  without requiring a global unique identifier for each and all
>>>>> objects that
>>>>>  enter a supply chain
>>>>>  b)Define a protocol for advertising/publishing data resources
>>>>> (Resource
>>>>>  Discovery)
>>>>>  c)Define a protocol and policy for retracting or voiding  
>>>>> published
>>>>> data
>>>>>  d)Define policies for updating stale and broken links (e.g. for
>>>>> records
>>>>>  with a long retention period, it is vital that links can be
>>>>> updated, when
>>>>>  required)
>>>>> 4.Query Interface
>>>>>  a)Define a protocol for querying published data, facilitating  
>>>>> 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)
>>>>>  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. This has particular implications  
>>>>> for
>>>>>  peer-to-peer searching across multiple Discovery Services)
>>>>> 5.DS-DS Peer Communications Interface
>>>>>  a)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)
>>>>>  b)Define a peer-to-peer protocol 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)
>>>>>  c)Determine if Discovery Services should facilitate peer-to-peer
>>>>> 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)
>>>>>
>>>>> Goals and Milestones:
>>>>> Done            Submit a draft problem statement
>>>>> April 2008      Submit a document outlining the Initial  
>>>>> Conventions
>>>>> July 2008       Submit a draft on requirements for Security
>>>>> September 2008  Submit a draft requirements for Publishing  
>>>>> Interface
>>>>> November 2008   Submit a draft proposed protocol for Publishing
>>>>> Interface
>>>>> January 2008    Submit a draft on requirements for Query Interface
>>>>> March 2009      Submit a draft proposed protocol for Query  
>>>>> Interface
>>>>> May 2009        Submit a draft on requirements for DS-DS peer
>>>>> Communications Interface
>>>>> July 2009       Submit a draft proposed protocol for DS-DS peer
>>>>> Communications Interface
>>>>>
>>>>> Current Internet-Drafts:
>>>>> http://www.ietf.org/internet-drafts/draft-rezafard-esds-problem-statement-00.txt
>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-young-esds-concepts-03.txt
>>>>> http://www.ietf.org/internet-drafts/draft-thompson-esds-commands-02.txt
>>>>> http://www.ietf.org/internet-drafts/draft-thompson-esds-schema-02.txt
>>>>>
>>>>> Further Background Reading:
>>>>> BRIDGE project - Requirements for Discovery Services
>>>>> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf
>>>>>
>>>>>
>>>>> BRIDGE project - high-level design for Discovery Services
>>>>> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf
>>>>>
>>>>> _______________________________________________
>>>>> ESDS mailing list
>>>>> [e-mail]
>>>>> http://www.ietf.org/mailman/listinfo/esds
>>>>
>>>> _______________________________________________
>>>> ESDS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/esds
>>>
>>> _______________________________________________
>>> ESDS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/esds
>>
>

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