Subject: [ESDS] Draft ESDS BOF minutes from IETF 71

From: Elaine Chin <[email-masked]>
Date: Wed, 19 Mar 2008 12:14:10 -0400

Hi all,

Attached are the draft minutes of the ESDS BOF session held in Philadelphia on March 10, 2008.
Please let me know of any omissions or corrections within the next week.

Thank you.
Elaine Chin

Extensible Supply-chain Discovery Service (ESDS) BOF Minutes

Meeting    : IETF 71, Monday, March 10, 2008
Location   : Marriott Philadelphia Downtown, Salon I , 13:00-15:00
Chairs     : Ted Hardie <[email-masked]>
             Mark Harrison <[email-masked]>
Minutes    : Elaine Chin <[email-masked]>
             version: 1.0    

==================================================================

AGENDA

    1.  Agenda Bashing ( Mark Harrison ) [5 min]
    2.  Introduction to concept ( Mark Harrison ) [15 min]
        - Questions regarding clarification [15 min]
    3.  Review of Problem Statement ( Michael Young ) [10 min]
        - Questions regarding clarification [10 min]
    4.  Expectations of deliverables ( Mark Harrison ) [15 min]
        - Questions regarding clarification [15 min]
    5.  Scope of work ( Mark Harrison ) [10 min]
        - Comments [15 min]
    6.  Next Steps and Action Items [10 min]

===================================================================

MEETING Report 

    1.  Agenda Bashing (Mark Harrison) (5 min)

        * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt     
       
        Ted Hardie welcomed attendees and did introduction of Chairs,
        followed by meeting administrivia:

        Elaine Chin volunteered as scribe.
        Stephen van Egmond volunteered as jabber scribe.
   
        Mark Harrison displayed the agenda (Slide 3) and reviewed the scope of
        discussion (Slide 4). No items were added to the existing agenda.            

    2.  Introduction to concept ( Mark Harrison ) [15 min]

        * draft-young-esds-concepts-03.txt
        * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt

        Mark provided a conceptual overview of the role of Discovery Services
        (DS) by walking through a food traceability scenario which followed a
        cow through the supply chain from farm to retailer (Slides 5,6). He
        showed how Discovery Services enable end-to-end traceability by
        providing links or referrals to providers of product information along
        this chain of custody.  He emphasized that Discovery Services do not
        store detailed information; they point to where you can find it. He
        also pointed out that Discovery Services differ from public search
        engines in that Discovery Services will normally enforce access control
        policies restricting who can access information. 

        Next Mark reviewed current business drivers resulting from the
        increased adoption of automatic identification technologies (e.g. RFID,
        2D Barcodes). These drivers include improved traceability, more
        efficient data sharing and improved supply chain efficiency through the
        exchange of serial level information. (Slide 7). He talked about how DS
        also enables the improved gathering of life cycle information history,
        which allows companies to make better decisions on how to remanufacture
        or extract residual value from products. The latter is of interest to
        organizations like PROMISE.

        From a technical perspective, he showed the role of Discovery Services
        in relationship to existing network stacks and architecture frameworks
        (Slide 8), such as those using EPCglobal standard interfaces (E.g.
        EPCIS, ALE). The focus of ESDS within IETF would be a technical
        protocol centered on 3 aspects: a Query protocol, a Publish Protocol
        and a Bootstrapping protocol. The ESDS group has worked with EPCglobal
        and is hoping to complement its efforts by feeding the work done by the
        IETF community into future EPCglobal standards.

        He then outlined what's different about Discovery Services (Slide 9),
        highlighting the focus on being lightweight referral services that
        scale, and are able to store changes of identifier mappings (e.g. upon
        aggregation, disaggregation or relabelling). He also talked about the
        challenges needing to be addressed (Slide 10), such as the scalability
        of access control permissions.

        A diagram (Slide 11) was then shown outlining the interaction between
        companies representing a client application (Q), an information
        provider resource (R), and one or more Discovery Services (D,E,F). To
        better illustrate that D, E, and F all represent Discovery Services,
        they were renamed as follows: D=D1,F=D2,E=D3. R has stored event
        information about an object with ID=X. R can publish records (or
        events) to one or more Discovery Services so that those Discovery
        Services can link back to R as an information provider for object with
        ID X. Note that it does not need to publish all of its detailed events
        about object X - it is sufficient to just publish a single record to
        say that at some time it collected information about object X.  

        At the same time, companies such as R will probably also specify access
        control policies to protect the DS records they post from viewing by
        unauthorized users. Q can query a Discovery Service to ask who has
        information about object R. If the Discovery Service directly queried
        by Q has this information and if Q is authorized to see it, the
        Discovery Service can respond to Q with information that contains a URL
        link to R. 

        Q can then contact R directly to request detailed event information.
        This direct interaction between Q and R would be out of scope for
        Discovery Services - and something that could be handled by a standard
        interface dealing with querying of serial-level event data, such as the
        EPCglobal EPC Information Services (EPCIS) query interface that is
        already defined and ratified. 

        If Q contacts a Discovery Service that has no knowledge about object X,
        Q could try making a different kind of query via the Discovery Service
        it usually contacts. This different kind of query is a query across a
        federation of Discovery Services that know of each other's existence
        but do not exchange or mirror records. This would allow another
        Discovery Service within the federation to identify itself if it held
        information about object X. Q could then contact that alternative
        Discovery Service to request referral information. 

        These companies could also define access control policies to control
        the extent of information sharing. This diagram was referred to often
        in the course of discussion.. It was made clear that the direct
        interaction between Q and R would be out of scope for Discovery
        Services, and something that would be handled by a standard interface
        dealing with query content (e.g. EPCIS). 

        - Questions regarding clarification [15 min] 
        * Appendix A: Detailed Discussion Notes     

        Eric Rescorla wanted to better understand a) the business relationships
        among partners in the diagram (Slide 11). Had concerns about b) whether
        DS would enforce a business relationship c) in scope and out of scope
        boundaries e.g. with respect to information content.

        Mark: a) Answer is it depends. The DS shown may be independent of each
        other but have some sort of federation. b) No c) We are not dealing
        with a data model or the interfaces to the database, which is already
        addressed by interface standards such as EPCIS.

        Margaret Wasserman: Need to understand who the players are, what data
        they have. Defining that defines the problem. The problem statement is
        too weak on what is the real interesting problem trying to solve. Need
        to make it more clear in the documents what you are trying to solve.

        A few speakers commented on leveraging existing protocols and open
        source implementations, as well as work done previously such as the
        TISDAG project(distributed whois directory), which are described in the
        RFC archives.

        Kurt wanted to understand the scope of communications being handled.
        Mark outlined the 3 protocols ESDS hopes to develop: publish, query and
        bootstrapping.

        Phillip Hallam-Baker raised point about too often trying to solve for a
        specific application and not abstracting to a generic. Thinks a focus
        on architecture still has value, but is opposed to architectural
        thinking divorced from a use case.

        Dave Crocker: Don't have a track record in IETF of solving this
        category problem in terms of large scale global activity with the
        exception of DNS. Not in a position yet to say there's a solution that
        exists because can't understand the problem statement yet. Thinks we
        need an IETF process, possibly a requirements group, to get to the
        point of specifying protocol or protocol choices.

        One speaker wanted to know the current status of solution with respect
        to IP protocols. Mark replied that the object itself may not have a
        network interface as such. Communication often involves talking to an
        agent or information service representing that object. (e.g. Database
        records).

     3. Review of Problem Statement ( Michael Young ) [10 min]

        * draft-rezafard-esds-problem-statement-01.txt
        * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt

        Mike asked for a show of hands how many had read the Problem Statement.
        Approximately 45%, or 30 people raised their hands. By way of
        addressing some of the "sore points" that might arise from the Problem
        Statement re: who will contribute to this effort, etc., he showed a
        list of organizations including EPCglobal (Slide 14) who represent both
        contributors and users defining requirements.  

        To explain "Why the IETF" (Slide 15), Mike talked about challenges that
        IETF, based on its expertise and lessons learned, could help solve,
        such as the complexity of the bootstrapping process and scaling to
        global operations. 

        To answer the question "What does this work enable?" (Slide 16), Mike
        talked about the importance of point-to-point communications and real
        world needs, such as an audit trail for safety-critical products,
        counterfeit product detection and support for product recalls. Cited a
        Pfizer recall example where Pfizer received back 2.5 times as much
        product as was shipped due to lack of accurate track and trace
        capabilities in the distribution network, and lack of visibility by the
        manufacturer and retailer into that network. 

        Mike spoke to the driving forces behind Discovery Services (Slide 17),
        including fraud protection for consumables like drugs or food products.
        He also talked about how multiple circles of relationships and
        increased demand for security necessitates having multiple Discovery
        Services vs having one global Discovery Service. 

        - Questions regarding clarification [10 min]
        * Appendix A: Detailed Discussion Notes

        A number of questions arose after Slide 16:

        Speaker at mic: How many different organizations are contacted to get
        this information? Is there an automated way of doing this? Where does
        this scale today? i.e. How many actors do you imagine being involved in
        a product's life cycle?

        Mike: On a given object may have 20 or more organizations. Mark: the
        Bridge project has seen up to 50.

        Margaret Wasserman: That's for a serialized item. If you want to find
        all of the Tylenol manufactured in the last 2 months it could be a very
        large number.

     4. Expectations of deliverables ( Mark Harrison ) [15 min]

        * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt     
       
        Mark reviewed expectations of what Discovery Services will provide,
        derived from user requirements for the BRIDGE project. He provided a
        brief history of BRIDGE. In terms of functionality required, he
        mentioned how DS enables object tracking, forecasting, and alerting on
        misplaced ids by providing links to sources of information that need to
        be checked. Other requirements around support for standing queries and
        provisioning were also discussed (Slide 20).

        Technical expectations were covered next (Slides 21,22). Primarily
        referral URLs and possibly some meta data for defining access control
        policies. Other expectations included the need to support scalability
        that might involve billions of events/year, support for synchronous and
        asynchronous responses, full trace query, journal logging and creation
        of a voiding policy. The slide provides a link to a Bridge website for
        more details.
              
        - Questions regarding clarification [15 min]
        * Appendix A: Detailed Discussion Notes

        A number of questions were posed after Slide 21:

        One speaker made the point that if the assumption is that DS is a
        simpler model than distributed directory services because it is only
        dealing with referrals, this is a mistake. Feels DS will have problem
        of modelling and matching rules. Mark agreed that a simple data model
        doesn't make it less complex to solve.

        Phillip Hallam-Baker: The reason most directory projects fail is
        because the content isn't there to look up in the directory. Should
        recognize that this is an IETF proposal to take on part of the
        technical work going on in EPCglobal. If we do the work for EPCglobal
        they will either use it or if not completed in time, do the work on
        their own.

        Questions after slide 22:

        Andrew Sullivan: Because you are dealing with distributed meta data -
        makes it more complicated because you have a vocabulary of meta data
        spread out .i.e. Have a directory of directories problem plus problems
        of directory issue itself. Wondered if we should go back and use the
        DNS model in ONS even if you are going back to one source.

        Margaret Wasserman: To Phillip's point re: EPCglobal - Work at present
        in EPCglobal is requirements gathering only. The hope is that their
        work would feed into this group with a technical protocol done in this
        body. There is no technical work being done at EPCglobal in this area.

        Ted: From a process perspective it's not a global distributed directory
        problem. Real question is "What does it take to make this a manageable
        chunk of work? 

     5. Scope of work ( Mark Harrison ) [10 min]

        * http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt     
       
        Mark read the ESDS Charter and the Scope of Discovery Services (Slides
        24,25)and indicated he would like consensus on the BOF questions (Slide
        26):

        1) Is this an interesting problem to tackle?
        2) Is the scope of work appropriate to the problem?
        3) Is there support to form a work group with the following charter?
              (i.e. that the charter itself is ready and supported by the
               community)
        4) Can I ask for a show of hands for who is willing to review
               documents?
        5) Do we have any additional volunteers as an editor for some of the 
               document(s) to be produced by the work group?         
             
          - Comments [15 min]

        Leslie Daigle: I do think its an interesting problem to tackle. Some
        similarities to the whois service problem where have some entities
        notionally working together and problems in establishing a shared
        context. Not a global directory services problem.

        Eric Rescorla is unclear what it is we are trying to achieve. Had a
        lengthy exchange around the nature of the business relationships (e.g.
        D1 and D2) represented in diagram on Slide 11 leading to the topic of
        how does one become a DS and how do you stop malfeasance in a single
        large circle of trust if you assume that an access control problem will
        be handled by non-technical measures? Problem with the security model
        is that everyone is in trust boundary. There's limited access control.

        Margaret Wasserman: Comment on Eric's question. Not sure this is a
        solvable problem. One of the answers is that R tells us the level of
        security of information allowed (which Qs are allowed to see it, which
        D2s are allowed to expose itself to).

        Eric Rescorla: I don't understand how only certain Ds can see it,
        because all Ds are identical.
 
        Margaret Wasserman:  We don't have a strawman proposal for this. A
        particular group will contract to provide their Discovery services.
        Margaret used an example where D1, D2 and D3 could cover different
        industry sectors that do not intersect. R. has to say whether it's
        sensitive information or not. Answers to BOF questions: 1. Yes
        interesting problem to solve. Need to define problem better within IETF
        context before can charter work group on a solution. 2. Don't get the
        sense of the scope of work. Charter needs some work to be done about
        what work items are to come out. 3. Charter needs to be more complete.
        4. She's willing to review documents, she would help with document
        producing. 5. She supports the effort but feels it needs more work to
        be a well defined IETF Working Group.

        Michael Richardson: Answers to BOF questions 1. Yes, interesting
        problem to tackle. Lessons from DNS sec space who has been through this
        valuable to review. 3. Charter has to say specifically what kinds of
        ACLs are necessary and what kinds of privacy and security are relevant
        because it changes scope of solution. For this to be useful the problem
        and scope will have to defeat the assumption that all D1s are at the
        same security level. 

        Speaker at mic: Agrees it's an interesting problem and support the
        effort, but wanted to know what is the consideration for Discovery
        Services under multiple standards, such as those to be built by China,
        Korea, that are independent of existing standards (e.g. EPCglobal)? 

        Mark replied DS is completely agnostic. Points a URL to something which
        hopefully has a standard protocol.

        Andrew Sullivan: 1. thinks it's interesting to tackle 3. Concerned over
        scope of charter - Is this a global directory problem? Whether it's a
        global supply chain or not, make it clear in the charter. 5. He is
        willing to contribute.

        Phillip Hallam-Baker: Answers to BOF questions 1. Yes interesting
        problem to tackle. Many interesting problems to tackle. The real
        questions are 6. Will we be able to solve it? 7. Is the world going to
        care if we do?  Re: access control, thinks it's an accountability based
        control not an access control.

        Dave Crocker: Instead of a requirements group, let's call this a
        service specification. Benefit is that there are real world needs. If
        you have someone with the need, it constrains and motivates the service
        specification.

        Leslie Daigle agreed largely with Dave. Emphasized need to express it
        in IETF space. Important to look at it architecturally but has to be
        driven by actual requirements that exist.
 
        Eric Rescorla agreed needs to be driven by actual requirements but is
        fuzzy about what they are. Not crisp enough For IETF to charter.

        Brian had some questions back to diagram on Slide 11 about who needs to
        know what and how they find that. Some key or index serving as starting
        point for query?

        Mark: EPC identifiers are structured identifiers - so it is possible to
        use patterns and ranges for indexing. However, there may be a case for
        supporting unstructured/opaque identifiers. 

        Speaker at mic: Back to Slide 11 - What kinds of information should
        information provider R provide to D? Does D have some information first
        from R? 

        Mark: If Q is in a relationship with D1 it might not need to go through
        the federated D1 to find link information for R. Re: protecting the
        information, have to have some way about restricting who will have
        access to that. R may not publish to a Discovery Services unless
        legislation might require it to do so. 

        Same speaker at mic: What is published to D? Mark: mainly the URL for
        R. Speaker supports the ESDS effort.

     6. Next Steps and Action Items [10 min]
       
        Ted observed that at this point, he has seen some interest. Asked for a
        show of hands of those who agreed with BOF Question 1. but were not
        ready for agreement on a BOF charter today. No one disagreed that this
        is an interesting problem to tackle or that there needs to be work done
        (e.g. On the charter) before a working group is ready to be formed. 

        He asked who were willing to work on the charter between now and the
        Dublin IETF. About 20 raised their hands.

        Ted indicated there are two ways to move forward: Have a second BOF in
        Dublin or request an IETF study group. There are a maximum of two BOFs
        allowed. You don't have to wait for a second BOF, if you form a Working
        Group in the meantime. The move to a study group is an important step.
        The benefit of this move is some scoping according to a charter. 

        Ted: Does anyone here believe there's a difference between staying as  
        a BOF or becoming an IESG study group?       
       
        Margaret Wasserman: Haven't done enough yet to form a study group
        charter.  Maybe having a study group will come out of the next IETF.
        Could aim for a working group but have a study group come out of it.
       
        Ted asked if anyone thought this work didn't need to be done? No hands
        went up. He then asked for a show of hands if you think this work
        belongs in the IETF. Approximately 30 hands in the room were raised. 
       
        Phillip Hallam-Baker: All we can ask at this point is if anyone thinks
        this doesn't belong in the IETF. 

        Ted summarized the next steps in terms of Action Items as follows:           
 
        Action Items:  Those interested should join the mailing list.  Work to
        be done on technical documents to be more IETF-like Refine the charter
        Aim to form a working group before Dublin. If not possible, consult
        with Lisa Dusseault and IESG on whether to form a study group or have a
        second BOF in Dublin. 

        Strong sense of the room in continuing the effort within IETF and a
        strong sense that there is a need for work on next set of steps before
        proceeding.
              
        Participants were invited to a Beer BOF that evening at McGillans. 

        The session was attended by approximately 65 people, and there was a
        high level of engagement and participation.                

Appendix A

Detailed Discussion Notes of Agenda Items:
 
See slides for each section:

* http://www.ietf.org/proceedings/08mar/slides/esds-1.ppt

1. Agenda Bashing (Mark Harrison)

Ted Hardie welcomed attendees to the ESDS BOF and reminded them of the
statements in the Note Well, particularly that any statement made within the
context of an IETF activity is considered an "IETF contribution". He then did
an introduction of the Chairs. Mentioned the ESDS introductory session that
morning in the APPs open meeting and asked if there was any Agenda bashing. No
items were added. Noted for those listening to audio stream, that the BOF rooms
were not set up early enough. Instead they will find a Jabber scribe in APP
area room. In terms of meeting administrivia:

Elaine Chin volunteered as scribe.
Stephen van Egmond volunteered as jabber scribe.

Slide 3 - Mark Harrison displayed the agenda briefly before moving to next
slide.

Slide 4 - Mark reviewed the scope of discussion (see points on the slide).

2. Introduction to concept ( Mark Harrison )

Slide 5 - Mark talked through the example titled "How to chase a bull" which
walked through the food traceability scenario following a cow through the
supply chain from farm to retailer. In this scenario Discovery Services could
perform a one to many mapping of a cow to its various parts after processing.
Showed when events might be published at various points in the life cycle e.g.
upon being transported to processing plant, or upon shipping to a retailer who
can publish an event to say they received the product. The goal is end-to-end
traceability. Also used examples of surviving object composition (e.g.
assembling a plane or laptop from individual components) or decomposition
(breaking a container into pallets, pallkets into cases). Mark made the point
that Discovery Services are about enabling traceability and that this slide
represented a conceptual overview of how you publish records.

Slide 6 -  In the reverse scenario, a consumer may want to know where a product
has come from. For the traceability scenario discussed on Slide 5, a Discovery
Service can answer questions such as "Is my food safe for consumption? Where
has it been? How fresh is it?" . Discovery Services could provide links or
referrals to this chain of custody. Discovery Services are a referral service.
They do not store detailed information; they point to where you can find it and
only the information you're allowed to access. It is not a public search engine
in that sense.

Slide 7 - Mark reviewed current business drivers, such as improved traceability
(i.e. things are safe and we know where they come from). Another driver
mentioned  is improving supply chain efficiency which can be done by enabling
the exchange of serial level information. It's about balancing supply and
demand using fine-grained data for each individual item. Talked about the
trending toward more efficient data sharing e.g machine to machine interfaces
via EDI progressing towards web services. Talked about how DS enables improved
gathering of life cycle information history. Important for reuse of products at
end of life, like refurbished products, allowing for better decisions on how to
remanufacture or extract residual value. This is of interest to D. Potter of
PROMISE as this is an issue which is of concern to them.

Slide 8 - Discovery Services from a technical perspective. Mark explained the
EPCglobal network stack and noted that the EPCglobal community has made
progress on defining open standard interfaces between these components. e.g.
ALE specification is a way to request filtered data, while EPCIS specifies ways
to query an individual company for its detailed information including business
context. (i.e. answers not only where, what, and when but why). EPCglobal have
developed standards based on end user requirements and these are freely
downloadable. They have worked with ISO on e.g. GEN 2 air interface standard,
embraced  by both standards bodies. Discovery Services provides pointers to
information services (e.g web services, EPCIS) to find out which organizations
have information about an object. Some companies may not use the EPCglobal
network framework but have similar architecture stacks, as shown on this slide.

The focus of this work is on a technical protocol for Discovery Services. The
role of Discovery Services to provide referrals or pointers to the
organizations who have information about an individual object. There are 3
aspects focused on by ESDS work:  a) Publish protocol (how to get information
into DS) b) Query protocol (how to retrieve it) and c) bootstrap protocol which
is concerned with how to find relevant DS in the first place. The ESDS group
has worked with EPCglobal and is hoping for good collaboration. The IETF
community can help solve some of the technical problems and feed into future
EPCglobal standards work.

Slide 9 - What's different? Not so much concerned about describing a service
itself but finding which organizations have information about a unique id. The
focus is on a lightweight referral service that provide links to resources.(see
points on slide). Can be multiple providers to an organization. One object may
be handled by multiple organizations.  Many changes can occur in mapping along
the supply chain - e.g. cow to various meat products with various ids. Should
be able to map changes of links over time. Path an object takes can't be
predicted in advance, so need a directory-type referral service to find out
where things go over time. Some of the challenges: scalability. There are
potentially trillions of records for the objects in circulation. e.g. A pharma
company had said they were shipping a billion units of a product every year for
one product line. IETF expertise on scalability issues could be valuable here.
Also information may not be publicly accessible. Commercially sensitive
information needs to be protected by access control policies, proper
authentication etc. Need to have security at Discovery Services layer as well
as the information service layer to protect those links and prevent competitors
from mining the links.

Slide 10 - Some Specific Challenges: Scalability issues with access control.
There could be potentially trillions of records of objects in circulation.
Could end up with a cat's cradle or hyperlinear scaling of access control
permissions, if we don't develop a framework to handle security policy scaling.
Another challenge is co-existence and co-operation between multiple Discovery
Services and how to find the appropriate Discovery Service to locate
information for an object.

Slide 11 - This diagram shows the interaction between a client application, an
information provider resource, and one or more Discovery Services (D1-D3).
Start with Organization R, a company that has information and a database; it
handles an object with a particular id and stores event information in its own
database or information service. In order for other people such as trading
partners to find out this information, R needs a way to declare that it has
information about an object. It can publish a link into one or more Discovery
Services (e.g. D1, D2) to say it has information and possibly define an access
control policy to say with whom the information can be shared. Sometime down
the supply chain Organization Q encounters the object. It has an application
and wants to make a query on this object. Say the object information resides on
D1. Q makes a query to a Discovery Service it knows about (D3). That Discovery
Service can communicate with other Discovery Services it it is aware of (D1 and
D2)and reply with a delegation to D1.  Could keep an index or it could do
multi-path broadcast. One or several Discovery Services could respond (query
routing). D3 can say D1 knows about it. Q can then query D1 directly to request
information, and subject to access permissions, D1 can send a referral response
to say organization R has some information. Q can then make a direct query to
information provider R for more information. R may decide to release some
information to Q in response. Q's direct interaction with R is not something
Discovery Services would handle, but something which could be handled using the
open standard EPC Information Services (EPCIS) interface, which is downloadable
from the EPCglobal website. Discovery Services would focus only on the
referral, not the content of the query.

- Questions regarding clarification [15 min] 

Q. Eric Rescorla?: (audio not clear). Wanted to understand the business
relationships among partners in the diagram on Slide 11. 

A. Mark: There may be several information providers in the supply chain. The
Discovery Services shown may be independent of each other, and focused on
different geographic regions, industry sectors etc. but may have some sort of
federation so they are aware of each other's existence. May also have different
business models or different Discovery Services.

Q. Eric Rescorla?:(audio not clear) Rephrase of question: How do D1 and D2
relate from a business perspective?

A. Mark: A Discovery Service will by definition represent a type of community.
Within Discovery Services you need to have clusters or Supply Chain networks
who may have a policy on allowing another company to join their network. There
may be policies governing who is allowed to query or publish. Mike Young gave a
real world example of European pharmaceutical association EFPIA who is
considering use of a Discovery Service for their members. EFPIA is an example
where people with no mutual trust have obligations (imposed externally) to
cooperate.

Q. Eric Rescorla: (audio not clear) What stops a D4 from claiming he has a part
when he doesn't?

A. Mike Young: One of the working items being proposed for the group is a need
for a security model around Discovery Services. 

Q. Eric Rescorla:(audio not clear) Do you expect Discovery Services to enforce
a business relationship? Answer from Mark to this was "No". You seem to be
avoiding the information content question. Mixing up boundaries re: what parts
of series of protocols are in scope vs out of scope. 

A. Mark: We are not dealing with a data model or the  interfaces to the
database, which is addressed by EPCIS already. Interested in Discovery Services
in finding links to one or more information services. While there are some
similarities in the commands and framework of EPCIS, it's not about replicating
all the detailed information in a Discovery Service. It's a lightweight
referral service. We are trying to align terminology with EPCglobal where
appropriate. 

Q. Margaret Wasserman: (audio not clear) Need to understand who the players
are, what data they have. Defining that defines the problem. The problem
statement is too weak on what is the real interesting problem trying to solve.
It's an interesting problem when Q doesn't know which Rs are needed.(i.e. when
Discovery Services might be a different provider). R may have opinions about an
object but may not want to have another R to know. Complicated and interesting
problem to solve. Need to make it more clear in the documents what you are
trying to solve.

A. Mark: Certainly an interesting problem to solve.

Q. Speaker at the mic:(audio not clear): There are existing protocols that do
this, though not in this body. Wouldn't have to reinvent the wheel. At least
two open source implementations are available. He will post a link to the ESDS
list space.

A. Mark: If we can leverage existing work, that will help all of us. XML and
Web Services are not a problem. 

Q. Ted Hardie: When D1 sends a pointer to Q that tells it to talk to R, it
might use an independent query mechanism that's not an EPCglobal standard.
Maybe it can tell you what the query mechanism is. There's a requirement for
generality. Other piece is tied to the business model. There are definitely
going to be information providers who are tightly bound to specific
identifiers. This would be useful in cases where it's very loose. e.g. creating
commentary meta data rather than ownership meta data, where there may be
multiple places to query because with commentary meta data it's not about
control vs a baggage handling use case, where the bag cannot be in more than
one place at one time. There are many things that are not as unitary as a bag.
Commentary-related things can benefit from generality.

A. Mark: Discovery Services can point to other information services or
commentaries and so on. A serviceType field could be used to distinguish
between different kinds of service accessible through the various referral
URLs. 

Q. Speaker at mic: If you go back in the RFC archives for the TISDAG project
(distributed whois directory), the search and referrals model is very similar
to this and there may be good experiences to draw from. Some of the same
problems were identified. Written in technical terms that were hot at that
time. Like LDAP.

Q. Kurt: Clarification question on diagram (Slide 11)- which of those
communications are you looking at standardization in this forum?...D1 and D3? R
and D1? 

A. Mark: We're looking at developing protocols for publishing (R to D1), query
(Q to D3) and also interested in the bootstrapping problem between DS. whose
problem lies in the pink triangle on the diagram (D1 - D2 - D3), not in the Q
to R query response, which is already handled, for example by EPCIS. 

Q. Phillip Hallam-Baker: Noticed in security world a higher incidence of people
asking for security and Access Control Lists (ACLs) than using them when
deployed. Thinks this is due to lack of visibility in existing systems of
knowing whether security is there. Would be a shame to go through designing a
system that could be secure but in fact is as insecure as the rest of the
infrastructure, because it is not configured right. Keep coming back to this
trying to solve for a specific application and not abstracting to a generic and
then reinstantiating a problem as an example. Has seen too many one offs that
we should now be thinking about an architectural approach. Opposed to
architectural thinking divorced from a use case. Focus on architecture - it
still has value.

Q. Dave Crocker - Phillip's suggestion is good. For this group bringing this to
the IETF is a bad idea. I think there's multiple agendas here that could and
should be served. Here you have a use case that could be solved. You want us to
help you with it. "We" in the IETF world have some knowledge that can come to
bear, but we'll be thinking about this in a larger way than you might need us
to. Not there yet. What's really great is to have some outside group come with
a narrow concrete easy  to understand problem where we could provide an narrow
concrete easy solution. Not the case here. Don't have a track record in IETF of
solving this category problem in the general or in terms of large scale global
activity with the exception of DNS. Given the usage scenarios, you wouldn't do
it in 15 min. Not in a position yet to say there's a solution that exists
because can't understand the problem statement yet. Think you are in need of an
IETF process to get to the point of specifying protocol or protocol choices.
Loathe to call it a requirements working group, vs choosing a protocol space.
Problem space is way more complicated than that. Will take time and work to
make sure IETF understands the problem before getting your world and our world
to the point where we know the solution. 

Q. Speaker at mic: wanted to understand relationship between ESDS...and IP in
the triangle figure (Slide 11). Current ISO, or EPC solutions don't consider IP
protocol. New devices like RFID, need end to end connectivity using IP. Wants
to know the current status of solution.

A. Mark: Some of the objects you are trying to track might not have network
interfaces as such. Can respond saying this is my ID. Won't be able to
communicate via TCP/IP to talk to that object. What you're doing often is
talking to an agent that represents that object. e.g. Records in a database.
The object itself has no network interface as such. Communication often
involves talking to an agent (e.g. an information service) that represents that
object.  

3. Review of Problem Statement ( Michael Young )

Slide 13 - Mike asked for show of hands how many had read the Problem
Statement. Approximately 45%, or 30 people raised their hands. Mike pointed out
that he had been at IETF meetings where people haven't. Wanted to pick out some
"sore points" that IETFers will ask in their heads re: the Problem Statement.
e.g. who's interested, going to contribute, consume, do the work, etc? 

Slide 14 - The list of names on this slide represents both consumers as well as
contributors to DS work. ESDS mailing list has over 70 members. He mentioned
the EPCglobal working group whose information can be consumed to satisfy need
for defining requirements and get to the work of the technical protocol. Some
of its members here today are people who have worked for research groups such
as BRIDGE and PROMISE. 

Slide 15 -  Why the IETF?. There are some problems that IETF could help solve.
e.g. complexity of the bootstrapping process and scaling to global operations.
The IETF have long, deep expertise and knowledge of mistakes we can learn from
e.g. where not to go. Security consideration is a big work item. Security will
be borne out of requirements. It has to adhere to or enable a security model,
so if validation is done externally, could work with that. Protocol has to be
able to work if security is to be done externally. Can leverage other learning
too. The Forest Guides have outlined a similar problem  P2PSIP has distinct
similarities to DS and differences (proxy validation). Looking for feedback on
the right way to deal with these issues.

Slide 16 - Answers the question: What does this work enable? Today the world is
about point-to-point (PTP) communication when it comes to physical objects
moving around. If you don't have PTP won't have access to a lot of information.
So if you are tracking maintenance on airplane parts there is no reason not to
enable that solution to find all the MROs for airplane parts. This work enables
the addressing of real world needs, such as audit trail for safety-critical
products, counterfeit product detection and support for product recalls. How to
establish and enforce trust is important. Shortly legislation will require
pharma track and trace. No easy way to do this today. Items like Discovery
Services make this more valuable. Cited Pfizer heart drug recall example where
Pfizer received back 2.5 as much product as was shipped due to lack of accurate
track and trace capabilities in the distribution network not known to the
pharma manufacturer or retailer in depth. DS could help heuristically discover
things like that. 

Slide 17 - See slide points. Driving forces include fraud protection for
consumables like drugs or food products. Need for multiple Discovery Services -
In an open market, even if it is technically possible to have one Discovery
Service to share, with access controls no one would accept that. Reality is
that a supply Chain dealing in car parts in Europe doesn't care about a milk
delivery supply chain in Delaware. The World is a series of circles of
relationships so multiple Discovery Services have to be assumed. Also mentioned
the demand for increased security. It is not assumed that anyone can connect to
Discovery Services. 

- Questions regarding clarification [15 min]     (came after slide 16)   

Q. Speaker at mic : When a query is done today (e.g. What part is in the
airplane, Where are these drugs now?). How many different organizations are
contacted to get this information? Is there an automated way of doing this?
Where does this scale today? i.e. How many actors do you imagine being involved
in a product's life cycle?

A. Mike: Reality is scary. Current plane part records are maintained on paper. 

Q. Same speaker at mic: It's a multiple choice question... What is the number?

A. Mike: On a given object may have 20 or more organizations Mark: the Bridge
project has seen up to 50.

Q. Margaret Wasserman: That's for a serialized item. If you want to find all of
the  Tylenol manufactured in the last 2 months it could be a very large number.
There's a large number with these tabs of 50 going through it.

Questions were cut off at this point in order to move on with the agenda.

4. Expectations of deliverables (Mark Harrison)

Slide 20 - Reviewed expectation of what Discovery Services will provide, based
on user requirements for the BRIDGE project.(3 year project with 30
organizations).  Started by asking what functionality needs to be provided:
tracking, forecasting (where's an object expects to be), alerting, misplaced
and duplicate ids. Discovery Services enable those applications by providing
links to sources of information that need to be checked. When would you update
a DS? On shipping and receiving events. Latency should be ideally 1 sec. Should
have support for standing queries. Manufacturer might want to know who's
handling the product next. Provisioning with multiple information providers.
Emphasized the need for all supply chain parties to contribute to the service
preferably on subscription basis.

Slide 21, 22 - Technical expectations: Primarily referral URLS, timestamp and
possibly some meta data to have hooks for defining access control policies. In
terms of size need to support scalability e.g. up to 1 billion events per year
for a particular line with 50 or more companies handling an object and 100K
queries a day. Discovery Service records might refer to other systems where
information is stored: EPCISs, ERP systems, or other Discovery Services. Not a
hard-coded link. Should allow full trace query of all organizations who have
event information, preferably time ordered. Support for synchronous and
asynchronous responses. Felt shouldn't be allowed to update records. Maintain a
journal log. Have a voiding policy. Further details can be found at the Bridge
project website listed on the slide. There are also some design documents
related to ESDS activity.

- Questions regarding clarification [15 min] 

(Questions after slide 21)

Q. Speaker at mic: Substantial list of requirements. The assumption you're
making is that you're only dealing with referrals; you hope that would simplify
things enough for you to get this Working Group. This ends up looking like a
distributed directory.  You think that just dealing with referrals will make it
more successful than previous distributed directory attempts. Is it your
assumption that you're only going to deal with referrals vs other distributed
directory attempts?

A. Mark: A lot of detailed information might be stored with a company (e.g. 100
events), but you only need to post one link. Referrals is a way of reducing the
scale of the problem.
 
Q. Same Speaker at mic: Would have to maintain some sort of index. Brings up
problem of modelling and matching rules (essentially LDAP). If assumption is
that it's a simpler model, it's a mistake. Just as complex as any distributed
directory. Won't get away with dealing with matching. 

A. Mark: Trying to reduce the amount of space records take up. Simple data
model doesn't make it less complex to solve. There are some patterns in
existing EPC identifiers that can be used for matching. 

Q. Phillip Hallam-Baker: The failure of directory systems has been raised.
Reason x.500 is extinct has nothing to do with technical merits. The reason
most directory projects fail is because the content isn't there to look up in
the directory. Should recognize that this is an IETF proposal to take on part
of the technical work going on in EPCglobal. Clearly EPCglobal won't wait for
technical challenges to be addressed in this body. Good to have a use case that
focuses on the technical considerations. Similar to Keyprov and other working
groups. If deliver on time, it will be used. Likely one of these deals - if we
do the work for EPCglobal they will either use it or if not completed in time,
do the work on their own.

A. Mark: I have a slide that discusses that on a time scale, will show it
shortly.

(Questions after slide 22)

Q. Andrew Sullivan: General purpose directory-ness of this. Because you are
dealing with distributed meta data - makes it more complicated because you have
a vocabulary of meta data spread out. Have a directory of directories problem
plus  problems of directory issue itself. Does it make it worse? Should we go
back and use the DNS model in ONS even if you are going back to one source? At
least you'd have one well known problem. 

Q. Margaret Wasserman: Co-chairs SAG at EPCglobal. Work at present in EPCglobal
is requirements gathering only. The hope is that their work would feed into
this group with a technical protocol done in this body. Hope is that ongoing
process will feed in here. There is no technical work being done at EPCglobal
in this area.

Q. Ted: Follow up from a process perspective. It's not a global distributed
directory problem. Important to think about differences between distributed
directory vs global distributed directory. Security and scope considerations
have to be taken into account. Real question is "What does it take to make this
a manageable chunk of work? Is that enough?".

5. Scope of work ( Mark Harrison ) 

Read ESDS charter out loud. And scope of work. Any comments? Have some
questions he would like some rough consensus on:

BOF Questions 

        1) Is this an interesting problem to tackle?
        2) Is the scope of work appropriate to the problem?
        3) Is there support to form a work group with the following charter?
           (i.e. that the charter itself is ready and supported by the
           community)
        4) Can I ask for a show of hands for who is willing to review
           documents?
        5) Do we have any additional volunteers as an editors for some of the
           document(s) to be produced by the work group?  

- Questions regarding clarification [15 min] 

Q. Leslie Daigle: I do think its an interesting problem to tackle. Some
similarities to the whois service problem where do have some entities
notionally working together and problems in establishing a shared context. Not
a global directory services problem. Hasn't seen anything too scary here. 

Q. Eric Rescorla: Has read the documents. Unclear still about what trying to
achieve. I let the thing go Re: the business relationship but wants to go back
to it. Re: diagram on slide 11 - start with R (company who handles the object)
and D1 (who has Discovery Services). Does R have a contract with D1? 

A. Mark: R is a company who handles an object. May have a relationship with D1
as a Discovery Service for their region. May be posting to more than one DS
(e.g. If product is shipped from Europe to North America).

Q. Eric Rescorla: Is there a contract? SLA? Bilateral agreement? A. Yes should
be. Q. What is the relationship between D1 and D2? 

A. Mark: D1 and D2 could be aware of each other's existence. May be aware of
the scope that the DS services (e.g. Region).

Q. Eric Rescorla: Say I want to become a Discovery Service, how do I do that?
Post something on the Internet?

A. Mark: Ideally there should be conformance tests to a standard protocol; may
be independent auditing, enforcing access control policies ,further checks of
audit trails imposed by legislators. Checks and balances to be set up as a
Discovery Service. 

Q. Eric Rescorla: The system you're describing assumes a single large trust
boundary. 

Ted: He's saying that everyone who has a D prefix in this federation of DS is
in a single trust boundary. Important to remember that this trust boundary is
different from the boundary between Q and R. It is not the full trust boundary
implied  between Q + R. Answer is yes perhaps but its  a different trust
boundary that would have dealt with previously.

Q. Eric Rescorla: Would be fine if concerned with information leakage. Pushing
on this because he has heard two things. First: Important to conceal which info
providers are providing info about an entity. Seems Every DS knows. It matters
where things actually are. Don't understand what stops any information provider
from claiming to own any entity at any time.

A. Michael Young: Reality is there's not one owner of this object. Consequences
of misbehavior: e.g. If D1 is a large contractor company with an accreditation
process, the D1 operator will have some type of an out-of-bound physical
verification where if you misbehave we point the authorities to you. But this
is out-of-bounds to a technical protocol. 

A. Ted: Recast the problem by going back to baggage claim scenario. Is your
issue: If a bad D4 is willing to lie, they can point you to an R2 who doesn't
have your bag but is willing to claim the bag is there? So if there's an R2
with a relationship with  D1 or D2 it can claim to have the bag even if it
doesn't?

Q  Eric Rescorla: Problem with the security model is everyone is in trust
boundary. There's limited access control. Way you stop malfeasance is by having
people shot. Goes to fact that you've already assumed the fact that access
control problem will be handled by non-technical measures.

A. Ted: There are aspects of this that require non-technical measures. Part of
it is in way identities are minted. Assuming if IATA assigns minting, if try to
handing over to D2 they are risking their bilateral agreements to D1 and
accreditation with signing authority and even if they are willing to risk
those,it doesn't give me the bag. 

Q. Eric Rescorla: Whole premise of systems being described is that there is a
disjunction between people doing the minting and people who have the stuff. If
they're the same it'd be different

A. Ted: That's true. In beginning they may be the same.

Q. Eric Rescorla: Trying to figure out what the implied relationships are in
terms of what's being enforced. Seems 90% of enforcement is non-technical. You
say important to have technical access controls. So one way to handle it, have
no access controls. If people are looking at wrong information, have them shot.
Before get into tech access controls, wants to know why can't do that?

A. Ali Rezafard: Everyone who injects goes over SSL layer. 

Q. Eric Rescorla: How can that be relevant? 

Ali: They are given a certificate by certified authority so know who published
it. If bad information is published. Can have consequences.

Q. Ted: Agreed you can shoot a person as long as it's not a member of the
author team or the BOF chairs.

Q. Margaret Wasserman: Comment on Eric's question. Not sure this is a solvable
problem. One of the answers is that R tells us the level of security of
information allowed (which Qs are allowed to see it, which D2s are allowed to
expose itself to). Forget the ID minter. 

Q. Eric Rescorla: I don't understand how only certain Ds can see it, because
all Ds are identical.
 
Q. Margaret Wasserman:  We don't have a strawman proposal for this. A
particular group will contract to provide their Discovery services. If D1, D2
and D3 are different information Services (shoe containers example). R. has to
say whether it's sensitive information or not. Answers to BOF questions: 1. Yes
very interesting problem to solve. Have read more about this problem because of
involvement with EPCglobal, etc. Doesn't think the problem has been effectively
defined within an IETF context. Need to define problem better before can
charter work group on a solution. 2. Don't get the sense of the scope of work.
Charter needs some work to be done about what work items are to come out. 3.
Charter needs to be more complete. 4. She's willing to review documents, she
would help with document producing. 5. She supports the effort but feels it
needs more work to be a well defined IETF Working Group.

Q. Michael Richardson: Answers to BOF questions 1. Yes, interesting problem to
tackle. Lessons from DNS sec space who has been through this. When DNS was
invented,it had no  Access Control Lists (ACLs). Over the  20 yrs. since
deployed and DNS sec have added ad hoc mechanisms... DNS sec's previous
processes are valuable to review.  Didn't invent ACLs. Contained information
for people wanting to know it. 3. Charter has to say specifically what kinds of
ACLs are necessary because it changes scope of solution and has to say what
kinds of privacy and security are relevant. It's not enough to say there's SSL
on the communications path. Important for the reason Margaret mentioned with
respect to shoes in box in container shipping to Walmart in St. Louis that also
contains diamond rings. Similar to Internet: we do standards for things like
BGP or diffserv Because traffic flows through different providers to get from
Point A to Point B. Its the Same problem... even if people are members of
various associations. If I'm a Manager of Wal-mart I have to talk to a dozen
organizations that I have no relationship with. For this to be useful the
problem and scope will have to defeat the assumption that all D1s are at the
same security level. Bigger problem there to make it useful but maybe good it's
shown up at the IETF which is good at solving interdomain problems. Maybe we
don't care about Q to R, as Q to D1-D3 relationships.

Q. Speaker at mic: Agrees it's an interesting problem, but before he answers
the five questions wants to ask - EPCglobal is used as an example for the
problem statement. But so many standards countries like China, Korea are going
to build standards for supply chain. What is your consideration for Discovery
Services under multiple standards? Independent of existing standards? 

A. Mark: DS is completely agnostic. Points a URL to something which hopefully
has a standard protocol to it, accompanied by a service type.

Q. Same speaker: He supports (BOF question 3.)

Q. Andrew Sullivan: Worry he has is in the scope of proposed charter. Is it a
global directory problem? On one hand talking about some relationships on other
hand talking about the global supply chain (i.e. everyone in the world).
Clarification in charter needs to be made or could end up with a very big
problem. Would be willing to review docs and work on them. Re: Answers to BOF
questions - 1. thinks it's interesting to tackle 3. Is this a global directory
problem? Whether it's a global supply chain or not, make it clear in the
charter. Becomes automatically a distributed directory problem. 5. He is
willing to contribute.

Q. Phillip Hallam-Baker: Missing some questions. Answers to BOF questions 1.
Yes interesting problem to tackle. Many interesting problems to tackle. The
real questions are 6. Will we be able to solve it? 7.Is the world going to care
if we do? To Margaret's point, he is aware of EPCglobal politics more than you
think and has been pouring oil on troubled waters these past weeks. There are a
lot of problems here. Control of world supply chain could be another can of
worms. To answer a previous speaker's point re: access control - doesn't think
this will work as an access control problem. Can't write all the rules in
advance. All you can do is keep audit trails and have accountability, so if
someone does default, can shoot them or fine them. Use case of bag is not a
problem. It's an accountability based control not an access control.

Q. Dave Crocker: beginning to believe he knows what ought to do now. A
requirements group would be the worst thing in world. We have the best track
record for doing syntax and exchange rules. Let's call this a service
specification. There was no protocol reference in the discussion last night
which led to diagram on Slide 11. What you need to do is work through or
negotiate functionality without worrying about the acronyms that go with them.
Trust domains are not easy. That's serious technical work. Benefit is that
there are real world needs. If you have someone with the need, it constrains
and motivates the service specification. It's fine if it does more, not if it
does less. Makes it a realm that's larger than before but at least its
constrained and concrete.

Q. Leslie Daigle: Largely agrees with Dave Crocker's last comment. Wanted to
emphasize need to express it in IETF space to make it something can get our
heads around. Look at in terms of an architecture related to but separate from
efforts done before in directory services, so it's reusable. Make it be an
engineering problem and separate out the business requirements. Interesting
problem to tackle. Make it part of an architectural suite of Internet services.
Important to look at it architecturally but has to be driven by actual
requirements that exist, else theoretical.

Q. Eric Rescorla: Agrees needs to be driven by actual requirements but is fuzzy
about what they are. Not crisp enough For IETF to charter. Not convinced about
this control thing. Gave example of a friend's move with items in a shared
container. Suddenly he's part of a larger sphere of influence now. Doesn't see
how the system doesn't devolve into a single global database almost
immediately. Fascinating research problem to build a system like that with
reasonable security but doesn't know how to solve it.        

Q. Brian Dickson: Back to the diagram on Slide 11 - Another couple of questions
based on Ds, Q and who needs to know what and how they find that. Presumably
will have a lot of Ds - Hundreds? Thousands?

A. Potentially lots of Qs and Rs that will outnumber Ds. 

Q. Brian Dickson: Ds will likely be less but still numerous. D's may or may not
have a bilateral relationship but not a multilateral relationship other than at
the protocol level. A problem: Anything other than the ID itself acting as a
key into the system that allows Q to decide who to ask? 

A. By inspection? 

Brian Dickson: By some index that this ID is this kind of thing (e.g UPC +
something else). How does it start querying anywhere in the system?

A. Mark: EPC has those structured identifiers. Some use cases where identifier
may be opaque (structured or not).e.g. Pharma unclear whether to use structured
identifier because someone might read it. May involve technical solutions like
pseudonym schemes. 

Q. Brian Dickson: As long as there's some structure to start with could provide
insight as to what is or is not needed. A key part of understanding those
relationships and what's needed to make it work. 

Q. Speaker at mic: Simple question. In future will be many information
providers e.g. China, Korea. Referred to Slide 11 Diagram.  Why would
Information Provider R provide information to D to discover the service? Some
information may be secret. What kinds of information should information
provider R provide to D? Does D have some information first from R? 

A. Mark: If Q is in a relationship with D1 it might not need to go through the
federated D1 to find link information for R. What you're saying about
protecting the information, have to have some way about restricting who will
have access to that. In some cases may not publish to a Discovery Service.
Whole mixture of possibilities. R may not publish to a Discovery Services
unless legislation might require it to do so. 

Q. Same speaker at mic:  What is published to D? Mark: mainly the URL for R.
Speaker thinks R should provide general information to D. He supports the BOF.

6. Next Steps and Action Items

Ted wanted to know how many interested in going forward. Clearly at this point
has seen some interest. And has some strong sense of the room that this group
is not yet ready to be chartered as a Working Group. Anyone disagree? No hands
ready.

Ted: How many of you are willing to work on charter to prepare it for a Working
Group? Fair number of hands raised.

Ted: There are two ways of doing this: 1) aim for another BOF in Dublin. 2) ask
IESG for a study group (similar to a requirements group but gives you formal
standing). Anyone believe it makes a difference to be a study group or BOF?

Ted: Raise hands if think should be a study group, which has a charter. Only
get two BOFs. Could ask for a Working Group if activity on the mailing list
justifies an update between now and Dublin (without having a second BOF).

Margaret Wasserman: Study group might be good for this effort, but not scoped
enough to make a study group charter. Maybe form a study group out of the next
IETF. 

Ted: Aim for a Working Group but come out with a study group.

Ted: Anyone believe this work does not need to be done? One participant can't
tell. 

Ted: Does anyone believe it shouldn't be done here? One participant can't tell.
No one else is raising an objection.

Ted: Raise your hand if you believe this work belongs in the IETF. Sense of
room is pretty strongly in favour.

Given that, he proposed as Action Items:

1. Those who continue to be interested in the problem go on the mailing list.
2. Refine charter.
3. Continue to work on the technical documents.
4. Caucus with Lisa and IESG to see they believe if next steps are Working
   Group, BOF or study group. With the presumption that work needs to be done to
   bring technical docs into IETF terminology.

Strong sense of the room in continuing the effort within IETF and a strong
sense that there is a need for work on next set of steps before proceeding. 

Anyone object to next set of steps? No. 

Ted thanked attendees for their time. 

Ted: See you on the mailing list where we will be working on technical docs to
make them more IETF like. And where we will refine the charter and continue the
conversation on whether we are going for a study group or Working Group before
or at Dublin.

Mark also thanked everyone.

Beer BOF invitation extended to participants at McGillans on Drury Street.
_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Mar 2008 16:16:52 -0700

>Please let me know of any omissions or corrections within the next week.

Elaine,
	Thanks very much for these very detailed notes.  Given
that a number of mailing list participants were not able to be there,
I'm sure your work will be appreciated. 
	If folks have additions or corrections, please send them
to the mailing list. 

>Anyone object to next set of steps? No.

	For those interested in seeing this work progress, it is
very important to continue to have technical discussions on the
mailing list.  In a sense, it is easiest to justify a working group
when a mailing list is already acting like one:  producing documents,
getting technical review, and achieving forward progress. 
	Thanks again to Elaine for her very detailed notes.
				Ted

>Content-Type: text/plain; name="IETF_ESDS_BOF_Minutes_Draft_0.4.txt"
>Content-Description: IETF_ESDS_BOF_Minutes_Draft_0.4.txt
>Content-Disposition: attachment;
>	filename="IETF_ESDS_BOF_Minutes_Draft_0.4.txt"; size=66880;
>	creation-date="Wed, 19 Mar 2008 09:14:37 GMT";
>	modification-date="Wed, 19 Mar 2008 09:14:37 GMT"
>
>Attachment converted: Macintosh HD:IETF_ESDS_BOF_Minute#715AC5.txt (TEXT/ttxt) (00715AC5)
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=191;
>	creation-date="Wed, 19 Mar 2008 09:14:37 GMT";
>	modification-date="Wed, 19 Mar 2008 09:14:37 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 690.txt (TEXT/ttxt) (00715AC6)