Re: [provision] Scope of SPML -- Identities and Resources

[jbohren@opennetwork.com (Jeff Bohren)]

OK, perhaps the SNMP example was a little esoteric, so here is another one:
LDAP standard schemas, such as inetorgperson (rfc 2798). LDAP implementors
are free to use, extend, or ignore inetorgperson as desired. But if they use
it, they know that thier person definitions will be compatible with any
other LDAP server that supports inetorgperson.

There is allways a trade-off between flexibility and standardizations. If we
define a mechanism for provisioning without some commonly used schema's at
some level, there will never be any interoperability between provisioning
systems.

More comments below.

Jeff Bohren

Bill Games wrote:

> Delineating "standard schema's for common classes of targets" is too
> open ended to be practical.  What about all the home-brewed service
> delivery platforms built by service providers, themselves?  They can not
> be outside the scope of SPML.  Furthermore, commercial hardware as cited
> below already has well defined APIs that can be used for direct
> provisioning purposes.  Why mirror them in SPML?

"home-brewed service delivery platforms built by service providers",  do not
currently use SPML, and so are out of scope by definition.

I did not mean to suggest that we are going to replicate SNMP MIBs in SPML.
That was an example of an approach used by another standard.

>
>
> The problem statement as I see it is:
> How do you structure an SPML message, in general, so that any
> provision-able service can be specified or described to an
> SPML-compatible provisioning controller?
>

By defining a standard schema for a provisionable service.

>
> Note: A provisioning controller interacts directly with target service
> delivery platform APIs.  This implies prior configuration of the
> provisioning controller, itself, to talk to target APIs.  The benefit of
> SPML is that generic service provisioning messages can be sent to an
> SPML compatible provisioning controller without a need to know how to
> talk to the native APIs of the service delivery platform, themselves.
> In effect, an SPML provisioning controller is a universal service
> provisioning API.
>
> As a simpler alternative, consider a generic schema that defines
> provisioning parameters as name-value data pairs contained within a
> service element.  This approach enables the description of -any- service
> attribute or provisioning parameter.
>

LDAP is based on generic name value pairs to define a directory entry. But
even LDAP requires schema definitions to define what those name value pairs
can be.

>
> Here's a proposed definition of a service element:
> A -service element- defines an atomic unit of service that grants or
> links a customer access to or use of a specified resource owned or
> controlled by the service provider.  As an atomic unit, it is the
> "smallest", indivisible unit of service that can be provisioned for a
> customer.  A service element is composed of zero or many service
> attributes or provisioning parameters along with additional generic
> transaction and control attributes.
>

I was with you unit the part about "additional generic transaction and
control attributes" What would an example of this be, and how would they be
different from provisioning parameters.

>
> Bill Games
> (512) 327-9346
>
> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Friday, December 07, 2001 8:45 AM
> Cc: provision@lists.oasis-open.org
> Subject: Re: [provision] Scope of SPML -- Identities and Resources
>
> One idea I brought up in XRPM was to emulate the SNMP approach of
> defininge
> extensible, standard schema's for common  classes of targets. I'm not
> suggested we use ASN.1, but what I am suggesting is that after defining
> a
> mechanism for defining schemas in general, we define a set of predefined
> schemas for commonly provisioned services, or using Darran's proposed
> terminology, Provisioning Service Target (PST).
>
> For instance, in SNMP, all agents should conform to the core schema
> MIB-II,
> but all agents that are embedded in printers should additionaly conform
> to
> the standard Printer MIB. Likewise all routers should conform to the
> Router
> MIB. This way any management SW written to the Printer MIB could manage,
> in
> some fashion, any printer that also adhered to the Printer MIB. Of
> course
> all vendors can, and do, extend their schemas to cover features they
> view as
> important, but are not covered in the standard schema.
>
> Note that in Anand's e-mail about the Jamcraker experience with
> provisioning, he naturally groups the PST's into catagories (e.g.
> Directories, OS's, Networks, Security, etc.). I think that this is a
> logical
> thing to do, and will enhance interoperability.
>
> Obviously a complete set of standard schemas can not be accomplished in
> the
> time frame of the proposed charter. What we could do is to define a
> schema
> definition mechanism and publish drafts for one or two standard schemas.
>
> Jeff Bohren
>
> Darran Rolls wrote:
>
> > An assumption
> > --------------
> > As a pre-cursor to my comments here, I should state a working
> assumption
> > that I personally have in mind that we need to discuss (I have several
> > other relating to identity scope etc that I will fwd in a separate
> > mail).  My assumption is that the PSTC is not setting out to define a
> > DTD/schema library for every resource/service/thingy we envisage being
> > supported by a SPML compliant provisioning service.  It would be the
> job
> > of the queried SPML service to respond with an artifact that detailed
> > the attributes required to complete a request. This process would look
> > something like this:
> >
> > A queries B for the required schema for thing X
> > B send an attribute/type list to A to provision a new instance of X
> > A makes up a suitable SPML artifact from this and sends it back to B
> > B does it's thing with the artifact and communicates the results back
> to
> > A
> >
> > I do believe we will need to define some notion of an identity schema
> as
> > this will be required in many cases for updates and initial
> > queries/requests that relate to some already established primary
> > identifier.
> >
> > Comment on the thread
> > ---------------------
> > I believe my assumption above make it less relevant the list of things
> > we have to say are in scope.  At the OMG/OASIS interoperability and
> > modeling summit this week, I had the opportunity to ask someone what
> > they would consider in scope for provisioning. Interestingly, he took
> > provisioning to include distributing software and applications! Having
> > worked on a software distribution product in a previous life, the
> > implications his answer had on scope and complexity at first horrified
> > me.  However, once I picked myself up off the floor and thought about
> > it, I came to the conclusion that yes, maybe it could considered in
> > scope.  After all, in the context of my initial assumption does it
> > matter what B says it wants so long as A can supply it?.
> >
> > This position puts SPML as the structure and framework for the
> > request/response flow not the prescription of the schemas that can
> flow
> > over it. This enables the desirable things re RBAC that Edward
> mentions
> > but does not sign us up for a 4 year schema design course.
> >
> > I'm at Disney World Orlando right now so telling me I'm on another
> > planet on this would be somewhere near the truth ;-)
> >
> > --------------------------------------------------------
> > Darran Rolls                      http://www.waveset.com
> > Waveset Technologies Inc          drolls@waveset.com
> > (512) 657 8360                    PGP  0x8AC67C6F
> > --------------------------------------------------------
> >
> >
> >
> > -----Original Message-----
> > From: Truitt, Edward D. (OSED) [mailto:OSED@chevrontexaco.com]
> > Sent: Thursday, December 06, 2001 5:15 PM
> > To: 'provision@lists.oasis-open.org'
> > Subject: RE: [provision] Scope of SPML -- Identities and Resources
> >
> > My comments, below.
> >
> > Edward D. (Ed) Truitt
> > Systems Analyst, Directory Services
> > Global Infrastructure Delivery / Global IT Delivery
> > ChevronTexaco  Information Technology Company
> > Ph# +1 281.596-3246 Fax# +1 281.596-2714
> > Cell phone / Pager # +1 832.443-7283
> > "Got IT?"
> >
> > -----Original Message-----
> > From: Ranthidevan, Anand [mailto:aranthidevan@jamcracker.com]
> > Sent: Thursday, December 06, 2001 4:13 PM
> > To: provision@lists.oasis-open.org
> > Subject: [provision] Scope of SPML -- Identities and Resources
> >
> > [snip for brevity]
> > IDENTITIES: As *who* requires to be added, modified, or deleted. This
> > shouldn't be limited to just Users, as that's too narrow. The main
> ones
> > we've come across and have implemented (albeit without the benefit of
> a
> > standard) are:
> > 1. Systems
> > 2. Companies
> > 3. Company Structures -- like Divisions, Departments, Cost Centers,
> > Locations, Employee Types, and so on.
> > 4. Users
> > 5. User Roles
> >
> > [Truitt, Edward D. sez] While this is a good list, I still feel
> strongly
> > that we need to include other inanimate IT entities in the list - like
> > PC and server systems, switches, routers, PBXes, applications...  The
> > reason is that, while may of us think of these as "resources" or
> > "services" to be provisioned, in a real sense they can take on the
> role
> > of "provisionee" - for example, you could use a provisioning system to
> > connect an application to a middleware bus (e.g. TIBCO), or
> > to "provision" a certain level of network service (QoS) to a web
> server,
> > or to "provision" a PC to the Active Directory (create/manage its
> > computer account).  This could allow us to extend RBAC into places we
> > are just beginning to think of (example:  I may want to prohibit any
> > system from running the IIS service, unless it is in a role that
> > requires it, and unless the primary user for that system understands
> > this and is aware of the risks involved.  So, I define what "roles" a
> > machine must occupy in order to be authorized to start the IIS
> service,
> > and "provision" the machine to that service via a provisioning flow -
> > for example, placing the machine into a specific group, or OU within
> the
> > directory.)
> >
> >  [More snippage for brevity]
> >
> > To make this more concrete, I can go ahead and put together some
> general
> > business scenarios and use cases.  Would that work for everyone?
> Should
> > I post them to this list?
> >
> > [Truitt, Edward D. (OSED) sez] Works for me!
> >
> > -Anand
> > [Anand Ranthidevan]
> > Product Manager - Jamcracker Platform
> > aranthidevan@jamcracker.com
> > http://www.jamcracker.com
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> --
> Jeff bohren
> Product Architect
> OpenNetwork Techologies
> jbohren@opennetwork.com
> (727) 561-9500x219
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Jeff bohren
Product Architect
OpenNetwork Techologies
jbohren@opennetwork.com
(727) 561-9500x219