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: Inputs to Strawman/Issue List - Group 2: B2B Scenario Variati ons




> -----Original Message-----
> From: Evan Prodromou [mailto:evan@outlook.net]
> Sent: Tuesday, February 27, 2001 1:05 PM
> To: UseCaseList
> Subject: Re: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> Variations
> 
> 
> >>>>> "OD" == Orchard, David <dorchard@jamcracker.com> writes:
> 
>     OD> There's options missing from each issue:
>     OD> x) Drop this issue/scenario/requirement
>     OD> y) Seek further clarification
> 
> If you check the issues list, you'll see that when I added these use
> cases the option "Don't add this requirement" is included. I think
> Zahid read the "Potential Resolutions" in the parliamentary sense,
> e.g. "We, the Use Case and Requirements Subcommittee, do hereby
> resolve....". Whereas I've taken it to mean -- and I think you meant
> originally -- "Here's a list of things we can do to fix this problem."
> 

Cool.
> I find the "seek further clarification" option kind of lame. I mean,
> shouldn't we be clear before we go to a vote? If someone isn't clear
> on an issue, then they should ask for clarification from the issue
> champion before it even gets to the voting stage.
> 

It's really clear from our first round of voting that this hasn't happened.
An awful lot of the issues seemed to have been voted on and with additional
comments.  Thus this gives the voters a chance to say that it hasn't been
clearly thought through enough.  

>     OD> What I suggest is that the scenarios you propose should have
>     OD> some clearly delineated sections so that we could vote on
>     OD> portions. 
> 
> It'd be nice if we could try to maintain a one-vote-per-issue
> effort. If there is more than one vote, then there should be more than
> one issue. There's nothing holy about the issue numbers and names.
> 

I agree, I suggest a each votable section should be an issue/requirement.

<snip/>

> 
>     OD> On the session mgmt, I broke them up - the general notion of
>     OD> session management - and specific step sets.  Some people
>     OD> wanted session with timeouts, some wanted session with
>     OD> logouts, some wanted session with logouts and timeouts.
> 
> ? My take away from your rewrite of Group 3 was that sessions were a
> monolithic concept, and that doing separate requirements for logout,
> timeout, and etc. were not required. Let me quote:
> 
>         "ISSUE:[UC-3-03:Logout] Should SAML support transfer of
>         information about logout (e.g., a principal intentionally
>         ending a session)? [DavidO: Isn't this covered in UC-3-1? I've
>         kept here for backwards compatibility]"
> 
> So I'm not sure I get your point.
> 

There is a difference between my earlier opinion, what is expressed in the
document, and my current opinion.  I followed the instructions from Darren
that said keep the issues as they were.  It turns out this was the right
thing to do (IMHO) and my comment in UC-3-03 is simply wrong.  The
instructions that Darren gave me were spot on.  In particular, keeping
3-1,3-3, and 3-5, allowed people to vote for the concept, then for
particular aspects of the concept.  Which was very good.  


> ~ESP
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org
> 


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


Powered by eList eXpress LLC