Re: [v6tc] v6tc - is there life

Kurt Erik Lindqvist <kurtis@kurtis.pp.se> Wed, 17 November 2004 13:38 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28886; Wed, 17 Nov 2004 08:38:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUQ3L-0001Bm-S1; Wed, 17 Nov 2004 08:40:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPyA-0001Hf-V4; Wed, 17 Nov 2004 08:35:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPra-0000Pp-Ur for v6tc@megatron.ietf.org; Wed, 17 Nov 2004 08:28:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28226 for <v6tc@ietf.org>; Wed, 17 Nov 2004 08:28:45 -0500 (EST)
Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=laptop2.kurtis.pp.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPu0-00012E-L0 for v6tc@ietf.org; Wed, 17 Nov 2004 08:31:17 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 07F80675130; Wed, 17 Nov 2004 14:28:44 +0100 (CET)
In-Reply-To: <Pine.LNX.4.61.0411162232140.23785@netcore.fi>
References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> <Pine.LNX.4.61.0411162232140.23785@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Message-Id: <52BFDE46-3883-11D9-818C-000A95928574@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
Subject: Re: [v6tc] v6tc - is there life
Date: Wed, 17 Nov 2004 11:27:46 +0100
To: Pekka Savola <pekkas@netcore.fi>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: v6tc@ietf.org
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit

-----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
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc