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 30th January 2013


Meeting Minutes Con Call 30 January 213.

Attendees:

Agrawal, Roshan              Rackspace Hosting, Inc.          Voting Member
Carlson, Mark                Oracle                           Voting Member
Chapman, Martin              Oracle                           Chair
Durand, Jacques              Fujitsu Limited                  Voting Member
Heneveld, Alex               Cloudsoft Corporation Limited    Voting Member
Johnston-Watt, Duncan        Cloudsoft Corporation Limited    Voting Member
Karmarkar, Anish             Oracle                           Voting Member
Malhotra, Ashok              Oracle                           Voting Member
Miller, Rich                 Cloudsoft Corporation Limited    Voting Member
Mischkinsky, Jeff            Oracle                           Voting Member
Otto, Adrian                 Rackspace Hosting, Inc.          Secretary
Pilz, Gilbert                Oracle                           Voting Member
Rutt, Tom                    Fujitsu Limited                  Voting Member
Tupitza, Charles             JumpSoft                         Voting Member

Roshan assumes scribe duties


Intro:
    Roll: attendees listed above: Attendance recorded 14 of 18 (77%) Meeting is quotrate
    Agenda:  Approved as posted

Minutes:

   Jan 2013 F2F Meeting: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00156.html 
   
   Motion:  m:Jeff, s:Tom: adopt the Jan 2013 F2F minutes, linked above.
   Passed w/o

   
Administrivia:


   
   Reminder that Tom will be pro tem chair next week,  with support from Adrian

Editing Team Update:
 
   CSD01 publication:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00151.html 
   Gil: is CSD01 public and we can hand out references?
   Martin: yes
   Mark Carlson (Oracle): When you get the Kavi notice of the document upload you will see a "public" link along with the "Download the latest version" link...
   Martin: recommend point people to docs directory
   All work in the TC is public though there are private and public urls for each TC artefact.


   Applied issues closed:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00152.html 
   Gil asks about when we review the applied edits to see if they are ok.
   When the motion to make a wd and CSD is made that is the time to check - approving such a motion implies the edits are ok.

   Anish: started working on next working draft, has a question on https://tools.oasis-open.org/issues/browse/CAMP-14 
   ... The minutes and JIRA seem out of sync with reference to an r3 and an 24 version.
   Adrian: do we need an amendment?
   Adrian: made revision to r4 in the current proposal
   Chair: the actual JIRA resolution and the minutes are in sync. No update needed.

New Issues:

   https://tools.oasis-open.org/issues/browse/CAMP-47 remove requirement that any additional format be supported uniformly for all resources
   Adrian: Issue 47 should be a non issue as covered by CAMP-14
   Motion: m:Adrian, s: Gil moves to close no action for Issue 47
   Passed w/o

   Issue 47 is now closed

Issues Discussion:

   https://tools.oasis-open.org/issues/browse/CAMP-10  Extension Scheme
   Adrian presenting CAMP-10 on WebEx
   Can someone use "_" instead ?
   Adrian: yes, as long as ensure this does not collide with someone else
   Adrian making editorial tweaks based on review
   Extensions Resource: Type: should it be an array of links, or map?
   Gil: you can say extensions["Name of Extension"].link
   Going for: an array of links.
   Jacques (Fujitsu): +1 to ExtensionsList
  
   Adrian Otto (Rackspace): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48060/camp-10-2013-01-30_r4.doc

   Motion: m:Adrian, s: Anish to resolve CAMP-10 with updated proposal  camp-10-2013-01-30_r4.doc
   Passed w/o

   jeffm: woohoo!
   Alex Heneveld (Cloudsoft): Hello All -- same excuse as Duncan but good to be here.  Excellent work Adrian and all on CAMP-10.

   https://tools.oasis-open.org/issues/browse/CAMP-39  Discovery Features
   related to CAMP-10
   anish: 39 is a container issue
   anish: we have now resolved 10 and 14. once we resolve 1, we would have automagically resolved 39
   Adrian: establish a uniform discovery pattern
   Adrian: Camp 10 and 14 already adhere to this discovery pattern. CAMP-1 still needs to be resolved.
   Jacques: could we end up with 2 references to the same resource?
   Adrian: that is beyond the scope of this discussion
   MartinC : resolving this issue would require any discovery mechanism to use this pattern and for open issues related to link to this issue
   Tom: is the discovery link a mandatory attribute
   Adrian: yes, it is required is CAMP-14 for discovery of formats
   Anish: this does not require any more spec updates, for CAMP-39. just use it as a pattern for future issues
   Motion: m:Adrian, s: Anish: moves to resolve CAMP-30 with the pattern document and agreed at the f2f (in jira)
   Passed w/o

   CAMP-39 marked resolved and closed
   No spec Editing actions required
   Martin: other than CAMP-1, is there anything else that needs to point to CAMP-39 as a pattern?
   Gil will identify and add the link


   http://tools.oasis-open.org/issues/browse/CAMP-38   resourceState attribute needs clarification
   Proposal revised after F2F
   Gil has updated proposal

Roshan Agrawal relayed scribe duty to Adrian Otto

   Gil explains the concept of ResourceSkew
   Jacques (Fujitsu): or "stateSkew"
   Tom Rutt suggests the name representationSkew (because resourceRepresentationSkew is too long)
   Jacques suggests the elimination of STEADY
   Anish asks if the values of the *skew attribute are the only ones allowed, or might an extension be allowed to show other values.
   Jacques (Fujitsu): Skew attribute: instead of STEADY, value could be NONE as "no skew for the resource state at this time"
   Tom Rutt (Fujitsu): Do we have a conformance requirement somewhere which constrains the implementation to respond to gets 
   ... after posts, etc, with consistent values  (even more if the underlying implementation has a state change, 
   ... is there a requirement on how long the implementation takes to make that new value available to a get?
   Jacques (Fujitsu): ... or "UNSKEWED" or "ALIGNED". Something that suggests no skew regardless of the state.
   MartinC : discussion on normativeness/explicit behaviour of table in 5.3.7
   Adrian: I prefer the name NONE rather than STEADY. I agree the UNKNOWN state needs further explanation.
   Tom Rutt (Fujitsu): how about "methods allowed" -> "methods available"
   Gil: "there is no skew in this resource and, of course, when I say 'no skew' I do mean that there is some"
   Jacques (Fujitsu): how about "Method Reliability"? with an additional mention of the risks in executing the listed method.
   Gil to redo propossl based on the discussion.

AOB:

   stragglers: none
   Martin will resume as chair in two weeks after one meeting Chaired by Tom Rutt.

Meeting adjourned


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