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] Latest Draft Use Cases


Comments in line.

 

I have attached the latest draft with all to date received comments.  If there are no more, I propose publishing this on the public site.

 

Darran Rolls  
MSIM  drolls_waveset@hotmail.com
AIM    drollswaveset
YIM    drolls_waveset
http://www.waveset.com/
drolls@waveset.com

 

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Thursday, May 23, 2002 3:54 PM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Latest Draft Use Cases

 

Colleagues - Some comments ...

 

1. I suggest putting the glossary up front and limiting it to just those terms that are unique to our domain.  There is no need to provide definitions for XML, User, System, Subject, SPML, Service, Security, Resource, Organization, End-user, External enterprise, Credential, Identity (twice), Attribute, Actor, Administrator.  The common English usage is fine.  The text uses the term "target".  So, delete the terms "resource", "managed resource", "account" and "operating system account".  PSP-ID is not used in the text.

 

Does anyone have any objection to moving the glossary and deleting the “out of domain” items as Tim suggests?

 

I have been through the document and tried to use “target” more consistently.

 

2. Is there confusion between vId and PSU-ID?  Surely a single term will suffice here.  If so, PSU-ID seems clearer.  The discussion of identifiers sometimes gets confusing.  The point is (surely) that the specification will not require use of a single common namespace.  Rather entities are allowed to choose namespaces and names by local bilateral agreement.  So uniqueness exists only within those local agreements.  The entity that enforces uniqueness has to be identified.  Sometimes it is the RA, sometimes the PSP and sometimes it is the PST.

 

There is no contention, just errors in the document.  The Provisioning Service User (Identity) is the definitive article.  I have fixed this.

 

3. On line 126 (and other similar locations), suggest using "relationship", instead of "model".

 

          Done.

 

4. On line 143, suggest adding "In this use case, the PSP chooses the PSU-ID."

 

          Agreed but worded slightly differently.

 

5. In Use Case 5, add PST to Actors section.

 

I have somewhat deliberately left out the PST as an actor for the RA sourced use cases.  In the context of the protocol, UC 5 outlines the interaction between the RA and the PSP.  Yes subsequent activity is required between the PSP and the PST in order to complete the request but this is expressed in a separate use case and is now referenced appropriately.

 

6. On line 241, replace "The requested PSU exists managed by PSP" by " PSU-ID exists in the PSP".

 

Done.

 

7. Line 246 is not clear.

 

Re worded to be “PSU-ID that the new PSTD-ID will be related to”

 

 

8. On line 255, replace "PSP updates internal model to map PSTD-ID to PSU-ID" by "PSP updates record mapping PSTD-ID to PSU-ID"

 

Done

 

9. In Use Case 6, add PST to Actors section.

 

See 5 above.

 

10. In line 273, replace "The requested PSU exists managed by PSP" by "PSU exists in the PSP"

 

Done

 

11. In line 282, it is not clear why the RA has to deal with the PSTD-ID.  Surely, it should deal only in PDU-IDs.

 

In this case the PST itself is generating the PSTD-ID.  282 allows the RA to be notified of what could well be the account ID generated on the requested target. 

 

12. In lines 276 to 283, exchanges between the RA and PSP are missing.

 

Corrected.

 

13. In Use Case 7, add PST to Actors section.

 

See 5 above.

 

14. In lines 306 to 313, exchanges between the RA and PSP are missing

 

Corrected

 

15. In line 309, delete " 1.c. PST"

 

Whilst I agree that the PST should be identifiable from the PSTD-ID but I’d rather leave the PST in there (for now) so it’s very clear.

 

16. In line 345, clarify to whom the PSTD-ID is unique.

 

Done

 

17. In Use Case 11, clarify whether the PSTD-ID is deleted, or just the PSTD

 

Done

 

18. In line 457, replace "PR-ID status check is for" by "PR-ID for the request whose status is being checked"

 

Done

 

19. In line 458, explain what "operation type" is

 

Added “Operation type (e.g.  RA-PSP Add)”

 

20. In Use Case 20, consider using XACML for the filtering function

 

Interesting.  We need to discuss this further. I’ll add an item to the issues list.

 

21. In line 504, delete "therefore", it is tautological.

 

Done

 

22. In line 526, delete "to"

 

Done.

 

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

 

-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com]
Sent: Wednesday, May 22, 2002 12:28 AM
To: provision@lists.oasis-open.org
Subject: [provision] Latest Draft Use Cases

Folks

 

Attached is the latest draft of the SPML use cases.  I have incorporated the discussion and comments from the last meeting.  I hate to send everyone their own copy (like I have) but I don’t want to put it on the site until it looks close.

 

The attached is basically a first cut editors draft.  I’d like to set a deadline of end of day 6/28/2002 for comments, changes and issues, with the intention of publishing on the site 6/30/2002.

 

Thanks

 

Darran Rolls  
MSIM  drolls_waveset@hotmail.com
AIM    drollswaveset
YIM    drolls_waveset
http://www.waveset.com/
drolls@waveset.com

 

Attachment: SPML Use Cases Draft v03.doc
Description: SPML Use Cases Draft v03.doc



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


Powered by eList eXpress LLC