Re: [sca-policy] ISSUE-93 More Rationale

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

I still don't understand the rationale
for this.

If I can attach an intent externally,
why didn't I attach an actual concrete policy (or policies) to exactly
the same locations, using the existing
external attachment functionality?

I really don't get why external attachment
of intents (rather than concrete policies) is useful to anyone.

How do the intents, so attached, actually
get used?  If all they do is then guide the attachment of policy
sets, surely it is possible to simply
attach the policy sets in exactly the same locations (and for exactly
the same set of reasons that Ashok outlines
in the note below).?

If the intents are being used for for
some other purpose, then it would be good to describe that purpose
since I don't see it at the moment.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	ashok malhotra <ashok.malhotra@oracle.com>
To:	OASIS Policy <sca-policy@lists.oasis-open.org>
Date:	04/12/2009 18:44
Subject:	[sca-policy] ISSUE-93 More Rationale

---

http://www.osoa.org/jira/browse/POLICY-93
 Allow External Attachment for 
Intents
Here is further rationale in addition to what was presented in
http://lists.oasis-open.org/archives/sca-policy-comment/200906/msg00007.html


Our developers are now convinced that intents are a good thing and serve
as useful
abstractions for policy requirements.  They are using intents, however,
in a manner that is a bit
different from what was originally envisaged when intents were 
invented.  Here are some
issues/requirements.  These reflect our continuing emphasis on 
separating policy artifacts from
implementation code and are drawn from real situations

1. Security intents are not attached by the developer.  There are
special, separate, security experts
who attach intents after the developer has done his job.  So, it should
be possible to attach security intents
as a separate step after the code is written and it is better if the 
security expert does not need to muck
with the code.

2. In some cases the customer can change intents.  Oracle products
are 
shipped "secure by default"
The customer may think this is unnecessary and/or too expensive and may
want to lower the bar.
Again. you don't want him changing the code.  If intents are attached
externally he changes just the intents file.

3.  And, of course, corporate policies change.  External attachment
just 
makes changing intents or attaching additional
intents much easier.

4. Developers cannot be trusted.  In the case of "secure by default"
we 
have special scripts that go through the code
and check if the right intents have been attached.  This would much
simpler if intents were attached externally.

PROPOSAL:
Add an "attachTo"  attribute to intents.   It's a simple
addition.  You 
don't have to use it if you don't want to.
-- 
All the best, Ashok

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU