[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
-----Original Message-----
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. -----------------------------------------
|
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