From v6tc-bounces@ietf.org Fri Nov 12 09:22:07 2004 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 JAA05345; Fri, 12 Nov 2004 09:22:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScKt-00013J-5o; Fri, 12 Nov 2004 09:23:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScDY-000405-3i; Fri, 12 Nov 2004 09:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc5Q-00024x-Vl for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 09:07:37 -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 JAA03974 for ; Fri, 12 Nov 2004 09:07:34 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSc6m-0000fd-Sv for v6tc@ietf.org; Fri, 12 Nov 2004 09:09:02 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACE6sZ20388 for ; Fri, 12 Nov 2004 16:06:57 +0200 Date: Fri, 12 Nov 2004 16:06:54 +0200 (EET) From: Pekka Savola To: v6tc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [v6tc] v6tc draft charter discussion X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi, (If folks don't mind, I'll try to ensure that the process is moving forward until WG chair(s) is appointed or someone else steps up..) Find below the v6tc draft charter which was discussed at the meeting. I made two changes at this point: - shifted the first milestones forward a bit - tried to clarify point 1). Note that this was just meant to say that we would find a "rough approach" how to move forward (L2TP, an existing tunnel server protocol, ...) -- not that we decide the actual solution (detailed proposal) yet. Does this make sense? - I removed the end-point discovery *solution* documents from the input document list, because apparently that was causing confusion, as people also wanted all the other solutions on that list. Comments? Suggestions? ....? I think we should try to get the charter in a reasonable shape within a week or so. ..... IPv6 Tunneling Configuration (v6tc) WG ====================================== [...] (On Internet Area) Description of Working Group: IPv6 Operations working group has identified and documented IPv6 transition scenarios where the existing, standardized solutions are not sufficient. In particular, the solution for scenarios where an IPv6 connectivity provider is helping the customers to set up a tunnel needs to be specified. Work has already started in identifying the precise goals/requirementsfor the solution. The action items for the WG are: (1) Based on the input documents, gain rough consensus on at most *one* to-be-standardized approach to fit these goals. (2) Work on two components of the solution: a) method to discover the tunnel end-point; and b) the specification of the tunnel set-up protocol. Publish the results on Standards Track. (3) Document the goals and tradeoffs of analysis for 2) as Informational RFCs. Any other tunneling mechanism or any other activity is out of the scope of this very focused WG. List of documents to be used as input to the WG: http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt draft-ietf-v6ops-assisted-tunneling-requirements-01.txt draft-palet-v6ops-tun-auto-disc-02.txt Goals and Milestones: Nov 2004 Update the documents on goals/tradeoffs Dec 2004 Gain consensus on the rough approach for the solution Dec 2004 Get initial individual submissions for solutions Feb 2005 Submit the solution as WG I-D Jun 2005 WG last call on the solution document Aug 2005 Submit the protocol specification to the IESG for Proposed Standard Aug 2005 Submit the documents on goals/tradeoffs to the IESG for Informational RFCs Sep 2005 Shut down or recharter _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 09:59:37 2004 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 JAA08641; Fri, 12 Nov 2004 09:59:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScvC-0001zI-4D; Fri, 12 Nov 2004 10:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScsO-0005WJ-SH; Fri, 12 Nov 2004 09:58:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScfg-0002fa-Ug for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 09:45:04 -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 JAA07628 for ; Fri, 12 Nov 2004 09:45:02 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSch4-0001ey-Mh for v6tc@ietf.org; Fri, 12 Nov 2004 09:46:31 -0500 Received: from [130.129.135.232] ([130.129.135.232]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000579472.msg for ; Fri, 12 Nov 2004 15:50:13 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 12 Nov 2004 09:43:35 -0500 Subject: Re: [v6tc] v6tc draft charter discussion From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Fri, 12 Nov 2004 15:50:13 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.135.232 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6tc@ietf.org X-MDAV-Processed: consulintel.es, Fri, 12 Nov 2004 15:50:13 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hi Pekka, all, I don't mind ... actually I was tempted to start some noise yesterday already, but I wondered if somebody will complain about me ;-) In principle I think I agree with your 1st two suggestions, but not sure if it makes sense removing the solution documents, in the sense that those are to be used as inputs only. We aren't at this time proposing to take them as WG items or whatever like that, but just to note that there are some proposals in the table, that of course, could evolve, depending on the analysis and requirement documents. Next week we will try to get an update of draft-palet-v6ops-tun-auto-disc-02.txt It will be nice if the folks can read it and provide any new inputs ! Regards, Jordi > De: Pekka Savola > Responder a: v6tc-bounces@ietf.org > Fecha: Fri, 12 Nov 2004 16:06:54 +0200 (EET) > Para: v6tc@ietf.org > Asunto: [v6tc] v6tc draft charter discussion > > Hi, > > (If folks don't mind, I'll try to ensure that the process is moving > forward until WG chair(s) is appointed or someone else steps up..) > > Find below the v6tc draft charter which was discussed at the meeting. > I made two changes at this point: > - shifted the first milestones forward a bit > - tried to clarify point 1). Note that this was just meant to say > that we would find a "rough approach" how to move forward (L2TP, an > existing tunnel server protocol, ...) -- not that we decide the actual > solution (detailed proposal) yet. Does this make sense? > - I removed the end-point discovery *solution* documents from the > input document list, because apparently that was causing confusion, as > people also wanted all the other solutions on that list. > > Comments? Suggestions? ....? > > I think we should try to get the charter in a reasonable shape within > a week or so. > > ..... > > IPv6 Tunneling Configuration (v6tc) WG > ====================================== > [...] (On Internet Area) > > Description of Working Group: > > IPv6 Operations working group has identified and documented > IPv6 transition scenarios where the existing, standardized > solutions are not sufficient. > > In particular, the solution for scenarios where an IPv6 > connectivity provider is helping the customers to set up a > tunnel needs to be specified. > > Work has already started in identifying the precise > goals/requirementsfor the solution. > > The action items for the WG are: > > (1) Based on the input documents, gain rough consensus on at most > *one* to-be-standardized approach to fit these goals. > > (2) Work on two components of the solution: > a) method to discover the tunnel end-point; and > b) the specification of the tunnel set-up protocol. > > Publish the results on Standards Track. > > (3) Document the goals and tradeoffs of analysis for 2) > as Informational RFCs. > > Any other tunneling mechanism or any other activity is out of the scope of > this very focused WG. > > List of documents to be used as input to the WG: > > http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01. > txt > draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt > draft-ietf-v6ops-assisted-tunneling-requirements-01.txt > draft-palet-v6ops-tun-auto-disc-02.txt > > Goals and Milestones: > > Nov 2004 Update the documents on goals/tradeoffs > Dec 2004 Gain consensus on the rough approach for the solution > Dec 2004 Get initial individual submissions for solutions > Feb 2005 Submit the solution as WG I-D > Jun 2005 WG last call on the solution document > Aug 2005 Submit the protocol specification to the IESG for Proposed Standard > Aug 2005 Submit the documents on goals/tradeoffs to the IESG > for Informational RFCs > Sep 2005 Shut down or recharter > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 10:30:47 2004 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 KAA12596; Fri, 12 Nov 2004 10:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdPM-0002hi-2q; Fri, 12 Nov 2004 10:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdEQ-0007lG-Lq; Fri, 12 Nov 2004 10:20:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdAc-00060k-9O for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 10:17:02 -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 KAA11326 for ; Fri, 12 Nov 2004 10:16:59 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdBq-0002Of-F2 for v6tc@ietf.org; Fri, 12 Nov 2004 10:18:28 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 25AC388194; Fri, 12 Nov 2004 16:16:42 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06533-02; Fri, 12 Nov 2004 16:16:40 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 8255788035; Fri, 12 Nov 2004 16:16:40 +0100 (CET) Subject: Re: [v6tc] v6tc draft charter discussion From: Jeroen Massar To: Pekka Savola In-Reply-To: References: Organization: Unfix Date: Fri, 12 Nov 2004 16:16:38 +0100 Message-Id: <1100272598.22942.29.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1975688309==" Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 --===============1975688309== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eb/XGhWS+kVQjiKM2y/Y" --=-eb/XGhWS+kVQjiKM2y/Y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-11-12 at 16:06 +0200, Pekka Savola wrote: > Hi, >=20 > (If folks don't mind, I'll try to ensure that the process is moving=20 > forward until WG chair(s) is appointed or someone else steps up..) Pekka, you are already doing a great job for v6ops, and as this WG is a spin-off and mostly related to v6ops it would be IMHO a good idea to have the same chairs, so that they can better overview the work. Of course, if you have the time etc to do it. > (1) Based on the input documents, gain rough consensus on at most > *one* to-be-standardized approach to fit these goals. >=20 > (2) Work on two components of the solution: > a) method to discover the tunnel end-point; and > b) the specification of the tunnel set-up protocol. psst, you forget: c) The specification of the tunneling protocol (when it is a new one) also I assume with "set-up" you mean "optional negotiation and configuration". Greets, Jeroen --=-eb/XGhWS+kVQjiKM2y/Y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBlNPWKaooUjM+fCMRAr4LAJ9hR9jyEQOmkNYyd0wqwT5bU9g+1gCfYp8i YvI/UqIFowKNv9of6ElNe+k= =+a/G -----END PGP SIGNATURE----- --=-eb/XGhWS+kVQjiKM2y/Y-- --===============1975688309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc --===============1975688309==-- From v6tc-bounces@ietf.org Fri Nov 12 10:48:00 2004 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 KAA13988; Fri, 12 Nov 2004 10:48:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdg0-00033v-RP; Fri, 12 Nov 2004 10:49:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdPW-0001wD-Le; Fri, 12 Nov 2004 10:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdKq-0000w4-Rq for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 10:27:36 -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 KAA12461 for ; Fri, 12 Nov 2004 10:27:34 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdMD-0002du-Uy for v6tc@ietf.org; Fri, 12 Nov 2004 10:29:03 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACFR1M22478; Fri, 12 Nov 2004 17:27:01 +0200 Date: Fri, 12 Nov 2004 17:27:01 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ Subject: Re: [v6tc] v6tc draft charter discussion In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Fri, 12 Nov 2004, JORDI PALET MARTINEZ wrote: > In principle I think I agree with your 1st two suggestions, but not sure if > it makes sense removing the solution documents, in the sense that those are > to be used as inputs only. We aren't at this time proposing to take them as > WG items or whatever like that, but just to note that there are some > proposals in the table, that of course, could evolve, depending on the > analysis and requirement documents. Those drafts certainly aren't removed from consideration in any way. This was just done to recognize that any list which would be shorter than about 5 different proposals would be incomplete, and it seems to make sense not to call out (only some of) the proposals in the charter. The only use in the charter would be showing that "yes, we've thought about the solutions as well". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 10:57:24 2004 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 KAA14620; Fri, 12 Nov 2004 10:57:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdp8-0003GA-5O; Fri, 12 Nov 2004 10:58:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdf8-0005jB-3y; Fri, 12 Nov 2004 10:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdS2-0002qt-8h for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 10:35:02 -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 KAA13036 for ; Fri, 12 Nov 2004 10:34:59 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdTQ-0002nX-E0 for v6tc@ietf.org; Fri, 12 Nov 2004 10:36:29 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACFYOY22646; Fri, 12 Nov 2004 17:34:26 +0200 Date: Fri, 12 Nov 2004 17:34:24 +0200 (EET) From: Pekka Savola To: Jeroen Massar Subject: Re: [v6tc] v6tc draft charter discussion In-Reply-To: <1100272598.22942.29.camel@firenze.zurich.ibm.com> Message-ID: References: <1100272598.22942.29.camel@firenze.zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Fri, 12 Nov 2004, Jeroen Massar wrote: > On Fri, 2004-11-12 at 16:06 +0200, Pekka Savola wrote: >> Hi, >> >> (If folks don't mind, I'll try to ensure that the process is moving >> forward until WG chair(s) is appointed or someone else steps up..) > > Pekka, you are already doing a great job for v6ops, and as this WG is a > spin-off and mostly related to v6ops it would be IMHO a good idea to > have the same chairs, so that they can better overview the work. > Of course, if you have the time etc to do it. Let's make this straight: I *don't* want to chair this working group :). I'll rather be a technical contributor only. At this point, I was just trying to make sure that something keeps happening with this proposed WG until someone gets the more official responsibility to do that.. > >> (1) Based on the input documents, gain rough consensus on at most >> *one* to-be-standardized approach to fit these goals. >> >> (2) Work on two components of the solution: >> a) method to discover the tunnel end-point; and >> b) the specification of the tunnel set-up protocol. > > psst, you forget: > > c) The specification of the tunneling protocol (when it is a new one) Hmm. Maybe the charter should use a bit more generic language to make it possible to include an encapsulation as well, if that's deemed necessary.. without having to call it out explicitly, conditionally as you suggested. > also I assume with "set-up" you mean "optional negotiation and > configuration". That may mean negotiation or configuration; that is not a requirement for the solution. Basically b) was meant to mean "how a v6-in-v4[udp] is set up at the both endpoints of the tunnel". That might also include specification or guidance on how to get IPv6 addresses and possibly other information on top of that link. Again, there are multiple ways to achieve that, so the charter wording should probably be sufficiently generic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 11:24:27 2004 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 LAA17152; Fri, 12 Nov 2004 11:24:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeFI-00040p-DO; Fri, 12 Nov 2004 11:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeCU-0007Kq-Df; Fri, 12 Nov 2004 11:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdyB-0003IQ-Kh for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 11:08:15 -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 LAA15776 for ; Fri, 12 Nov 2004 11:08:12 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdzZ-0003cA-UH for v6tc@ietf.org; Fri, 12 Nov 2004 11:09:42 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iACG84Gn010135; Fri, 12 Nov 2004 16:08:04 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA19783; Fri, 12 Nov 2004 16:08:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iACG83h18547; Fri, 12 Nov 2004 16:08:03 GMT Date: Fri, 12 Nov 2004 16:08:03 +0000 From: Tim Chown To: Pekka Savola Subject: Re: [v6tc] v6tc draft charter discussion Message-ID: <20041112160803.GB17725@login.ecs.soton.ac.uk> References: <1100272598.22942.29.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Fri, Nov 12, 2004 at 05:34:24PM +0200, Pekka Savola wrote: > > Hmm. Maybe the charter should use a bit more generic language to make > it possible to include an encapsulation as well, if that's deemed > necessary.. without having to call it out explicitly, conditionally as > you suggested. Sounds fine. > That might also include specification or guidance on how to get IPv6 > addresses and possibly other information on top of that link. Again, > there are multiple ways to achieve that, so the charter wording should > probably be sufficiently generic. Ditto. Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 17:13:14 2004 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 RAA06299; Fri, 12 Nov 2004 17:13:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjgt-00031E-VH; Fri, 12 Nov 2004 17:14:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjaj-0005lX-IT; Fri, 12 Nov 2004 17:08:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjYy-0005CS-Jn for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 17:06:36 -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 RAA05975 for ; Fri, 12 Nov 2004 17:06:33 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjaP-0002f4-F4 for v6tc@ietf.org; Fri, 12 Nov 2004 17:08:06 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iACM6XGn021769 for ; Fri, 12 Nov 2004 22:06:33 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA29627 for ; Fri, 12 Nov 2004 22:06:28 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iACM6Sq26877 for v6tc@ietf.org; Fri, 12 Nov 2004 22:06:28 GMT Date: Fri, 12 Nov 2004 22:06:28 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: [v6tc] v6tc draft charter discussion Message-ID: <20041112220627.GE25815@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Fri, Nov 12, 2004 at 04:06:54PM +0200, Pekka Savola wrote: > > IPv6 Tunneling Configuration (v6tc) WG > ====================================== I agree with the charter. > List of documents to be used as input to the WG: > > http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt > draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt > draft-ietf-v6ops-assisted-tunneling-requirements-01.txt > draft-palet-v6ops-tun-auto-disc-02.txt There is much overlap in these documents. I would like to know if you feel we can converge to 1 or 2 goals/tradeoofs documents, rather than four? I know 3gpp wants something now, but I still feel this could be achieved as one subsection of a general text, citing which specific requirements 3gpp has, rather than a separate doc. Duplicating and then editing from the duplicates is likely to lead to inconsistencies, at the very least. > Goals and Milestones: These do seem optimistic, but we can try :) -- Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 12 17:32:10 2004 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 RAA07484; Fri, 12 Nov 2004 17:32:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjzA-0003s4-Ml; Fri, 12 Nov 2004 17:33:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjsd-00063U-0J; Fri, 12 Nov 2004 17:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjmx-0000yj-2Z for v6tc@megatron.ietf.org; Fri, 12 Nov 2004 17:21:03 -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 RAA06689 for ; Fri, 12 Nov 2004 17:21:00 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjoP-0003IT-1R for v6tc@ietf.org; Fri, 12 Nov 2004 17:22:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACMKPn00828; Sat, 13 Nov 2004 00:20:25 +0200 Date: Sat, 13 Nov 2004 00:20:24 +0200 (EET) From: Pekka Savola To: Tim Chown Subject: Re: [v6tc] v6tc draft charter discussion In-Reply-To: <20041112220627.GE25815@login.ecs.soton.ac.uk> Message-ID: References: <20041112220627.GE25815@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Fri, 12 Nov 2004, Tim Chown wrote: >> List of documents to be used as input to the WG: >> >> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt >> draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt >> draft-ietf-v6ops-assisted-tunneling-requirements-01.txt >> draft-palet-v6ops-tun-auto-disc-02.txt > > There is much overlap in these documents. I would like to know if you feel > we can converge to 1 or 2 goals/tradeoofs documents, rather than four? [...] FWIW, I think because we need to update the material in any case, it also makes sense to merge the first three. The key here is to just to avoid putting too much work into the documents, trying to make them perfect and waiting for them to finalize before starting the real work.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 07:00:18 2004 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 HAA19949; Tue, 16 Nov 2004 07:00:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU22e-0003MF-Jz; Tue, 16 Nov 2004 07:02:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU200-0007OC-2x; Tue, 16 Nov 2004 06:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU1yv-0007GC-KB for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 06:58:45 -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 GAA19851 for ; Tue, 16 Nov 2004 06:58:43 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU217-0003JO-QV for v6tc@ietf.org; Tue, 16 Nov 2004 07:01:02 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAGBwgP03886 for ; Tue, 16 Nov 2004 13:58:42 +0200 (EET) X-Scanned: Tue, 16 Nov 2004 14:00:00 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAGC00u0017156 for ; Tue, 16 Nov 2004 14:00:00 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 004traNM; Tue, 16 Nov 2004 13:59:59 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAGBd7a16247 for ; Tue, 16 Nov 2004 13:39:08 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 13:39:08 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 13:39:08 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.64 172.21.155.64 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15564.ntc.nokia.com by ESEBE054.noe.nokia.com; 16 Nov 2004 13:39:07 +0200 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6tc@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 16 Nov 2004 13:39:07 +0200 X-OriginalArrivalTime: 16 Nov 2004 11:39:08.0129 (UTC) FILETIME=[E22A8510:01C4CBD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [v6tc] v6tc - is there life X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hello, as you may have heard in the IETF meeting the Internet AD (Margaret) encouraged the WG to start working. This would be a clear indication that the work is needed and there is enough interest. I would like to hear from the possible-future-wg two things: 1) Should we still work on the requirements or do the current three requirements shape the goal enough? (draft-ietf-v6ops-assisted-tunneling-requirements, draft-nielsen-v6ops-3GPP-zeroconf-goals, draft-suryanarayanan-v6ops-zeroconf-reqs) 2) Do people have proposals for solutions? Personally, I think the three requirements documents should give us the guidance for being able to start the solution work. I guess, the question is more do we want to compile them into one document or do three of them separately give the best guidance. Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 08:23:11 2004 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 IAA27288; Tue, 16 Nov 2004 08:23:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3Kq-0005Mw-Eh; Tue, 16 Nov 2004 08:25:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3HY-0002wf-Ta; Tue, 16 Nov 2004 08:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3ED-0002WE-5H for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 08:18:37 -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 IAA27014 for ; Tue, 16 Nov 2004 08:18:36 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3GP-0005IT-L1 for v6tc@ietf.org; Tue, 16 Nov 2004 08:20:54 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAGDI2u13607; Tue, 16 Nov 2004 15:18:02 +0200 Date: Tue, 16 Nov 2004 15:18:02 +0200 (EET) From: Pekka Savola To: "Soininen Jonne (Nokia-NET/Helsinki)" Subject: Re: [v6tc] v6tc - is there life In-Reply-To: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> Message-ID: References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi, On Tue, 16 Nov 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > I would like to hear from the possible-future-wg two things: > > 1) Should we still work on the requirements or do the current three > requirements shape the goal enough? > (draft-ietf-v6ops-assisted-tunneling-requirements, > draft-nielsen-v6ops-3GPP-zeroconf-goals, > draft-suryanarayanan-v6ops-zeroconf-reqs) I'd say yes, though we shouldn't get stuck on details, and we shouldn't wait for the completetion of this summarization to move forward. (I've actually already polled the people "behind" the existing documents whether they'd want to revise it, and it seems this should already be in some progress.) > 2) Do people have proposals for solutions? > > Personally, I think the three requirements documents should give us the > guidance for being able to start the solution work. I guess, the > question is more do we want to compile them into one document or do > three of them separately give the best guidance. Yes ;-). We need not wait for the requirements document though. Florent, Alain D., Karen and myself talked a bit about different solution approaches, and will likely be posting some rough ideas for the folks to give feedback on to the list within a week or so. Jordi also ndicated he'd be updating the tunnel endpoint discovery documents shortly to incorporate the latest analysis and discussion. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 09:20:55 2004 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 JAA01757; Tue, 16 Nov 2004 09:20:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4Ej-0006UP-Vg; Tue, 16 Nov 2004 09:23:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU49f-0001yM-3a; Tue, 16 Nov 2004 09:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU43z-0000rw-8i for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 09:12:07 -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 JAA01042 for ; Tue, 16 Nov 2004 09:12:05 -0500 (EST) Received: from smtp5.wanadoo.fr ([193.252.22.26] helo=mwinf0508.wanadoo.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU462-0006Hi-JE for v6tc@ietf.org; Tue, 16 Nov 2004 09:14:24 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0508.wanadoo.fr (SMTP Server) with SMTP id 372551800081; Tue, 16 Nov 2004 15:11:25 +0100 (CET) Received: from Rmi (APuteaux-105-1-3-93.w80-11.abo.wanadoo.fr [80.11.85.93]) by mwinf0508.wanadoo.fr (SMTP Server) with ESMTP id A7C06180012E; Tue, 16 Nov 2004 15:11:24 +0100 (CET) Message-ID: <003001c4cbe6$2f1ad220$0200a8c0@Rmi> From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= To: "Soininen Jonne (Nokia-NET/Helsinki)" , References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> Subject: Re: [v6tc] v6tc - is there life Date: Tue, 16 Nov 2004 15:11:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA01042 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Comment below R=E9mi Despr=E9s ----- Original Message -----=20 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: Sent: Tuesday, November 16, 2004 12:39 PM Subject: [v6tc] v6tc - is there life > Hello, > > as you may have heard in the IETF meeting the Internet AD (Margaret) > encouraged the WG to start working. This would be a clear indication > that the work is needed and there is enough interest. > I would like to hear from the possible-future-wg two things: > > 1) Should we still work on the requirements or do the current three > requirements shape the goal enough? > (draft-ietf-v6ops-assisted-tunneling-requirements, > draft-nielsen-v6ops-3GPP-zeroconf-goals, > draft-suryanarayanan-v6ops-zeroconf-reqs) > Yes we should (but the work on solutions can start). Imho, there are still some significant needs which are not covered yet. (See in particular my past contribution http://ops.ietf.org/lists/v6ops/v6ops.2004/msg01761.html ) > > 2) Do people have proposals for solutions? > > Personally, I think the three requirements documents should give us the > guidance for being able to start the solution work. I guess, the > question is more do we want to compile them into one document or do > three of them separately give the best guidance. > > Cheers, > > Jonne. > --=20 > Jonne Soininen > Nokia > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 13:45:41 2004 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 NAA28693; Tue, 16 Nov 2004 13:45:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8N0-0004cj-JS; Tue, 16 Nov 2004 13:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU85H-0003AJ-7u; Tue, 16 Nov 2004 13:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7xn-0001j5-Nk for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 13:21:59 -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 NAA26751 for ; Tue, 16 Nov 2004 13:21:57 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7zy-00044a-L8 for v6tc@ietf.org; Tue, 16 Nov 2004 13:24:20 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAGILnui026614 for ; Tue, 16 Nov 2004 11:21:49 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7A00MG7B0CT1@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 16 Nov 2004 11:21:49 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7A00H8BB08H4@mail.sun.net> for v6tc@ietf.org; Tue, 16 Nov 2004 11:21:45 -0700 (MST) Date: Tue, 16 Nov 2004 10:21:43 -0800 From: Alain Durand Subject: Re: [v6tc] v6tc - is there life In-reply-to: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> To: "Soininen Jonne (Nokia-NET/Helsinki)" Message-id: <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> X-Spam-Score: 0.0 (/) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT On Nov 16, 2004, at 3:39 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > 1) Should we still work on the requirements or do the current three > requirements shape the goal enough? > (draft-ietf-v6ops-assisted-tunneling-requirements, > draft-nielsen-v6ops-3GPP-zeroconf-goals, > draft-suryanarayanan-v6ops-zeroconf-reqs) I think those 3 documents have served their purpose as is, that is, explain the need for the new wg, so no further work is needed on each one of them separately. However, the new wg would benefit from a combined goals document, as the above docs shared a lot in common and as we discovered the differences are in the access media properties. We should get something soon, before the end of the calendar year, but this should not stop the work in the solution space to start. Parallel to that, the work on the tunnel-end-point discovery goals should advance and integrate the latest proposal so we can have a meaningful discussion on how to implement it. > 2) Do people have proposals for solutions? Yes, there are already severals. However, before jumping the gun and pushing one particular solution, what we need to do is look at the different general avenues and understand the tradeoffs in the solution space. As Pekka mentioned, some people have started analysis work (follow up to what we did in San Diego) and preliminary results should be published as individual submission before January 05. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 14:39:07 2004 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 OAA03711; Tue, 16 Nov 2004 14:39:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9Cj-0005xP-1Z; Tue, 16 Nov 2004 14:41:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU92n-0004fT-B5; Tue, 16 Nov 2004 14:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8td-0003KZ-0O for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 14:21:45 -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 OAA01793 for ; Tue, 16 Nov 2004 14:21:43 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8vr-0005Rk-S6 for v6tc@ietf.org; Tue, 16 Nov 2004 14:24:05 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iAGJLaGn017774 for ; Tue, 16 Nov 2004 19:21:36 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA04359 for ; Tue, 16 Nov 2004 19:21:32 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iAGJLWJ06099 for v6tc@ietf.org; Tue, 16 Nov 2004 19:21:32 GMT Date: Tue, 16 Nov 2004 19:21:32 +0000 From: Tim Chown To: v6tc@ietf.org Subject: Re: [v6tc] v6tc - is there life Message-ID: <20041116192132.GN4961@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 I agree with Alain. 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. Tim On Tue, Nov 16, 2004 at 10:21:43AM -0800, Alain Durand wrote: > > On Nov 16, 2004, at 3:39 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > >1) Should we still work on the requirements or do the current three > >requirements shape the goal enough? > >(draft-ietf-v6ops-assisted-tunneling-requirements, > >draft-nielsen-v6ops-3GPP-zeroconf-goals, > >draft-suryanarayanan-v6ops-zeroconf-reqs) > > I think those 3 documents have served their purpose as is, that is, > explain > the need for the new wg, so no further work is needed on each one of > them separately. > However, the new wg would benefit from a combined goals document, > as the above docs shared a lot in common and as we discovered the > differences > are in the access media properties. > We should get something soon, before the end of the calendar year, > but this should not stop the work in the solution space to start. > > Parallel to that, the work on the tunnel-end-point discovery goals > should advance and integrate > the latest proposal so we can have a meaningful discussion on how to > implement it. > > >2) Do people have proposals for solutions? > > Yes, there are already severals. However, before jumping the gun and > pushing one particular > solution, what we need to do is look at the different general avenues > and understand > the tradeoffs in the solution space. As Pekka mentioned, some people > have started analysis work > (follow up to what we did in San Diego) and preliminary results should > be published > as individual submission before January 05. > > - Alain. > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Tim _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 15:38:16 2004 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 PAA10512; Tue, 16 Nov 2004 15:38:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUA7z-0007PF-0s; Tue, 16 Nov 2004 15:40:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUA53-0000S3-AQ; Tue, 16 Nov 2004 15:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUA1d-0007Do-Is for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 15:34:05 -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 PAA10054 for ; Tue, 16 Nov 2004 15:34:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUA3r-0007Jg-2N for v6tc@ietf.org; Tue, 16 Nov 2004 15:36:26 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAGKXJ123809; Tue, 16 Nov 2004 22:33:21 +0200 Date: Tue, 16 Nov 2004 22:33:19 +0200 (EET) From: Pekka Savola To: Tim Chown Subject: Re: [v6tc] v6tc - is there life In-Reply-To: <20041116192132.GN4961@login.ecs.soton.ac.uk> Message-ID: References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Tue Nov 16 20:15:02 2004 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 UAA19322; Tue, 16 Nov 2004 20:15:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUERp-0001Cr-U0; Tue, 16 Nov 2004 20:17:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUECv-0004k3-PB; Tue, 16 Nov 2004 20:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUEBJ-000492-6o for v6tc@megatron.ietf.org; Tue, 16 Nov 2004 20:00:21 -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 UAA17769 for ; Tue, 16 Nov 2004 20:00:20 -0500 (EST) Received: from webmail.ict.ac.cn ([159.226.39.7] helo=ict.ac.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUEDR-0000oK-P5 for v6tc@ietf.org; Tue, 16 Nov 2004 20:02:45 -0500 Received: (qmail 16097 invoked by uid 507); 17 Nov 2004 00:29:10 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 17 Nov 2004 00:29:10 -0000 From: "Liu Min" To: , Date: Wed, 17 Nov 2004 08:59:31 +0800 Message-ID: <00cd01c4cc40$b270b2c0$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CE_01C4CC83.C093F2C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [v6tc] FW: I-D ACTION:draft-liumin-v6ops-silkroad-02.txt X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C4CC83.C093F2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: There is a new version of the draft silkroad. Compared with the previous version, there are the main changes: 1. Change the model of Silkroad. SN (silkroad navigator) will not = receive SC (silkroad client)'s request by http, and will not assign SAR = (silkroad access router) for SC. There will be no direct interaction between SC = and SN. 2. The authentication and coherence for SARs and SNs in one ISP will = follow the specific ISP's security and route consideration and existing = mechanisms. There will be no automatic synchronization and interaction between SARs = and SNs belonging to different ISPs, unless there are prior agreements. Generally, the packet forwarding between SARs belonging to different = ISPs will follow IPv6 rules and no route optimization could be made. =20 3. Explicitly indicate that SN is recommended for ISP whose SARs are relatively few. However, it is mandatory for ISP who has many SARs and = SCs. There may be hierarchical SNs for one ISP.=20 4. Explicitly indicate that Silkroad is one mechanism to be used by the = ISP to provide a managed tunnel work through NATs to its customers. 5. Remove the component in the protocol for requesting an arbitrary = length. The default prefix length will be a /64. Whether providing an arbitrary length prefix will be up to the specific ISP's policy and business = process. The ISP may require prior agreement for special requirements. 6. Remove Control Option type to determine the transmission method = between SARs and leave the choice to ISP. 7. Change the transmission process between SC and regular node in 4.2.4 = and 4.2.5 change all the figures in this draft.=20 8. Add the consideration of mobility support in 7.3. 9. Move the comparison with Teredo to Appendix A and add the comparison with tunnel broker solutions. 10. Indicate that route optimization is optional and ISPs could decide whether to support route optimization for their Silkroad clients. = Generally, route optimization will only be done between SCs belonging to the same = ISP, unless there are prior agreements between different ISPs. =20 Any comments will be appreciated. =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, November 17, 2004 5:13 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-liumin-v6ops-silkroad-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tunneling IPv6 with private IPv4 addresses=20 behind NAT devices Author(s) : L. Min, et al. Filename : draft-liumin-v6ops-silkroad-02.txt Pages : 24 Date : 2004-11-16 =09 The growth of IPv6 networks started mainly using the transport = facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. However, classic tunneling methods do not work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device. We propose here a service, = called Silkroad, to enable nodes located behind one or several IPv4 NATs to = obtain IPv6 connectivity. It can provide IPv6 connectivity through all existing = NAT types and does not require any update of them. In addition, Silkroad = could provide managed IPv6 prefixes with path optimized routing directly = between clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liumin-v6ops-silkroad-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-liumin-v6ops-silkroad-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-liumin-v6ops-silkroad-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_00CE_01C4CC83.C093F2C0 Content-Type: Message/External-body; name="ATT00120.dat" Content-Disposition: attachment; filename="ATT00120.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-11-16113036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liumin-v6ops-silkroad-02.txt ------=_NextPart_000_00CE_01C4CC83.C093F2C0 Content-Type: Message/External-body; name="draft-liumin-v6ops-silkroad-02.txt" Content-Disposition: attachment; filename="draft-liumin-v6ops-silkroad-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-11-16113036.I-D@ietf.org> ------=_NextPart_000_00CE_01C4CC83.C093F2C0 Content-Type: text/plain; name="ATT00123.txt" Content-Disposition: attachment; filename="ATT00123.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_00CE_01C4CC83.C093F2C0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc ------=_NextPart_000_00CE_01C4CC83.C093F2C0-- From v6tc-bounces@ietf.org Wed Nov 17 01:17:07 2004 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 BAA15684; Wed, 17 Nov 2004 01:17:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJAE-0007yY-CC; Wed, 17 Nov 2004 01:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJ34-0002pJ-UY; Wed, 17 Nov 2004 01:12:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUIxy-0001K6-71 for v6tc@megatron.ietf.org; Wed, 17 Nov 2004 01:06:54 -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 BAA14689 for ; Wed, 17 Nov 2004 01:06:53 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJ08-0007lc-Nx for v6tc@ietf.org; Wed, 17 Nov 2004 01:09:20 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAH66fNH010694 for ; Tue, 16 Nov 2004 23:06:41 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7B00ATR7N4KW@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Tue, 16 Nov 2004 23:06:40 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7B00D3D7N2HK@mail.sun.net> for v6tc@ietf.org; Tue, 16 Nov 2004 23:06:39 -0700 (MST) Date: Tue, 16 Nov 2004 22:06:37 -0800 From: Alain Durand Subject: Re: [v6tc] FW: I-D ACTION:draft-liumin-v6ops-silkroad-02.txt In-reply-to: <00cd01c4cc40$b270b2c0$4b74a8c0@ThinkPadX31> To: Liu Min Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <00cd01c4cc40$b270b2c0$4b74a8c0@ThinkPadX31> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Thank you for your submission. In my personal opinion, Silkroad is a fairly complex model, and a lot of the complexity is rooted in the desire to enable direct communication between two silknodes within the same ISP. However, in the v6tc case, such direct communication has not been identified as a required component. IMHO, it would actually help the v6tc discussions if you could separate the tunnel set-up part between the SC and the SAR from the rest of the silkroad model. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Nov 17 02:18:12 2004 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 CAA04673; Wed, 17 Nov 2004 02:18:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUK7L-0000hk-Tz; Wed, 17 Nov 2004 02:20:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJzQ-0008Ax-4k; Wed, 17 Nov 2004 02:12:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJxU-0007H6-H0 for v6tc@megatron.ietf.org; Wed, 17 Nov 2004 02:10:28 -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 CAA27425 for ; Wed, 17 Nov 2004 02:10:26 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJzp-0000Z2-P1 for v6tc@ietf.org; Wed, 17 Nov 2004 02:12:55 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAH7ALF04941; Wed, 17 Nov 2004 09:10:22 +0200 (EET) X-Scanned: Wed, 17 Nov 2004 09:09:14 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAH79ESC029917; Wed, 17 Nov 2004 09:09:14 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00swkXkP; Wed, 17 Nov 2004 09:08:55 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAH78ra11394; Wed, 17 Nov 2004 09:08:53 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 09:08:40 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 09:08:39 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Nov 2004 09:08:40 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.64 172.21.155.64 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15564.ntc.nokia.com by ESEBE054.noe.nokia.com; 17 Nov 2004 09:08:39 +0200 Subject: Re: [v6tc] v6tc - is there life From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola In-Reply-To: References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 17 Nov 2004 09:08:39 +0200 X-OriginalArrivalTime: 17 Nov 2004 07:08:40.0324 (UTC) FILETIME=[440DBC40:01C4CC74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hello, in the interest of time, I would propose that a *simple* goals document is written that comprises the requirements from all three requirements documents. This is then used as a guideline when designing the protocol. Also I'm a bit afraid if we start elaborated requirements/analysis/gap analysis/etc. this project will take number of years or we don't even wg started as we cannot show that we really need this new protocol. Basically, I propose that we combine the current requirements to a single document that the authors of the current document do together - in fairly short time. Parallel to that people would submit their protocol proposals as Internet-Drafts. Then we just do a quick analysis on the mailing list of the protocols vs. the requirements and choose the one that seems to be the best fit as a *baseline* document. After that it's just work, which is of course easy... ;) Cheers, Jonne. On Tue, 2004-11-16 at 22:33, ext 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? -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Wed Nov 17 08:38:24 2004 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 ; 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: References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> 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 Subject: Re: [v6tc] v6tc - is there life Date: Wed, 17 Nov 2004 11:27:46 +0100 To: Pekka Savola 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: , List-Archive: List-Post: List-Help: List-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 From v6tc-bounces@ietf.org Wed Nov 17 12:50:01 2004 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 MAA24239; Wed, 17 Nov 2004 12:50:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTyu-0007Yu-OV; Wed, 17 Nov 2004 12:52:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTqM-0002wB-2S; Wed, 17 Nov 2004 12:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUToB-0002OO-Nj for v6tc@megatron.ietf.org; Wed, 17 Nov 2004 12:41:34 -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 MAA23530 for ; Wed, 17 Nov 2004 12:41:28 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTqR-0007N3-Ko for v6tc@ietf.org; Wed, 17 Nov 2004 12:44:04 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAHHfINH012665 for ; Wed, 17 Nov 2004 10:41:18 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7C00AQF3STKW@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Wed, 17 Nov 2004 10:41:17 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7C00AQY3SSY8@mail.sun.net> for v6tc@ietf.org; Wed, 17 Nov 2004 10:41:17 -0700 (MST) Date: Wed, 17 Nov 2004 09:41:14 -0800 From: Alain Durand Subject: Re: [v6tc] v6tc - is there life In-reply-to: <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> To: "Soininen Jonne (Nokia-NET/Helsinki)" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7BIT On Nov 16, 2004, at 11:08 PM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > Hello, > > in the interest of time, I would propose that a *simple* goals document > is written that comprises the requirements from all three requirements > documents. This is then used as a guideline when designing the > protocol. > Also I'm a bit afraid if we start elaborated requirements/analysis/gap > analysis/etc. this project will take number of years or we don't even > wg > started as we cannot show that we really need this new protocol. > > Basically, I propose that we combine the current requirements to a > single document that the authors of the current document do together - > in fairly short time. Parallel to that people would submit their > protocol proposals as Internet-Drafts. This is the process I have described in my previous mail, where things will get done in parallel. However, one should not confuse speed with rush, and there are serious tradeoff to consider in the different avenues in the solution space, and it is worth spending some time (a couple months at most) looking at them. This, of course, should not stop people from submitting their protocol proposal as individual ID. > Then we just do a quick analysis on the mailing list of the protocols > vs. the requirements and choose the one that seems to be the best fit > as > a *baseline* document. There is no such thing as a "quick analysis on the mailing list", you know that. - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 03:47:43 2004 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 DAA01662; Thu, 18 Nov 2004 03:47:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhzl-0003jH-NZ; Thu, 18 Nov 2004 03:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUhw7-0006Lj-5d; Thu, 18 Nov 2004 03:46:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUhuP-0005vK-MI for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 03:44:54 -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 DAA01443 for ; Thu, 18 Nov 2004 03:44:51 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhwi-0003er-R6 for v6tc@ietf.org; Thu, 18 Nov 2004 03:47:34 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAI8iWR2020905 for ; Thu, 18 Nov 2004 09:44:32 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 09:44:32 +0100 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVXGSSS; Thu, 18 Nov 2004 09:44:32 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Nov 2004 09:44:31 +0100 Message-ID: X-Sybari-Trust: 862ceb0e bfd556f1 47c125ae 00000139 From: "Karen E. Nielsen (AH/LMD)" To: "'Kurt Erik Lindqvist'" , Pekka Savola , "'Tim Chown'" Subject: RE: [v6tc] v6tc - is there life Date: Thu, 18 Nov 2004 09:44:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 Nov 2004 08:44:32.0345 (UTC) FILETIME=[D2F03C90:01C4CD4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable I think that it is important to have scenario specific sections where = the finer points of the various requirements vis-=E0-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=20 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: v6tc-bounces@ietf.org [mailto:v6tc-bounces@ietf.org]On Behalf = Of > Kurt Erik Lindqvist > Sent: Wednesday, November 17, 2004 11:28 AM > To: Pekka Savola > Cc: v6tc@ietf.org > Subject: Re: [v6tc] v6tc - is there life >=20 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On 2004-11-16, at 21.33, Pekka Savola wrote: >=20 > > 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=20 > >> whether > >> the requirements are may/should/must. > >> > >> We shouldn't repeat the "confusion" of scattering=20 > requirements in the > >> scenarios text. > > > > What would you feel about putting the scenario-specific=20 > justifications=20 > > inside the requirements, so that the requirements would be better=20 > > grounded in the reality? > > >=20 > I like Tim's approach above. I think that would give a easy=20 > to read and=20 > clear document. >=20 > - - kurtis - >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 >=20 > iQA/AwUBQZsnqKarNKXTPFCVEQLfHACglcgohp1XjqLaOUu3g9k6zwjPFCsAn1gs > AGNzz7gknfsuz4Rzz/ffsLEK > =3D8u0f > -----END PGP SIGNATURE----- >=20 >=20 > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc >=20 _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 03:59:18 2004 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 DAA02176; Thu, 18 Nov 2004 03:59:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUiAy-0003uJ-Qj; Thu, 18 Nov 2004 04:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUi7k-00007x-IW; Thu, 18 Nov 2004 03:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUi3Y-0007qo-SE for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 03:54:21 -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 DAA02011 for ; Thu, 18 Nov 2004 03:54:18 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUi68-0003od-Ee for v6tc@ietf.org; Thu, 18 Nov 2004 03:57:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAI8rHv10091; Thu, 18 Nov 2004 10:53:17 +0200 Date: Thu, 18 Nov 2004 10:53:17 +0200 (EET) From: Pekka Savola To: "Karen E. Nielsen (AH/LMD)" Subject: RE: [v6tc] v6tc - is there life In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 04:09:43 2004 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 EAA03061; Thu, 18 Nov 2004 04:09:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUiL4-0004Eg-0z; Thu, 18 Nov 2004 04:12:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUiGL-00028W-OV; Thu, 18 Nov 2004 04:07:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUiF5-0001wA-P7 for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 04:06:15 -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 EAA02762 for ; Thu, 18 Nov 2004 04:06:13 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUiHW-0004Aj-21 for v6tc@ietf.org; Thu, 18 Nov 2004 04:08:56 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAI964R2029431 for ; Thu, 18 Nov 2004 10:06:04 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 10:06:04 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVXGZCY; Thu, 18 Nov 2004 10:06:04 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Nov 2004 10:06:03 +0100 Message-ID: X-Sybari-Trust: 9fcda551 bfd556f1 47c125ae 00000139 From: "Karen E. Nielsen (AH/LMD)" To: "'Pekka Savola'" Subject: RE: [v6tc] v6tc - is there life Date: Thu, 18 Nov 2004 10:05:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Nov 2004 09:06:04.0158 (UTC) FILETIME=[D4EB41E0:01C4CD4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Pekka, I can live with what you suggest, provided that the should and mays are made deployment scenario specific, i.e. (which I think was what you said in an earlier mail, anyway, though this mail made me doubt it a little bit). Which of the various requirements that a potential solution supports will be described in a trade-off document, not in the requirements document as such, I suppose ? BR, Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, November 18, 2004 9:53 AM > To: Karen E. Nielsen (AH/LMD) > Cc: 'Kurt Erik Lindqvist'; 'Tim Chown'; v6tc@ietf.org > Subject: RE: [v6tc] v6tc - is there life > > > 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 > _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 13:28:07 2004 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 NAA19236; Thu, 18 Nov 2004 13:28:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUr3Y-0008H4-Cs; Thu, 18 Nov 2004 13:30:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqst-0002mE-9b; Thu, 18 Nov 2004 13:19:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqiV-0008EO-IL for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 13:09:11 -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 NAA17798 for ; Thu, 18 Nov 2004 13:09:08 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqkz-0007pV-T8 for v6tc@ietf.org; Thu, 18 Nov 2004 13:11:57 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAII8xun027727 for ; Thu, 18 Nov 2004 11:08:59 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7D00ELBZQYJN@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 18 Nov 2004 11:08:59 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7D00AJHZQXJR@mail.sun.net> for v6tc@ietf.org; Thu, 18 Nov 2004 11:08:58 -0700 (MST) Date: Thu, 18 Nov 2004 10:08:55 -0800 From: Alain Durand Subject: Re: [v6tc] v6tc - is there life In-reply-to: To: "Karen E. Nielsen (AH/LMD)" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT On Nov 18, 2004, at 12:44 AM, 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. 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. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 14:03:08 2004 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 OAA22104; Thu, 18 Nov 2004 14:03:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrbQ-0000eL-I3; Thu, 18 Nov 2004 14:05:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrIF-0000kd-5d; Thu, 18 Nov 2004 13:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrAs-0006AQ-0A for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 13:38:30 -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 NAA19973 for ; Thu, 18 Nov 2004 13:38:28 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrDW-0008Tp-Lo for v6tc@ietf.org; Thu, 18 Nov 2004 13:41:16 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIIcNv04913; Thu, 18 Nov 2004 20:38:24 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 20:38:11 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAIIcBsW007159; Thu, 18 Nov 2004 20:38:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00drY7MX; Thu, 18 Nov 2004 20:38:09 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIIc9S20494; Thu, 18 Nov 2004 20:38:09 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 20:38:07 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 20:38:06 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.64 172.21.155.64 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15564.ntc.nokia.com by ESEBE054.noe.nokia.com; 18 Nov 2004 20:38:07 +0200 Subject: Re: [v6tc] v6tc - is there life From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Alain Durand In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100803086.4434.55.camel@essrv103nok15564.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 18 Nov 2004 20:38:07 +0200 X-OriginalArrivalTime: 18 Nov 2004 18:38:06.0813 (UTC) FILETIME=[BED0C8D0:01C4CD9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit 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. On Thu, 2004-11-18 at 20:08, ext Alain Durand wrote: > On Nov 18, 2004, at 12:44 AM, 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. > > 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. > > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 14:40:35 2004 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 OAA25347; Thu, 18 Nov 2004 14:40:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsBf-0001Ur-Ax; Thu, 18 Nov 2004 14:43:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUs2W-0005GA-GJ; Thu, 18 Nov 2004 14:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrrN-0002V5-Oa for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 14:22:25 -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 OAA23610 for ; Thu, 18 Nov 2004 14:22:23 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUru0-00016p-NY for v6tc@ietf.org; Thu, 18 Nov 2004 14:25:12 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIJIWF20997; Thu, 18 Nov 2004 21:18:33 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 21:20:45 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAIJKjL9008865; Thu, 18 Nov 2004 21:20:45 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00XdasFj; Thu, 18 Nov 2004 21:20:43 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIJIQa02071; Thu, 18 Nov 2004 21:18:26 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 21:17:17 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 21:17:17 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.64 172.21.155.64 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15564.ntc.nokia.com by ESEBE054.noe.nokia.com; 18 Nov 2004 21:17:17 +0200 Subject: Re: [v6tc] v6tc - is there life From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Alain Durand In-Reply-To: References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100805436.4434.96.camel@essrv103nok15564.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 18 Nov 2004 21:17:17 +0200 X-OriginalArrivalTime: 18 Nov 2004 19:17:17.0301 (UTC) FILETIME=[37D0CA50:01C4CDA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Alain, On Wed, 2004-11-17 at 19:41, ext Alain Durand wrote: > On Nov 16, 2004, at 11:08 PM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > > Hello, > > > > in the interest of time, I would propose that a *simple* goals document > > is written that comprises the requirements from all three requirements > > documents. This is then used as a guideline when designing the > > protocol. > > Also I'm a bit afraid if we start elaborated requirements/analysis/gap > > analysis/etc. this project will take number of years or we don't even > > wg > > started as we cannot show that we really need this new protocol. > > > > Basically, I propose that we combine the current requirements to a > > single document that the authors of the current document do together - > > in fairly short time. Parallel to that people would submit their > > protocol proposals as Internet-Drafts. > > This is the process I have described in my previous mail, where things > will get done in parallel. However, one should not confuse speed with > rush, > and there are serious tradeoff to consider in the different avenues in > the solution > space, and it is worth spending some time (a couple months at most) > looking at them. > This, of course, should not stop people from submitting their protocol > proposal > as individual ID. I do too agree, but still a little disagree. I think we have looked at these requirements quite long already and they should be in pretty good shape in general. Now we just have to take out the conflicts - if any. Anyways, I think somebody said that in requirements work it's (generally) better to look at the intersection of the requirements and not the union of the requirements. This may somewhat apply here as well. > > > Then we just do a quick analysis on the mailing list of the protocols > > vs. the requirements and choose the one that seems to be the best fit > > as > > a *baseline* document. > > There is no such thing as a "quick analysis on the mailing list", you > know that. Alain, maybe I stated too strongly my wish to do the analysis relatively quickly and painlessly. I don't want to start another two year project of scenarios and analysis. Cheers, Jonne. > > - Alain. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Thu Nov 18 14:56:10 2004 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 OAA27391; Thu, 18 Nov 2004 14:56:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsQl-0001rf-1l; Thu, 18 Nov 2004 14:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsHp-00089v-NW; Thu, 18 Nov 2004 14:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsBQ-0006qJ-ID for v6tc@megatron.ietf.org; Thu, 18 Nov 2004 14:43:08 -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 OAA25602 for ; Thu, 18 Nov 2004 14:43:06 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsE5-0001X8-P7 for v6tc@ietf.org; Thu, 18 Nov 2004 14:45:55 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAIJh6Vu015039 for ; Thu, 18 Nov 2004 12:43:06 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I7E00EAV43TJN@edgemail1.Central.Sun.COM> for v6tc@ietf.org; Thu, 18 Nov 2004 12:43:06 -0700 (MST) Received: from [192.168.1.2] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I7E00EKD43QVV@mail.sun.net> for v6tc@ietf.org; Thu, 18 Nov 2004 12:43:05 -0700 (MST) Date: Thu, 18 Nov 2004 11:42:59 -0800 From: Alain Durand Subject: Re: [v6tc] v6tc - is there life In-reply-to: <1100805436.4434.96.camel@essrv103nok15564.ntc.nokia.com> To: "Soininen Jonne (Nokia-NET/Helsinki)" Message-id: <0D192C02-399A-11D9-B9DD-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1100605147.10092.23.camel@essrv103nok15564.ntc.nokia.com> <5DFA372B-37FC-11D9-96B1-00039376A6AA@sun.com> <20041116192132.GN4961@login.ecs.soton.ac.uk> <1100675319.13315.16.camel@essrv103nok15564.ntc.nokia.com> <1100805436.4434.96.camel@essrv103nok15564.ntc.nokia.com> X-Spam-Score: 0.0 (/) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT On Nov 18, 2004, at 11:17 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > Anyways, I think somebody said that in requirements work it's > (generally) better to look at the intersection of the requirements and > not the union of the requirements. This may somewhat apply here as > well. Agree. >> >>> Then we just do a quick analysis on the mailing list of the protocols >>> vs. the requirements and choose the one that seems to be the best fit >>> as >>> a *baseline* document. >> >> There is no such thing as a "quick analysis on the mailing list", you >> know that. > > Alain, maybe I stated too strongly my wish to do the analysis > relatively > quickly and painlessly. I don't want to start another two year project > of scenarios and analysis. Agree 100%. I'm talking about a few months to understand the spectrum of solution better. Let me briefly show some of the trade-off to analyze, and I really do not want to start a thread now on each of them, but just show that those will be issues to address in the very near future. - Could we live with UDP encapsulation always on? - Do we need mutual authentication? How strong should this be? Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase as finished? - Should we embed some kind of signaling in the tunnel? - Alain. _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc From v6tc-bounces@ietf.org Fri Nov 19 02:18:41 2004 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 CAA26946; Fri, 19 Nov 2004 02:18:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV35A-0004Qi-EB; Fri, 19 Nov 2004 02:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV30x-0005Wk-Bn; Fri, 19 Nov 2004 02:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV2wu-0004Yf-3p for v6tc@megatron.ietf.org; Fri, 19 Nov 2004 02:12:52 -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 CAA22056 for ; Fri, 19 Nov 2004 02:12:50 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV2zV-0004Ij-Pd for v6tc@ietf.org; Fri, 19 Nov 2004 02:15:44 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAJ7CZvD023360 for ; Fri, 19 Nov 2004 08:12:35 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 08:12:33 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFZKPK23; Fri, 19 Nov 2004 08:12:33 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Nov 2004 08:12:33 +0100 Message-ID: X-Sybari-Trust: 035d1ac4 ad48f3dd 011e0ca6 00000179 From: "Karen E. Nielsen (AH/LMD)" To: "'Soininen Jonne (Nokia-NET/Helsinki)'" , ext Alain Durand Subject: RE: [v6tc] v6tc - is there life Date: Fri, 19 Nov 2004 08:12:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 19 Nov 2004 07:12:33.0926 (UTC) FILETIME=[241E1260:01C4CE07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: v6tc@ietf.org X-BeenThere: v6tc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: v6tc.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: v6tc-bounces@ietf.org Errors-To: v6tc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Agree with both of you. I especially agree with providing _qualified_ guidance rather than solid requirements - we are not in a product development process here. There has never been doubt about that we should use the term goals in the document, only when we(I) speak about it we(I) sometimes forget the subtle difference and use the term we(I) are more familiar with. Karen > -----Original Message----- > From: Soininen Jonne (Nokia-NET/Helsinki) > [mailto:jonne.soininen@nokia.com] > Sent: Thursday, November 18, 2004 7:38 PM > To: ext Alain Durand > Cc: Karen E. Nielsen (AH/LMD); v6tc@ietf.org > Subject: Re: [v6tc] v6tc - is there life > > > 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. > > On Thu, 2004-11-18 at 20:08, ext Alain Durand wrote: > > On Nov 18, 2004, at 12:44 AM, 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. > > > > 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. > > > > > > _______________________________________________ > > v6tc mailing list > > v6tc@ietf.org > > https://www1.ietf.org/mailman/listinfo/v6tc > -- > Jonne Soininen > Nokia > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com > _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc