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


If I may, I would like to volunteer to be the liaison to the ASN.1
group.  They are planning to have a meeting in the middle of next month
in Somerset, NJ, where if deemed appropriate, I may introduce our
working group to them and obtain some feedback and response from them.
I would be interested to report back how they are defining their data in
their transmissions.  I am including a reference presentation to some
notations they have shown.  Of initial interest may be the Basic
Encoding Rules (BER), Distinguished Encoding Rules (DER) that ASN.1
covers.

BER was created in the early 1980s and is used in a wide range of
applications, such as Simple Network Management Protocol (SNMP) for
management of the Internet; Message Handling Services (MHS) for exchange
of electronic mail and TSAPI for control of telephone/computer
interactions. 

DER is a specialized form of BER that is used in security-conscious
applications. These applications, such as electronic commerce, typically
involve cryptography, and require that there be one and only one way to
encode and decode a message.

ASN.1 -->  www.asn1.org

-Gavenraj

Gavenraj Sodhi
Senior Technology Analyst
Business Layers, Inc.
Tel: (949) 388-0088   Fax: (949) 767-5851
gavenraj.sodhi@businesslayers.com
www.businesslayers.com

AIM    gavenrajsodhi  
YIM    gavenrajsodhi


-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com] 
Sent: Saturday, December 08, 2001 7:36 AM
To: provision@lists.oasis-open.org
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
http://asn1.elibel.tm.fr/en/xml/


--------------------------------------------------------
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
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



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

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

ASN.1 Markup Language Value Notation.ppt



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


Powered by eList eXpress LLC