OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Draft Minutes 4th June 2014

Meeting Minutes 4th June 2014


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


      Scribe: Anish
      Roll: Attendees listed above.  10 of 10 (100%) Meeting is quorate.

      Agenda: https://www.oasis-open.org/apps/org/workgroup/camp/event.php?event_id=36492 
         agenda approved w/o change

Topic: Approval of minutes


      Motion: m:Gil s:Anish approve minutes of 2014-05-28 located at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201405/msg00019.html 
      motion approved w/o

Topic: Adminitrivia
      3 open issues on the spec, 2 p2 and 1 p1

Topic: editing update
      no update; no new draft
Topic: new issues
      no new issues
Topic: Issue 171 https://tools.oasis-open.org/issues/browse/CAMP-171 

      Proposal in Jira
      gil walks through his proposal
      Jacques: new normative requirement is a MAY that is essentially a MUST for the provider
      Gil: sounds like PR76 is an analog of PR8, but no analog of PR7
      ... we do say in PR12 that the only thing that the consumer can put in the body of the req is what is in the select_attr
      ... PUT means replace, what more do we need to say?
      Tom Rutt (Fujitsu): Administrative Detail:  Both PR-47 and PR-12 are copied into the test assertions CSD01.  We need to have a way of tracking that changes to requirements in CAMP get reflected into the TA
      Tom: any change to normative stmt or new normative stmt needs to figure into the TA doc
      Adrian Otto (Rackspace): 4XX status code is not a specific code
      Adrian Otto (Rackspace): in the proposed text for 6.5
      Adrian Otto (Rackspace): 400 Bad Request is the right response
            need to make sure that absence of an attr in the body but when it is present in select_attr means deletion
      Gil: PR-25 covers  it
            happy with PR-25
            Adrian thinks the 400 is the right status code
        Gil: need to fix it one way or another. Currently inconsistent
      Gil: will fix it everywhere to make it 400
      ... and update the TAs
      Adrian: we should make all the client status codes specific
      Gil: don't need an analog to PR-47. PR12 & 13 cover it
      Jacques: concern is that we are still expecting the server to support it
            we need to say that the server must support PUTs with select_attr
      Gil: in that case we need the same wrt PR-08
      Martin: PR-47 covers the case for requiring servers to support GET with select_attr, we just need one for PUT
      Gil: may be a way out of this is to not try to match what we say for PUT (with what we say for GET)
      ... will create a v2 for this
      Martin: may need a new issue for 4XX or address this in the proposal

      ACTION: Gil to generate a v2 proposal for issue 171
Topic: issue 172

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

      Derek talks about using an expression language
      Gil: Adrian - does OpenStack use any expression language like this?
      martin: would prefer to use an existing expression language
      Alex Heneveld: i'd like to have this (versioning) in time. but we don't yet even define types so it feels like premature weight.
            osgi uses semantic versioning, similar to what Derek as outlined and they use LDAP query strings    
      Alex Heneveld: i expect most implementers will follow maven/osgi/sem-ver anyway, but there will be other issues, i think it should gestate first.
            Gil: would like to find out if OpenStack has a solution for this
      Alex: would want this in fullness of time; need to have agreement on types, version is a property of these types
      ... better off to let folks define types and versioning for those type
      ... when things mature we can include it in v2 of the spec
      ... concerns about getting in wrong
      Gil: this is a chicken-egg problem
      ... by not specifying anything there is a higher chance of various types/versioning not interoperating. Think of this as seeding the direction
      Tom: Alex what did you mean by 'types'. Are they user's types or spec types?
      Alex: i mean artifact, service and requirement types
      ... all sorts of things will have versions (specs, platform, components etc)
      ... will take a while to figure out the best practices for versioning
      ... we are better off not doing this in the main spec, but in implementation, best practices, primer etc
      ... for now and then later uptake it in .next version of the spec
      Gil: to answer Tom's Q, the version we are talking about is specifying characteristics provided by the platform provider
      ... the customer has an app and wants specify exactly what it needs from the platform. For example MySql version
      ... if everyone has a different way of saying verison 5.1 or greater the we lose portability
      Tom Rutt (Fujitsu): maybe get back to two sequences of intervals for inclusion and exclusion
      ... we can take a small step to make things easier
      AlexH: what version is AWS on? how do I specify that
      Gil: in this case you would not specify a version
      ... this is where we have to chose the right level of conformance (SHALL/SHOULD/MAY)
      ... it would be helpful to have *a* way of doing things
      Alex: folks may specify different ways of specifying their notation
      Derek: the pt. that concerns me is -- specifying the version is quite important and without that it is difficult to work with
      ... not having it nailed down is tough. I may have to make different plans for different platform. From a portability point of view it is important
      ... Are we talking about different usecases
      Martin: I agree with Alex in that we may not necessarily know what we are doing here. But Derek is saying that we need to examine the usecase and figure out what kind of expression language we need. But I would rather point to an existing language. OR do a analysis of what's the minimum we can get away with
      Alex: version will be important for what we do. But I do think versioning and matching is upto the type-definer
      ... you have described Maven/OSGi vesioning. But if I'm dealing with Ubuntu, it is different. Or I might want a Linux kernel that is even or odd.
      ... we need to examine the various types that we will be dealing with and how they do versioning. But it is an important goal.
      Derek: the Q is do you want to have a canonicalized syntax or leave it to the types
      Alex: I think 90% can be canonicalized, but products that use "marketing" version (10%) may be difficult
      Derek: for me, if I can't specific version or range it is not useful
      Alex: this is something that type designers need to think about
      Martin: this is P2 issue, we need to get a direction. At least whether we are going to address it, postpone it etc
      no response
      Martin: we'll have to come back to it another time. More thinking needs to be done
      Gil: seems like a semi-consensus that we want to defer it
Topic: issue 169

      https://tools.oasis-open.org/issues/browse/CAMP-169  CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
      Gil: didn't get around to this
      ... next week

Topic: AOB
     Stragglers: Tom, Jacques, Derek.

Meeting adjouned

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]