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


Help: OASIS Mailing Lists Help | MarkMail Help

sdd message

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

Subject: OASIS Provisioning Services TC

Hi all,

Here is the information on a deployment/provisioning related TC

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.

They developed SPML (Service Provisioning Markup Language) V2.0.

CDDLM-WG thinks SPML is orthogonal to their work. Thus same as

Hiro Kishimoto

> -------------------------------------------------------------------------
> Hi Hiro,
> Below is my evaluation from about 2-3 years ago, that happened before I
> started CDDLM or around that time:
> Service Provisioning Markup Language (SPML, www.openspml.org) is an
> OASIS (www.oasis-open.org) standard, which defines an XML- based
> framework for exchanging information between Provisioning Service
> Points. It is a framework for the exchange of user, resource, and
> service provisioning information.
> SPML is being defined by the OASIS Provisioning Services Technical
> Committee.  It is focused on user provisioning.  Their definition is
> "Provisioning is the automation of all the steps required to manage
> (setup, amend & revoke) user or system access entitlements or data
> relative to electronically published services".  Thus, it addresses a
> subset of the lifecycle services and attributes that we desire.
> The XML schema for SPML has a well-defined type system, but, while it
> could be extended to cover the configuration of more than just
> identities, it really doesn't provide anything but the barest foundation
> for such extension.  Further, each service object is treated as an
> independent entity.  There is no provision for modeling any kind of
> relationship between them."
> I read the new spec, and while it evolved it is still orthogonal to what
> CDDLM does. The closest I can see is that some time in the future CDDLM
> builds on top of the SPML protocol. I will also touch base with the rest
> of the CDDLM team during our forthcoming meeting.
> In a summary 100% of the CDL and component model does not depend or
> conflict with SPML. Small fraction of deployment API might be dependent
> on it (if we decide that we implement SPML protocol as a basis), but I
> will have to confirm this with Steve. In any case, there is no immediate
> action item on this.
> Thanks,
> Dejan.
> -------------------------------------------------------------------------
> Hi Hiro and Dave,
> The rest of the team agrees with my estimate, see from the end of the
> notes from this morning:
> ----
> "5. SPML discussion
> Stuart: very high level protocol, does not say anything about how to do
> things. Has nothing to do with deployment. Telco works this way, how to
> provision a circuit. No desire to go anywhere near SPML."
> ----
> The rest of the team agreed, I did not make any more detailed note on
> this topic. We can address it at GGF17 if there is a need.
> Thanks,
> Dejan.

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