Draft Minutes 28th May 2014

[Martin Chapman <martin.chapman@oracle.com>]

Meeting Minutes 28th May 2014

Attendees:  

Oracle			Martin Chapman	Chair
Fujitsu Limited		Jacques Durand	Voting Member
Oracle			Ashok Malhotra	Voting Member
Rackspace Hosting, Inc.	Adrian Otto	Chair
Oracle			Gilbert Pilz	Voting Member
Fujitsu Limited		Tom Rutt	Voting 	Member
Software AG, Inc.		Prasad Yendluri	Voting Member



Intro:

     Scribe: Adrian
     Roll: attendees listed above., 7 of 11 (63%) Meeting is quorate.
     Agenda: Agenda approved as posted

Minutes:
 
       7th May 2014: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201405/msg00010.html 
            MOTION: m/Gil s/Tom TO approve minutes from previous meetings
             no objections, motion passed by UC

Admin/Status:

     Tom: will Solum be an Implementation of CAMP?
      Adrian: If Solum is an instrument for CAMP exit criteria, contributors will need to add code as an additional API for Solum. There are no contributors currently working on this for the purpose of standards compliance.
      Contributions are welcome.
            nCAMP will be one implementation of CAMP for exit criteria purposes

New Issues:

    https://tools.oasis-open.org/issues/browse/CAMP-171  spec doesn't explicitly say you can use "select_attr" with PUT

      Gil presents CAMP-171
      PR08 says that selectattr may be used in a GET request
      PR12 Specifies that Request parameters may be specified
      the PR12 language is ambiguous
      Gil proposes improving the language to be more explicit WRT selectattr with PUT
      MOTION: m/Gil s/Tom to open CAMP-171 as a P3 issue
      No objections to the motion.
      Motion carried by UC

      https://tools.oasis-open.org/issues/browse/CAMP-172  consider specifying a generic 'version' characteristic for use in ServiceSpecifications

      Gil Presents CAMP-172
      We acknowledge that we do not want to dictate the exact form of service specifications at this point
      This issue suggests that having a version matching scheme would be a benefit for the sake of interoperability
      the style of version matching used by Maven is proposed as an option
      We do not define services, but will specify how versions of services are expressed by confirming providers
      MOTION: m/Gil s/Tom to open CAMP-172 as a P2 Issue
      No objections
      Motion is carried by UC
 
Open Issues:


      https://tools.oasis-open.org/issues/browse/CAMP-169  CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
      2 pronged approach
      1) Remove from Examples
      2) Explain nested ServiceSpecifications in the Primer
      Implementations would need to support both styles of expressing nested ServiceSpecifications
      Gil has written a parser for dealing with these relations, and does not feel it's burdensome for spec implementers.
      We do not need to change the normative statements. This is about deleting an example expression of a plan.
     Gil to propose exact edits.

AOB:

      Gil expects to have a concrete proposal for CAMP-169 and CAMP-171 next week.
      next week we will meet.
      Straggler roll call:       +Jacques
      
Meeting Adjourned