[ESDS] [Fwd: Re: ESDS BOF approved, and comments]

[Ali Rezafard <[e-mail]>]

Forwarding because of mail server issues and the email not getting archived.

--- Begin Message ---

Dear ESDS folks,

I'm re-posting this message to the list.  I sent it just over 14 hours  
ago (around 00.15 GMT on 5th February) to Lisa Dusseault, copied to  
Elwyn Davies, Jari Arkko and the [e-mail] mailing list - but it  
appears that no-one on the ESDS list received it.  Hence the re-send  
now.  Perhaps there is a problem with the listserver configuration  
that is blocking messages that are addressed to [e-mail] only in  
the Cc: field.

Best regards,

- Mark



> Dear Lisa,
>
> Many thanks for informing us of the approval of the ESDS BOF  
> request.  We would like to provide some responses to the useful  
> questions raised by Elwyn Davies and Jari Arkko.
>
> Best regards,
>
> - Mark Harrison
>
>
> The following are answers (A) to the outstanding questions (Q)  
> posted to the ESDS mailing list with respect to the ESDS BOF and  
> Charter.
>
> Q)[Elwyn] The proposed charter appears enormous (17 work items). The  
> charter appears to envisage both the schema and the protocol work  
> (indeed at least 3 protocols).
>
> A)The proposed items of the Charter will be grouped as sub-items of  
> five major work items. Each work item is already well researched,  
> with initial protocols proposed by the EU BRIDGE research project  
> and published ESDS drafts. The ESDS Work Group needs to review and  
> validate the proposed protocols. Some sub-items can draw upon  
> existing protocols or be deferred if there are others working on the  
> problem domain (e.g. access control policy schema might be developed  
> by the EU BRIDGE project work package 4 (Security)).
>
> 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 no  
> 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)
> 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
> b)  Define a peer-to-peer protocol to enable linking Discovery  
> Service servers together
>
>
>
>
> Q)[Elwyn] Given the concerns about reusing/adapting/overloading DNS  
> I don't see much work in the charter relating to the distributed  
> storage system that probably needs to be addressed before designing  
> both the schema and the protocols - or maybe it is subsumed in item  
> 11.. but I would have thought that needed to come earlier.
>
> A) ESDS is intended to be purely an application layer protocol  
> disassociated from implementation specifics and challenges. The  
> problem statement hints at some of technical challenges certain  
> business requirements, however ESDS is not chartered to address  
> these implementation challenges.
>
> ESDS aims to minimize and offload the traffic off the DNS roots by  
> adopting successful peer-to-peer strategies such as XMPP. In our  
> vision of ESDS, the protocol will minimize reliance on DNS  
> infrastructure, although we may borrow concepts from NAPTR records  
> to distinguish between different kinds of services and may use URLs  
> (which require DNS resolution) to refer to the locations of  
> information services.
>
>
>
> Q)[Elwyn] The charter doesn't offer a timescale.
>
> A) Below is a proposed set of milestones based on collective  
> experiences and estimates:
> April 2008, Submit a Draft for Initial Conventions
> July 2008, Submit a Draft on Requirements for Security
> September 2008, Submit a Draft on Requirements for Publishing  
> Interface
> November 2008, Submit a RFC on Publishing Interface
> January 2009, Submit a Draft on Requirements for Query Interface
> March 2009, Submit a RFC on Query Interface
> May 2009, Submit a Draft on Requirements for DS-DS peer  
> Communications Interface
> July 2009, Submit a RFC on DS-DS peer Communications Interface
>
>
>
>
>
> Q)[Jari] I'm getting a little bit nervous about other SDOs that are  
> already working in this space. Would an IETF standard here have a  
> chance in succeeding? Who are the proponents of this work, and do  
> they represent entities that can drive this market to some direction?
>
> A) There is really only one other standards development organization  
> (SDO) with an interest in this space: EPCglobal. This SDO is doing  
> related work but with a tighter focus within a subscriber based  
> community, which supports unique identifiers based on GS1 system  
> identifiers.  The work at the IETF deals with broader considerations  
> such as non-unique identifiers, and expert oversight as to the  
> impact on public networks (including DNS). Additionally, it gives  
> the ability to enlarge the participating community by allowing free  
> participation. Key Aerospace organizations such as SITA and Air  
> France have already indicated their support of the IETF effort.   
> SITA and Air France already have pilot environments operating on the  
> existing drafts.
>
>
>
>
> Q)[Jari] If the existing standards have problems, are those problems  
> already being addressed somewhere?
>
> A) Discovery Services addresses a problem domain that is not covered  
> by any other protocol. Currently there are no existing protocols  
> intending to solve this problem. Discovery Services enables  
> authorized and authenticated users, to gather and retrieve links to  
> providers of complete lifecycle information about an object, which  
> is fragmented across the whole supply chain. There are related  
> standards such as ONS, EPCIS, and UDDI which deal with completely  
> different problem statements and domains.
>
> Object Naming Service (ONS) is a mechanism that leverages the Domain  
> Name System (DNS) to locate sources of authoritative information and  
> related services about a product when queried using a hostname  
> derived from the Electronic Product Code (EPC). As a Discovery  
> Service protocol it lacks access controls, authorization and  
> authentication. Also the volumes and commercial sensitivity of  
> serial-level records generated by the supply chains make it  
> unsuitable for serial-level link information. However, Discovery  
> Service can be used in collaboration with ONS to meet specific  
> business requirements.
>
> EPC Information Services (EPCIS) targets the sharing of data within  
> an established network of trust and relationships. Typically, a  
> company can provide an EPCIS query interface to allow trusted  
> partners to retrieve some of its data. It is not the role of EPCIS  
> to enable robust linking to information across the entire supply  
> chain or product lifecycle, nor to perform recursive 'proxy queries'  
> to retrieve data from other parties, nor to facilitate exception  
> handling and object bootstrapping across the whole supply chain.
>
> UDDI is a standard for description and discovery of services and the  
> functionality that they offer.  In contrast with UDDI, ESDS is  
> concerned with locating services that provide information about a  
> specific physical object; the ID of a physical object is the primary  
> lookup key for ESDS, whereas UDDI is primarily queried for a  
> particular type of service functionality desired.  Unlike UDDI  
> registries, the data held within ESDS may be much more commercially  
> sensitive because it could reveal volumes and flows of goods in  
> supply chains; from a security and scalability perspective, ESDS  
> therefore attempts to solve a more challenging problem than the  
> problem that UDDI already solves.
>
>
>
> Q)[Jari] I do not understand the market and political forces  
> involved in the interconnection of these tracking systems. I fear  
> that we may be surprised what is required beyond simple connection,  
> e.g., policies involving how information can be accessed via third  
> parties etc.
>
> A) Access control policies will need to be definable (e.g. using  
> existing standards such as XACML).  The BRIDGE project work package  
> 4 (Security) are continuing to do work on this. British Telecom is  
> leading that work package.
>
> The protocol framework for access controls must be extensible and  
> flexible to address the need for customization. Similarly, the  
> protocol itself should allow for adequate extension to enable  
> handling of unforeseen use cases. ESDS will be a thin layer  
> providing a basic and universal set of information to service  
> (authenticated and authorized) users. This information could include  
> links to back-end business applications, information services or  
> public websites. It is not in the scope of ESDS to have any control  
> over the service hosted at the link. ESDS facilitates and enforces  
> authentication and authorization policies as defined by the business  
> requirements of each supply chain.
>
>
>
> Q)[Elwyn] Further to Dave's concerns about the constituency, are  
> there enough people interested in the project to carry through such  
> a large work program?
>
> Q)[Jari] The IETF would clearly have a lot of expertise in the  
> technology. Are there enough participants from this business section  
> that we understand well enough what the user perspectives are. We  
> don't necessarily need many if they are good ones, but we do need  
> some.
>
> A) There is great interest in Discovery Services and the problem  
> domain it addresses. There has already been extended research done  
> in this domain by the EU research project BRIDGE, which includes  
> members of the University of Cambridge, AT4 wireless, BT Research,  
> SAP Research, ETH Zurich, and GS1 UK.
> The BRIDGE project has identified industrial drivers and regulatory  
> drivers for Discovery Services. Industries have expressed an  
> immediate need for deployment of Discovery Services in tracking of  
> reusable containers, consumer items, and airline baggage. Some of  
> the governmental and regulatory drivers are the UK Food safety act  
> 1990, the EU food regulation, the US bioterrorism act, FDA  
> Prescription Drug Marketing Act (PDMA) and EFPIA regulations.
> The document “EFPIA White Paper on Anticounterfeiting” outlines the  
> need for track and trace systems for the European medicine supply  
> chain to ensure safety and security of consumers. EFPIA  and several  
> other organizations working in the Discovery Service domain will  
> make requirements documents public in the  near future.
> Food supply chain members, including manufacturers such as Benedicta  
> and retailers such as METRO are actively contributing to the  
> development of the Discovery Services protocol and are keen on its  
> deployment to meet regulatory and business needs.
> The airline industry members SITA and Air France have expressed  
> great interest in this problem domain and are active contributors to  
> the ESDS list. There is great potential for ESDS to solve the  
> problem of lost luggage and enable aircraft part tracking from  
> manufacturing to part termination, which can span over 30 years  
> across multiple organizations.
>
>
>
>
>
>
>
> -------------------------------------------------------------
>
>> The ESDS BOF request was approved by the IESG and IAB today,  
>> although the discussion raised quite a few questions not answered  
>> in the overview or drafts.  I've forwarded one of the comments  
>> received (below) and I'm working with the other commenters on  
>> either forwarding their issues or scheduling a conversation with  
>> the draft authors.
>>
>> FYI, the date of the BOF meeting is not yet known, because the  
>> agenda has not yet been built.  However, the Apps Area people  
>> traditionally meet Monday Morning and discuss various topics of  
>> interest.  The Sunday reception is also a great time to meet people  
>> and arrange conversations for later in the week. 	
>>
>> Thanks,
>> Lisa Dusseault
>>
>> Begin forwarded message:
>>
>>> From: Elwyn Davies <[e-mail]>
>>> Date: January 31, 2008 6:06:02 AM PST
>>> To: IAB <[e-mail]>rg>, "Iesg (E-mail)" <[e-mail]>
>>> Subject: ESDS BOF comments
>>>
>>> ...The proposed charter (http://www1.ietf.org/mail-archive/web/esds/current/msg00020.html 
>>> )
>>> appears enormous (17 work items).
>>>
>>> The charter appears to envisage both the schema and the protocol  
>>> work (indeed at least 3 protocols).
>>>
>>> Given the concerns about reusing/adapting/overloading DNS I don't  
>>> see much work in the charter relating to the distributed storage  
>>> system that probably needs to be addressed before designing both  
>>> the schema and the protocols - or maybe it is subsumed in item  
>>> 11.. but I would have thought that needed to come earlier.
>>>
>>> The charter doesn't offer a timescale:  Further to Dave's concerns  
>>> about the constituency, are there enough people interested in the  
>>> project to carry throigh such a large work program?
>>>
>>> Elwyn
>>
>> From: Jari Arkko <[e-mail]>
>> Date: January 31, 2008 6:14:54 AM PST
>> To: IAB <[e-mail]>rg>, IESG <[e-mail]>
>> Subject: ESDS BOF Comments
>>
>>
>> The problem is very interesting. I think it would be great if APPS
>> worked on new applications infrastructure like this.
>>
>> However, I have a few question marks:
>>
>> 1) I'm getting a little bit nervous about other SDOs that are already
>> working in this space. Would an IETF standard here have a chance in
>> succeeding? Who are the proponents of this work, and do they  
>> represent
>> entities that can drive this market to some direction? If the  
>> existing
>> standards have problems, are those problems already being addressed
>> somewhere?
>>
>> 2) I do not understand the market and political forces involved in  
>> the
>> interconnection of these tracking systems. I fear that we may be
>> surprised what is required beyond simple connection, e.g., policies
>> involving how information can be accessed via third parties etc.
>>
>> 3) The IETF would clearly have a lot of expertise in the  
>> technology. Are
>> there enough participants from this business section that we  
>> understand
>> well enough what the user perspectives are. We don't necessarily need
>> many if they are good ones, but we do need some.
>>
>> Jari
>
_______________________________________________
ESDS mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/esds

--- End Message ---

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