Subject: RE: [v6tc] v6tc - is there life

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Thu, 18 Nov 2004 09:44:31 +0100

I think that it is important to have scenario specific sections where the
finer points of the various requirements vis-à-vis the individual deployment scenario,
can be addressed in a coherent manner -
otherwise I am afraid that we loose the big picture, deployment wise.

We could under each requirement in the general requirements section
list the applicability of the requirement in the various scenarios -
like "applicable for Scenario x, Section ?.?, Scenario y etc."

As such I generally agree with the outline proposed by Pekka.

Another issue. I have some problems with SHOULD and MAY requirements.
I would much rather stick with must-only requirements, perhaps with the addition 
that a certain feature (requirement) possibly could be profited from in this and that
deployment scenario. I do not see the point in having SHOULD requirements and in general
I do not see the point in using the words MUST, SHOULD and MAY in a requirement document.

BR, Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kurt Erik Lindqvist
> Sent: Wednesday, November 17, 2004 11:28 AM
> To: Pekka Savola
> Cc: [email-masked]
> Subject: Re: [v6tc] v6tc - is there life
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 2004-11-16, at 21.33, Pekka Savola wrote:
> 
> > On Tue, 16 Nov 2004, Tim Chown wrote:
> >> I think the single doc should be split into
> >>
> >> Intro
> >> Assumptions
> >> Requirements (all)
> >> Scenarios (including 3gpp)
> >>
> >> with the Scenarios stating which requirements are applicable, and 
> >> whether
> >> the requirements are may/should/must.
> >>
> >> We shouldn't repeat the "confusion" of scattering 
> requirements in the
> >> scenarios text.
> >
> > What would you feel about putting the scenario-specific 
> justifications 
> > inside the requirements, so that the requirements would be better 
> > grounded in the reality?
> >
> 
> I like Tim's approach above. I think that would give a easy 
> to read and 
> clear document.
> 
> - - kurtis -
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> 
> iQA/AwUBQZsnqKarNKXTPFCVEQLfHACglcgohp1XjqLaOUu3g9k6zwjPFCsAn1gs
> AGNzz7gknfsuz4Rzz/ffsLEK
> =8u0f
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> v6tc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/v6tc
> 

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Nov 2004 10:53:17 +0200 (EET)

On Thu, 18 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> Another issue. I have some problems with SHOULD and MAY 
> requirements. I would much rather stick with must-only requirements, 
> perhaps with the addition that a certain feature (requirement) 
> possibly could be profited from in this and that deployment 
> scenario. I do not see the point in having SHOULD requirements and 
> in general I do not see the point in using the words MUST, SHOULD 
> and MAY in a requirement document.

I think it's useful to be able document those features which we think 
really must be in the solution, as must, but also be able to express 
those features we'd really, really like to see in the solution if 
that's feasible from the solution's point of view, as "should". 
Otherwise the result is either: 1) too few requirements to make a 
realistically usable solution in all the scenarios, or 2) elevating of 
too many 'should' statements to musts.

The usefulness of "may" requirements comes not that they're mays, but 
from the fact that the reader sees that those requirements have been 
considered and they are NOT shoulds or musts.  That could be 
accomplished as a non-requirements section as well, of course. I don't 
have personally a strong opinion on what to do with these, removing 
them would be OK by me.

I agree that uppercase keywords shouldn't be used, unless we define 
when those mean ourselves.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Nov 2004 10:08:55 -0800

> I do not see the point in using the words MUST, SHOULD and MAY in a 

Karen,

I remember Brian Carpenter strongly advising us to use the term goal 
instead
of requirements and remove the uppercase normative language.

I makes sense to focus on what is really needed. However, if there are 
"really nice to have" things,
it might make sense to mention them as such.

	- Alain.

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 18 Nov 2004 20:38:07 +0200

Hi,

I agree with Alain. Let's not use normative text and have "goals"
instead of requirements. The documents should be guiding of nature - not
stating hard requirements.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]