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

[Doug Newdick <Doug.Newdick@dia.govt.nz>]

Hi,

The answers from John and Neil seem to me to illustrate the point of my question. To the question of is there anything that is distinctive about public sector agencies' requirements on the cloud John appears to have answered "obviously, yes" and Neil "obviously, no" - thus it appears that we do not have consensus on this question. I suppose I believe that if the answer is "no" then there is no point to such a TC - or am I misunderstanding things?

With respect to Neil's original comments, I think we are agreeing on one area - data sovereignty is a significant issue for the public sector. However, I don't see, in NZ at least, that this is an issue around legislation, the issue seems to me to be more around policy and risk management. My experience in both the public and private sector is that the public sector is more concerned about security and privacy. Most private sector bodies look at these factors in terms of financial risk, whereas the public sector tend to view this in terms of fundamental rights and liberties.

What I should have said explicitly is that I believe that this TC should focus on the areas where public sector agencies have particular or unique needs - perhaps the ones that I mentioned in my previous email. I don't think this TC should try and solve all of the problems related to cloud computing. Instead we can use the more general material provided by other bodies where the requirements on the public and private sectors are the same. is that a reasonable approach?

I'm quite happy that we are moving in the right direction, and I will look to work with Collin to suggest some specific wording around the deliverables.

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


-----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: Friday, 29 June 2012 1:47 a.m.
To: John Borras
Cc: public-sector-cloud-discuss@lists.oasis-open.org
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


---------------------------------------------------------------------
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

====
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.
====