RE: [public-sector-cloud-discuss] PROPOSED TC CHARTER

["Neil McEvoy" <neil.mcevoy@l5consulting.net>]

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:[mailto: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:[mailto: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:[mailto: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:[mailto: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