[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 30th October 2013
Minutes 30th October 2013
Attendees
US Department of Defense (DoD) Michael Behrens Member
Software AG, Inc. Bhaskar Reddy Byreddy 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
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Krishna assumes scribe duties
Roll: Attedndees listed above, Voting Members: 11 of 11 (100%), meeting is quorate.
We are quorate (90%)
Discussing agenda. No objections to agenda as posted. Agenda: no addition, adopted as posted.
Minutes:
23rd October 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00254.html
Discussing minutes. Adrian moves to approve the minutes of the 23rd. Jacques seconds.
No discussions. Motion passes.
Admin:
We have 3 P1 issues, 25 P2 issues, 8 P3 issues
Editors update:
Anish: Editors put out 2 WD:26, 27. All issues that were resolved at F2F except for 3 have been applied.
Anish Karmarkar: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00257.html
Issues 85, 87, 135 not applied.
Note: Issues are not yet in resolved state. Editing team only sets them to applied.
Gil Pilz (Oracle): I haven't been changing the state to "applied" - my bad
Gil Pilz (Oracle): will do so in the future
Anish: did not make updates to text. If there are changes in diagram that are being applied to text then that will need to be in WD 28. There is an open issue to update section 3.
Anish: have some issues with Appendix C which will be taken up offline.
Anish: we should be able to consider latest draft (WD 27)stable. Remaining 3 un-applies issues are relatively minor.
Jaques: My understanding is that WD is where every update is taking place. CD is just a label on the WD.
Gil: CD04 is a directory which contains all the WD that led from CD03 to CD04. CD04 is a symbolic link to last WD.
Issue discussion:
Discussing https://tools.oasis-open.org/issues/browse/CAMP-85
Gil Pilz (Oracle): http://www.rfc-editor.org/in-notes/rfc-ref.txt
Should not take hyperlink away and leave it added at the end.
Tom Rutt (Fujitsu): OASIS ok'd the bsrp references to rfcs as [RFC3987]M. Duerst et al., Internationalized Resource Identifiers (IRIs), IETF RFC 3987, January 2005,. http://www.ietf.org/rfc/rfc3987.txt
Agreed to use verbatim the rfc-ref.txt citation.
Discussing https://tools.oasis-open.org/issues/browse/CAMP-87
Issue does not specify what language to add
Gil: There are terms used that are not previously defined.
... Should look at this issue as narrowly as possible.
Adrian: Should create multiple issues out of this with narrow scope. Can we create the multiple issues as an administrative action?
Anish: During F2F, had decided to add language to say that Spec doesn't specify functional interfaces and that is what this issue is referring to
Anish suggests giving editors power to decide on language
Adrian Otto (Rackspace): +1
Adrian Otto (Rackspace): we can solicit comments on the issue
Adrian Otto (Rackspace): and drive a consensus on proposed text
Adrian Otto (Rackspace): and allow the editors to apply it in the absence of objections
Adrian Otto (Rackspace): (ODCA are not the first to be confused by the term "functional interfaces")
Mark: Possibly request commenters to add actionable material if spec change is required
Martin: perhaps create a new issue derived from 87 and make it a p3
M. Behrens: +1
Adrian Otto (Rackspace): yes, opening a separate issue for remark #2 in CAMP-87 makes sense
Anish Karmarkar: 1.4 Non-Goals
The specification of functional interfaces specific to services provided by individual components is out of scope for this document. This is because such interfaces may be
quite diverse and differ significantly from platform to platform.
M. Behrens: replace "such" with "functional"
Adrian motions to create a new issue and open it derived from CAMP-87 to work on point (2)
Gil seconds
Gil Pilz (Oracle): "Components and services are generally thought of as having two general classes of interfaces. The functional interface which ?."
Anish Karmarkar: @mike sure
No discussion, no objections.
Adrian Otto (Rackspace): thanks Martin for agreeing to open the issue pursuant to this motion (P3)
Motion was to make that a p3 issue
Gil Pilz (Oracle): we need to establish the notion that we are distinguishing management interfaces from functional interfaces
Motion passes
Discussing https://tools.oasis-open.org/issues/browse/CAMP-144
If we look at the way we have set up type definition resource. There is no way to co-relate a type with description
Gil: the type definition resource describes a type of resource. Add a further constraint on the type definition's name
... to make it match the type that it is describing.
Gil: it would go in the description of the type definition resource.
Gil will make another iteration on this.
Discussing https://tools.oasis-open.org/issues/browse/CAMP-135
Gil Pilz (Oracle): The value of the "name" attribute SHALL match the value of the "type" attribute of the resources described by this TypeDefinition.
Anish: What we agreed on was that other than URL be upper case, we would take Patricks suggestion. There are 2 problems with this. (1) If you
... look at original text. The statement is accurate but confusing. Patricks suggestions does not
... clarify the confusion. (2) If we applied consistently, we would need to change one like in description of every attribute.
Ashok: recommend typing the sentence as you think itshould read. Don't take Patricks recommendation literally.
Anish Karmarkar: This attribute contains URI of the Operations resource. The Operations ... resource lists the Operation resources links available for the Sensor resource.
Anish Karmarkar: This attribute contains the URI of the Operations resource. The Operations ... resource lists the Operation resources links available for the Sensor resource.
TC agreed with Anish's change as editor's discretion.
Discussing https://tools.oasis-open.org/issues/browse/CAMP-83
Jacques starting with https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51207/NormativeChallenges-4.docx
Jacques: recap of what should be done on core spec to some places where we are missing normative tags.
Jacques: Nothing much new, just made it more current based on WD 27
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51208/camp-spec-v1.1-wd27-normativeChallenges.doc
Jacques: Perhaps editors should make a pass over the doc and get back
Martin: Perhaps editors should make a pass and come back with an update.
Jacques (Fujitsu): " Consumers SHALL NOT assume that the order of the
ArtifactSpecifications within this array implies a particular processing order by the Provider".
And this is not really testable in a significant way (maybe only partially)."
Martin: consider CAMP-115. It will delete 3 of the issues raised in doc above.
Looking at https://tools.oasis-open.org/issues/browse/CAMP-115
Jacques: agrees with not rephrasing
MartinC: Proposal: delete the normative statements pdp-20, 21, 23, 24 and replace with this note:
Note: For portability reasons, Providers are cautioned not to regard the order of the element as this array as significant.
Jacques moves to resolve CAMP-115 with proposal in JIRA. Gil seconds
No discussion. No objections. JIRA-115 resolved
AOB:
Stragglers: Add Alex
Meeting Adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]