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

I understand the SNMP example and its LDAP adoption and agree with some
part of the sentiment.  Is it a fair conclusion to say this implies the
following for SPML schema's:

* SPML defines the framework for exchanging extensible schemas for the
purpose of service provisioning

* SPML will provide base reference schemas for commonly used services.
These schema will build upon/take reference from existing definitions
where ever possible (ASN.1, DMTF-CIM or Provisioning Service Target
(PST) specific where it exists).

* SPML PST schemas will be intentionally minimal. There primary purpose
would be: A) To define a core around which SPML can define the required
query and request vocabulary. B) To define a commonly understood base
for extensions.

I'm sure we are going to need a PST schema sub-committee moving forward
and direct liaisons to DMTF's XML encoding work (Winston I believe has
volunteered for general liaison to DMTF) and to the ASN work at

Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 

OK, perhaps the SNMP example was a little esoteric, so here is another
LDAP standard schemas, such as inetorgperson (rfc 2798). LDAP
are free to use, extend, or ignore inetorgperson as desired. But if they
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
some level, there will never be any interoperability between

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
> be outside the scope of SPML.  Furthermore, commercial hardware as
> 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
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
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
> 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-
> attribute or provisioning parameter.

LDAP is based on generic name value pairs to define a directory entry.
even LDAP requires schema definitions to define what those name value
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
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
> a
> mechanism for defining schemas in general, we define a set of
> 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
> 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
> 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
> 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
> 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
> > 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
> > DTD/schema library for every resource/service/thingy we envisage
> > supported by a SPML compliant provisioning service.  It would be the
> job
> > of the queried SPML service to respond with an artifact that
> > the attributes required to complete a request. This process would
> > 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
> to
> > A
> >
> > I do believe we will need to define some notion of an identity
> 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
> > 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
> > provisioning to include distributing software and applications!
> > worked on a software distribution product in a previous life, the
> > implications his answer had on scope and complexity at first
> > me.  However, once I picked myself up off the floor and thought
> > 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.
> > 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
> 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 -
> > PC and server systems, switches, routers, PBXes, applications...
> > 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
> > 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
> > 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"
> > 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
(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