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] Charter...


I completely agree with the omission of the term end-to-end, in fact I'd like to take this a step further and explain exactly why it's not end-to-end...

We made a mistake early on in the scope discussion by not making a clear distinction between the producers and consumers of SPML requests.  Anand's submission (http://lists.oasis-open.org/archives/provision/200112/msg00046.html) and that of Bill Games (http://lists.oasis-open.org/archives/provision/200112/msg00050.html) discussed the definition and description of provisioning requests from an order entry/order management and service specification view point. 

This is very much a producer use-case view that defines how underlying provisioning actions would be packaged together (with qualifying attributes) to form a service definition that could be agreed upon with a customer and then executed (using SPML requests).

Where as the expression and definition of service in this context does warrant a full use case, I don't believe in effects the scope of SPML as radically as one might at first think. If we exclude the "service relationship and options" syntax from the SPML dialog and concentrate on a robust exchange relating to the resource and resource schema/attributes, we could leave this to an adjacent or subsequent effort. Such an effort would build upon SPML to standardize how to define and package together service element to form service delivery options and eventual end-to-end service delivery...  


In summary:

1) Are we in agreement that end-to-end means the kind of service specification implied above and in Anand and Bill's notes?
2) If so are we happy to omit this from the scope of our initial efforts (for the record I am)?
3) If so do we need to add verbiage to this extent?
4) If so how about something like the following:

"SPML does not address the needs of end-to-end service definition in the context of order entry/order management and service delivery.  It is however envisioned that future efforts will employ SPML requests in a wider "service expression and delivery" syntax targeted at the end-to-end problem"


--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
(512) 657 8360                    PGP  0x8AC67C6F   
--------------------------------------------------------      

-----Original Message-----
From: Ranthidevan, Anand [mailto:aranthidevan@jamcracker.com] 
Sent: Thursday, January 03, 2002 8:13 PM
To: Jeff Bohren; provision@lists.oasis-open.org
Subject: RE: [provision] Charter...

Based on our discussions on 12/17 and 12/10 (where issues like not having phrases like "end-to-end" in the charter, inclusion of the organization/user identities, and the hosted model, etc. ), I'd like to propose the following modified version for the charter:
 
------------------------------------------------------------------------------------
 
The purpose of the OASIS Provisioning Services Technical Committee (PSTC) is to define an XML-based framework for exchanging *identity* and *resource* provisioning information. This framework will be referred to as the Service Provisioning Markup Language (SPML).
 
The Technical Committee will develop an open specification addressing the required semantics to exchange identity related requests (where an identity could be organizations, groups, or users) between cooperating provisioning resources. A resource could be any application or system capable of consuming a well-formed SPML request. A Provisioning Request will include actions like: provision, activate, amend, suspend, enable, and delete.
 
The scenarios SPML will cover include (but are not limited to):
 
1) Provisioning any internal resource within an organization
2) Provisioning any external resource hosted by 3rd party providers, aggregators, ASPs, etc.
3) Providing a Hosted SPML-based provisioning service that can act as an intermediary between two or more systems.
 
The finished specification is expected to include (but is not limited to) core XML schemas for the following:
 
1) Defining a common schematic to describe a Resource -- including its configurable parameters.
2) Query and exchange of available resources that can be provisioned for an identity
3) Query and exchange of available resource attributes and options
4) Query and exchange of available identities and information pertaining to each identity
5) Query and exchange of resource hierarchies
6) Request and response for specific provisioning messages 
 
SPML will assume a pre-existing trust model between participating resources and will utilize available security mechanisms for encryption and message integrity. The SPML specification will be developed with consideration of the following existing specifications (which are of public knowledge -- accessible and freely distributed): Active Digital Profile (ADPr), eXtensible Resource Provisioning Management (XRPM), and Information Technology Markup Language (ITML).
 
The goal of the Technical Committee (subject to revision) is to submit a Specification (including Use Cases & Requirements, Information Model, Protocols, Bindings, and Conformance) to the OASIS Membership for its approval by September 2002. 
 
------------------------------------------------------------------------------------
 
Thanks,
-Anand
 
[Anand Ranthidevan]
Product Manager - Jamcracker, Inc.
http://www.jamcracker.com 
 
-----Original Message----- 
From: Jeff Bohren 
Sent: Thu 1/3/2002 6:22 AM 
To: provision@lists.oasis-open.org 
Cc: 
Subject: [provision] Charter...
I the last meeting I proposed that we vote on the charter in the meeting
on jan 7th. From the discussions so far I see no reason the charter last
propsed by Darran can not meet our needs. I would like to have this
added to the agenda for the meeting. If we can not reach quorum on the
7th, then we should schedule an e-mail vote on this following the
meeting.

The last draft I saw of this was:

------------------------------------------------------------------------

The purpose of the OASIS Provisioning Services Technical Committee
(PSTC) is to define an XML-based framework for exchanging user, resource

and service provisioning information. This framework is commonly
referred to as the Service Provisioning Markup Language (SPML).

The Technical Committee will develop an end-to-end, open specification
addressing the required semantics to exchange requests between
cooperating provisioning services. A provisioning service is defined as
any infrastructure component capable of consuming well formed SPML
request.

The finished specification is expected to include (but is not limited
to) core XML schemas for the following:

*       Query and exchange of available resources to provision to
*       Query and exchange of available resource attributes
*       Query and exchange of available resource identities
*       Query and exchange of resource hierarchies
*       Request and response for specific provisioning requests

The following are also initial assumptions relating to the scope and
nature of the SPML framework:

*       SPML assumes a pre-existing trust model between the SPML
requestor and the SPML  compliant service
*       Encryption and message integrity should be available at the
session level (via      SSL/TSL) and at the individual element level
though XML-Encryption and XML-  Signatures

The SPML specification will be developed with consideration of the
following existing specifications (which are of public knowledge,
accessible, and freely distributed).

*       Active Digital Profile (ADPr)
*       eXtensible Resource Provisioning Management (XRPM)
*       Information Technology Markup Language (ITML)

The PSTC will produce a set of one or more Committee Specifications that

will cover the following (all of which are to be examined with respect
to security considerations):

*       Use cases and requirements
*       Information model
*       Protocol(s)
*       Bindings
*       Conformance

The goal of the committee (subject to revision) is to submit a
Specification to the OASIS membership for its approval by September of
2002.

--------------------------------------------------------


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


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


Powered by eList eXpress LLC