I personally would welcome the sort of summary of pros/cons for each model
that Gerry proposes
Paul
>-----Original Message-----
>From: Gearard Woods [mailto:]
>Sent: Tuesday, March 11, 2003 5:12 PM
>To: Jeff Bohren
>Cc:
>Subject: RE: [provision] Simple example scenario
>
>
>
>
>
>
>Jeff,
>I just received your implementation of the scenario in the
>current approach
>and I have to admit that it looks like you've done a very comprehensive
>job. I'd like to spend some time with it over the next couple
>of days and
>perhaps it might be useful if we both summarised our
>perspectives on the
>comparitive advantages and shortcomings of each based on the
>exercise. I
>think this would benefit committee members who don't have the
>time to wade
>through a lot of XML, and would help to highlight the
>important points of
>our recent discussions with these concrete examples at our fingertips.
>Since you feel so strongly about the need for filtered
>searches, I'll post
>an updated set of examples with a filtered search to redress
>the balance
>and provide a better point of comparison.
>
>To address your confusion about suspending accounts, I think
>the problem
>comes down to misunderstandings about the schema. It appears
>to me that
>you have misinterpreted my proposed schema and arrived at the
>conclusion
>that all "subscriptions" are accounts and that the model only supports
>entities that can be suspended/locked/terminated etc. I was
>not dismissing
>the value of being able to express these notions at all, I was
>trying to
>make light of your continued misinterpretation. Personally, I feel the
>idea of state and lifecycle are very important in a provisioning model.
>You obviously feel differently but regardless, there is nothing in the
>schema that requires that these features be used. Perhaps the
>problem is
>the name subscription although I have to admit that it's hard to find a
>term that is not overloaded with even more meaning so I think
>I'll stick
>with it for now.
>
>On the general concerns expressed in your previous message, I
>want to point
>out that I appreciate what I'm asking the committee to
>consider but that
>makes this exercise no less valuable in my opinion. It's
>encouraging to me
>that the attendance at the committee meetings seems to have grown and
>includes more interested parties than even a few months ago.
>This is not
>at all surprising because of the increased profile of
>provisioning of late,
>and the entry of large interests such as IBM into the market.
>Beyond that,
>there is a real need for a solid provisioning service
>definition as we're
>all too aware. The discussion we've been having is the start
>of what, I
>imagine, will be a continued wave of questions regarding approach and
>current technology trends as the spec undergoes more scrutiny. You and
>OpenNetworks have obviously, as you have frequently pointed
>out, committed
>to DSMLv2. There are others, Tivoli among them, who have immediate
>problems that cannot be addressed by this kind of solution
>without, as I
>frequently point out, jumping through a lot of uncomfortable
>hoops. As we
>near the end of this exercise, and since you bring it up, I
>should say that
>I feel that the responsibility of the PSTC is not to Burton or
>any single
>member of the committee but to the community of consumers the PSTC's
>product. If the community is not served then any number of
>analyst events
>won't matter.
>Gerry
>
>
>
>
>
>|---------+---------------------------->
>| | "Jeff Bohren" |
>| | <jbohren@opennetw|
>| | ork.com> |
>| | |
>| | 03/10/2003 06:52 |
>| | PM |
>| | |
>|---------+---------------------------->
>
>>--------------------------------------------------------------
>----------------------------------------------------------------|
> |
> |
> | To: Gearard Woods/Irvine/IBM@IBMUS
> |
> | cc: <>
> |
> | Subject: RE: [provision] Simple example scenario
> |
> |
> |
>
>>--------------------------------------------------------------
>----------------------------------------------------------------|
>
>
>
>
>Gerry,
>
>I am not talking about returning 30 million records in a
>search response.
>That would be a search WITHOUT a filter. Which is, of course, what I am
>trying to avoid. The scalability I am referring to is the
>ability to look
>for a set of records, in a large record set, that match a specific
>criteria. This has nothing to do with directories and has
>everything to do
>with provisioning (and is one of our agreed to use cases).
>Unless you think
>that provisioning only means a client pushing data to a
>server, then this
>is a provisioning issue.
>
>Handling large data sets is an entirely different issues. The
>current SPML
>specification does not address this issue, and neither does
>your proposal.
>
>I would like nothing more than to stop talking about searches. Just
>supplement the Tiny Telecom example you posted with sample of
>a scalable
>search mechanism. For this example just assume scalable means
>to find some
>small number of accounts that satisfy a search criteria. You
>can make it as
>"Provisioning centric" as you like. Work it in any way you
>like, just show
>me how it is done.
>
>Note that all the previous paragraphs discuss provisioning.
>
>Now I am confused about suspending accounts. You created the
>ProvisioningSubscriptionState element in you proposed schema
>to represent
>the state of accounts. First you say that explicitly representing such
>things in your protocol is one of the features that makes if more
>"Provisioning Centric", and now you seem to be saying that it
>was just an
>unimportant example. Which is it? Is explicity representing
>account state
>part of your proposed protocol or not? If it is part of your
>protocol, then
>tell me how you handle things that can not be suspended (or locked, or
>terminated). This is part of the provisioning discussion you
>want to have.
>
>I do understand your concerns and I agree with many of them. But simply
>put, you have yet to convinced me that the current approach is
>unworkable,
>insufficient, or will not be adopted by the industry at large. You are
>asking me to do several things: first flush the last 6 months
>of work the
>committee has done, give up on the Burton interop, give up a
>solution that
>I have seen work in practice, and implement your proposed
>solution in the
>OpenNetwork Technologies provisioning web service (note that this
>implementation will require some sort of search capability).
>If you think
>raising these issues means I am ignoring yours, you are wrong. I will
>continue to raise these issues as they are important to the decision at
>hand.
>
>Jeff Bohren
>OpenNetwork Technologies
>
> -----Original Message-----
> From: Gearard Woods [mailto:]
> Sent: Mon 3/10/2003 5:21 PM
> To: Jeff Bohren
> Cc:
> Subject: RE: [provision] Simple example scenario
>
>
>
>
>
>
>
> Jeff,
> I should really have come up with some example other than
>suspending an
> account - we seem to be getting stuck on that. I
>am equally
>open to
> debating search behaviour but the other points
>that I'm trying
>to impress
> upon you seem to be falling on deaf ears. But
>let's address
>search anyway
> and then move on to what I consider to be more
>interesting and
>relevant
> topics. You cannot argue that the currently
>proposed search
>mechanism is
> scalable, particularly if you intend to support
>SOAP. In your
>example of a
> recon of 15-30 million records, the current
>search mechanism
>will require
> that you collect all of the results, embed them in a SOAP
>envelope, and
> return this huge data set to the client. The scalability
>issues are evident
> but I'll enumerate them: memory constraints on
>the PST or PSP
>whichever is
> performing the search; bandwidth requirements on
>the network;
>memory
> constraints again on the client that requested
>the search once
>the results
> are returned. In the spirit of cooperation, let
>me suggest
>that you
> consider RFC 2696 (but you'll need to put
>controls back in).
>
> You simply cannot claim that you have solved the search
>problem once and
> for all, that my examples haven't, and use that to justify
>ignoring my
> other complaints. I will address the implementation of
>searching in my
> proposed scenario if it comes down to it but we
>need first to
>discuss the
> model since the model is the central argument.
>First though,
>I think we
> need to dispel this argument that the problem is
>a federated
>namespace
> problem. If that were the case then I need to buy a
>meta-directory not a
> provisioning system and we are all on the wrong
>committee. It
>might be
> easy to simply say that the current proposal is a
>bottom-up
>approach and
> that I'm suggesting a top-down approach. My real
>argument is
>that we need
> to talk about provisioning and what that means in
>terms of a
>simple useful
> model that integrates well with modern web services
>technology, not how we
> simply get an attribute value from point A to point B. We
>need to address
> the problem at the right level of abstraction so that the
>foundation we
> build today will continue to meet the needs of
>the community
>when/if we go
> on to address the other apsects of a provisioning
>model such
>as
> entiltlements, policies and even simpler issues
>such as change
> notifications.
>
> I'm not out to win an argument here, I simply
>want to do the
>right thing.
> At this point I don't want to reiterate my
>apparently wasted
>arguments on
> provisioning-centric solutions because I think my
>views are
>clear. We can
> continue to talk about attributes, objectclasses,
>controls,
>DSML search
> filters etc. as much as you want. My question is
>when are we
>going to
> start talking about provisioning?
> Gerry
>
>
>
> |---------+---------------------------->
> | | Jeff Bohren |
> | | <jbohren@opennetw|
> | | ork.com> |
> | | |
> | | 03/10/2003 11:44 |
> | | AM |
> | | |
> |---------+---------------------------->
>
>>--------------------------------------------------------------
>----------------------------------------------------------------|
>
> |
>|
> | To: Gearard Woods/Irvine/IBM@IBMUS
>|
> | cc:
>|
> | Subject: RE: [provision] Simple
>example scenario
>|
> |
>|
>
>>--------------------------------------------------------------
>----------------------------------------------------------------|
>
>
>
>
>
> Gerry,
>
> Let me answer some of this with an example.
>
> In the Tiny Telecom example, the friends and
>family account
>has up to
> ten contacts that can be associated with it. Since people
>could be a
> contact for more than one person it makes sense that the
>contact could
> be an independent record. In this case creating
>the friends
>and family
> account could consist of:
>
> 1) Creating or looking up one or more contacts
> 2) Creating a friends and family account with
>references to
>the newly
> created or existing contacts
>
> This example illustrates two points. First not
>everything in a
> provisioning system is an account that can be suspended.
>Second,
> searching for existing records may be an
>important part of a
> provisioning process. Note that nothing I say in this
>paragraph has
> anything to do with directories.
>
> Finding existing contacts in a telco environment
>may require
>searching
> through millions of records. Our current filtered search
>mechanism will
> support this in a fashion that has been demonstrated to be
>scalable in
> other deployments.
>
> And of course there is the reconciliation issue
>inherent in
>enterprise
> provisioning. That requires some kind of
>parameterized query
>(filtered
> search) to be done correctly.
>
> So is some form of parameterized query (filtered search) a
>requirement?
> Not for all systems, but the spec must define it
>for where it
>is
> required or it not complete. It is certainly a
>requirement for
>our PST
> product.
>
> Could some sort of XML Query be used as a
>parameterized query
>(filtered
> search)? It's a possibility, but I would like to see an
>example before I
> could say whether it was a good solution.
>
> I am willing to keep an open mind on this and consider all
>proposed
> solutions, but I am unwilling to agree to a
>solution that does
>not
> include well thought out solution to parameterized queries
>(filtered
> searches). I would also judge such a solution on
>how well it
>meets our
> specific scalability needs (i.e. it must scale to 15-30
>million user
> populations).
>
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
>
>
> -----Original Message-----
> From: Gearard Woods [mailto:]
> Sent: Monday, March 10, 2003 2:03 PM
> To: Jeff Bohren
> Cc:
> Subject: RE: [provision] Simple example scenario
>
>
>
>
>
> Jeff,
> Although we've probably covered most of this in
>the call this
>morning, I
> imagine that we'll want to keep this thread going
>through the
>week so
> I'll
> address the questions that you have here.
>
> Filtered search I think we've agreed is made more
>difficult
>when the
> schema
> becomes more complex. My approach to this
>problem is twofold
>and I
> think
> we've touched on these before. First, if really
>required by
>the PST
> requirements and use cases then I would argue a
>solution could
>be found
> in
> one of the XML query langauges currently available.
>Alternatively, I
> would
> question the need for a full blown query language at all
>considering the
> use cases. I tend to favour this latter position
>and think
>that the use
> cases could be satisfied with a set of methods and schema
>elements
> targeted
> to querying aspects of the model. I can expand
>on this if you
>want some
> more concrete examples.
>
> PSP-PST communication doesn't differ
>significantly from RA-PSP
> communication in this approach. The model would
>be the same
>but
> obviously,
> it would be common to have the PSP support many targets.
>
> I disagree with your point about the state
>implying accounts,
>the
> enumerations seem relatively general to me. If you are
>arguing that
> they
> are not extensive enough then I would agree that there is
>probably room
> for
> more.
>
> As we discussed in the call, since we are
>satisfying the same
>use cases,
> our operations (which to me embody the use cases)
>will appear
>very
> similar.
> Where the significant difference lies is in the
>model used in
>theses
> conversations. As far as the target being semantically
>equivalent to an
> objectclass I would have to say that no, a target is a
>distinct entity.
> A
> target has identity which an objectclass does not. An
>objectclass
> implies
> type - a target encapsulates schema. I think there is a
>significant
> difference here.
>
> The current request schema message satisfies the
>query target
>schema
> uses
> cases as does the getTarget method in my example.
>
> Constraining the schema is an important point and
>here I think
>is where
> we
> diverge most in our approaches and general philosophy. I
>don't see the
> need to constrain the schema any more than LDAP
>or the current
>approach
> dictates what specific objectclasses may be used. I think
>I've argued
> before that the target schema is a contract and
>the PSP or RA
>on the
> other
> side of the relationship needs to understand the
>language of
>the
> contract,
> as identified by the schema namespace. My
>examples provide
>only for
> the
> ability to declare what schema element represents
>the type of
>the
> target.
> As I mentioned earlier too, I don't want to even
>restrict the
>schema
> language to XML-Schema. It should be possible to
>use other
>schema
> languages, a good example might be Oasis' Relax NG.
>
> The philosophical difference at the root of the schema
>argument is
> critical. My view is that the SPML should be a
>vehicle for
>the
> communication of provisioning-related
>information. This does
>not extend
> to
> constraining the target schema which should be
>opaque to the
> provisioning
> system. The SPML only provides the provisioning
>model not the
>target
> model.
> Gerry
>
>
>
> |---------+---------------------------->
> | | "Jeff Bohren" |
> | | <jbohren@opennetw|
> | | ork.com> |
> | | |
> | | 03/10/2003 04:43 |
> | | AM |
> | | |
> |---------+---------------------------->
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
> |
> |
> | To: Gearard Woods/Irvine/IBM@IBMUS
> |
> | cc: <>
> |
> | Subject: RE: [provision] Simple
>example scenario
> |
> |
> |
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
>
>
>
>
> Gerry,
>
> I am just starting to look at the scenario this
>morning, so I
>don't know
> how much of an example I can have back to you by today's
>meeting.
> Looking at it, I do have some concerns and questions.
>
> Concerns:
>
> My biggest concern is that you do not show an example of a
>filtered
> search. This scenario should include it somehow.
>
> This scenario does not show an example of the
>communication
>between a
> PSP and a PST. That should also be included.
>
> The ProvisioningSubscriptionState type implies
>that all SPML
>will be
> used for is for provisioning accounts, and
>further, that those
>accounts
> will support the enumerated states. I don't
>believe that these
> assumptions are valid or add any value.
>
> Questions:
>
> Is there any semantic difference between
>createSubscriptionRequest and
> addRequest? Likewise is modifySubscriptionRequest
>the same as
> modifyRequest and deleteSubscriptionRequest the same as
>deleteRequest?
> Using the word "subscription" would seem to imply that the
>protocol only
> supports subscriptions, what ever that means. Also, is the
>"target"
> element semantically the same as the
>"objectclass" attribute
>in the
> current spec?
>
> Your query targets concept seems to imply the
>same concept as
>the
> current SPML schema query for object classes. Is
>that correct?
>
> The type ProvisioningTargetType contains an XSD schema
>element. Is this
> intended to be completely open ended? If not how
>is it to be
> constrained?
>
>
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
>
>
> -----Original Message-----
> From: Gearard Woods [mailto:]
> Sent: Friday, March 07, 2003 5:03 PM
> To: Jeff Bohren
> Cc:
> Subject: RE: [provision] Simple example scenario
>
>
>
>
>
> Jeff,
> I'm attaching a set of documents that attempt to take that
>next step.
> As I
> said in a previous message, I'm punting on the
>filtered search
>for now
> until there is at least some feedback on the
>overall strategy
>but the
> scenario does include provisioning an e-mail
>account. To view
>the
> scenario, unzip the attached file and open
> examples/telecom/telecom.html.
> Gerry
>
> (See attached file: scenario.zip)
>
>
>
>
> |---------+---------------------------->
> | | "Jeff Bohren" |
> | | <jbohren@opennetw|
> | | ork.com> |
> | | |
> | | 03/04/2003 04:51 |
> | | AM |
> | | |
> |---------+---------------------------->
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
> |
> |
> | To: Gearard Woods/Irvine/IBM@IBMUS
> |
> | cc: <>
> |
> | Subject: RE: [provision] Simple
>example scenario
> |
> |
> |
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
>
>
>
>
> Gerry,
>
> Gerry,
>
> I suggest doing email as at least as a part; since that is
>what we
> already have examples for in the current draft
>specifications.
>It should
> not be much work to add it to what you have
>already laid out.
>
> Anyway, the next step should be for you to take
>the scenario
>you suggest
> (with an added email component) and lay out the
>specific RAs,
>PSPs, and
> PSTs and do a rough system design. It does not
>need to be in
>detail, but
> there needs to be enough information that you can do the
>examples using
> your proposed approach and I can do the examples using the
>current
> approach.
>
> There is still one concern, however. I'm not sure if this
>scenario will
> illustrate the filtered search problem. I have no problem
>doing this
> exercise, since it should be very informative,
>but I will not
>support
> changing the current data model without a corresponding
>filtered search
> solution.
>
> Perhaps as part of the provisioning process there could be
>some searches
> done for possible pre-existing similar accounts
>at the service
> providers?
>
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
>
>
> -----Original Message-----
> From: Gearard Woods [mailto:]
> Sent: Tuesday, March 04, 2003 2:20 AM
> To: Jeff Bohren
> Cc:
> Subject: RE: [provision] Simple example scenario
>
>
>
>
>
> Jeff,
> I was hoping to take on something a little more
>substantive
>but go deep
> rather than wide. In other words, rather than
>illustrate the
>use of
> each
> of the operations, I'd like to go through the
>steps and data
>formats
> that
> you would realistically expect to see used to describe a
>target (or set
> of
> targets) and provision it, including the SOAP
>messages if you
>think
> that's
> appropriate. I don't want to burden you with a
>lot of work or
>anything,
> I
> just want to show what each would look like soup
>to nuts, so
>to speak.
>
> I realise that this kind of thing takes time. If
>you feel it
>should be
> less detailed then let's simplify it but I'd
>rather not make
>it too
> simple.
> The important aspects to me are:
> - The use of schema since that's one of the
>hotspots in our
> conversation.
> Obviously there are elements in this scenario
>that work in my
>favour
> including cardinality, enumerations, formatted strings and
>complex types
> but since those come up in real life I think that's fair.
> - The overall message passing sequence and
>content. It's not
>clear to
> me
> which approach would be more chatty or more
>verbose in a real
>life
> situation. Also, this might clarify some of the
>implementation
> difficulties since we were debating the level of
>complexity
>for an
> implementation.
> - The composite or aggregate abilities of each solution.
>
> Would adding an e-mail service to the phone
>account be enough
>do you
> think?
> Gerry
>
>
>
>
>
>
> |---------+---------------------------->
> | | Jeff Bohren |
> | | <jbohren@opennetw|
> | | ork.com> |
> | | |
> | | 03/03/2003 07:21 |
> | | PM |
> | | |
> |---------+---------------------------->
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
> |
> |
> | To: Gearard Woods/Irvine/IBM@IBMUS,
>
> |
> | cc:
> |
> | Subject: RE: [provision] Simple
>example scenario
> |
> |
> |
>
>
>>--------------------------------------------------------------
>---------
> -------------------------------------------------------|
>
>
>
>
> Gerry,
>
> We use the hosted email service example
>throughout the spec
>document, so
> it
> would be a good idea to work that into the
>scenario. Perhaps
>it can be
> an
> email service that is accessable from the handset.
>
> Jeff Bohren
>
> -----Original Message-----
> From: Gearard Woods
>[mailto:]
> Sent: Mon 3/3/2003 5:09 PM
> To:
> Cc:
> Subject: [provision] Simple example scenario
>
>
>
>
>
>
>
> Further to our discussion in the
>conference call
>today, I'd
> like to suggest
> the following scenario as a starting
>point for a
> comparitive
> study of the
> current SPML and the alternative
>approach that we
>have been
> debating. Any
> changes, improvements or comments
>are, of course,
>welcome.
> Gerry
>
> Tiny Telecom provides mobile phone
>services to
>California
> residents. In
> addition to the five types of basic
>account that
>Tiny
> offers:
> personal,
> personal anytime, family, corporate,
>and prepaid,
> subscribers
> are offered a
> full range of options which are
>generally handled
>by Tiny's
> partners or
> subsidiaries. These options include
>voice mail,
>caller ID,
> call
> forwarding, text messaging, web access,
>long-distance,
> handset
> options, and
> a comprehensive friends and family
>calling plan.
>To create
> a
> basic
> account, Tiny requires the subscriber's full
>name, a user
> name, a credit
> card number (and expiration), and a valid
>California
> driver's
> license
> number. Subscribers may also
>provide an e-mail
>address for
> notification of
> changes in the account policy or for opt-in
>notification of
> special offers
> from partners. Basic plans have a
>two year term
>and for a
> limited time all
> new accounts receive free caller ID
>as part of a
>promotion
> by
> one of Tiny's
> partners.
>
>
> The friends and family plan is one
>of the most
>popular
> options
> and allows
> subscribers to select a set of 10
>contacts that
>may be
> called
> at a
> significant discount. To identify these
>contacts,
> subscribers
> are required
> to provide their names and phone numbers.
>
>
> Tiny has implemented a provisioning
>service that
>manages
> their
> basic
> accounts and also allows partner
>services to be
> provisioned.
> A typical
> usage scenario for the service is the
>implementation of the
> self-service
> facility on Tiny's website. This facility is
>implemented
> as a
> Java servlet
> that is a client of the provisioning
>service and
>goes
> through
> the following
> sequence of operations:
> 1. Offer the user a selection of
>provisionable
>services
> offered by Tiny and
> partners
> 2. Query the schema of the services requested
> 3. Present a form allowing the user
>to enter the
>required
> and
> optional
> fields
> 4. Submit the provisioning request for the
>services
> 5. Notify the user of the success or
>failure of
>the request
>
>
> For the purposes of this scenario,
>assume that
>the
> subscriber
> requests
> voice mail, text messaging, and
>lists two family
>members in
> the friends and
> family plan. The user also selects
>the default
>handset
> which
> they will
> receive by mail. When the account
>is activated,
>a password
> is
> automatically assigned to access voice mail.
>Before the
> phone
> is received
> by the user, they return to the self-service
>website to
> check
> the status of
> the request. The self-service
>facility allows
>the user to
> retrieve details
> of the account which now reflects
>the fact that
>an account
> has
> been
> activated, provides access to the voicemail
>password, and
> notifies the user
> that the request for text messaging has been
>denied for
> technical reasons.
>
>
>
>
>----------------------------------------------------------------
> 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>
