OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [provision] Scope of SPML -- Identities and Resources

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?

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?  

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.

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. 

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
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
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
but all agents that are embedded in printers should additionaly conform
the standard Printer MIB. Likewise all routers should conform to the
MIB. This way any management SW written to the Printer MIB could manage,
some fashion, any printer that also adhered to the Printer MIB. Of
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
thing to do, and will enhance interoperability.

Obviously a complete set of standard schemas can not be accomplished in
time frame of the proposed charter. What we could do is to define a
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
> 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
> 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
> A
> I do believe we will need to define some notion of an identity schema
> 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
> over it. This enables the desirable things re RBAC that Edward
> 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
> we've come across and have implemented (albeit without the benefit of
> 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
> 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
> 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
> 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
> and "provision" the machine to that service via a provisioning flow -
> for example, placing the machine into a specific group, or OU within
> directory.)
>  [More snippage for brevity]
> To make this more concrete, I can go ahead and put together some
> business scenarios and use cases.  Would that work for everyone?
> 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
(727) 561-9500x219

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC