Temporary page for presenting points of view about the [[https://lists.cacert.org/wws/arc/cacert-board/2010-04/msg00083.html|proposed contract]] in a structured way.

Importance scale:

 * *** I won't approve this proposal unless this is changed
 * ** I don't like this - won't approve contract if too many issues of this importance scale occur
 * * I'd like this improved but isn't essential
 * - Not important

= Misc =
||Issue ||By ||importance ||Suggested Alternative ||Comment ||by ||importance to commenter ||
||All employees may not be assurers[[https://lists.cacert.org/wws/arc/cacert-board/2010-04/msg00085.html|(ref)]] ||Mario ||* ||"most employees are assurers" ||I don't see this worth clarifying ||Dan ||- ||
|| || || || || The point here being that if this were a Community Agreement, then '''we, CAcert, the Community would''' like the Member to be fairly well experienced with CAcert processes.  Things like Assurer status, CARS, CATS, DRP then become interlinked and build a good solid trust for all parties.  But it seems that the proposition to the board is that the other party is not entering into the spirit of a Community Agreement, and therefore the contract is entirely everything we have to go on.  In the contract, all our other community assumptions are swept away, and we have to look at reputation, swiss law & courts, etc.  So, if we do accept a Swiss contract, then the "assurer" relationship isn't so important (and arguably could cause damage to the jurisdictional questions).  So depending on how this pans out, we may have to drop all reference to community nature of other party, for their own protection. ||  [[Iang]] || ** ||
|| The first section speaks to a mission that is not really agreed or current within CAcert. || [[Iang]] || * || || its not totally off track so I don't see it worth clarifying or coming to an agreement of what is our defined mission for the purposes of this contract. || Dan || - ||
|| Document says "''May not be amended in writing...''" || [[Iang]] || *** || || This was an acknowledged error || Dan || ** ||
|| || Dan || ** || "''May be amended in writing...''" || || || ||
|| I would like to see the words "''this Agreement is in English.''" || [[Iang]] || * || || Petty and I still don't see its value || Dan || - ||
|| Agreement is with the board, and the Board will agree by means of committee motion.  Two signatures are not necessary, and will just generate additional work. || [[Iang]] || * || || Two digital signatures are reasonably easy however a single president signature will for for me || Dan || - ||


= Offering =
||Issue ||By ||importance ||Suggested Alternative ||Comment ||by ||importance to commenter ||
|| I've read the contract, I like what we get (nice server, with connectivity and power) but it's still not clear to me what exactly is requested in return. I'm fine with logos and all on our web site, as long as they're comparable with what we offer to other sponsors, for instance BIT. These banners/logo's only appear on the main web site (www.cacert.org), not on the blog or wiki! || LambertHofstra|| **|| || For this reason, the provision of sponsor benefits should be a "package" that is offered on common basis. || [[Iang]] || * || ||
|||||||| || something small on wiki/blog is probably ok as they are providing that service || dan || * ||
|| Can someone please explain what we as CAcert need to provide? I've read par 3.1 and 3.2, but still don't understand what "the 65% of the bullets in 3.1" actually means|| LambertHofstra|| **|| || We have to provide 65% of the things listed, by bullet point, where each bullet point is equal.  Unfortunately we don't have some of those things, and we don't have a plan to provide those things.  So it is hard to promise.  || [[Iang]] || *** ||
|| 2.1 "Sponsor's employees only have access to ColoBern." Does this mean we cannot do a physical inspection of the server? That would exclude using this site for critical systems, even as a shadow site: we for instance have no visibility of how the infrastructure is set up (they might have logging on all console ports?. We'd need an auditor to verify setup, or for instance a sas-70 statement from an independant auditor, before moving critical systems there)|| LambertHofstra|| *|| || The statement should be "Only Sponsor's employees have access to ColoBern."  Grammatical thing, the location of the word 'only' changes the meaning. || [[Iang]] || * ||
|||||||| || Given the difficulties discussed here and the distance from Security Policy, there is no way that any critical assets could be moved into this regime.  An audit won't help, it has to start with us complying with our own policies first.  This is a disadvantage, because it reduces our flexibility.  But it wasn't the objective to move critical assets anyway, so it is probably unreasonable to measure the agreement on that basis. || [[Iang]] || * ||
|||||||| || Concur - this isn't for critical infrastructure || dan || - ||
|| The contract should not list the precise hardware configuration.  To so is to limit operational flexibility.  As supplier is responsible for hardware, they are also responsible for substitution without having a contract as a millstone around their neck.  If we can assume that this is a community agreement, we can also assume they will do the right thing. || [[Iang]] || ** || Agreement refers to an appendix that is changed from time to time on mutual agreement of the parties. || Good idea - fine by me || Dan || * ||
|| It would be good to get a dollar estimate of the value.  This would enable us to work out whether the risks of taking on the contract were worth it, or we are better off just paying the money elsewhere.  Standard due diligence. || [[Iang]] || * || || I think a simple good points/bad points table could summarise this without getting into dollar values. Feel free to add that. || Dan || * ||
|| The provision of services (65% of the list) appears to be high.  In particular it appears to be higher than other sponsors have gained. || [[Iang]] || ** || || Without putting them side by side its hard to measure. Whether its higher or not it is immaterial as we don't have another comparable offer nor does there seem to be a willingness to find one. The decision is if the cost is of sufficient benefit to CAcert and can we manage to provide on it. || Dan || - ||
|| We do not have the capability in technical, planning and contractual terms to guarantee the offering.  Most of the elements lack a clear leader, and we have no coordinated marketing posture, no person, no team.  Some of the elements don't exist.  || [[Iang]] || *** || || The sysadmins do have the capacity to change web pages. Andreas did volunteer to fix leaflets.  Our events officer was ok with what was presented.  Marketing position isn't needed - only someone to write up a press release in conjunction with adfinis and decimate this is needed. Not a big job - no team needed. || Dan || - ||
|| The contract gives the right for the other party to choose. || [[Iang]] || ** || || Correct. If there's something you don't want chooses object now and remove it from the contract. || Dan || - ||
|| The contract includes a blanket NDA.  This is not how we work. || [[Iang]] || *** || ''"Both parties understand that in preparing joint marketing materials (section 3.1) there may be a need to share confidential details about marketing and strategies.  To the extent reasonable and efficient, both parties agree to respect such confidentiality over marketing details."'' || To me this alternative saying the same as the current agreement. I don't see it as worth rewording || Dan || - ||
|| Point 4 requires that every marketing effort be approved in writing?  This sounds terribly inefficient.  || [[Iang]] || ** || || It ties into section 4 quite well. I don't support a change here || Dan || - ||


= Jurisdiction =
||Issue ||By ||importance ||Suggested Alternative ||Comment ||by ||importance to commenter ||
||Swiss Jurisdiction is unacceptable. I would consider signing this a breach of trust of CAcert Inc.||PhilippDunkel||***||DRP (and NSW.au law)|| Please explain "breach of trust" - I don't remember any promise to a jurisdiction. Nor can any other work be done without another unjustified "you've breached our trust again" without references. || Dan || - ||
|||||||| || I might have used another word than "breach of trust". The thing is that the CCS and DRP are here to protect CAcert, CAcert Inc. and the members. Adding another jurisdiction could have an impact on CAcert, and its members. We cannot be sure what the impact is until this has been revewed, and CAcert does not have funding to investigate  || Lambert || ** ||
|||||||| || Breach of Trust:  this is possibly a statement that a Member of the Community places itself outside of the Community for its convenience, while benefiting from being within the Community at other times.  It raises difficult questions about how we can rely and deal.  I'm not sure I would use the term "breach of trust" either, but the term certainly focuses the question well. || [[Iang]] || * ||
||DRP should be used for disputes || PhilippDunkel|| *** || ||  [[https://lists.cacert.org/wws/arc/cacert-board/2010-04/msg00102.html|DRP isn't acceptable]]. || Adfinis stance conveyed by Andreas || *** ||
|||||||| ||  Consider DRP from Adfinis' point of view - can DRP that CAcert made be --(considered)-- perceived as independent? If Adfinis had a dispute resolution service would we consider it independent? || Dan || - ||
|||||| || [[http://www.cacert.org/policy/DisputeResolutionPolicy.php|DRP 1.5]] says ''"Arbitrators are experienced Assurers of CAcert. They should be independent and impartial, including of CAcert itself where it becomes a party. "'' ||  The point about Independence of Arbitrators is null;  if they are not fair and independent in any and every dispute, then they aren't useful to the community in any respect.  A supplier of VMs is no different to a user of certificates when it comes to a dispute.  || [[Iang]] || * ||
|| || [[Iang]] || ** || DR1:  Set disputes in the first instance to CAcert's dispute resolution.  In the second instance, given adfinis's place within its local jurisdiction, adfinis has leave to appeal any adverse ruling from the first instance to its local court, and with reference to the Swiss Law. || || ||
|||||||| || The DRP has been introduced to protect both CAcert and its members: it for instance limits liability of members AND CAcert, and saves a lot of legal costs and for instance travel cost. If Adfinis agrees to arbitration, it also agrees to limited liability. Since CAcert has limited funds, we for instance need a maximum on liability. If Adfinis does not agree to the CAcert DRP, we at least need to make sure the maximum liability of CAcert, including legal costs, is limited, for instance by adding a clause to this extend to the contract.  || Lambert || --( *** )-- * ||

|| --(Objections to jurisdiction should of been raised by last board about the time Andreas initially proposed it)-- I concede the irrelevance of this point based on Lambert's assessment || Dan || - ||  || This is irrelevant: the current board is responsible for this contract, if it is to be signed while this board is in function.  || Lambert || - ||
|||||||| || To my recollection, the board was never notified of an intention to enter into a contract with Swiss Jurisdiction.  Dan, if you can correct that, please do.  || [[Iang]] || ** ||
|||||||||| It is probably reasonably that supplier seeks a local agreement for own efficiency.  For this reason, we used Foundations (and the like) to intermediate. || [[Iang]] || * ||
|| Zurich Chamber of Commerce Arbitration for arbitration. We need alternatives if courts and DRP aren't acceptable to parties || dan/andreas || * || CAcert and Adfinis will use (fore-mentioned) for arbitration || [[https://lists.cacert.org/wws/arc/cacert-board/2010-04/msg00102.html|Zurich isn't much better]] in terms of acceptability || andreas/michael || - ||
|||||||| || Choosing another Arbitration forum isn't going to help, because of the structure of the Arbitration industry.  If anything, it might make matters worse for adfinis, without improving matters for CAcert. || [[Iang]] || ** ||
|||||||| || The package of our dispute resolution is what makes it attractive to all members:  Our set of rules, short, clearly documented and aligned to our business;  Volunteer Arbitrators who do not as yet charge;  A clear focus on the Community as well as the written rules;  an ability to keep this economic equation no matter who or where in the world the parties are located.  Changing these elements needs to be done with care. || [[Iang]] || ** ||
|| I can't see identifying a jurisdiction/mechanism of dispute resolution that will be agreeable to both parties. Can we leave this out such that the mutual 2 party resolution can take place and failing that termination clauses of the contract will be far more favourable that any legal resolution process that will cost too much. || dan || ** || CAcert and Adfinis will always attempt to mutually resolve differences. If this fails then the termination clauses of the contract will be the sole remaining option to resolve the issue(s).|| One reason why it is hard to see how to deal with this is that we have little information about adfinis's views.  They choose the default, we choose the default, then no more discussion.  Under these conditions, without the two parties talking there is no easy path to resolving the situation. || [[ Iang]] || * ||
||  || [[Iang]] || ** || DR2:  Set the termination notice to immediate.  In the event of any dispute, either party has the right to terminate immediately, and a limit of liability of $0.  Fair, symmetric, and if you think it through, it has very good ramifications for our own resiliance. || Immediate is a bit too soon. We'll at least have to move or archive services. Suggest minimum of 1 month though current contract specifies this as 6 months so really no need to limit it further. || dan || ** ||
|||||||| || ''"We'll at least have to move or archive services."''  That's why I said it has very good ramifications for our own resiliance.  We can lose a service in an instant, and we can lose it because of this deal, or we can lose it for completely separate reasons.  So, we'd like to be able to cope with the result, not get hung up on SLA thinking.  However, this is just an observation, it isn't the responsibility being examined today. || [[Iang]] || * ||
|||||||| || Said before: ''Termination:  we need to look at the reality of the deal.  adfinis control the hardware, so they can turn off in an instant.  CAcert controls the software on the hardware so they can withdraw in an instant.  So the harsh reality is "stop in an instant" and the contract won't really stop that.  And the polite way is to talk.''  || [[Iang]] || * ||
|| The writing of the contract incorporates all CAcert Members into the jurisdiction.  "''Officers, key persons, coworkers and voluntary contributers of the Parties are referred expressly to this regulation.''" || [[Iang]] || *** || ''"Each party is responsible for informing its own officers, key persons, coworkers and voluntary contributors to the extent necessary for the parties to meet their responsibilities under this agreement." '' || || || ||
|||||||| ||  '''18-6:''' if the contract is between CAcert Inc. and Adfinis, then members are still protected: CAcert Inc. and not a member would be the party in a legal dispute, later on CAcert Inc. can raise a dispute with a member if a member was involved || Lambert || * ||

= Data Security =
||Issue ||By ||importance ||Suggested Alternative ||Comment ||by ||importance to commenter ||
||Access to the servers needs to be considered.  Although this is not Security Policy work, the data will be sensitive, if only least from a PR point of view.  Who has access, and what is the basis for the control?  The separate contract takes us into new territory, in contrast to Oophaga's SP regime and Sonance's CCA regime. ||[[Iang]]||**|| CCA/DRP || agree that access control is important. "CCA/DRP" isn't a alternative/addition to satisfactory deal with this issue however. Some more comprehensive text is needed || dan || * ||
|| || Dan || *  || adfinis employees are permitted to access for the sole purposes of diagnosing hardware fault and maintaining the backup agent installed. || || ||  ||
|| Backups run by an outside organisation places our data outside.  The requirement for such will require a much beefier regime.  A simple line item in another contract won't do, it won't pass muster before data protection regulators. ||[[Iang]]||**|| CCA/DRP || Point of clarity - it only says "external storage". I agree - a more concise view of how our data is managed in terms of accessibility (especially beyond the end of the contract). So for clarity we need to address Australian Privacy Act 1988 (our [[http://www.cacert.org/index.php?id=10|privacy policy]]) - which talks in principles about secure maintenance and destruction [[http://www.privacy.gov.au/materials/types/guidelines/view/6582#npp3|NPP]]4 and information transfer overseas NPP9 || dan || ** ||
|||||||| || My impression on reading the contract was that supplier provides a backup agent which is installed on the server, and manages the data in a server elsewhere.  But, yes, this was an assumption that could be cleared up. || [[Iang]] || ** ||
|| || Dan || ** || The contents of the backup data will remain exclusively accessible to adfinis employees. On termination of this agreement backups of CAcert data will be erased such that they are not recoverable using known techniques. || || || ||