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


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.
 
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.
 
3. On line 126 (and other similar locations), suggest using "relationship", instead of "model".
 
4. On line 143, suggest adding "In this use case, the PSP chooses the PSU-ID."
 
5. In Use Case 5, add PST to Actors section.
 
6. On line 241, replace "The requested PSU exists managed by PSP" by " PSU-ID exists in the PSP".
 
7. Line 246 is not clear.
 
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"
 
9. In Use Case 6, add PST to Actors section.
 
10. In line 273, replace "The requested PSU exists managed by PSP" by "PSU exists in the PSP"
 
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.
 
12. In lines 276 to 283, exchanges between the RA and PSP are missing.
 
13. In Use Case 7, add PST to Actors section.
 
14. In lines 306 to 313, exchanges between the RA and PSP are missing
 
15. In line 309, delete " 1.c. PST"
 
16. In line 345, clarify to whom the PSTD-ID is unique.
 
17. In Use Case 11, clarify whether the PSTD-ID is deleted, or just the PSTD
 
18. In line 457, replace "PR-ID status check is for" by "PR-ID for the request whose status is being checked"
 
19. In line 458, explain what "operation type" is
 
20. In Use Case 20, consider using XACML for the filtering function
 
21. In line 504, delete "therefore", it is tautological.
 
22. In line 526, delete "to"
 
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

 



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


Powered by eList eXpress LLC