Title: Message
Jeff, did you get this? I keep getting
postmaster notifications that my email deliveries to your address
failed.
I still very much want to understand your
approach.
Gary
----- Original Message -----
From:
Gary
Cole
To: Jeff Bohren
Cc:
Sent: Tuesday, April 06, 2004 9:47
AM
Subject: RE: [provision]
PSO/Account/ProvisionedState
Okay
so far....
Wouldn't we call the attribute something more
specific than "state" (since we've already agreed that there are several kinds
of state)? This feels like the "disabled" attribute in PrOM. (Or
are you perhaps suggesting that there is only a single "state" attribute, and
that the set of interfaces that an object class supports determines the valid
set of values for "state"?)
Suppose that Win2K supports immediate disablement and
Solaris does not. Further suppose that RACF supports *scheduled*
enablement and disablement, but that Win2K does not. In PrOM, I proposed
three attributes to represent these: "disabled", "enableDate" and
"disableDate".
How
would RACF advertise its support for immediate disablement/enablement AND
scheduled disablement/enablement?
Gary
-----Original Message-----
From: Jeff Bohren
[mailto:]
Sent: Tuesday, April 06, 2004
6:49 AM
To:
Subject: RE:
[provision] PSO/Account/ProvisionedState
Take for example two kinds of accounts; Win2K and Solaris accounts.
Assuming that both are a kind of account, but Win2K accounts can be
suspended and restored, where as Solaris accounts can not (some provisioning
system support suspending Solaris accounts via passwords, but for the
purpose of this discussion I will assume that is not the case for this
PSP).
A
standard schema might define an object class for account which has the
typical uid/password attributes and it might also define an object class for
anything (account or otherwise) that can be suspended and restored. For
instance the following could be object classes in a standard
schema:
Account
uid
password
Suspendable
state
Then a PSP may publish a schema that defines Win2K and Solaris
accounts:
Win2KAccount : Account, Suspendable
SolarisAccount : Account
Thus the RA could know a prior what PSOs support suspend and restore
semantics. It would be those PSOs that inherit the Suspendable
class.
BTW, this is all supportable in the SPML 1.0
standard.
Jeff Bohren
Product Architect
OpenNetwork Technologies,
Inc
-----Original
Message-----
From: Gary Cole [mailto:]
Sent: Monday, April 05, 2004 5:44 PM
To: Jeff
Bohren
Cc:
Subject: Re:
[provision] PSO/Account/ProvisionedState
Jeff,
I think the ball's in your court on this
one. I'm ready to agree, but I need help imagining what a standard
schema for state might look like, and how provisioned object classes would
declare the features they support. (Of course, I realize you've been
busy writing the Use Cases.)
Gary
----- Original Message -----
From:
Gary
Cole
To: Jeff
Bohren
Cc:
Sent: Tuesday, March 30, 2004 10:36
AM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I'm convinced. I see the
complexities of "program by exception", I see the elegance
of making this schema-dependent, and I see that this kind of
elegance has practical value in a network protocol.
So what would a "standard" state schema look
like? I just need a little help imagining this.
Would the standard state
schema contain elements or attributes to represent the multiple
facets of provisioned object state? How would the schema for each
object class specify which facets of provisioned object state it
supports? Would the schema for each object class be
target-specific?
Gary
-----Original Message-----
From: Jeff
Bohren [mailto:]
Sent: Tuesday,
March 30, 2004 9:09 AM
To:
Subject: RE: [provision]
PSO/Account/ProvisionedState
This is essentially the same as the "program by exception"
approach that is sometimes used in software development. In most cases
the arguments for and against it are more stylistic and philosophical
that practical. However since this is a network protocol, not a
software API, there a several practical issues that must be
addressed:
1) A PSP could legitimately consider setting unsupported status
attributes to be an error. In the case of batch requests, this could
result in the RA needing to resubmit all or part of the original batch
request (if "continue on error" is not specified).
2) From the standpoint of minimizing network traffic, the RA
must have a way to determine if a specific PSO supports a specific
state attribute. This is a must because if the RA is going to present
a set of state options for an authorized user of the RA system, it
must be able to present the supported state options for each PSO, not
all of them. Fortunately this is easily supported via standard
schema.
3) This approach will make status logic more complex. How does
the RA differentiate between a successful attempt to change an
unsupported attribute versus a failed attempt to change a supported
attribute?
This all requires extra complexity that is frankly unnecessary.
So far no one has brought up any state issues that could not be easily
supported in SPML 1.0 with the additional of standard schemas. If we
created a standard schema that only addresses account state, the SPML
1.0 could start addressing this issue immediately without even needing
SPML 2.0 to be in place.
By using SPML 1.0 with a standard "state" schema, the state
management would be explicit, efficient, standards based, and
available immediately. What more do you want in a network
protocol?
Jeff Bohren
Product Architect
OpenNetwork Technologies,
Inc
-----Original
Message-----
From: Gary Cole [mailto:]
Sent: Tuesday, March 30, 2004 7:02 AM
To: Jeff
Bohren; Gearard Woods
Cc:
Subject: Re: [provision]
PSO/Account/ProvisionedState
Could we discuss the identification
attributes for a minute, because I think that sets the stage for the
discussion of state attributes?
In the email that teed this all up, I
wrote:
>
> To identify the account, Account has "target",
"name",
> and "guid" attributes. The account is usually
associated
> with some target, has a name that is changeable,
and
> may have an internal identifier
> that is not supposed to change.
>
When I say "Account", I think of this
as roughly equivalent to "ProvisionedObject". (I realize that
not all features of Account apply to every provisioned object,
but this doesn't bother me too much because not all features of
Account apply to every account. Target
accounts all different, but there are also common
features.)
Not every target supports "guid", but
it's common enough (especially among the modern targets) that it's
reasonable to model this as a common feature. We can simply
leave "guid" null or empty where it is unknown or
unsupported.
I don't want to leave this
"open" (i.e., an entirely arbitrary
attribute) because guid is pretty common and very
useful in managing the account. Where guid is supported, it is
the preferred identifier. It is *very* handy to keep a guid as
a native identifier, since this helps in detecting native renames
(and distinguishing a 'move' from a 'delete' and an 'add').
Where the target supports some kind of guid, I want to map that
value to an attribute that my management code
recognizes.
I'm guessing that everybody basically
buys this premise, because the discussion has centered on the
state-related attributes. Here's the part where I step off the
ledge...
I think of the state-related attributes
we've been discussing in the same way: common and useful where
supported, harmless and empty if unsupported. For example, it doesn't bother me at all if a
particular class of provisioned object doesn't support "disabled",
as long as the value that comes back is harmless (e.g., empty or
"NOT_SUPPORTED").
It's common enough (not just for
accounts, but also for policies and other objects) to add
objects disabled and then enable them at a later date.
This is such a common aspect of management that I'd prefer to model
this explictly as a well-known aspect of state.
I'm interested to know what
everyone thinks. I'm not sure everyone will agree with this
line of reasoning, but if this explains where I'm coming from, then
maybe you all can use it to explain things to me.
Gary
----- Original Message -----
From:
Gary Cole
To: Jeff Bohren
Cc:
Sent: Friday, March 26, 2004
9:32 AM
Subject: Re: [provision]
PSO/Account/ProvisionedState
This sounds
interesting. Defining multiple interfaces (as Gerry
suggests) sounds like a reasonable way to tease apart the facets
that interest some (but not necessarily all) of us. Tying
these to a common schema (as Jeff B suggests) seems like a
reasonable way to keep the whole thing from flying
apart.
I need a little more help
imagining how we'd structure this. I wanted to define a
bunch of common state-related attributes, but Jeff B and others
point out that not all of these apply to all types of
accounts. Perhaps none of these state-related attributes
(beyond "exists") apply to some kinds of provisioned
object.
I had imagined calling a method
like:
State
getProvisionedState(PSO-ID);
For an Account, I'd get back all the
attributes that apply:
<State
psoId='ID' exists='true' disabled='false' disableDate='NONE'
enableDate='NONE' expired='false' expireDate='DATE'
/>
For a provisioned object that
supports only "exists", I'd get back only "exists":
<State
psoId='ID' exists='true'/>
But it sounds to me from the
discussion above, that I might have to define a different schema
for each combination of attributes. Am I right about that,
or could 'Stateful' contain our "starter kit" of common
state-related attributes?
Would each kind of provisioned
object have to define in its schema which state-related attributes
it supports?
Or would I just call a different
method (e.g., #listSupportedStateAttributes)?
Or could I figure this out just
from the set of attributes returned by
#getProvisionedState(PSO-ID)?
Sorry if I'm misunderstanding
your suggestion. If so,
perhaps we should talk offline (rather than email
everyone).
Gary
----- Original Message -----
From:
Jeff Bohren
To: Gearard Woods ; Jeff Larson
Cc: Gary Cole ;
Sent: Thursday, March 25,
2004 7:51 PM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I would not be opposed to having mulitple provisioning
interfaces, provided it was tied to a standard schema that
normatively defined what interfaces where appropriate for what
object classes. The clients still need to know what interfaces
would apply to what PSOs.
For example the SPML core operations could apply to all
object classes but the SPML state operations may only apply to
an object class that inherits from a "Stateful" object class in
a standard schema (note that SPML 1.0 supports multiple
inheritance so this is easy). This way the schema for the
resource does not even need to extend an abitrary "Account"
schema, it merely needs to extend the "Stateful" schema.
Jeff Bohren
OpenNetwork
-----Original Message-----
From:
Gearard Woods [mailto:]
Sent: Thu
3/25/2004 6:01 PM
To: Jeff Larson
Cc:
Gary Cole; Jeff Bohren;
Subject: RE: [provision]
PSO/Account/ProvisionedState
I agree that granularity of the calls is important and it
really shouldn't take 42 calls to determine the state of an
object - a single call should suffice. I think we can model
state effectively and still minimize the traffic needed to
manage it.
Jeff (Jeff B) has also raised the slippery
slope argument, and my take on it is that we should provide an
interoperable way to do the things we feel are a core part of
the provisioning process. There is a line here between what is
horizontal to provisioning and what is resource-specific.
State management is obviously important and passwords have
come up before, although Jeff B would argue that state is not
even relevant to most resources and is only applicable to
accounts.
The provisioning process is obviously not
the same thing to all people. We have disagreement even down
to the fundamentals of the provisioning model. Perhaps a way
to tackle these different viewpoints is to divide and conquer.
Imagine that we split up the problem into a number of
interfaces:
SPML core - Basic provision (add),
deprovision (delete), modify, list/search
SPML state - An
interface and schema representing state management (lifecycle
included or separate?)
SPML events - An interface and
schema for event notifications
SPML password - Password
management perhaps
SPML relationships -
TBD
Implementors must publish core to be SPML
compliant. They may then in turn overlay any of the other
interfaces to offer enhanced provisioning capabilities. These
would be simple interfaces with minimal schema but would be
complementary and all take advantage of the core schema.
Vendors who deal with directory-style interfaces need go no
further than the core interface while others may wish to offer
the full suite. Obviously these categories are just off the
top of my head but does this sound like an approach that has
promise?
Gerry
'
src="gif00032.gif" width=16>"Jeff
Larson" <>
"Jeff Larson"
<>
03/25/2004 02:20
PM
To: Gearard
Woods/Irvine/IBM@IBMUS, "Jeff Bohren"
<>
cc: "Gary Cole"
<>,
<>
Subject: RE: [provision]
PSO/Account/ProvisionedState
I haven't been following this that
closely, but I like aspects of both approaches. I
like
the notion that
you can carry out near-universal operations like disable,
enable, and expire,
in a schema independent way. But I also like the
notion that I can at least obtain the current
state
from the model
so I don't have to make 42 web services calls to get
everything I want to display.
I guess as
long as the schema is arbitrary we can have it both ways. If I
choose
to use fine
grained standard operations I can. If the PSP exposes the same
functionality
through
the model, I can use that too, though I will be outside of the
SPML spec.
But we're on a slippery slope here. Almost every
account will have an associated
password, email address, and full name. Do we
then provide individual operations
to get and set those so we can access them in an
standard way without having to be
bothered with PSP specific schema? How far does
this go?
Jeff
-----Original Message-----
From: Gearard
Woods [mailto:]
Sent: Thursday, March 25, 2004 3:35 PM
To: Jeff
Bohren
Cc: Gary Cole;
Subject: RE:
[provision] PSO/Account/ProvisionedState
I think there's a fundamental difference here
even though the intent may be the same. Basically, we're all
trying to model state and provide some kind of standardized
view of it to the outside world so that we can offer
interoperability. By placing state in the resource schema you
have immediately abandoned the possibility that arbitrary
resource schema may be supported, which I believe to be
important. You are also now requiring a mapping from the
"standard" schema to the real resource schema. On the other
hand, by placing the emphasis on the service provider and
providing an operational interface to effect state changes,
the provider can now apply its knowledge of the resource to
make the state change however it wishes to do so and places no
restrictions on the resource schema.
Gerry
