Re: [ESDS] Proposed Charter - update

[Ali Rezafard <[e-mail]>]

Dear Kary,

Thank you very much for your support and suggestions. I am going to  
start a separate thread to review the clarified charter with the group.

Best Regards,
Ali

On 3-Sep-08, at 9:52AM, 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