From: Adrian Viego <adrian.viego@businesslayers.com>
To: Tony Gullotta <TGullotta@access360.com>,'Yoav Kirsch' <Yoav.Kirsch@businesslayers.com>,'Gavenraj Sodhi' <gsodhi1@cox.net>,Adrian Viego <adrian.viego@businesslayers.com>
Date: Fri, 08 Feb 2002 12:02:21 -0500
All,
I have
followed the discussions with great enthusiasm since I'm usually the one
creating the dissension and confusion. Having said this, I think that much
of the agenda is premature and I'll state my case.
Most
of the items on the agenda assume that the group has reached consensus on the
use cases and operating models for SPML. I think that is is essential that
we finalize the use cases and then determine the requirements that the use cases
mandate for authentication, authorization, messaging, session management, error
handling, status reporting, schema, roll back, protocol,
etc.
Many
of the arguments that have been presented in the email have focused on issues
that suppose the architecture of a physical solution. For example, the use
of a meta-directory as an agent in the provisioning process. I think it is
important for us to do all of our work using an abstract model that does not
constrain us due to the limitations of an existing type of target system or
intermediary. DSML is a good example. It supposes an LDAP directory and is
thus limited by how the model works and what it can address.
The
PSTC introductory document makes the correct assertion in stating that, "it is not necessary to define the implementation or physical
makeup of a provisioning system. It should simply be assumed that a facility or
capability exists within a network to carry out provisioning actions on a given
set of resources."
The
opportunity at hand is to correct the rest of the assertions in the paragraph,
"In many (but not mandatory to all) provisioning systems, the
"system" denotes the capacity to take provisioning requests and to execute them
in the context of some pre-defined flow of execution.In many cases (but not mandatory to all)
the provisioning system encompasses a formal work-flow to implement these
pre-defined business process."
My
belief is that we cannot presuppose the workflow of the target system or that
all provisioning activities are based on predefined execution models that must
be arranged by the two parties before transactions can
occur.
Also,
I would like the face to face to deal with acknowledging the role and
requirements for SPML in the transaction between the Provisioning Service Point
and the Provisioning Service Target.
My
reasoning is that the requirements for protocol, model, schema, etc. may differ
when exchanging provisioning requests or information between two PSPs or between
a PSP and a PST.
I
think we should concentrate our current efforts on the modeling and
terminology. After that, we should examine the requirements for
information and services. Modeling the information we will need to
exchange and the services we will require will be a substantial
task.
I feel
strongly that the selection or definition of protocols should come at the
end. Once we understand the requirements for information exchange,
services, and user cases, we will be better able to determine the
characteristics of the protocols we require including factors like synchronous
or asynchronous operation, delivery guarantees, transitive trust,
etc.
Regards,
[Adrian
Viego]
-----Original
Message----- From: Tony Gullotta
[mailto:TGullotta@access360.com] Sent: Thursday, February 07, 2002
6:55 PM To: 'Yoav Kirsch'; 'Gavenraj Sodhi'; Adrian
Viego Cc: 'provision@lists.oasis-open.org' Subject: RE:
[provision] Austin F2F#1 Straw-man Agenda]
These are all good points if we are talking about peer-to-peer
provisioning (between two provisioning systems). We may want to distinguish
this however from a more master-slave approach when provisioning IT or telco
resources from a provisioning system. This distinction may or may not be
needed depending on the possible integration opportunities we are trying to
address. For example, Jeff's point is very valid if we think that
Meta-Directories should be able to provision these resources using the same
set of standards. Since Meta-Directories are more LDAP centric, then DSML (or
LDAP for that matter) may be a good approach for a protocol. Since billing,
approvals, and scheduling doesn't really apply in this master-slave scenario,
something simple and currently supported may give us all the quickest road to
adoption.
Just a thought.
Tony
-----Original Message----- From:
Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com] Sent: Thursday,
February 07, 2002 12:43 PM To: 'Gavenraj Sodhi'; Yoav Kirsch; Adrian
Viego Cc: 'provision@lists.oasis-open.org' Subject: Re:
[provision] Austin F2F#1 Straw-man Agenda]
DSML v2 is a
Directory protocol and allows user to manipulate Directory entries
through XML.
Provision
protocol should support a much broader aspect. The provision protocol
should support workflow features such as provision dates. (Do we need this
resource now or can we wait for next month), Approval chain (who approve
the provisioning), Billing information (we should support scenarios where
the provision server actually charge for the resources that it supplies.
This is the ASP model) and support Auditing and reporting
functionalities.
Another
difference is that provisioning activity may take few days. The protocol
should support this and allows disconnected transaction between the client
and the server.
In general I
Think that the following protocols SOAP ,UDDI, ebXML , are closer to
the SPML protocol and that we should
use them as our starting point
Although I will not be able to attend the F2F in Austin, I would like
to make a proposal in refence to the "Core Protocol - Model Overview"
section of the agenda.
I would like to propose that instead of creating another XML protocol
for provisioning, that the SPML standard be based on the DSML V2 standard.
I am suggesting that we use DSML V2 as the SPML protocol and define a set
of schemas that define the provisioning model.
I believe that defining a Provisioning Model is going to be the most
difficult task for this group, so by using a predefine protocol, we would
be that must closer to a standard. So far I have not seen anything in the
submitted use cases that could not be accomodated with DSML V2 as the
protocol.
I apologize for making this proposal without being able to attend the
F2F and discuss it. But I feel that it is important to put this forward if
the group is going to be talking about the core protocol.
Jeff Bohren
Darran Rolls wrote:
Folks
Below is a straw-man agenda for next weeks meeting. The general objective is to discuss
develop and produce a body of technical requirements suitable to begin
the analysis and development of the core protocol. The general tone of the meeting is
that of a guided open discussion.
The intention is to produce a large list of technical requirements,
issues and comments for presentation back to the list and committee
members.
I have arranged for teleconference facilities in the room. There will also be IP available for
everyone that needs it. Where
applicable we can arrange Webex web conferencing for any remote members
that want to connect and see any slides that might be available - I
intend to have a summary presentation of the use cases and the Core
Protocol Model overview - these would be suitable for
"broadcast".
If you are not attending but would like to dial-in for any part
of the agenda please let me know in advance. Also, regardless of attendance, do feel
free to suggest changes/amendments/additions - I'm doing the agenda
because you are not ;-)
Monday 11th February
2002
9:00
Coffee
9:30 Call
to order
9:35 Review
agenda - agree meeting objectives
9:45
Proposed f2f dates through July
10:00 Use
case reviews
12:30
Lunch
1:30 Use
case next steps
2:00 Core
protocol - model overview
3:00 Coffee
break
3:15
Requirements for authentication &
authorization
5:00
Adjourn
7:30 Local
dinner for anyone interested
Tuesday 12th February
2002
8:30
Coffee
9:00 Call
to order
9:05
Requirements for request/response message
flows
10:30
Requirements for state & session
management
11:30
Requirements for error handling and status
reporting