RE: [provision] missing use cases?

[Jeff Bohren <jbohren@opennetwork.com>]

Actually I was suggesting the exact opposite. Using an extended request
for an asynchronous notification is not required, will inhibit
interoperability, and will be much harder to implement. It's all pain,
no gain.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com] 
Sent: Tuesday, February 18, 2003 1:31 PM
To: provision@lists.oasis-open.org
Subject: RE: [provision] missing use cases?

In conclusion then, for 1.0 the model for asynchronous notifications
from PST to PSP, the committee is going to recommend using custom
ExtendedRequest flows?

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


> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Monday, February 17, 2003 12:40 PM
> To: provision@lists.oasis-open.org
> Subject: RE: [provision] missing use cases?
> 
> 
> I don't think we need to formalize this, but there are several simple
> ways to make this work. All the PSP needs to do is either expose a
> different web service URL for PSTs to post updates to, or have one URL
> and differentiate between RAs making requests and PSTs posting updates
> based on the principle of the web service client.
> 
> Unless you want to support anonymous provisioning request, there
should
> be no problem differentiating provisioning requests from an RA from
> notifications from a PST.
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
> 
> 
> -----Original Message-----
> From: Cohen, Doron [mailto:Doron_Cohen@bmc.com]
> Sent: Monday, February 17, 2003 1:05 PM
> To: provision@lists.oasis-open.org
> Subject: RE: [provision] missing use cases?
> 
> Keep in mind though that a PST that sends a modification as client to
> the
> PSP will need to be able to indicate (for the PSP sake)  that this is
a
> notification and not  and update to the real object at the PST
> (otherwise
> the PSP may try to provision this update as if it was an RA requesting
> it) .
> In any case, I would say that this can also be an extended request of
> some
> kind unless we formalize something more structured in the specs.
> 
> Doron
> 
> Doron Cohen
> BMC Software
> 
> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Monday, February 17, 2003 7:43 PM
> To: provision@lists.oasis-open.org
> Subject: RE: [provision] missing use cases?
> 
> 
> 
> Looking at the case where there is a local change on a PST that needs
to
> get
> updated in a PSP, there are two solutions, both supportable by our
draft
> SPML spec:
> 
> 1) The PSP discovers the change using an SPML search (reconciliation).
> 2) The PST acts as client to the PSP (which acts as a server) to send
> the
> change as a modification request (serves as an asynchronous
> notification).
> 
> I do not believe that we need to add explicit asynchronous
notification
> operations at this point.
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
> 
> 
> -----Original Message-----
> From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com]
> Sent: Monday, February 17, 2003 10:55 AM
> To: provision@lists.oasis-open.org
> Subject: [provision] missing use cases?
> 
> We don't have use cases (nor operations obviously) that address
> asynchronous
> messages from the servers to the clients.  For example, a notification
> from
> a PST or PSP to indicate that a service has been suspended or deleted
> for
> some reason other than an add/delete/modify request.
> 
> Is this intentional or an oversight on our part?  If intentional, how
> would
> we address this scenario?  Discovery by the client?
> 
> Mike Polan
> IBM Canada Ltd
> 
> 
> ----------------------------------------------------------------
> 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>
> 
> ----------------------------------------------------------------
> 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>

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