[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER
Sure John I understand that, I'm simply saying to me the charter is ready to go under these terms too cheers Neil. > Neil > > Just a point of procedure. Any TC has to operate within the confines of > its > Charter. It cannot move the goalposts mid-term. If it wants to change > course or expand it has to re-Charter and that's a bit of a procedural > headache. So getting agreement at the outset on a clear but flexible > Charter is essential. > > So what I am looking for now is that clear, but flexible, list of > deliverables. I'm hoping that we can get to that on the Discussion List > over > the next couple of weeks max. > > John > > > -----Original Message----- > From: public-sector-cloud-discuss@lists.oasis-open.org > [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf Of > Neil > McEvoy > Sent: 28 June 2012 12:20 > To: neil.mcevoy@l5consulting.net > Cc: Doug Newdick; 'Peter F Brown'; Colin Wallis; > public-sector-cloud-discuss@lists.oasis-open.org > Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER > > > Sorry I meant to add that with this in mind I would vote against ongoing > discussion and instead propose we offer up a last round of edit/inclusions > and then move to launch the tc. > > Given the breadth and depth of what is already in the charter I think > we're > at risk of moving into a cycle of diminishing returns of what can be > achieved in this phase that will slow progress, when instead we have the > opportunity to step up the project and pick up the pace through what we > can > move on to post launch. > > Kind regards, Neil. > > > >> Hi Doug >> >> I would disagree with the points below, ie. Do you really think >> governments are more concerned with privacy and security than say, a >> bank? >> I'd say not, and neither do they have technical requirements that are >> unique either, indeed there is increasingly commonality, like using >> shared identity log-in systems et al. >> >> I would say that they are unique in that while a bank will charge >> ahead autonomously, governments instead need a higher 'official >> approval' before they are prepared to act, and at the moment there is >> a blanket rejection of Cloud principally because current legislation >> does not adequately provide this. Indeed most resort to the catch all >> 'keep it hosted in country else the Patriot Act boogey man gets ya'. >> >> Due to this factor there is near zero adoption of public Cloud in >> Government and this is where this tc could be concentrated. ie. it >> could also inform legislative bodies and provide an agreed set of >> standards that could be reflected in local legislations towards this >> end. >> >> This simple act alone would unblock the tidal wave of Cloud adoption >> not just in Govt but in all other industries who would take it as a >> statement of confidence. >> >> Cheers Neil. >> >> >> >> >> >>> Hi, >>> >>> Apologies for coming in to this discussion a bit late, and perhaps >>> uninformed. My colleague Colin Wallis suggested that I might find the >>> work being done here of value. >>> >>> From my point of view the single most important question is: Are the >>> requirements of public sector agencies different enough from those of >>> the private sector to warrant a separate TC, and producing the >>> deliverables suggested? >>> >>> I think that the answer is "yes", but I don't believe that it is >>> obvious. >>> When I look at the issues that concern me about cloud adoption versus >>> those that worry my private sector counterparts I see the following >>> differences: >>> >>> 1. Public sector agencies are more concerned about security. >>> >>> 2. Public sector agencies are more concerned about privacy. >>> >>> 3. Public sector agencies (at least in NZ) are concerned about >>> maintaining the "public record" - something that is of little concern >>> to the private sector. This includes making these records available >>> when requested by Official Information Act requests. >>> >>> 4. Public sector agencies are concerned about "sovereignty" - this >>> is >>> a term that wraps up worries about national and commercial >>> jurisdictions. >>> >>> Many of the differences are quantitative differences, not qualitative >>> - we are more concerned about certain matters than the private >>> sector. You could argue that items 3 and 4 are more specifically >>> public sector only. >>> >>> I believe that public sector agencies will get value from this >>> exercise to the extent that the list of features and requirements (as >>> described in the >>> charter) can be used to inform RFPs, vendor and service evaluations >>> or drive the creation of cloud services. >>> >>> My concern is that we will not be able to get that value without >>> including some level of technical requirements. To that extent I >>> favour carrying on this discussion further. >>> >>> Cheers, >>> >>> Doug >>> >>> Doug Newdick >>> Enterprise Architect >>> Government Technology Services >>> The Department of Internal Affairs Te Tari Taiwhenua Direct Dial: +64 >>> 4 474 8110 Extn: 8110 www.dia.govt.nz >>> >>> From: public-sector-cloud-discuss@lists.oasis-open.org >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Peter F Brown >>> Sent: Thursday, 28 June 2012 3:19 p.m. >>> To: Colin Wallis; public-sector-cloud-discuss@lists.oasis-open.org >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> +1 >>> >>> From: public-sector-cloud-discuss@lists.oasis-open.org >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Colin Wallis >>> Sent: Wednesday, 27 June, 2012 19:40 >>> To: public-sector-cloud-discuss@lists.oasis-open.org >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> Personally I favour a bit more discussion first. Maybe look at a few >>> other examples.... >>> >>> IMHO if we go the generic summary too early, we may risk the >>> perception that there is not enough 'meat' in the resulting >>> requirements to deliver something of value. >>> >>> Cheers >>> Colin >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org]<mailto:[mai >>> lto:public-sector-cloud-discuss@lists.oasis-open.org]> >>> On Behalf Of John Borras >>> Sent: Wednesday, 27 June 2012 7:50 p.m. >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> OK let's step back a bit. If, and I stress if, the main objective of >>> the TC is to "develop and deliver a non-technical >>> implementation/conformance profile for government, which provides >>> common, readily-understood rules that inform assurance and >>> conformance testing and acquisition criteria" >>> as >>> I suggested the other day, then we have to ask ourselves what >>> elements can be included in such a profile. They need to be ones that >>> are measurable and can be tested and that therefore would exclude the >>> needs and goals aspects that Peter highlights below. >>> >>> So the main question at this stage is do we agree on the prime >>> deliverable from the TC as stated above? If so then we would do well >>> to recruit into the TC some procurement and accreditation experts to >>> help define what >>> elements could and should be included in such a profile. We can also >>> discuss at that stage what constitutes a functional and a >>> non-functional requirement and also what constitutes a technical and > non-technical one. >>> >>> Do I therefore re-draft the Charter with a much more generic summary >>> of the TC deliverables to get us going, or do we continue this >>> discussion to agree a final detailed list of requirements before >>> starting the TC? >>> >>> John >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org]<mailto:[mai >>> lto:public-sector-cloud-discuss@lists.oasis-open.org]> >>> On Behalf Of Peter F Brown >>> Sent: 27 June 2012 06:56 >>> To: Colin Wallis; >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> Colin, >>> The OGF paper certainly helps by laying out a clean set of functional >>> and non-functional requirements (FRs and NFRs) - although I don't >>> understand why some FRs appear as NFRs, such as "security"; or some >>> are stated as FRs whereas, I would argue, they are not requirements >>> at all, but "needs" or "goals" (such as "[API] calls must return >>> quickly") - important considerations but not requirements. >>> >>> I guess my feeling is not whether we are going for "shallower" or >>> "deeper" >>> in terms of requirements but rather whether we want to express >>> "requirements" in the broader sense: more "API calls must return >>> quickly" >>> than "a JSON-scripted call should respond within 500ms". In the SOA >>> Reference Architecture Framework we make a distinction between these, >>> in terms of "needs" (broadly stated, "know it when I see it") and >>> "requirements" (formally and tractably stated, specific, measurable, >>> etc.) >>> but I don't want to confuse the terminology of this discussion >>> further (at least not now!) >>> >>> Also, you call out the three classic layers of IaaS, PaaS and SaaS >>> and flag the need for requirements for each - but what about >>> requirements for interoperability between different offerings at the >>> same layer, IaaS to IaaS, for example. >>> >>> Peter >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Colin Wallis >>> Sent: Tuesday, 26 June, 2012 21:43 >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> Hmm.. >>> >>> Well we need to take a deeper look at these items from the >>> charter...and decide what we would expect to see in the deliverable. >>> >>> >>> 1 A base set of required attributes, expressed as >>> architecture-neutral functional features, that generally should be >>> sought in any cloud or remote computing infrastructure employed by or >>> on behalf of governments (including computer networking, network >>> management, data storage and shared repository, service or device >>> management and virtualization management). >>> >>> 2 A base set of required attributes, expressed as >>> architecture-neutral functional features, that generally should be >>> sought in any cloud or remote computing platform services employed by >>> or on behalf of governments (including common transactional, >>> eventing, notification and messaging operations such as middleware >>> and enterprise service buses, and interaction patterns and protocols >>> among autonomous physical or virtual machines). >>> >>> 3 A base set of required attributes, expressed as >>> architecture-neutral functional features, that generally should be >>> sought in any cloud or remote computing data application services >>> employed by or on behalf of governments (including application >>> program interfaces >>> (APIs) >>> and end-user software applications). >>> >>> >>> >>> Some folks might expect to see something like this....as I highlight >>> attribution to OGF and the author... :) >>> >>> >>> >>> http://ogf.org/documents/GFD.162.pdf >>> >>> >>> >>> To take this as a benchmark, would folks consider this technical, or >>> non technical? >>> >>> >>> >>> Is this the flavor of the deliverable we expect to get? Something >>> even deeper? Something shallower? >>> >>> Cheers >>> Colin >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org]<mailto:[mai >>> lto:public-sector-cloud-discuss@lists.oasis-open.org]> >>> On Behalf Of John Borras >>> Sent: Tuesday, 26 June 2012 8:08 p.m. >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> Colin >>> >>> A fundamental point here, what should be regarded as technical and >>> what non-technical? The list and Charter was drafted by Jamie not >>> Belgian SPFF colleagues and my interpretation is that his list is >>> non-technical things but I can appreciate that may be open to debate. >>> So we need to clarify and agree this. Without question this TC is >>> focusing on non-technical requirements as there is already a plethora >>> of other groups working on technical aspects, so the list has to be >>> unambiguous about that. >>> >>> Just a reminder of the process, the purpose of the Discussion List is >>> to agree whether we should proceed with the TC or not, and not to >>> necessarily to agree a final Charter, although a near final version >>> would be good. >>> So >>> for now let's not get too hung up on word-smithing the list other >>> than to >>> be very clear about what the list should or should not contain. I >>> know >>> it's perhaps a bit of chicken and egg in that people want to see the >>> proposed outputs before agreeing to get involved or not, but I think >>> perhaps we should at this stage just put in some overview of the >>> outputs rather than a definitive list. >>> >>> Does that make sense, if so any suggestions for some overview wording >>> of the outputs from all on the List would be appreciated. >>> >>> John >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org]<mailto:[mai >>> lto:public-sector-cloud-discuss@lists.oasis-open.org]> >>> On Behalf Of Colin Wallis >>> Sent: 26 June 2012 01:02 >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> +1 to Peter's view on the title. >>> >>> <<The TC will develop and deliver a non-technical >>> implementation/conformance profile for government i.e. the features >>> that governments want to see in cloud offerings to government. The >>> profile will include as a minimum the following:>> >>> >>> Hmm..I see what you are trying to get to here, but for me it's not >>> quite there yet. >>> The thing is that much of that list *is* technical and I suspect >>> Belgium wanted that. >>> What it didn't have is the (non technical) process (and to a lesser >>> extent but my implication workflow) piece to balance it such that you >>> can achieve and measure both technical interop and non technical >>> process standardization. This latter piece is what in Kantara >>> parlance is called the Service Assessment Criteria (SACs) >>> >>> So I think the better way to tackle it is to remove the 'non technical' >>> reference to the sentence above, but add an additional bullet to the >>> list that addresses the non technical process requirements for >>> standardization >>> >>> Cheers >>> Colin >>> >>> >>> >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Peter F Brown >>> Sent: Tuesday, 26 June 2012 2:09 a.m. >>> To: John Borras; >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> John, >>> I would keep the current title. >>> "Requirements" shouldn't automatically invoke the idea that they must >>> be technical (even if, sadly, they all too often do). >>> >>> Peter F Brown >>> Independent Consultant >>> www.peterfbrown.com<http://www.peterfbrown.com> >>> +1 310 694 2278 (USA) >>> Twitter @PensivePeter >>> >>> Sent from my phone - Apologies for brevity and typos: it's hard >>> writing on a moving planet ________________________________ >>> From: John Borras >>> Sent: 25-Jun-12 2:01 >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER Colin >>> >>> I really like your "tag-line" of producing an >>> implementation/assurance profile. This really nails it for me and >>> provides total clarity of what it is this TC is about. I've amended >>> the draft Charter to reflect this. >>> >>> Only question in my mind is do we need to change the title of the TC >>> to include the words "non-technical requirements" as we're not going >>> to produce the technical spec bits of an assurance profile. It would >>> make the TC title rather a mouthful - OASIS Public Administration >>> Cloud Non-Technical Requirements Technical Committee (abbreviated as >>> OASIS Public Cloud TC or PACNTR TC). >>> >>> John >>> >>> -----Original Message----- >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Colin Wallis >>> Sent: 22 June 2012 01:59 >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> @Tony: Noting and agree with Tony's point about the additional >>> (seemingly >>> limitless) works in play right now .. >>> >>> @John: While I don't disagree with the fundamental thrust of the >>> draft, I think it could do a slightly better job of contextualising >>> what it is trying to achieve. >>> >>> My thought was that if 'cloud' was a spec of IT bits 'n pieces >>> collected together to offer something (like SAML in spec of XML to >>> offer authentication), then what we are proposing here is an >>> implementation/conformance profile for government i.e. what features >>> do governments want to see in cloud offerings to government. Once >>> you have these, you can set up conformance programs to check to see >>> if the features in cloud vendor x or y are indeed present. >>> >>> Taking the SAML analogy one step further, armed with the conformance >>> profile, governments then might agree on how those features (or a sub >>> set that can be commonly agreed upon) are configured, in what is >>> usually understood as a deployment profile. This is where the >>> 'levels' come in - the configuration of the features will vary >>> depending on the level. >>> >>> If the SAML conformance and deployment profile notions were well >>> enough understood, then applying that approach here might help >>> further decompose what seems to be an amorphous list of stuff.. >>> >>> Linking back to Neil's reference to goings-on in Kantara, it's worth >>> noting that Kantara does conformance testing and certification for >>> SAML and will do for OpenID Connect when the spec is stable. And in >>> the non technical spec area, it does assurance approval of identity >>> IdPs and CSPs. So in essence, Kantara's work groups outputs are >>> inputs to the assurance and certification programs. So to Neil's >>> point, the outputs from the proposed Kantara CloudIDsec wg would >>> inform the work in this group, and visa versa. >>> >>> Cheers >>> Colin >>> >>> -----Original Message----- >>> From: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> [mailto:public-sector-cloud-discuss@lists.oasis-open.org] On Behalf >>> Of Neil McEvoy >>> Sent: Friday, 22 June 2012 7:52 a.m. >>> To: >>> public-sector-cloud-discuss@lists.oasis-open.org<mailto:public-sector >>> -cloud-discuss@lists.oasis-open.org> >>> Subject: Re: [public-sector-cloud-discuss] PROPOSED TC CHARTER >>> >>> >>> Thanks John. >>> >>> Here is an article I have just posted that clarifies the main ideas >>> behind the Kantara CloudIDsec wg I have proposed for inclusion: >>> >>> http://cloudbestpractices.net/2012/06/21/ccommerce/ >>> >>> The main idea being the role of Kantara as approved Trust Framework >>> provider can enable Cloud hosters to be regulated in a form relevant >>> to GovClouds, meeting the requirements of various relevant Whitehouse >>> & other programs. >>> >>> Cheers Neil. >>> >>> >>>> Thanks to all for the messages of support so far and for the >>>> constructive suggestions. We will of course need many more >>>> supporters if we are to get the TC up and running but let's try and >>>> consolidate what we have so far into >>>> a possible Charter for the new TC. Attached is a draft and please >>>> feel >>>> free to edit it as you see fit. It's important that we get this >>>> right as it will be used to drive the work of the TC, so for >>>> instance have we got the right set of Deliverables or are the other >>>> things we should try and produce? >>>> >>>> >>>> >>>> >>>> Assuming that we can make good progress on this over the next few >>>> weeks then the plan would be to launch the new TC adjacent to the >>>> next International Cloud Symposium (ICS 2012) which will be held in >>>> Washington DC on 10th - 12th October. It was of course the ICS 2011 >>>> event that was the origin of this new TC so having the first meeting >>>> at ICS 2012 would be a very good piece of publicity and hopefully >>>> would attract several new members. >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> - >>>> To unsubscribe, e-mail: >>>> public-sector-cloud-discuss-unsubscribe@lists.oasis-open.org<mailto: >>>> public-sector-cloud-discuss-unsubscribe@lists.oasis-open.org> >>>> For additional commands, e-mail: >>>> public-sector-cloud-discuss-help@lists.oasis-open.org<mailto:public- >>>> sector-cloud-discuss-help@lists.oasis-open.org> >>> >>> >>> -- >>> Neil McEvoy >>> Founder and President >>> Level 5 Consulting Group >>> http://L5consulting.net >>> ==== >>> CAUTION: This email message and any attachments contain information >>> that may be confidential and may be LEGALLY PRIVILEGED. If you are >>> not the intended recipient, any use, disclosure or copying of this >>> message or attachments is strictly prohibited. If you have received >>> this email message in error please notify us immediately and erase >>> all copies of the message and attachments. Thank you. >>> ==== >>> ==== >>> CAUTION: This email message and any attachments contain information >>> that may be confidential and may be LEGALLY PRIVILEGED. If you are >>> not the intended recipient, any use, disclosure or copying of this >>> message or attachments is strictly prohibited. If you have received >>> this email message in error please notify us immediately and erase >>> all copies of the message and attachments. Thank you. >>> ==== >>> ==== >>> CAUTION: This email message and any attachments contain information >>> that may be confidential and may be LEGALLY PRIVILEGED. If you are >>> not the intended recipient, any use, disclosure or copying of this >>> message or attachments is strictly prohibited. If you have received >>> this email message in error please notify us immediately and erase >>> all copies of the message and attachments. Thank you. >>> ==== >>> >>> ==== >>> CAUTION: This email message and any attachments contain information >>> that may be confidential and may be LEGALLY PRIVILEGED. If you are >>> not the intended recipient, any use, disclosure or copying of this >>> message or attachments is strictly prohibited. If you have received >>> this email message in error please notify us immediately and erase >>> all copies of the message and attachments. Thank you. >>> ==== >>> >> >> >> -- >> Neil McEvoy >> Founder and President >> Level 5 Consulting Group >> http://L5consulting.net >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> public-sector-cloud-discuss-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: >> public-sector-cloud-discuss-help@lists.oasis-open.org >> >> > > > -- > Neil McEvoy > Founder and President > Level 5 Consulting Group > http://L5consulting.net > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > public-sector-cloud-discuss-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: > public-sector-cloud-discuss-help@lists.oasis-open.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > public-sector-cloud-discuss-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: > public-sector-cloud-discuss-help@lists.oasis-open.org > > -- Neil McEvoy Founder and President Level 5 Consulting Group http://L5consulting.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]