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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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


Subject: Re: Ballot Attached - Group 3: Sessions


>>>>> "JH" == Jeff Hodges <jhodges@oblix.com> writes:

    JH> rationale: I believe this is subsummed within the topic of
    JH> [UC-3-1:UserSession] and we should deal with it explicitly in
    JH> that context.

    JH> [...]

    JH> rationale: I believe this is subsummed within the topic of
    JH> [UC-3-1:UserSession] and we should deal with it explicitly in
    JH> that context.

    JH> [...]

    JH> rationale: I believe this is subsummed within the topic of
    JH> [UC-3-1:UserSession] and we should deal with it explicitly in
    JH> that context.

    JH> [...]

    JH> rationale: I believe this is subsummed within the topic of
    JH> [UC-3-1:UserSession] and we should deal with it explicitly in
    JH> that context.

Jeff,

So, I'm kind of confused by this rationale. What do you mean by "that
context"? Do you expect that the use case and requirement that were
presented in UC-3-1:UserSession should be re-edited? My understanding
is that we enter the scenario and requirement as stated.

It seems to me that the process we are going through is breaking down
large conceptual spaces (like "user session") into smaller votable
items. You seem to be indicating some movement in the opposite
direction, but I can't see how that would work.

In the process we have in place now, if we want to add further
requirements, aren't we just going to have to go back through another
round of issue proposal, championing, editing and voting again?

I guess I'm just wondering what the point was. I could understand if
you didn't like the reqts as stated, or didn't think they had
technical merit, but it seems like your rationale is based on a
process I don't quite comprehend.

As it stands now, we have 4 semi-orphaned requirements that aren't
going in to SM3, and a use case scenario with a number of new terms
that aren't supported by the requirements.

~ESP


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


Powered by eList eXpress LLC