There is an error in the list of issues to be closed with no action; issue 143 was transposed as issue 148.
We need to re-open issue 148 and close issue 143.
~ gp
On Nov 14, 2013, at 8:14 AM, Martin Chapman <> wrote:
> Minutes 13th November 2013
>
>
> Attendees:
>
> Software AG, Inc. Bhaskar Reddy Byreddy Voting Member
> Oracle Mark Carlson Voting Member
> 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 Secretary
> Oracle Gilbert Pilz Voting Member
> Fujitsu Limited Tom Rutt Voting Member
> Software AG, Inc. Prasad Yendluri Voting Member
>
> Intro:
>
> Roll Call: Voting Members: 11 of 12 (91%) meeting is quorate
> Topic: Agenda approval
>
> Redfining the order of the issues discussion
> Anish Karmarkar: discussing CNAs first would be good
> add new issue: https://tools.oasis-open.org/issues/browse/CAMP-150
> Approved as modified.
>
> Minutes:
>
> 6th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00041.html
> Correction needed the minutes approved were for the 30th october 2013.
> Motion Gil, s: Ashok approve minutes of the 6th fixing the reference to past minutes to 30th October 2013
> Passed w/o
>
> Topic: Scrum sessions notes availabale - informal so no need to approve:
>
> Session 1: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00051.html
> Session 2: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00078.html
> Session 3: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00094.html
>
> Anish: observes the meetings were very useful
>
> Topic: Action Items
>
> None
>
> Topic: Editing Team Update
>
> Gil: Pushed out WD 29: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=51313
> Jacques: New version of test assertions doc by next week
>
> New Issue:
>
> https://tools.oasis-open.org/issues/browse/CAMP-150 mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use
> Anish Karmarkar: note, we do have a high bar for new issues
> MartinC: 2/3 majority
> Gil: Need to fix this sooner than later
> .. proposing this to be a P1 issue
> Alex Heneveld: +1 we need to do this
> Use a multi-part data format
> Adrian Otto (Rackspace): +1 this is a good improvement and will aid adoption. I think forming and approving a proposal for this will not be difficult.
> Anish: Things will look complicated on the wire due to multi-part but
> ...you are not dealing with raw messages but APIs etc. May be ok
> Anish Karmarkar: agree with @adrian, proposal would be easy
> Motion: Gil moves to open 150 as P1 second Adrian
> No objections. 150 is open
>
> Issue Discussion:
>
> Martin: Summarized the issues into 3 groups (some errors)
> Anish Karmarkar: my suggestion: deal with P1 first then the CNA group
> We have two P1s with proposal 86 & 80
>
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-86
>
> modified proposal in JIRA: [YAML 1.1] Oren Ben-Kiki, Clark Evans, Brian Ingerson, "YAML Ain't
> Markup Language (YAML) Version 1.1, 2005-10-18" http://yaml.org/spec/1.1/ .
> Also archived at: http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html
> Motion to resolve 86 with the proposal in Jira: mov: Adrian: Sec: Tom
> Motion Approved w/o
>
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-80
>
> Gil: Presents the issue..
>
> Anish Karmarkar: this should be easy. We now have multiple URLs to post to. By ref is
> always json. By value is based on what you are posting: yaml has yaml media-type, zip has the appropriate zip media type and so on
> Anish Karmarkar: note that this may change based on resolution of 150
> Anish Karmarkar: with the introduction of multipart
> Anish Karmarkar: in which case would just talk about the root part in the multipart
> Anish Karmarkar: the nice thing about multipart is that by-ref and by-value are equivalent as both can now have parameters
> .. and proposed resolution
> Anish: likes the proposal but issue 150 might change it ..
> Alex: Likes the proposal
>
> MOTION: Gil: Moves to resolve issue 150 the proposal in Jira S: Tom
> Approved w/o
>
> Issues with proposals to close with no action:
>
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-147
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-143
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-114
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-88
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-84
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-79
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-42
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-11
> All above are P2s
> P3:
> https://tools.oasis-open.org/issues/browse/CAMP-69
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-59
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-27
> Ashok: Scaling Policy, Alex talked about sending us an example.
> Alex: I am happy to send the example, we can keep the issue open but I don't think it belongs in the spec
> Ashok: I am happy to close the issue but like see the example AI
> Motion: Ashok moves to close all the issues listed above with no action, second: Anish
> issus: 147, 148, 114, 88, 84, 79, 42, 11, 69, 59, 27
>
> Motion approved w/o objections
>
> Issue: https://tools.oasis-open.org/issues/browse/CAMP-62
>
> Gil: Explains the issue and proposal
> MartinC: note this was an action from the scrum so the proposal was not agreed in the scrum per see
> Anish: we are stuck with JSON types and
> ... The order is relevant
> ...if the client or provider does not maintain that order unexpected things can happen wrt issue resolution, should we just stay silent?
> Tom: Sympatise with Gil. But..
> What is the scope of this across multiple HTTP requests?
> Anish: You are asking reg. reboots and patch etc. We already say you should do conditional updates
> .... You do a get prior to update but, if things change (e.g. reboot after get) if not
> .... sure resources are in the same order, you should do a conditional update, i.e. update only if things are the same as befopre.
> Adrian: I am not clear on the problem..
> Anish Karmarkar: i'm more inclined to CNA this
> Anish Karmarkar: don't mess with the order
> Gil: the issue stems from my impl. experience
> Anish Karmarkar: if you mess with the order bad things will happen
> Adrain: Are you providing advise but not placing restrictions in the spec?
> GiL: I am asking for restrictions
> Adrin: why use soft lang. like advise..
> Anish: We have already said order is relevant (saying something restrictive already)
> .. we already have a strong language
> Alex: This has never been an issue before but it might become ..
> It is technically not necessary but, this should go in the primer not the spec
> we should state the problem more precisely..
> discussing tweaking proposal text
> Gil: contemplates aloud the wisdom of putting in the spec or in a primer
> Anish Karmarkar: if we wanted to say something stronger (as suggested by Adrian) we could
> ...say: "Providers SHALL preserve the order of the elements in JSON arrays across HTTP requests when there is no change to the array"
> Tom: the last sentence (the advise) should not be part of the spec, it is the confusing part
> Anish Karmarkar: or something like that
> Gil: suggests to close with no action and take it up in the primer
> MOTION: Gil: Moves to close issue 62 with no action. Second: Adrian
> Approved w/o objections. Isues 62 is close with no action
>
> Issue: CAMP 74 https://tools.oasis-open.org/issues/browse/CAMP-74
>
> Gil: Elaborates the issue
> Tom: section 2.3 needs to be updated
> Tom Rutt (Fujitsu): need to update 2.3
> Anish Karmarkar: i like this proposal
> Anish Karmarkar: this is a very clever way
> Anish Karmarkar: it reduces the number of ways to do the same thing
> Anish Karmarkar: to one
> Tom Rutt (Fujitsu): change sentence under fig 2-6 On platforms that choose to support Plans,
> ... a CAMP Consumer can create a Plan resource by uploading either a PDP or a Plan file to the
> .... Plans resource URI using an HTTP POST request.
> Tom Rutt (Fujitsu): to
> Tom Rutt (Fujitsu): On platforms that choose to support Plans, a CAMP Consumer can create
> .... a Plan resource by uploading either a PDP or a Plan file to the Assemblies resource URI using an HTTP POST request.
>
> Gil: Still need to update the proposal
>
> MOTION: Gil: motions to approve Jira proposal with Toms' suggested modification above, Second: Tom
> Approved w/o objections. Issue 74 is resolved.
>
> TOPIC: AOB
>
> Straggler: none
>
> Meeting Adjourned
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
