[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Agenda for Security Services TC 20 March 2001 telecon/Comments onUC Domain Model
I'm really pleased about the level of comments I've been seeing on the models. It feels like we're getting somewhere good! Thanks to Krishna for making some specific doc suggestions below. Here are some responses from me (chair hat mostly off). At 03:53 PM 3/17/01 -0800, Krishna Sankar wrote: > 0. The top-level/driving document would be the Architecture >Document(a.k.a.Core group V model) Keep in mind that at F2F #1, we agreed to put an "architectural model" chapter before the Core Assertions chapter. The conceptual/model information is global to the entire specification. > 1. The UC Domain Model should contain the sum of all actors > and all relevant entities from the use cases. So you're suggesting that the UC Domain Model should be the "base" on which we should work, to reflect any modifications suggested by the other diagrams? We can see how the group feels about this today. > 2. It also should contain *ALL* the assertions which are > exchanged between these entities. As Hal/David pointed out, this gives us > all the assertions we need to model. > > 3. Then the Hal/David diagram would be added to Section 3. > of the >Architecture document (a.k.a. Group V Model) > 3.a. At this point, we would need to have a single glossary, and >definitions. I agree about folding all definitions together. I have to say I also agree with the several comments (and the F2F #1 instructions) suggesting that the glossary should get rid of peripheral terms. I'll post my belated suggestions along these lines in a moment. > 4. We would need to add text to define and explain the > relationships and the assertions at an Architecture level in Section 3. > The current Section 4 would be consumed as a sub-section here. I'd want to move some of the Section 3 stuff into the "conceptual chapter." I suspect that Chapter 4 (Constraints) should become part of the separate Requirements document! > 5. The protocol section (a.k.a Protocol group model) > (Section 5) then elaborates the protocol for these exchanges, including > the acks and other biz signals, as required. (Now I see the rationale > behind the two groups merge more clearly (duh !)) I tend to agree with this. The Protocol chapter can introduce a few more concepts that are specific to its layer. > 6. We would need to merge the Model sub-section of the > protocol group document in Section 2/3 of the Architecture Document. The > Architecture doc now does not have the concept of security domains and so > we should be >able to do a straightforward merge. > > 7. The data structures in the Protocol group Model document > (model section) need to be reconciled with the assertions in the UC > domain model. After all, we are concerned about these data structures and > their manifestation. We'll be discussing this today: Should we pick one model as a base, and modify to incorporate all the good ideas of the others? Or is it useful to have multiple "views"? (After doing a more thorough review, I tend to agree that folding into a single one is a good idea.) > 8. Of course, we would merge the Group V model and example > documents. Yes, I would think so. > 9. At this point, we should have one combined document, > which could be version 0.1 of the SAML specification. We should all (in our subgroups and otherwise) be working towards contributing fresh sections to Bob Blakley so that we have a new SAML draft ready to review at F2F #2. I suspect that we'll be coming out with drafts more often after that point. > 10. To tell the truth, now I am totally confused ;-) Hope it > all make sense Not too bad! :-) > 11. I am sure all of us would have the documents in front of > us during the con call. I will also have a printed copy and could mark-up > the changes as the discussion progresses. (Not a good idea for all of us > to print copies - too many dead trees ;-0) Since you'll be the designated "backup secretary" for Heather (as she's in a weird time zone for the call), you'll have the opportunity to do just that, and thanks for the offer. Note that if the TC votes on any specific changes to documents owned by subgroups, they will be responsible for the changes. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC