OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-leaders message

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


Subject: Re: Use case doc handoff


At 11:38 AM 2/22/01 -0800, Darren Platt wrote:
>How will we determine the point where the use case and requirements subgroup
>turns over its doc to the other groups?  There are some who feel the use
>case subgroup's job is done at some point once the other groups have begun
>working.  There are others who feel there is some kind of maintenance mode
>that follows.    Others still think it should stay active.

I've been assuming that our TC will definitely publish a requirements 
document (or a requirements section of the SAML spec?), which means that 
there will be a document that needs care and feeding over time.  In keeping 
with Bob B.'s suggestion about subgroups "owning" pieces of documents, I 
think it would be a good idea to keep the use-case group "on reserve" to 
assess any comments that come in on the requirements document/section, and 
to attempt to do the traceability I described on the phone.  The workload 
probably won't be zero, nor will it be as heavy as the last few weeks have 
been.

On the idea of a requirements document vs. requirements section, I prefer 
the former because:

- Requirements and use cases are non-normative, and it's better not to
   fill a spec with non-normative stuff when you can just point to it

- It allows us to publish a relatively "whole" work product as soon as
   possible to the public, so we can get feedback and keep the momentum
   going

Does all this sound sensible, or am I missing something big?

>On a related note, I think at one point I suggested to the use case mailing
>list that our issue resolution process might be valuable to the TC at large
>after straw man 3 and/or the face to face.  I want to make sure that I was
>clear that my thought here was that Eve would take over the process at some
>point - whenever the TC as a whole deemed the group's work to be 'ready' (my
>first question, above) - as it could be effectively controlling the scope of
>our work.  I'd imagine that the issues that come up will be more and more
>implemenation specific (as opposed to requirement-oriented) as well.  I'd
>imagine a continuum of issues coming up, really, gradually moving from
>requirements to implementation details.  So I thought that maybe if we had a
>requirements issue resolution process with a little forward inertia, maybe
>it would save us some time as we widen the audience.

If I'm understanding correctly, you're asking whether the process you've 
developed for handling use-case issues could be suitable for other issues 
that come up on other SAML sections.  I'm pretty sure that it could.  Each 
subgroup will be a natural home for collecting issues on the spec section 
they own, but I agree that for a decision on an issue to be "official" it 
needs to be made by the TC as a whole.

If instead you're asking about the proper disposition of the *actual 
issues* you've come up with, I'm thinking that if we don't get through all 
the use cases/requirements/issues emanating from your subgroup on 2 March, 
we should make the next bunch of meetings be an extension of the F2F, where 
we continue to hear your subgroup's recommendations and consider them as a 
series of motions.

Hope this helps,

         Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com



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


Powered by eList eXpress LLC