Draft Minutes 19th March 2014

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

Meeting Minutes 19th March 2014

Attendees:

Software AG, Inc.		Bhaskar Reddy Byreddy	Voting Member
Oracle			Martin Chapman	Chair
Fujitsu Limited		Jacques Durand	Voting Member
Cloudsoft Corporation Limited	Alex Heneveld	Voting Member
Oracle			Anish Karmarkar	Voting Member
NetApp			Alex McDonald	Voting Member
Rackspace Hosting, Inc.	Adrian Otto	Chair
Vnomic			Derek Palma	Member
Oracle			Gilbert Pilz	Voting Member
Fujitsu Limited		Tom Rutt	Voting Member
Software AG, Inc.		Prasad Yendluri	Voting Member

Intro: 

      Scribe: Adrian Otto
      TOPIC: Roll Call
            Attendees listed above Voting Members: 10 of 12 (83%) Meeting Quorate
      TOPIC: Agenda
            No objections to agenda, accepted as approved.

TOPIC: Minutes
 
        12th March2014:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201403/msg00019.html 
            MOTION: m/Gil s/Tom - Approve minutes from https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201403/msg00019.html 
           Motion passed by UC.
      
TOPIC: Administrivia

      New Jira system was installed.
      Project status: 3 open issues
      Current open issues: 3 in total; 0 P1,  3 P2, 0 P3.
      PR2 for Spec ended Monday 17th, no new comments received.
      No comments on TA yet. Public review continues
      
TOPIC: Editing Team Update

      WD40:      https://www.oasis-open.org/apps/org/workgroup/camp/download.php/52518/link 
      
TOPIC: New Issues
      None
      
TOPIC: Issue Discussion

      https://tools.oasis-open.org/issues/browse/CAMP-166   CLONE - Response to call for comments: "application packag", "_uri", and "DP example"

            Possible CNA
            MOTION: m/Gil s/Adrian Close CAMP-166 with no action.
            Discussion: thee type of the value of an attribute must not be changed
            Motion carried by UC.


      https://tools.oasis-open.org/issues/browse/CAMP-167  New JSON RFC 

            Should we reference the new RFC for JSON?
            Gil Pilz (Oracle): +1 to Adrian
            Adrian: Changing the reference should happen when language support in prevailing libraries also uses the new JSON
            We can possibly defer this issue
            Alex McDonald expressed difficulty at NetApp using the new RFC, as there are considerable changes.
            ... elimination of duplicate key value is a concern for libraries that use the .Net JSON parser is impacted by the changes
          Gil Pilz (Oracle): specs don't have to say what happens when the actors in the spec violate the requirements in the spec
          Anish indicated that this restriction is not expected to impact CAMP

          Tom asked if we might consider using http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf 
            MartinC: im hearing either a defer or close
            Anish indicates that it's safer to remain with the current reference
            MOTION: m/AlexH s/Gil to close CAMP-167 with no action
            Discussion
            anish: one interesting potential impact is wrt our SelectAttr query param
            Gil: What about deferring the issue rather than closing it?
            anish: so if i want a single attribute in a resource which is of type int and use SelectAttr, the new RFC allows just the int (without curly braces). *If* we move to the new RFC, would we allow that?
            Motion carried by UC

      https://tools.oasis-open.org/issues/browse/CAMP-168   requirment_type is confusing for implementers

            RequirementsSpecification 4.3.6 should make it clear that there will be a number of other key/value pairs that are specific to that requirement_type and that the implementation will do the work to satisfy the requirement
           Gil indicates that using key/value pairs in the requirement might overlap with the ServiceSpecification
            Alex Heneveld: The `requirement_type` is a string which indicates to the CAMP server what logic to apply to satisfy the containing RequirementSpecification when matching the artifact with services.
            Alex Heneveld: (some proposed text)
           Gil Pilz (Oracle): I've got code in nCAMP which processes Service Specifications as per the PR draft
           General agreement not to materially change the spec but to add in better explanation of how requirement_type and service work. 
            Gil and Adrian to work on a proposal, to be ready for next call in two weeks.

AOB:

      Several people away or busy next week so next meeting on      2014-04-02 (timezones will be back in sync by then)
      Stragglers: add Jacques.

Meeting Adjourned.