[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 4th December 2013
Minutes 4th December 2013
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
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:
Adrian assumes scribe duties.
Roll call: 11/11 voting members present 100% in attendance, quorate
Agenda: link needed for editor's draft work product for CAMP-151 resolution work, approved as posted
Minutes:
27th November 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201311/msg00159.html
Motion: Adrian Otto moves to Approve minutes, second by Anish Karmarkar
Minutes approved, no objections.
Administrivia:
Chair wants a default motion on 18th December to close no action any open issues without a proposal (directional or concrete) so get writing!
Editing Team Update:
work in progress: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51594/camp-spec-v1.1-wd32-ed2.doc
updated figures from Tom https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51593/CampResourceModelFiles-WD32-NoCamel.zip
editing team has struggled with MSWord formatting bugs
links above are editor's drafts
thank you for your help with the figures, Tom
Tom indicated that all figures in the spec needed to be updated
no change to TA document
Jacques expects TA document completion prior to winter break in 2 weeks
New Issues:
none
Issue discussion:
CAMP-87: https://tools.oasis-open.org/issues/browse/CAMP-87
discussion by Martin suggesting a CNA
decided not to have a security section
Gil Pilz (Oracle): YEAH! No meaningless "security considerations" section!
CAMP-149 obviates the functional interface concern
Motion: Tom to close CAMP-87 CNA, s: Gil
No objections, motion passed UNAN
We plan to apply resolution, reject, then CNA. Martin will process it accordingly.
P1:
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
Gil presents this issue
Current upload mechanism is problematic because it is not easy to use by today's web browsers.
open question remains about whether each part in the multi-part upload should be named in a specific way.
should PDP's and Plan's have the same name, or a different name?
Adrian: suggests we use two names: "pdp" and "plan"
Gil now has enough direction to form a concrete proposal.
P2:
https://tools.oasis-open.org/issues/browse/CAMP-152 Normative Tags Challenges, and other issues arising from aligning TAs to WD30+
Proposal in JIRA
Jacques presents this issue.
most of the changes are editorial in nature
more of these will be raised because of alignment of normative statements and test assertions.
section 3.3 "Plan Schema" issue: "no such section"
Plan Schema is actually section 4.3 now
RMR-07 tag identifies this
remove RMR-07 is redundant with section 4.3, and should be dropped.
reference section needs to be adjusted for this
RMR-07 are actually covered by RMR-08, RMR-09, and RMR-10
General wording agreement to fix #1:
"Given that the schema of the Plan resource returned from a CAMP Provider conform to the schema for Plans described in Section 4.3, Plan Schema, the following are additional requirements:"
#2 Bad reference, editorial fix
#3 regarding section 4.3.5 wrt normative tagging
4.3.5 ContentSpecification pseudo-schema indicates "href: URI OR data: string"
the choices in the pseudo-schema today pertain only to the value space
Jacques suggests adding a new normative statement to clarify this. Gil opposed the proposal.
(by a comment in CAMP-152)
Martin speaks in support of adding a normative statement to clarify the mutual exclusion
Gil speaks in opposition because it would be an inconsistent level of detail compared to the rest of the spec
Tom speaks in support of the proposal.
general agreement to the following for #3: "A ContentSpecification type SHALL have one of two, mutually exclusive, values : href or data [PDP-25]. It has the following, general representation: ..."
Adrian: suggests we accept the new normative statement
Gil indicates he will no longer oppose
#4 "A PDP MAY contain a certificate, named camp.cert, at the root of the archive. [PDP-08] This file contains a signed SHA256 digest for the manifest file and the corresponding X509 certificate
Missing norm tag?"
Martin, why should this be a SHALL and not a MAY?
Jacques: If you have a CERT, then it must be SHA256
Gil: would this change our intended conformance with OVF?
this may be redundant with PDP-10
Gil Pilz (Oracle): we say "do this the way OVF does this"
Gil Pilz (Oracle): if OVF already has normative statements about the manifest and cert files - do we need to restate them
Gil Pilz (Oracle): ?
PDP-10: The format of the manifest file and the certificate file...
Martin suggests we tweak the scope of PDP-10 and drop "This file contains a signed SHA256 digest for the manifest file and the corresponding X.509 certificate"
Jacques says that should be two TA's
Jacques will update to the proposal.
https://tools.oasis-open.org/issues/browse/CAMP-102 4.1.2 Validating Integrity
Discussing Gil's comment
using different hash algorithms for transports and file signing is a normal practice.
Gil: SHA256 for manifest files and SHA for transport is acceptable
Gil: Using SHA-3 is not yet recommended
Anish speaks in support of Gil's position on the issue
Anish: these are two separate concerns completely
Martin asks about the "to be that a manifest file contains only SHA256..."
Adrian: is our intent to narrow the scope of what OVF allows?
Gil Pilz (Oracle): An OVF package may have a manifest file containing the SHA digests of individual files in the package.
OVF packages authored according to this version of the specification shall use SHA256 digests; older
OVF packages are allowed to use SHA1.
anish: https://www.schneier.com/blog/archives/2005/02/sha1_broken.html
Motion: Gil moves to close 102, s: Adrian
No Objection. Motion passed UNAN, CAMP-102 is closed with no action.
P3:
https://tools.oasis-open.org/issues/browse/CAMP-44 Clarify resource type issues and API
Directional Proposal
Anish indicates he can proceed with drafting a concrete proposal
Adrian discusses of the use of Link types in collections of resources
Anish: use of ATOM for pagination may be appropriate
Gil: Likes the current approach.
Krishna: one level of depth is standard, a parameter can specify additional depth levels
MartinC: this is camp-42 which we closed: close CAMP-42 with no action. there are many attempts at different levels (e.g. http) and to do correctly is too big a job for 1.1. Note that we have re-factored to minimize where the large arrays are are.
Adrian to thin about a new issue of re-opening camp-42
AOB:
Stragglers: None
Meeting Adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]